From g.c.prasad@gmail.com Wed Aug 1 14:23:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A511E8377 for ; Wed, 1 Aug 2012 14:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ4gCwHgSHXD for ; Wed, 1 Aug 2012 14:23:53 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 150A111E835C for ; Wed, 1 Aug 2012 14:23:52 -0700 (PDT) Received: by bkty7 with SMTP id y7so4146689bkt.31 for ; Wed, 01 Aug 2012 14:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=/llzuJ0IT0EjUWQT7Vfg2esmetzFT+y6nSpUu14ph6s=; b=pWZVApLUbs+kyT+ktdmLbAn8LViPHFLxb0RW58dC28O8rNXRrKRZE3U26af/md/ad7 1iAtwY+mjeqrC4hRfPXevu6Dt07cPXWMoBT8fmPtSFm4JtYr96B4atJO4Tlxr5b8lb00 WiMBkG4nU2lknqYgel7JlOCmMO+UCODrSVuO8mx5ZPW6zey7t9wY5YfI5YQq5XQWmCCR EkuezB3bZG1ROudX1EU3bd77/obvCAq98EQ5XkGYJFAILAtAXsXWOjX3ELKmVxZYrCau GrP3Rerkxh3trWBkMRJdiNOsz6XdsIEFpxJceyaElGORulLOzF/JQs9ZhUbXZ4KYhLlf 6/Dw== Received: by 10.204.156.87 with SMTP id v23mr7628269bkw.0.1343856231969; Wed, 01 Aug 2012 14:23:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Wed, 1 Aug 2012 14:23:31 -0700 (PDT) From: Ganesh and Sashi Prasad Date: Thu, 2 Aug 2012 07:23:31 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=0015175cba2255f21504c63ae96f Subject: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:23:55 -0000 --0015175cba2255f21504c63ae96f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable (I posted this on the SCIM Google Group, and I was advised to subscribe to the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Management is mainly through a 3-year project at an Australian insurance company, an experience I have written about as a eBook on InfoQ ( http://www.infoq.com/minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience with a loosely-coupled architecture that I found to be successful, I have the following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own internal IDs for a resource, which they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should be exposed through the API. The current specification's provision of an id (which is the external ID and the only one to be transferred through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, modify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major requirement with Identity Management is to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the same. If internal identifiers are revealed to external domains, such clean-ups become difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one created for this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation request, the cloud provider must generate its own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated internal ID of its own. In case the resource already has an identifier within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through the POST response. 2. If a resource is to be created, and one of its attributes is multi-valued, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" ] then on successful creation, the server response should include the representation of the resource, and this attribute should look like this: "email-addrs" : [ { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" }= , { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" }= , { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com" } ] The client now knows what each value is labelled. This now provides an unambiguous way to reference a value to add, modify and delete it: Add: POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs value=3D"js70@easy.com.au" Modify: PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43b9-= 9cda-8646c3085bbf value=3D"john.r.smith@gmail.com" Delete: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4cca-= 9db7-7a6d1de664e1 One can even delete all email addresses like this: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs I believe this is more elegant than what the spec recommends. 3. It's possible to think of the operations POST, PUT and DELETE as nested operations inside a PATCH. PATCH itself need not be nested because its semantics apply throughout the "tree" of a resource. However, the semantics of PUT are a little messy. Also, the use of HTTP verbs at a different level could be confusing. That's why I would recommend 6 separate verbs that are a little more unambiguous in their meaning: 1. INCLUDE (equivalent to POST): Add this resource to a collection and return a generated URI 2. PLACE (equivalent to one form of PUT): Add this resource at the location specified by the accompanying URI. (If there=92s already a value at that location, return an error status.) 3. REPLACE (equivalent to another form of PUT): Replace the value at the location specified by the accompanying URI with this value. (If there=92s n= o such URI, return an error status.) 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. (At the end of this operation, we want the specified URI to hold the accompanying value whether the URI already existed or not.) 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render inaccessible the resource at the specified URI. 6. AMEND (equivalent to PATCH): (This verb is just listed for completeness. We probably don=92t need a nested PATCH since PATCH cascades to every level of the tree.) A PATCH request could therefore look like this: PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Content-length: ... { REPLACE: { "key" : "first-name", "value" : "Jack" }, PLACE : { "key" : "middle-name", "value" : "Richard" }, FORCE : { "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "key" : "address.unit-number", "value" : "12" }, PLACE : { "key" : "address.state", "value" : "SA" }, FORCE : { "key" : "address.country", "value" : "Australia" }, INCLUDE : { "key" : "email-addrs", "value" : "js70@easy.com.au" }, REPLACE : { "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } } The PATCH response should utilise the status code "207 Multi-Status" because the nested operations could have varying status codes. A sample response is below: HTTP/1.1 207 Multi-Status Content-Type: application/json ETag: W/"b431af54f0671a2" Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646= " { "schemas":["urn:scim:schemas:core:1.0"], "external-id":"2819c223-7f76-453a-919d-413861904646", REPLACE: { "status" : "200 OK", "key" : "first-name", "value" : "Jack" }, PLACE : { "status" : "200 OK", "key" : "middle-name", "value" : "Richard" }, FORCE : { "status" : "200 OK", "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "status" : "200 OK", "key" : "address.unit-number", "value" : "12" }, PLACE : { "status" : "200 OK", "key" : "address.state", "value" : "SA" }, FORCE : { "status" : "200 OK", "key" : "address.country", "value" : "Australia" }, INCLUDE : { "status" : "201 Created", "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", "value" : "js70@easy.com.au" }, REPLACE : { "status" : "200 OK", "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "status" : "200 OK", "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", "location":" https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "version":"W\/\"b431af54f0671a2\"" } } If there are errors, they will take the place of the "200 OK" or "201 Created" status codes in the above successful case. But the outer status will remain "207 Multi-Status". The same scheme can be used to deal with operations on members of a group, and for bulk operations. I hope you find these suggestions useful. I read the SCIM spec afresh last week and these ideas came flooding into my head because I have been working at another organisation (a telco) for the last 5 months, also in Identity and Access Management, and my thoughts have moved further along the direction of evolving a specialised data model based on specific principles, especially for IAM. I am planning to write about this and also the data-related principles soon and am in negotiations with InfoQ regarding publication. Regards, Ganesh Prasad --0015175cba2255f21504c63ae96f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
(I posted this on the SCIM Google Group, and I was advised to subscrib= e to the mailing list and post it here instead, so here goes.)
Hi,

My name is Ganesh Prasad, and my = experience in Identity and Access Management is mainly through a 3-year pro= ject at an Australian insurance company, an experience I have written about= as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Sho= estring).

I have been following the SCIM spec off and on, and bas= ed on my experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make.

1. The enterprise client and the cloud provider should maintain their = own internal IDs for a resource, which they should not reveal to each other= . Both of them should map their internal IDs to a shared External ID, and t= his is the only ID that should be exposed through the API. The current spec= ification's provision of an id (which is the external ID and the only o= ne to be transferred through the API) and an "external ID" (which= is the client's internal ID and should be hidden) is diametrically opp= osite to this.

2. When dealing with multi-valued attributes of a resou= rce (expressed as arrays in JSON), they must be converted from an array int= o a dictionary with unique keys (UUIDs generated by the cloud provider when= the attribute is created). Without unique keys for every attribute value o= f a resource, manipulating it will be clumsy and inelegant.

3. The PATCH command can be improved in 3 significant w= ays:
3a. Leverage the fact (from 2 above) that every value has a = key, to greatly simplify the API
3b. Use special verbs as nested = operations of the PATCH command to add, modify and delete attributes at any= level
3c. Use the WebDAV status code of "207 Multi-Status" instead= of "200 OK" as the response to a PATCH (or BULK) command.
<= div>
To elaborate,

1. Revealing priv= ate IDs externally is a form of tight coupling. A major requirement with Id= entity Management is to split (or merge) identities when false positives (o= r false negatives) are detected, i.e., when a resource is discovered to be = more than one, or when multiple resources are detected to be the same. If i= nternal identifiers are revealed to external domains, such clean-ups become= difficult, hence every domain that wants to expose references to a resourc= e must map its internal ID to and external one created for this explicit pu= rpose, and only reveal this.

In the SCIM case, when an enterprise client POSTs a res= ource creation request, the cloud provider must generate its own internal U= UID as well as an external UUID, map them together, and only return the ext= ernal UUID in the "Location:" header. The enterprise client shoul= d map this external UUID to a newly-generated internal ID of its own. In ca= se the resource already has an identifier within the enterprise client'= s domain, then this is the internal ID that must be mapped to the external = UUID returned through the POST response.

2. If a resource is to be created, and one of its attri= butes is multi-valued, e.g.,

=A0 =A0 "email-a= ddrs" :=A0
=A0 =A0 [
=A0 =A0 =A0 =A0 "john_smith@yahoo.com",
=A0 =A0 =A0 =A0 "john.smi= th@gmail.com",
=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"
=A0 =A0 ]=

then on successful creation, the server response should include the re= presentation of the resource, and this attribute should look like this:

=A0 =A0 "email-addrs" :=A0
=A0 = =A0 [
=A0 =A0 =A0 =A0 { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : &= quot;john_smith@yahoo.com"= },
=A0 =A0 =A0 =A0 { "3bd10085-c474-43b9-9cda-8646c3085bbf&= quot; : "john.smith@gmail.com<= /a>" },
=A0 =A0 ]

The client now knows wh= at each value is labelled. This now provides an unambiguous way to referenc= e a value to add, modify and delete it:

Add:

POST /Users/2819c223-7f76= -453a-919d-413861904646/email-addrs

Mo= dify:

PUT /Users/2819c223-7f76-453a-919d-413861904646/email-a= ddrs/3bd10085-c474-43b9-9cda-8646c3085bbf

Delete:
DELETE /Users/2819c223-7f76-453a-919d-4138= 61904646/email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

One can even delete all email addresses like this:
DELETE= /Users/2819c223-7f76-453a-919d-413861904646/email-addrs

I believe this is more elegant than what the spec recom= mends.

3. It's possible to think of the operat= ions POST, PUT and DELETE as nested operations inside a PATCH. PATCH itself= need not be nested because its semantics apply throughout the "tree&q= uot; of a resource.

However, the semantics of PUT are a little messy. Also,= the use of HTTP verbs at a different level could be confusing. That's = why I would recommend 6 separate verbs that are a little more unambiguous i= n their meaning:

1. INCLUDE (equivalent to POST): Add this resource to a= collection and return a generated URI
2. PLACE (equivalent to on= e form of PUT): Add this resource at the location specified by the accompan= ying URI. (If there=92s already a value at that location, return an error s= tatus.)
3. REPLACE (equivalent to another form of PUT): Replace the value at t= he location specified by the accompanying URI with this value. (If there=92= s no such URI, return an error status.)
4. FORCE (equivalent to a= third form of PUT): This means PLACE or REPLACE. (At the end of this opera= tion, we want the specified URI to hold the accompanying value whether the = URI already existed or not.)
5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise rend= er inaccessible the resource at the specified URI.
6. AMEND (equi= valent to PATCH): (This verb is just listed for completeness. We probably d= on=92t need a nested PATCH since PATCH cascades to every level of the tree.= )

A PATCH request could therefore look like this:

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.= 1
Accept: application/json
Authorization: Bearer h480djs93hd8
=
Content-length: ...

{
=A0 =A0 REPLA= CE: {
=A0 =A0 =A0 =A0 "key" : "first-name",
=A0 =A0 =A0 =A0 "value" : "Jack"
=A0 =A0 },
=A0 =A0 PLACE : {
=A0 =A0 =A0 =A0 "key" : &quo= t;middle-name",
=A0 =A0 =A0 =A0 "value" : "Ri= chard"
=A0 =A0 },
=A0 =A0 FORCE : {
=A0 =A0 =A0 =A0 "key" : "do= b",
=A0 =A0 =A0 =A0 "value" : "01-Jan-1971&qu= ot;
=A0 =A0 },
=A0 =A0 REPLACE : {
=A0 =A0 = =A0 =A0 "key" : "address.unit-number",
=A0 =A0 =A0 =A0 "value" : "12"
=A0 =A0 }= ,
=A0 =A0 PLACE : {
=A0 =A0 =A0 =A0 "key" : &= quot;address.state",
=A0 =A0 =A0 =A0 "value" : &qu= ot;SA"
=A0 =A0 },
=A0 =A0 FORCE : {
=A0 =A0 =A0 =A0 "key" : "ad= dress.country",
=A0 =A0 =A0 =A0 "value" : "Au= stralia"
=A0 =A0 },
=A0 =A0 INCLUDE : {
= =A0 =A0 =A0 =A0 "key" : "email-addrs",
=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"
=A0 =A0 },
=A0 =A0 R= EPLACE : {
=A0 =A0 =A0 =A0 "key" : "email-addrs/3b= d10085-c474-43b9-9cda-8646c3085bbf",
=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"
=A0 =A0 },
=A0 =A0 RETIRE : {
=A0 =A0 =A0 =A0 "key" : "ema= il-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"
=A0 =A0 }
}

The PATCH response shou= ld utilise the status code "207 Multi-Status" because the nested = operations could have varying status codes. A sample response is below:

HTTP/1.1 207 Multi-Status
Content-Type: appli= cation/json
ETag: W/"b431af54f0671a2"

{
=A0 =A0 "schemas":["urn:scim= :schemas:core:1.0"],
=A0 =A0 "external-id":"2= 819c223-7f76-453a-919d-413861904646",
=A0 =A0 REPLACE: {
=A0 =A0 =A0 =A0 "status" : "200 OK",
=A0 =A0 =A0 =A0 "key" : "first-name",
= =A0 =A0 =A0 =A0 "value" : "Jack"
=A0 =A0 },
=A0 =A0 PLACE : {
=A0 =A0 =A0 =A0 "status" : &= quot;200 OK",
=A0 =A0 =A0 =A0 "key" : "middle-name",
=A0 =A0 =A0 =A0 "value" : "Richard"
=A0 = =A0 },
=A0 =A0 FORCE : {
=A0 =A0 =A0 =A0 "status&q= uot; : "200 OK",
=A0 =A0 =A0 =A0 "key" : &quo= t;dob",
=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"
=A0 =A0 },
=A0 =A0 REPLACE : {
=A0 =A0 =A0 =A0 &qu= ot;status" : "200 OK",
=A0 =A0 =A0 =A0 "key&q= uot; : "address.unit-number",
=A0 =A0 =A0 =A0 "val= ue" : "12"
=A0 =A0 },
=A0 =A0 PLACE : {
=A0 =A0 =A0 =A0 "= ;status" : "200 OK",
=A0 =A0 =A0 =A0 "key&quo= t; : "address.state",
=A0 =A0 =A0 =A0 "value"= : "SA"
=A0 =A0 },
=A0 =A0 FORCE : {
=A0 =A0 =A0 =A0 "stat= us" : "200 OK",
=A0 =A0 =A0 =A0 "key" : = "address.country",
=A0 =A0 =A0 =A0 "value" : = "Australia"
=A0 =A0 },
=A0 =A0 INCLUDE : {
=A0 =A0 =A0 =A0 "st= atus" : "201 Created",
=A0 =A0 =A0 =A0 "key&q= uot; : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",
<= div>=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"
=A0 =A0 },
=A0 =A0 REPLACE : {
=A0 =A0 =A0 =A0 &qu= ot;status" : "200 OK",
=A0 =A0 =A0 =A0 "key&q= uot; : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",
<= div>=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"
=A0 =A0 },
=A0 =A0 RETIRE : {
=A0 =A0 =A0 =A0 &quo= t;status" : "200 OK",
=A0 =A0 =A0 =A0 "key&qu= ot; : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"
=A0 =A0 }
=A0 =A0 "meta": {
=A0 =A0 =A0 =A0 "created":"2011-08-08T04:56:22Z",<= /div>
=A0 =A0 =A0 =A0 "lastModified":"2011-08-08T08:00:1= 2Z",
=A0 =A0 =A0 =A0 "version":"W\/\"b431af54f0671a2\&q= uot;"
=A0 =A0 }
}

If ther= e are errors, they will take the place of the "200 OK" or "2= 01 Created" status codes in the above successful case. But the outer s= tatus will remain "207 Multi-Status".

The same scheme can be used to deal with operations on = members of a group, and for bulk operations.

I hop= e you find these suggestions useful.

I read the SC= IM spec afresh last week and these ideas came flooding into my head because= I have been working at another organisation (a telco) for the last 5 month= s, also in Identity and Access Management, and my thoughts have moved furth= er along the direction of evolving a specialised data model based on specif= ic principles, especially for IAM.

I am planning to write about this and also the data-rel= ated principles soon and am in negotiations with InfoQ regarding publicatio= n.

Regards,
Ganesh Prasad
--0015175cba2255f21504c63ae96f-- From leifj@sunet.se Wed Aug 1 15:37:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BFD21F88A9 for ; Wed, 1 Aug 2012 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itke-xYWA6Lj for ; Wed, 1 Aug 2012 15:37:30 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0D14821F889D for ; Wed, 1 Aug 2012 15:37:29 -0700 (PDT) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q71MbM0f021348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 00:37:28 +0200 (CEST) Message-ID: <5019AFA1.1050308@sunet.se> Date: Thu, 02 Aug 2012 00:37:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 01 Aug 2012 15:38:35 -0700 Subject: [scim] attributes registry anyone? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 22:37:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 With no char hat on whatsoever! The following is strictly FYI and is not meant as a proposed WG contribution. Me and Heather F (with her Internet2 hat on) wrote a draft http://tools.ietf.org/html/draft-johansson-areg-reqs-00 which attempts to start to pull together the bits that are needed for a central or distributed registry of attributes that lets us move beyond our current model of relying on LDAP schema as a basis for describing attributes used in things like SAML, OpenIDC and perhaps SCIM too... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAZr6AACgkQ8Jx8FtbMZndqxwCfYBzc03zMdiZapYJoLxMU4wof aIAAn3VhZu3IGlOOf9rgHn7XV8HUvUZo =fKIj -----END PGP SIGNATURE----- From phil.hunt@oracle.com Thu Aug 2 11:10:41 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD521F85A0 for ; Thu, 2 Aug 2012 11:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.309 X-Spam-Level: X-Spam-Status: No, score=-10.309 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8+XTUHjJCtm for ; Thu, 2 Aug 2012 11:10:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 61E3811E80F9 for ; Thu, 2 Aug 2012 11:10:39 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q72IAVdG025280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 18:10:32 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q72IAUrH013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Aug 2012 18:10:30 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q72IATHI014452; Thu, 2 Aug 2012 13:10:29 -0500 Received: from dhcp-1578.meeting.ietf.org (/130.129.21.120) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Aug 2012 11:10:29 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Thu, 2 Aug 2012 11:10:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F47C100-AED3-4743-BC89-54A7F0C9A6EA@oracle.com> References: <42721FC7-1CF3-47F7-8A02-B2D5F362794E@oracle.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "scim@ietf.org" , Leif Johansson Subject: Re: [scim] Directory Support for SCIM X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:10:42 -0000 We did not manage to get an official room. I propose we meet in the = Hyatt Lobby and then go somewhere for drinks and chat. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-07-31, at 10:34 AM, Anthony Nadalin wrote: > API operation simplification >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Tuesday, July 31, 2012 10:26 AM > To: scim@ietf.org > Cc: Leif Johansson > Subject: [scim] Directory Support for SCIM >=20 > As discussed, I am proposing an informal meeting to discuss issues for = Directory Support of SCIM. The agenda is flexible. Some suggested = topics: >=20 > * Support for Complex Attributes > * LDAPv3 Client Compatibility - can existing clients be supported = without change to code (e.g. even filters or attribute names) > -> Extended controls for LDAP access to complex data. > * SCIM Directories - Should SCIM be the new LDAP? > -> Will an LDAPv4 be needed? > * Other topics? >=20 > We can report a summary of our discussion in the SCIM WG session on = Friday. >=20 > I propose we meet at the Hyatt Lobby at 1PM on Thursday to discuss. I = will see if I can arrange a room to meet and will let you know. >=20 > Also, the agenda looks fairly open at lunch time. Would anyone like to = meet up for lunch at 11:45? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Fri Aug 3 07:58:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46F521F8DE6 for ; Fri, 3 Aug 2012 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8KeIeFDNaNZ for ; Fri, 3 Aug 2012 07:58:55 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 05AA021F8DE5 for ; Fri, 3 Aug 2012 07:58:55 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CA55A40446 for ; Fri, 3 Aug 2012 09:18:47 -0600 (MDT) Message-ID: <501BE72D.2030409@stpeter.im> Date: Fri, 03 Aug 2012 08:58:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [scim] slides for today? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:58:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see no slides uploaded to https://datatracker.ietf.org/meeting/84/materials.html#wg-scim Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAb5y0ACgkQNL8k5A2w/vxrggCgq9iiiokdJeCi3suxDe2joy00 H5sAnAnmthEhOsSMEc16c37YTl9YTLwM =cUlG -----END PGP SIGNATURE----- From kelly.grizzle@sailpoint.com Fri Aug 3 08:13:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3922121F8D9F for ; Fri, 3 Aug 2012 08:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVFbZszp-V20 for ; Fri, 3 Aug 2012 08:13:31 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 13FE521F8DB5 for ; Fri, 3 Aug 2012 08:13:28 -0700 (PDT) Received: from mail189-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 Aug 2012 15:13:28 +0000 Received: from mail189-ch1 (localhost [127.0.0.1]) by mail189-ch1-R.bigfish.com (Postfix) with ESMTP id 1FCAF4601D4; Fri, 3 Aug 2012 15:13:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: PS-34(zz154cP9371Ic85fh542Mzz1202hzz1033IL8275dhz2fh793h2a8h668h839hd25hf0ah107ah34h) Received-SPF: pass (mail189-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail189-ch1 (localhost.localdomain [127.0.0.1]) by mail189-ch1 (MessageSwitch) id 1344006803389083_9107; Fri, 3 Aug 2012 15:13:23 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail189-ch1.bigfish.com (Postfix) with ESMTP id 482544200D9; Fri, 3 Aug 2012 15:13:23 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 Aug 2012 15:13:14 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.167]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0175.005; Fri, 3 Aug 2012 15:13:06 +0000 From: Kelly Grizzle To: Peter Saint-Andre , "scim@ietf.org" Thread-Topic: [scim] slides for today? Thread-Index: AQHNcYiFLR67oe8lNEeR3rnE8vyrN5dIMSCw Date: Fri, 3 Aug 2012 15:13:06 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373301E78E@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <501BE72D.2030409@stpeter.im> In-Reply-To: <501BE72D.2030409@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [184.70.136.106] Content-Type: multipart/mixed; boundary="_002_56C3C758F9D6534CA3778EAA1E0C34373301E78EBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] slides for today? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:13:32 -0000 --_002_56C3C758F9D6534CA3778EAA1E0C34373301E78EBY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for the delay, Peter. These are hot off the presses. I'll work with= Leif to get them uploaded via the datatracker as well. --Kelly=20 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Pet= er Saint-Andre Sent: Friday, August 03, 2012 7:59 AM To: scim@ietf.org Subject: [scim] slides for today? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see no slides uploaded to https://datatracker.ietf.org/meeting/84/materials.html#wg-scim Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAb5y0ACgkQNL8k5A2w/vxrggCgq9iiiokdJeCi3suxDe2joy00 H5sAnAnmthEhOsSMEc16c37YTl9YTLwM =3DcUlG -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_002_56C3C758F9D6534CA3778EAA1E0C34373301E78EBY2PRD0410MB354_ Content-Type: application/pdf; name="SCIM-Overview-IETF84.pdf" Content-Description: SCIM-Overview-IETF84.pdf Content-Disposition: attachment; filename="SCIM-Overview-IETF84.pdf"; size=784716; creation-date="Fri, 03 Aug 2012 15:09:20 GMT"; modification-date="Fri, 03 Aug 2012 15:09:24 GMT" Content-Transfer-Encoding: base64 JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlbi1VUykgL1N0cnVjdFRyZWVSb290IDIwOSAwIFIvTWFya0luZm88PC9NYXJrZWQgdHJ1ZT4+ Pj4NCmVuZG9iag0KMiAwIG9iag0KPDwvVHlwZS9QYWdlcy9Db3VudCAzNy9LaWRzWyAzIDAgUiA3 IDAgUiAxOSAwIFIgMjEgMCBSIDQ1IDAgUiA2MCAwIFIgNzQgMCBSIDc2IDAgUiA4MCAwIFIgODkg MCBSIDkxIDAgUiAxMDIgMCBSIDEwNSAwIFIgMTA3IDAgUiAxMDkgMCBSIDExNiAwIFIgMTE4IDAg UiAxMjcgMCBSIDEzNSAwIFIgMTM3IDAgUiAxMzkgMCBSIDE0MiAwIFIgMTQ0IDAgUiAxNDYgMCBS IDE0OCAwIFIgMTUwIDAgUiAxNTIgMCBSIDE1NSAwIFIgMTU3IDAgUiAxNTkgMCBSIDE2MSAwIFIg MTYzIDAgUiAxNjUgMCBSIDE3NyAwIFIgMTc5IDAgUiAxODMgMCBSIDE4NSAwIFJdID4+DQplbmRv YmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8 L0YxIDUgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01l ZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDQgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9T L1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAwPj4NCmVu ZG9iag0KNCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0NDM+Pg0Kc3RyZWFt DQp4nI2ST2vbQBDF7wJ9hznuBryemV1pVxBCieIYtxhaKugh9GAa2YjqTyv7En/6rhy78TpR04sQ 4s37vRk9mH6G6+vpMl/cAd7cwO1dDr/jCAEVIhIzWrCMkBiEvoyjb1fQxhHB5q8GMSU0gWh9FUdf 4ghmyxzgDEBHwG0RR9N7Ap2pzBko1oOjtwP/CUklBrRl5TIomgFzYM3j6EEsZsU9SC2ckd+h+BhH M+80uJ3GDTllgvEHARfaEzkNwWR9GNBsXia/5ovlGAg51I5RLvbLSFHCwDZVLj1hJLF4kpnYStJi J4lE2cBaMomuh7yXlIhuux1JohOnyIWOkzGtxeE8gfaxa1ZVC3JixOKxbKUTu2r39H9H44SUPwSz e/FbrtqVnGix8QuVzbPh2BFTNzgG4+fgVwXiywKxwvSiQCkCIyqtn9ujEm0PDTq8zN9F6DcQIYEd K22AEqOYj6k/SXKirGt/NyfmfSWN2O99UetybHVtlU1Dk3/mMme5TibkfAEtEPoGmKPJT6nTQxJp USg5ycSmr4Yo+9o/yg/bVVX/8vG6qvU/aKd+SELRNSMxE50oCgGvUv4Bxpje5Q0KZW5kc3RyZWFt DQplbmRvYmoNCjUgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEv QmFzZUZvbnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNj cmlwdG9yIDYgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjUvV2lkdGhzIDEzNTQgMCBSPj4N CmVuZG9iag0KNiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUr Q2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0Nh cEhlaWdodCA3NTAvQXZnV2lkdGggNTAzL01heFdpZHRoIDE2OTAvRm9udFdlaWdodCA0MDAvWEhl aWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NzYgLTI1MCAxMjE0IDc1MF0gL0ZvbnRGaWxl MiAxMzU1IDAgUj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIv UmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSL0YzIDE0IDAgUj4+L1Byb2NTZXRb L1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBd IC9Db250ZW50cyA4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMT4+DQplbmRvYmoNCjggMCBvYmoNCjw8L0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggNjkwPj4NCnN0cmVhbQ0KeJydlk1P20AQhu+W/B/muEZl 2dlPu4pckYS2VEVQEYkD6iGEJbEEcWunqfj33Q0UeYltLC6Jspl3dp75suHoAkajo7PJ6RRYnsN4 OoHfccSAUcYYcs4MGM5ASQaVjaOrA1jHEcLyxYYxjUwGRncHcfQjjuDkbALQuACfLxjP4ujoM4KU lGkJszvv0bkDBJ5xKjlIlVKVwezBX7O760scXZPjZZIRu75NDjmZJz9h9i2OTpwz7/C/B8kN1WnT wzWBhu1eVDyIioNwWDyMSgrqztOUGvXkccRYavIwAE/UojXslZacbxNDbJUcCrItrCP624GCqaJa h+JeFPEKhWvKXkWT+WiUfsmNIxljC8m+FBlSkwZicrWau/g3kKTkV5UgJ+XNvX3wP29LW0OCjFxO fLVOzzwuJIrU5f3Wn9tPXQV02U5FeE8vtRxIzRUV76ZuiJvURQ0eUDwDdjFxJakQoZdeJtXCpFug eCYpmrehdCtVU02+FrWvy8ZRlZWv2SN09iWnWSj+buu6TARZ9yRAmVDTmwC9N5X7E8lVRlG8NZH7 09jUkam1Lu5f/qMC9zEttn7JdHFgRo0MPfRymGHNyd15NqCO7WVsiMnlYuWLZx+6FiSmkppQ00uQ DmxFzJRPzTtbsakmF26XSFJufD+WiwSRlPddNBmjQobyXpxsWEFQu4YdQNMO0xCTS7v4s1v2xeax sySGYqjqZUA2EEIIn5x3QjTE5Hzjm2pl3YigIPPdrrfzGoo1JJIsVvNq43a7rT76FX9TrG+L9bL+ AH5NetMnwXK3953Bxv3bkQrlJluK8PL+XODA53eWUp72LQvR+fgOpUYyVMe5HDFkPDfuKzvOD4Ue MaHGueb+wL8XiVw5a6kY4knO0R1P9JOtMxFyOuz9gQvuxrURwX46/gEePviZDQplbmRzdHJlYW0N CmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTAvQmFzZUZvbnQvQXJp YWwvRW5jb2RpbmcvSWRlbnRpdHktSC9EZXNjZW5kYW50Rm9udHMgMTAgMCBSL1RvVW5pY29kZSAx MzU2IDAgUj4+DQplbmRvYmoNCjEwIDAgb2JqDQpbIDExIDAgUl0gDQplbmRvYmoNCjExIDAgb2Jq DQo8PC9CYXNlRm9udC9BcmlhbC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9H SURNYXAvSWRlbnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDEyIDAgUi9Gb250RGVzY3JpcHRv ciAxMyAwIFIvVyAxMzU4IDAgUj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PC9PcmRlcmluZyhJZGVu dGl0eSkgL1JlZ2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KMTMgMCBvYmoN Cjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQXJpYWwvRmxhZ3MgMzIvSXRhbGljQW5n bGUgMC9Bc2NlbnQgOTA1L0Rlc2NlbnQgLTIxMC9DYXBIZWlnaHQgNzI4L0F2Z1dpZHRoIDQ0MS9N YXhXaWR0aCAyNjY1L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL0xlYWRpbmcgMzMvU3RlbVYg NDQvRm9udEJCb3hbIC02NjUgLTIxMCAyMDAwIDcyOF0gL0ZvbnRGaWxlMiAxMzU3IDAgUj4+DQpl bmRvYmoNCjE0IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlwZS9UeXBlMC9CYXNlRm9udC9BQkNE RUUrQ2FsaWJyaS9FbmNvZGluZy9JZGVudGl0eS1IL0Rlc2NlbmRhbnRGb250cyAxNSAwIFIvVG9V bmljb2RlIDEzNTkgMCBSPj4NCmVuZG9iag0KMTUgMCBvYmoNClsgMTYgMCBSXSANCmVuZG9iag0K MTYgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDYWxpYnJpL1N1YnR5cGUvQ0lERm9udFR5cGUy L1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAwL0NJRFN5c3RlbUluZm8gMTcg MCBSL0ZvbnREZXNjcmlwdG9yIDE4IDAgUi9XIDEzNjEgMCBSPj4NCmVuZG9iag0KMTcgMCBvYmoN Cjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRvYmUpIC9TdXBwbGVtZW50IDA+Pg0K ZW5kb2JqDQoxOCAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUr Q2FsaWJyaS9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0Nh cEhlaWdodCA3NTAvQXZnV2lkdGggNTAzL01heFdpZHRoIDE2OTAvRm9udFdlaWdodCA0MDAvWEhl aWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NzYgLTI1MCAxMjE0IDc1MF0gL0ZvbnRGaWxl MiAxMzYwIDAgUj4+DQplbmRvYmoNCjE5IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBS L1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA5IDAgUi9GMyAxNCAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQw XSAvQ29udGVudHMgMjAgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9E ZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAyPj4NCmVuZG9iag0KMjAgMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggOTQ4Pj4NCnN0cmVhbQ0KeJylVttu2zgQfTfgf5hH qoAZ3ikBgYrYTrdZoMAuEKALFH1QbdkxEFtZX9L9/J2hbFdUJCdIH2xJ5JyZ4ZnDIeHqL7i+vvoy uZuCyHMYTyfw73AgQHAhhFRKePBKgDUCtuVw8PUDbIYDCcuzjRBOChMZLT4MB38PB3D7ZQLQCCCP Acb3w8HVJwnGcOEM3C/II7oDCdI57i0Ym3Kbwf2awoRYfwwH39jXhyKxbA+JYasd7B+SkWIlPG0T 6Vj1g74ey/XH5Dvc/zkc3GIUinRyba3m2jRdf2PQsH2RrorSVaA8z9I4XaO5Ap0aLo8er4VIfR4n QEvtwHrRwrLPFa7uJyRtuO6CS5Vy51rBpbwR0k+xKDofaUxGfaJ3Id0k14rmb+tfmtXj3uZK4PjE H7+n+Yjs0kkuLT6tyKXDp1A45/B7mmsyx+k0DOceH9nNeQaDk6G249zRN8Uhx2Mb3uvgk1yp81w+ Ik824HKMGYayMF0HwdyOU1IeEZTSRNaoEPwmNzWym3rXwbwVv3SwK7fJyLHnFSprVgIp6Z8eGUlE E+9NeJ/kZKq5a4W6KDndllxLMhklLg3P7FluY9m15pZWhOQ+jZA9YjsjLCJiwLyCO4SE7WZZlXik a5dotqo2UBBjkDh2QCahmCUjzWZJyqrDJpGKdqxji0QJVm2BMEQ3jj+vkOw+oq213LaS7t3b1DZM bHuRaPOCaC66yFap4Nq/RvYL7JHwJpoId68RHgHmFTKFnOPfvDyxngbWDbFOE0R0AYF1LEgxm2GM 6oAzyLtE3hd1b1xDktUil6JmHe16ic8yrlvJ9xGPvZ9bE9teJN6+QeHKWJ7K9yi8iXyTwiPASeGH p3mRIFF7+iuh2EBJKv4Pic/YfrVZAn2SytXvqxxXLOM0ekWeYd9yse1Frl3HAeZenl9KOG796+dX RxNtQolvc4Hv+ryKEEh4MjLsDtbFplgikyUsa8EenpDLXY8rbRVXNnbVR5p2lisZ214kzb9BoHQG ZO/RZwN4lqc7666YzwGlg8pBEgwr1ySw0GhJXmXY5vS2a2xrz5Z1Z0DGPM7syaCCJbWII2z/UJIj NMa700PZW6Bjikbxk7qCuLfBfxl6Okoc28pj+RyGHqFaYLOflVTE3a63BMpRCZqOL1YgfUsFhKe+ 854SNJAdNZjhanHnFkjmcfsjk5sSaxLMIrJ7F4x3Mu/jSBdXnLUuxlJFmbv6yqFQOyqtL8XcYrtd nl7C5Vj3tWjvQmv8he7I5n8oa35+DQplbmRzdHJlYW0NCmVuZG9iag0KMjEgMCBvYmoNCjw8L1R5 cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vWE9iamVj dDw8L01ldGEyMyAyMyAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdl SV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMjIgMCBSL0dyb3VwPDwvVHlw ZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50 cyAzPj4NCmVuZG9iag0KMjIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjc4 Pj4NCnN0cmVhbQ0KeJyFkV1LwzAUhu8D+Q/vZTtYek56knQwJuxDUShMKOxieDGlc4JzOvv/se02 7fzAuwRO3uc5eZHMMRwm+eR6ChqNMJ5O8KYVgQwRsbUUECzBCWFfarXo4UUrxuPnDJFnkrOhdU+r W60wyydAB8BHwLjQKrlkiBjygmLdJNZxYLD3JjiIy4wboNg2mJZ1pdUyWmxWsYsqxBI9vaPaxH0b lXjdx+yj3X1zey63F/EdihutZjWlIZ2inUtNKt3oZYTO7A9d+02X7ZmqD2S8hyUzsNlB1bg0tLrt oVWWP2x8qBfNuq//sUm/2ukfP5448KEEK8LyS1GZ4Yx8i3T11sHCO9hghFM81MwkL6uVTTHd4VTY B4LcaW4NCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvRm9ybS9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2UyNCAyNCAwIFIvSW1hZ2UyNiAyNiAw IFIvSW1hZ2UzMCAzMCAwIFIvSW1hZ2UzMSAzMSAwIFIvSW1hZ2UzMyAzMyAwIFIvSW1hZ2UzNCAz NCAwIFIvSW1hZ2UzNiAzNiAwIFIvSW1hZ2UzNyAzNyAwIFIvSW1hZ2U0MSA0MSAwIFIvSW1hZ2U0 MyA0MyAwIFI+Pi9Gb250PDwvRjQgMjggMCBSL0Y1IDM5IDAgUj4+Pj4vQkJveFsgMCAwIDU4OC44 OCA0MDIuNDJdIC9NYXRyaXhbIDAuMTIyMjcgMCAwIDAuMTc4OTIgMCAwXSAvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCA3NDk5Pj4NCnN0cmVhbQ0KeJztXUuPJLlxPnuA/g91XB9cSr7Jq60HJEDw oxfwYeGDXJC2bFRJkGBYkH+944sIPiuzu3o0GMxBWGC2v8hIMiJIBoNBJuuPL5+sMWcbTxv99w+m mLO3p+1sfC7h5Iw9+9Pl/vLpJ7+8/+bH31p/+ukfTv/68umPu6+5lM/xY285ezK5nL05+Y3eKuNr UV/7x++J9HN/omI3E07f/+7lk+ESzMlGdy75ZCIVZE/f07vb6Uf884uXTz98989//x+n73/18uln 30sh7a1kz2Z664fv/nTIG8/ENPH+eMSbzTm6mfc3h7wJJpt4f3/EW9w5Lbz/dcgbz2Fm/b8DVreZ Y1nRiMaerDnn7E73lXBTQqkEIJtG5DyjjdpUmIWQ6H/cQ7isGAcQcqi8YhqfTK2pEzpyJdWaFPWa dh+rkKq0MneCajQiuzB3AtDmOyJVy8RMBDs+TmFEMS3McXo6gmAX1jBoTwMv7CNl3nssZhxRZ6Z2 2Fxhs2/5nPwjweSzMSNO50x26SgYzwgGSWcrHYAwyUDYwFNshS2dzhsZAog8gCJmLucQx8fRjyit zClPj/NYT44VKXNx4+MBme28ccnWRLEIEXIlvIWU2cTx8RHaZbaTGB0p895jVndCA3M8l+JOAyKH 11H2fmZOsQyPI/v+huzMG3zXqPalEQ361Y4nthqQGXuptoL2eG2yjlIe+782P3lln1vX6CjEipTZ l/Gxn161K/M2lJV1/FYUpuFNBJeaSoRkkmDbEDKh2lGYq9Hdls7FtuYhRD5v6BdESEzwNOQ6itE1 lGk4hoF5HJ9pQhFmVUJHxjhGZGSgrMqPhI6cSwPyOc7M8NhHKC687PgPUJ0lJkIXmaeUCV1G/eRx 2vlzslKdt5TgaDiVR8IRstaPxQlBG3AXKTO1Nggln1aU65/anyB2e4YeNCBrF2Y3MVPP2kXKHMZa 0ZEfURU4Y2Zq+hyjS58fqqWO0cA8hw9jPHHViZ7lCdbUoKMTbiOB5W+I69QYww0zu7Vk8ljn8oZ4 slZU5980Pg4TM6ZFVxnF8lsK/Mg181TgfZt7GUeZeeW1bEov8VxiHuZ068n/uBodDAiyCupRSHss anbEFuglVwPl4gdzJR9Os20vO8a+iiMPbZDdV8Jth0Bv/W4JNI07uyXe/sNRUGqqf38iLqY4nhYQ sIBJyvvTQ16aZGbWwxA62zOZb+I9XB7kiNB84v3tYWhuye3NvJdDXnIzaeb9n+M4njvMyHtoXvUz z+hW+9bI+5eBF8s5Wh2h52aZYwJNmfbkSfScTn/67cunfz/9nlZj5NMdrSkzjZKNrGVPf/pRfCNJ 7T1T7iuBe5bD3O9lbSnARYokZC7EuCKDZum7ZAN4MprhAw0AWllm31AOcNmdGX0Bb0tZiqQa5VUh wCtFedLQupNW09Ao8aV2fV3pogVPKZzdFurAoeAgkhvcbB04RPAbxcU8cCwthCmYUKkrQdSIRkSD Gz7zBEdrTUyh1FWdCEpNgVDE0yuybC2iIuaZCTFzghOJ/mw2ngMnaWUQc9s5cgZoPKzXSVgtCHx5 WKq7TZfqGxwcOY8/v3yiDvSrE/3z36eltvsT1X+usdLa5hSzlvKljXVdaXsqEdPr82OEJhtHg0zs bDjCg0Ib2aDITN6NbZqxyWw0N5CxuUs79GEjg2nCbJ0N3Zvs51gWg0jYwVal+jtHxpZg0GaHfkeE DQEWmZK6n6N1HTxdZj0dbMRz52utPaG84FyrvhFq/aXWwfVnFFkQq1D9aCuKgqV2rzUEW6T23NoG tbMRvbFj7Z7fJ4tq5Q1r3SEBGxu4blokUIEUQHLd8CeBaKbVXtAzcoytG3nqPoFrJ4foMH8WrR0N jDIKmnSjRdZd7Ed/KQEIXZcsxhU6rFgIRYlPVV0iWINBLogUjJ05UEGltoxljxMwk1DFNPUOiEw0 MhtMpa0sQbUeYR7EsOgwVUjqEV3+Ub1L9w30gqN+yn2WIocttzqINYSxy7reZa2jfvhn/LnReECu sf7PUmH/9gvyHBs8x0aew2ynX3+a9bq/LITbZygKo1FvcKdqzwa+UtN8zDnQPFzIfbGhEyI5eoHc DfVBcjc5jLlW55ulC3lOsia7TvLW5Evj1kK4Tri1pT05h5zElxYiwJViBComxxzITD3om4q4rrS9 ekRr9Q1UmN/S4CyUcFsJaE8yfwi0ZLbSYgBbUV8VIHvwZyPugawSaIA6tyDm5ZxrIHcTg3SckYBY DlpW5NDcKHgL8vbGBJqkSjxVGSOv1Gd02dHp+oziEj8YpLBRfYDsOdvqUxq+CYbo5KlDrP14RJB8 c6Z2eXJfRHBWJkNaZBOKNtapIGAmbF6DvL5aWDwBgPVc7hbqm73PE8FvMn68bU0xyNtCI87Oy9xE bLnPVIxuE4Igm0cRLrbWIEUkz4V2NyQZOXOfazadkNnMgrThaWQEasA6HY0ElEW6NiRakl2Srw0/ 9AuRULvYCC6rMte3dVWT0IIxUoT5Z922WOImknIOMjqhxk1r4CRjbgiciDAETjKWh8BpIsAWnMOi nunaRD0ETolnT50eUw0GJHAa0WVH3OtK29Op+Ua3bciXkNfMrsgKwaFrKgH5H89e38TcEGbqlktC jIPJwNd8GAibrIWlLEIGYSLXJOAiZs1esS0BPVDfq0iKZV4maMW3ThC5tKgm86jSMJciQeB1LjXU G7HCp3Is61fyFP/F5uKT99RIHP9NYt1fFsLtr5XzmzT9ddXq/oaa5JucaWpiLDctGQxK6kPRSt57 0LFP39jJsRQ/csenNsTikOard5e/kiT2vBV5Xwk8cj0n3ClmzjCmInKHpaWYyTI1c0peu5AgkdMG xSKgqUjmtc4suRAtqgKupbKKENwcUhKinnyqtVQ0Svyw/OVEg0kWb2g0wFl+CrxN9UxF9KP2UUdE IaBKXQmzGtgFTtiRqHutlpfIdZUGRewZUX5FjjNEE+qeyUSDIO62ijsvgLMxdQHMS7FamvC+vQpe aro/U/XnWiqsDQ5LmS9tqetK29Pp+pEBYi1H1HXt63gOLqwPmQCh+PtrX2yJknmCqdNsJ+gKENtE tAREDloNQuIgW08RDjYmCZlUo37sCWNNKKEB/U3hUTxp1ABkqxOQZBK/XtrKu2GtG5v3KL+uTVC2 zTXSQHmh1Kq5AscbBRKW1HEq0SxaLU1L35hqebX2RtDqsZ1GdXhRPUmR0dagCkWWUOvHDpmzEsKp 3+C9HNQfEqMtDh4QZVD55Bl9jVOpIsEA0N2zwTStALSlsTqv0iiy0izKbEG81ADYUAcpbdk+IOSX B16OYVtRirQaZe5SIMRtMtIreRC/6fbOwtfynqZnK3/BhW9XSxe+nXD7DD3ZZl5WnGLOBr5Oy3zI MRyve00k3zUZOu2ue7P4EOvrDNQJ6ldjZj/R17no4+RG8+RXseRJ9ZWpjOtK26uoL3wjl5XL4CkE 3xas6zJDawsf6tLK0BokxLr8CWTmwB4XYzMVRqYsSJc/GIaBl/m3lYBxzkoqcoIMTKHLHzilYHm7 VYV05zL9fXnU5/q+ysuCl2XiVO19JeiSF148aKbecVsNSECpnT0JIbckEFQwfUIMvQNbHudi3dqD 8TjXlbW+Wnu71JvLaRAyqr8rVeTHVW+QJqTF830l3FYCpMT5hIDIsbWK56MS2gF8ZMImqQ52tFk0 GJF2AFjOJ0w0t5WADmBzR6IxvZ1j7QBsAukfVUrpaxO67Gh1fUb1p5bCfLRjDDk64SiM0lHYwygQ ng+jOPXMYVTLbc5hVCptstQQqIdRHV12xL2utD2dxG9s2M2lQFvWeUi+nJDQkUT7iG+CSXSDM1pM eO007FqX+lIn8FsGSx5DK09jd4vZISQhrK+0Qq/P1CwNv05837bAr83smIxMGNpBCVodGgY7Zb5W t7bUjA2idQxrHaNrkddn6hWDftsCvqrL13Q3zgQnTojOBGKmKDYiULabnpPy2JAufKgQs6uT4MTy 8jNtsuVXzokHbUBagaZJWQkhndBYET/ouQyceMBClmpBfhsehAyD0yEFEQzGLpbeOJUUsX2Pxzbw GhhjFVsHmFm4OpTskd3DSoNi5oIMZOSVN/VWTLM8f1VepLQDVrQZ8fc/wGVkdmBIgEymuOzY5vqM AXV8dUf6N5t/DZu/Lqc5PG/dQ8IwHFP/4bvXo+MfQU4I9xd++O6fDnmzLMwG3l8e8VIbbHbm/fUR L1m1iOujQOM9GfjM8sh6O2T1vCQYeQ9P4oQkeayB9/B0TXQ8/4+8hweHYuEvD0be9XTNT34e9r44 wHY8Nucj58vk1Z8dVIO0PHXuifd+wJt1v2XkPfp2oBje2Zl4j0xYvBwmGHmPmqZEGn1+5v27I94i OdmR96g3mw1p45n3qBkNzrstvEcHlAxO5y66/e8Rr5V4/RmbGesfeI8OanE8+IZutNTFqYFAPR6H UNzHDkkhfEE2BbEtpwBmwg1rZF7BG8QpInmQT2qcBD9gRh6H/ZnB+UAap1gc0ePNsuMQRI3vkT1o zBQLe1ryaFkVST2VWcRAyVKW3QyCba2noVHmJU9scF6V7Ef+mJcGaCd4U2s0jFcCKpa1gtk2VlXE VgJNHoMeWL5hmVZOhUYwf7IQkFG7cGMkJLVyRnENYV9uAsKaEz5woSlQ6hlEXc5I5az5S6qHJkQt ilnTeyniqZ77+/V+pok6oTX1FzfR9eVdbVoG6KlhYWmFiCTZcC4KngcrT3oUynu5YextYrYpXnNo M4HkQbwAzAd1sduBeKBw9oBoCFqBZEMTnR/qF87NkBkd92tsT52wsQR1Ci+WNT9LAMftUYJs488E qd6GVgf9a7HLU3jtj/rxDU3ZNKtR5LgHzE9voxkhOjcGVV+wV0KNNtVOxkRpcnJmJkjtOBLANViu HTN+RpKmyMk/FCifZVHlBbyZA7fWhziRgKGNyZfQ5ntyGEbF+TrqfU6sjw22WAnor1YeWwBkUk3h Y3yDsgWHyE4NZYR1jTmf5YiDTnMGrcCyWwoFK7LcYQZmi0RDK6siqacyNzEorECCSYSk9bzv8k/q vZkg1kqY9YudjJoVu78shNvHNYXVIKO3LXBo6Gu1zsccBHLEtDIfc8T0XuET6bzg77b25iFHDM9p vLhSW6efTmDfuvGWZ/E6ZOBKkf7OvGSovhUObjuH6o2nIq4rba8e0VrdA8pKo79Qwm0l4HByQA8s WGRhdGHDD5+HiL/AbAQChfsYo0jf0d+k/ATAia1ctH3E7s5tJdBoRwaqIpzqify2fKEGD4gkJb4Q KacqIhaFbkGXHZWuz+g9ZIrhNpCn3HBg9L7gG2OD098bn9Zs/VhQNVE6y0dURCB3yAT4Mcwpwlx8 nQ2glnzxUngFq/ZlXyCAXQG+gdQXe5cHIfHwqSKF0yTvnCTW2QmFbmWYrpRwWwlIgyVppRh6uwQ9 0EDtn3EmevM80mqTeh7RE5IusHEj8lbDbSVQF0js7ARVfT36vnYBbIRpD6lSSmeb0GVHq+szqr+b JMbMtNkh9BixBlIYLWMgVQdhGQhLIFXWQGqMNU0JHEjF2CbvHkhR10AKX2ZMDYRaINXB5VHU68u7 2jQ/iSVTFEcuOTdj/EAwhhMxcLBw/hVxf+c1gRCwAOU8XyOwx6tl6bauViXoIiaNpj2m1seGsr5a EZfMzEKQum8DQUTTsqrYo1bLUSnbT0phnbPJRnlhY759UGoW6v6yEG5/rZTfqu2vq2L3tzSNvHlW NY28eVY1jRoMN031seomr66a1pSvN573R1r2bCZglwZ7aLGmHx2mMFfTjx6f2sQhp+h9QQZA8o8B vqflHwP9L475x4CvIVr+MeTIuzqSfwwh8m5Wyz+GwofANP8YAn8GoPnHYAMvpnpO0dJUUPOPPsr5 D04/+siet7N6nMMINf3okpGPyDmWmE1x2bHN9RkDVjfZN43+ZvSvYfQl5wuz+SkxpDnffznIJHns 9PrnMoCeTBeWzNdfjnhxVuLJjJrHZumShTz6lNAn+5CpO8os+sQhyZO8HEU+lYX02TzwHmUhPQ4w heeykB5Lu2dthqV3fi4LGSh6WuU9ykJiZOHwzTNZyGDkjNYbWUgfAx/9+owspEdieMxCzgTsGZFe W8tCViSZw8rcEou+yM6SxFBowpaZQj/hNxsvacRpBilKkVRTmVteUYrSrKPW0tAo8ZKD9DnyYaWa g/Q0eacxwaaEHhf6VHA2u8eFIHAuxvInq0mDQvpLThS1mNDzFlpNrjXEX+uNQFkxGGvAN4m55B/b N5qSf9Sinss/TvXc36/3M81jH1uZ849f0kTXl3e1aWHzUwNiJ/8I/wTf/1T+ET0WW5Yt/zgTYBpM XS0BCWPEUBOQnqYq7rU1AUlR7NnW/KNP/szZvE2+z4uc25/yj6gt+iH/OBO0+tTyj6g+2Zp/hIfH qcaWf0T1LtT8I+ovvrZMwrdPc/4RlWHObvnHmaC1I1kv+UfUnjX9yHWXIf2IurUC/rZSuxAHmKg8 mIf0I8owYUg/goBTsEIASjWzB1DMkOCqukqCqyFOcDXmmrMCAcfxJKWFZsPiriNnJ+YNcUgrS5HW o8xdDMOzlgrJn24N8nf13kw/aiVfNv04K3Z/WQi3z9AUebRN+wJbdEBfqXU+5h920o+Dw3kv/QjH Gce04ExQ1+rH9CM8qR/Tj+xah/TjQxHXlbZXj2it3qGn4WbCbSWgRTnJxelHHl1xSD/CQQRNemGI ppZxnBGzcgar5x9nguet9I4sn4hv+Ue4EU0VUXRVZZSM44wuOzpdn1F8yD+y34g9/zjhm+CYa8ax deSGfBzyj9wbW/4RaCs1jaiTQc8/4rFpCcjmDXL1Bs4MGcih4iQjSIUKp0niOQOp81NPw82E20qA jDbXDGRrmZqBRBfwtmYgW6N6GdQj0k4Q8pCBnAnoBPgKtSLVt2YguRP0PlKllP42ocuOVtdnVH83 A4mxH+fYI46BVOLDumMgFf0SSMUx/6iDewmkSg+kPE/Xkn+sk/cUSOEOM50yxS/1QKqBy4Ok15d3 VOlekvcUh+Sj54x6JfgS+CCTJMAaqmmhSmgJsEZgf1fLkgxXraolwGBP0xJgPvNJw/pqRTUBVgkt 2dUIIpqWVcUetVqSj+N3mliU4OuI9Fz2cZbq/rIQbn+tmN+q8a+rYve3NOUUYtOU04tN05p9bJrq Y9VNXl01fZ3zYbhjCi0WogYuMwGihMI5osLfPN10csR3DjCtLoJHzO8E/mIDY3i3jB1C4iNr2EzR 2XUu8vp+rbsHqL9ZUV/ls1asd9o3ITMByUjcqOaZYPWjm6V5Hgm4ffBkIt8zedsp8/pMxXp2+tuW 8HX5LmLjhXXryjOB97Tkds2xK+OrK2OHppoJeMvpyrO290MxjwR8VJh7p3oo8/pMxbv9+duW9xVW D7xSHj50GgnEh9QcH1ouSBbedhrqkRCj9KHayx4KvT5Tc/0i4NsWsW4QWTLwpl+aywcEEwHtVLCq wI7C5iXuxL1SCXJY+DVCiWdkcvwWuhCh8J2yDhsLhbc3cJEaX946MLtgsG70cp2eo46CC1tpxYfl X+TLRp3lO2Aw/2xODrvzd754jJMCTq6LcpE/2vN8qB0lO8/CWrkfVD6ow2YLf1AXONXcmHFYnO/V LrwXneULNpxuRug4GuOyY53rMyZ8+Crgb1b/OlZf9ois40WpCzi8N+4RHe13WG/5yvT+whvn9wPf ujnxHu3loMX4A4iB9z8PD8/jbs6Z9/AAf5StwpH38MOAZB94Dw/7J84NT7yHNpMPKSfew+8Y5NPZ 52yGVdpis6MPDnDTSHqWlbfOnzIDLsVcRRi3iBCn4JrcyJ+s3lcChyUeHl0JjPKIcN8KIb3XxfKW JhPsaUB8t2JDZmIOGd/W3lbCgDBIJjS/rY8hSeDdmyplqHs5M6Gq1NEWJ2YxgdgMqHd8oNS6ijLj 7sP+2McR8Z1tY8luqFjbpiHsg0/MWxkfV5QF2ckaI2FAbMgRDcyRL/1iw29yheJKCJxNnQl8q2pD 3Myb2KTovgIIxQjhhLB2k6dGkM0VXSTqdWF8zI3aUFh4J9aQRxSDVqmsDTu+TXwPKGcenk1/p4Uv 7T0EKEvdJew9HIBZWVkJKw1VcKtGQ1kz2iNhfIrbKTvSa507IUyP4e9rpfnsJiH4xOeAuO+oor3v NMKWm8EaSG7qwdoI2oO1wXRsSFv2caQt357aidcuvEZ4ET2gt+UJmYq0M0YzPnZDwfwjBIPEhr/d rgrJTdPVFISiHcwmCzhgviu7yJzHLQCkQ7tUXsbSzgghUhs+HSVfmUHoo9Hw93sLoWIAb3dQ0F9l yDzA6reVDWU7ovpzIEpwImdHZUR2ZeZfbGnI2y5GmxkmwoCCCBUquHT1Hh82S3RWtVWbriqBjyQ9 EAbEP0IjzSJoaCciFHN6RGhhQcoM9w6CNLlPIwq+ImWOdnycplfLxGz5Iq76WHtpR5hDJmZ06f7Y T8wY/13miVDHxgNSa9RpQYzVUYoLGpl74LBEEleZh+EDIl/NeF8Jt4GgdXps2wLFPskTCn6c1ong Y5vICaFZdKYWVCffMj7WjqBIDV5LtrVJYBJCufeaikLziY3gxW/zq7R+6AXzAkSlMMJbWoDQAAsc zi082mJ7qJpWwJFUL1TNFKqZ1KYszmjhy47Jr6KBbaPsvhJuO4SdS/xpObOG50fHnJxDuvW5JYLD DWtLyH14073jnx6aeI+Ovdnk+N48jxP/7xwNw30kfM3zwHu49KhXQg+8h78OwPfoTqxHJsM1hau4 x7/xlR94j06G4U7D/IZq9YIGg2sA7XBjgxJuQpBPx+XEyquQcBY9JhzLuq+Em9wWgZ1MzIJ7hTzi dDYz+1Te9ZlKD28T+TZlVUPiEDWO0vT7Mhrh1u7pwI5fGa/dmNtnIRg5GG5HjrHQ6zM1j1eJfLsi vup1YjQqOd2gPxLxgYs403mTy+68TFoTgWMMvgaOb+srp4qS/AKFMpNETn/MCu7E8I9saLdSlDnp 2TmRw+BMFBdUkVRSmUWGS++iucjdpKb/OUrb9vL7b1AgtOGjB6wa58D5J1v0p4/k63Vcgdd+RQHb +SJzJcRBCf6znPRSfahj208q4DQStuxj/dlEVm4Gysq/KxVa4w9y3qaTjSnXmyGpDBwZkWqU9wM/ QTFWeX9Chs+1VX5ocL0o7Ava67rS9hT60NjYvYOTT5kg5Yubz94+54juq3enJc3xjwTeGeDkAl/F 5k96Iyff7e7qzYX8IxF6ESUvQ3hezvw5QZYr1/liNL6ujitoRw2BohRka/UNa+1Jk8D5pHdy8jVk sV7eiFdyqrVrDbY3owxTjDNumrHmVIvSmhvWmvEVHchWai5cmlw2qa7Euloxly557RzEtwT+FZiM H/YEcMMRx1pE5oXp/aXe9a4EvQYPKKR61Sk3bBjryyJNA8Z13lgT5PKLBnxXXLtIdEDOT8ybyKxl NVQ6bxfCSCuojHKoqcvf1RvOYdiz23IajzjqdfFgxf2oX+aI46zY/WUh3D6uKRstn0W14AbwdVrm Q16BproYXDvdGKFa4qP52IEJo5m9e7yAc9P9nw2sOv10grrUKD8Ao4OFPKjMMHpJmdwDjIBXJvyH Iq4rba+eukkrPqFwkuC+Em4roe4Y4eI4MTsGFj6F1p8F8Nxv8bGU/HhEZuDTDJhVTroV3y4kHgmW L2HryAoK1R3Jz0Tw51jiplhGuT9rQpcdna7PKD7dwykuA2dobPUonXATQhQBU+vGDXhhza3Dy28S bzIejCBX2gxQejeWGyXFwNUP4ESP3iNb39QuLw9NOg0ClnCaxW0Bkd7BKZMSfiPZj7OUEG4rQW++ RFlDu/D2gnYA3GRWOO3fmtSK+CPSLhAkJqy/SjQSuAuYjkRdp4t6+d2I2j+qiNLVJnTZUen6jN5P XMAZ6+VuPd7ohIMAqo7CMhDmAMqFJYDqBNg3SQDFVwnrnD0GUMm3yVLCnx5ANXDZkfW60vYUEq/x /4H+bnYNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyNCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvSW1hZ2UvV2lkdGggMjExL0hlaWdodCAxOTEvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1Bl ckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDI1IDAgUi9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDE0MD4+DQpzdHJlYW0NCnic7cExAQAAAMKg9U9tDQ+gAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArg3YVgABDQpl bmRzdHJlYW0NCmVuZG9iag0KMjUgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl L1dpZHRoIDIxMS9IZWlnaHQgMTkxL0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBd IC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCA3ODE4Pj4NCnN0cmVhbQ0KeJztXfk3m1v3f9UsxBRCKsQUQgwxBW3akNJSbRRRpYZK S2lUpbRqHhtFDCEVU4gphBAzHVb/te85z/MkdLgSrSvP/a5+fnjXvWu9vSuf7n0+e+/z7H32//73 F3/xF3/xF39hDBZXACytUFhawn+zMPdv+n1YQC7WNrZ2dvYODgQCwcHB3t7OztbG2sryP8nLAtKx tXMgOBGdXV3d3N1JJHd3N1dXZ6ITwQHy+o/RAvaxsgZ0iC5uJLIX5SqV6usH4Ev1uUrxIpPcXQEv O1trq/8MK2Aga1t7AtGVRKZQaYHBIYwwJjMiIoLJDGeE0oMDab5XvT1JrkSCvS2w1X+BFCTk4ORC 8vKhBYaER7HiEhKTr3Egrl9LTkyIY0UxGfQA36tkyMoOmArvpCyuWNnYO7l6UPyCGJEx7Gs3eekZ Wff5D3IAsvn37mak87jXE+NYzNBAPwrZDZCywTkpYCI7gguJQqMzY5Ju3srk5xU8Li1/WvG8CqCy 4umT0qICQXZWeiqHHcMMCaCS3Z2BpczqfhZInEFgYfHz77hiaWNPdPfyo0fEc25l5TwqfVr1UtzQ 2NTc2gbQ0vzubYO49kXFk8cPszN5HHY0I5Dq5U50sLU2CycLJGRagzhjCyKNra2NjfVPAQY4nYOz h08gM46Tzi8oq3xZ/66ts1fSPyAdGhoeHpJKB/olvV1tzW/qRBWlBQ8yUpJZYYFUsqsjNNQl08Gi jD0BhBki0RmASHRyhAHG+pTXXLGyJbiQfUNYyWn8QqGovrnzff+wTD6hmJqemZ2dnZmZnlJ8lMuG B/t62t+9Fj0rFmTxklkMfwqJ6ABO1GUSAgfExs7Bkeji6u7hSfbyplAo3t5ksgfJzYXo6GBng7Ky gIxcybSwOG7Ww3LRm7bewVH55Oycaml5Rb0KoVavLC2p5pXTivHhgfftjXXPSwVZKezIYKqnM8H2 0jihfAhOLm4eIMr40QKDgukIggL9aVSKl4ebs5MDlGIQXW0ILl7+TDYvu7iqvk0yJJ9SLiyvarTa LZ1ue3tnZ3tbp9vSajVr6iWVcko+3N/dLK4qyb3DiWHQyC6XxckCyQKcXNxh0AwKCWNGsWLj4hMS EuLjYlnREeGhQTSqtweML+BkAakj05iJ6blPXjb1SOUzqhWNdmt7d+/g4PDwCMHh4cHB3u6ObnNj bWVBqZAN9DS/elZ4PyUh3N/LlWBzCecJIQSyAE+KbwA9PCqWnczh8m6l376TkXEnPY2XciOZHRsV Rvf3AVLsCI4Z8LrwxHSBsK7tg2x6Qb2h29k7ODr+9OnzFwM+f/p0fHR4sLuztbG2ND8p6+98+6I0 Jy2R6U92cbCx/Jd1zwKJMUR3so8/nclKuMZNy7iXIygoKi4pLS0tKS56lJ/Dz0zjJsdFASn29nB3 I3nTwthpeUJxx+DHuZUN3S7gA9l8/Q4Ir+Ojg73tTc3ynGJE0lxbnpeeyKSRne3/ZS3XE6IGMqLi r6dm8AWFpcLnotq61w0Q9eJaUdXTsqK8+7e5SazwYBrVxzcwPIGXWy7ukCpUa1u7B8efTvH5BnCa 1qfjw/2dTc3SrLy/XSwUpLPDaZ7ODjDpQ2PexRPC8hpAKIyVyL3Nzy8WVtXWN7Z0dPW8l0j6+iTv e7s7W9811FYJi3Lv8pJjI8MYYVFsXk7Zq3apYlGj2z/6ZODz7TQMrD4fH+3vaNUqhbQDcEpjh9HI rk4EeyTm/QsllQWS13hcDWCwklPv5hYJq8WNrV2SfumIbFz+cQJALh8bHRqQdLW8qa0EUnyLk8RO 5KQ9KKttHZhY0GwfQJf7mc9pVpDU4Z5OszAp7RQLc3kJ4QFXye6uLs5YSXWhtYcFkte4edNCopNS swQllbVv23r6h2QfJ6eV86qFxSWARZVKOTP5USbt62wSV5U9zL6bkZElKKtp/iCf1+ggo19Y6CdS n44PttcXFdL2uic5PHZUSICvD4h5oKRyc3Ei6APehTACMRPkNUHMBG6moOS5uKmzb2hcMTO/uKzW rG9otZubm1qtdl2zurI4Pz0BpVhcLSwpKip+WtssGVOqt/b1jH5NyEAKGupgW6NSDLTVluWkc+Kj mYzQEBDyQMSDKnpRBZXFFWs7R1eyXyjrenpOcWVdc3f/6MSMamkViTK7e/sHEPt7u7vbOq1GvTQ3 CUi1NLyqEb2sb+uTzSxrd49QRv9M6IQU4KRbm5f3t9aWCbLSuNeT2Oz4OFZkGD2A6k1ydbK3vYDS AzJycqcEABNlFQhr33UNyCaVS+r1ze3d/YPDYxhmIEB8AUq8vwtYLYP4IpV0tbe19wyOzyyt7xx8 MoHRCaf9LbVy/EPrq4qShzn8rEwQ83g3k+OjgYpSPGBG+6ekgDDYE0k+wVHJaTklVQ0dH2STc8sa LQgyh8efvosyaIABUrwFSE2BbHRoSKZQLq/rULczRkhP6suno12tWikf6GisEz1/JnxSVlJUkHv/ Tuq1uAg6jUIC2d+fhSuUEZXO4mTkC2ub3w9PKJc1mzv7KJ+vPwKT4k3NysLczPS0chGkDHtHiJFM oYRyOj4AnOYVwx96OlqaGt821Ne9rBIW598HZysi2Bco+x+VHsDr7Ike1NBYblZhZX1H//jM4hpC 6PP3QfPbd/EFBs2NNfXKCnBP+H/+YjKlb9hx2tGuLsxMyIalg/0f+iQ9na2NddXlj7LTOXFhAX9W esBzRPTwDY1L4RdXN/YMKebV2u3vCP18GDBSQCu2NtGk7rPpjFBOQMp3t6ChZ6enJhUTH8dHpR96 WhtEwkd8XlIUneqJpOm/53yQEYkaGpeaXSJqksimFzVYXvNPMQYjhSRtQAT3YZaK8DeV0Td9eAIp H4gK6pVlGPLmphVjUklbg6hMkHEjjkEDabrd73EC8ciR5BMSl5Jd+rLlw7hyeWP7VF7zjz9JrxTH x1jWfQ4jGTiBPBYYGhRUW5vaDRAaVNPyofet4soiPo/NDPB2A8r3G5wsLG0IrhR6DJdfWtvaL59T a3fPzGu+M9QJjMTYX/15+FcCYgIsp9CQp9tcVy/MyKXdjaKy3PTkyEDK73EC0uDiFRjFuVdS09Iv n1/d2j00ngV8O5Vgn8B0Rid2BrRQAHuDikq3oVZNyfpa64T5GdeigiCnc2vEFSs7oieNmZxZ9KIZ MFrb2jM4nSk/6s8o/RgaoGLo1peV8sHO+oqCTE50MOB03lLe4ooNwY3KYKc/fN4okc+t6kxm9Itf 9WeU0ILq6GB3c1WlGO5+U1V4lxMN7HTe6wnE7YJYKTnChh4ZSD0NjM7z8y4CBkshpcfS9GhvI+QU FUiB1xPnOE4WlkDt/JjXskpedQ5Pr2yajdG370uPjeUZ2XvAKfNaZKCXi8N5JOKKtQNQu7j0gurm fsWSdvfQfIy+nS49drUrs5DTo4xk7HrCdEq2Th60yBvZwobe8XlYlZ4zvPw7pPScet9WPrydGO7n QTRd9iys7IGR4m8X1rQNTZ/UcOajpDfU8SHgNDPa0/BMcCs+lOruaGvqcbpi7UiiRXCyhW8kHxc2 TKvhLo/T8vRwl7g8JyUmmOJq8nGytHP2Do5LfyRqH55R60ys4S6D1Bek9liakrbXltznRAWQTXU9 C2sHN2pY8r0nDRK5wUjmZoRxgrXH+oKiv/lFUUZSuC/JRNcDfufhH8UVVLVIp3FjpG8nnHQalVzS WCG4FUdHXM8USnZE6HdFtV2yeQ1ujPTNwGlfp1bKul8/yb5psutZ2rv6MJKyyt/0TSxp949xw0jP 6QhKhLStBrheGNWdYGMCJWsCyBw4OZXNiN/hx0jf9Fcuh+A4ffzQWCngxQZ7u5gQcC3gUYpOyRd1 jCjXdo7wxMgge7o14HrisvucCJqHk61RIb9iQyQHxtwqfNU9plrfxZPffTMcp73N5Slp64uC9HiT FOKKLdGbHne75PV7+QJ6lMzN4zQMrqeSv28QZt+IhGayNEbJzpkSws4oawDqsIlIuLlpfAe966ln httriu4khFBcjZ6mK3YulFD23SeNIAnfgupgbhI/AFO9jcWPfW+f5tyMQk6TMUquVxmJWcLG/sll nFICrnegW50d7niJmcnqbIHAOyXsUnZXuzgBzPQAnCaSo5HYBBwPUioHjodPSt9OmammMD2O7u1s d3amh56lzLK3HxSoPJibwU8wmOmj5E05/zrT151wtkBcsXWm0BMyShokHxe1+7hTPAjMTOqZobYX D3msQDLxbIEAodYLZK2PxT3jqo09vMUlBJjoravGe8WldxMZPkYEwsLaiRzI4hW87JTNafCWPWBA zbS1MjXQVJlzEwrEmZ5nAdJWWtTNvOq24dnV7cPPeKX0+XBHoxztrAUCEexFtDvT86xAURt+jf/s HaLipn/Fu0xATsd7UCAanmQlG/U8SyB5IezMUpjkoYcJf5S+YQIxLW1+ngs9j2B9FiUsFS+oQaqL Q1wVTAaA3/T5aEczJwOelxYbZETz4GHyi7iRUwE9bxMta3HH6ZTnlWWyQykudmel4/Bm8ioItiXi njF8XT6cxonmVWSDaOvmcOZhAhUTlPF8eEW0smX26+NfA5rpaHttdrjthYAb5e/hePZhsia4U8OT 75W97h1XaXYOcXPt9R2g5+2uz491g8MUAw7TmamrhaWds1dQ7K2H1S2DU8ube+a/E/8VIKV9eJjq SzIS6BTnsyPTFRsCyZd57V6ZuFs2t6b/coEzTuhhWlb0NwqzkhhXXc/UByAQ0EwxPMHzd/0Tixu7 +HQ9IOOHSGSq4F9jUt0czr6BAGZyp4Yl3y2ubR9CvgLi0fUQfQBFU1tV7o0IPxLB6kxKwExA9KK5 D4T1PTLlqg4Hn5h+BqIPIM3rEAHJo3kQrM+kBEXP7WpIfPrD5+/65Cq0PRVvnDDJk3XVFqSyAjzP VnHkA7SThx/sexC1DigW13cOztfgdCmA+cO6aqzn1SNYBjoZoQTbBJy9AqNv8svqOoenl/WfoM3N 4jtAShuq8R5x4a0YEyjBZg74VZ2X96yhd2xu9Rztj5cGoOIopSKTKAGFsHUi+YYnZRSJWgYnl7S7 R7i7hjinlfSNUUiHir5VAJeUxnrqTDtLiJBDhbiWVVLbOTwLewVwRumcivc/rOvGNwx6XpsUCASS 6pmbxmno41KnCEnFz65rMcfT96+JWqVTWA+7uWmcAlpdrM6A7CHHhOzhf+h4ohuFzuJmQxmfUW/i zUrwkuhAtzI12ARyvHCqm73Rr0ywEdQrMPJaZmEVkkDocCYPyFXevnZpou/Nk7vsUGOZONLa6uBC 9mcm3c6vaOgewWItjighn2SAOkDBe4zc5Bn5yAS73p2R8UTBU3GnVLGgwVuoRS8nkaP0Ij8l2t/z 7PtWtLXVwy+MnS6Aw3wTKqRbF08JEWok4HeKD41P+deZVHcjggf1250aGn8rV4gM861u6juqzU0F g/4jtGZO1vXq8R1Qp5996YV1TQbHpDx4UoeNJ+rnEszNBYW+VQAYqb/peR6ISp5OZ38ItEA6qiM5 90pq2waRc3SkH4UxNxkIfW/egW5VOdpVV3I3iUF1M+J3sP7zYbDvPHrR3P/9eCIeKBm6Qnc0Knlf Y0VeKvxmdvanTQtLWKWzuLnP3rwfN2E88VJx0ru7s7GkGGytKcpIZFCNftm0hm3vSXdhR/WsWmfC eOLlQd9hfbS/vb40NdRZV8bHWtjO9jvk/jhV8LwJ6ag+whkjfR/84tRwV/3TPB5sNDRiJAsrB1cf RmJmSV23bE6zjas7POwYHe5urS1MDnc1VOSns8N8SU7GmgRsHD1oUdzcCmgk+C0GP+KNNRABG62p FNLOhoqHd2APPNFYExHWf1xU2zmKuy9m6Kf0feB1iqHO+oqHGcmRAV4uDjZnd+RZWKH9x+VvJBOL 2j18fTBDkwbYCDrS01BRABgFeht/7gLoHfS7vNP9x+ZmYoC+Z1Ill7yrKsy8jkzIGJ36gXoXFGvo P8YVo29Yy+TK9HBHbSmfywo2ad7MEmshQvttcPY9Xd+KB1K7qoLbUOyIJkwFWtljXQ8DUytbeGua PKHUWIm2vhOMM0J6UyJv5lbhsjdFn4BPDjRX5UNKJrZUewZEpz6s6RzFOojMTeM0EHnY34ItXqLC O/DGwUjegFBC+jjSiupgnxcOKcGvmdug8utBu8RJTsbnSL5vqcbZUdJ3rSGlH+J5pjTzw5ZqesKp lmpzs/gOJ7Uf0sx/nelHcjTWfozzlmr0zgGaaXKwubogHWqevdFPZbD/OAmv/cdYtQQL2vHeBiEf niZj7ceQkg8j+d7TJhCW4FiMuUn8AOzaYV+nngai9wi2H7sYqSzg8BJIWu8/axoElEBYMjeHH6Ef YdpYkEsayvnXwo22HxsoNQ9OqfFI6aT9eFraWm1K+/F/hBLSfjzWIy7JYIcYv5UEZykMv2cJAms/ BrGp8Vk20vhu5C7FDhkEFL7DpeIh0N/wz2I3/B5GbvjhxEVo4t1yfMYlFIbvMN2vikz4DqMfyHqD y+wBA/q1DOtrhYfJyMQFyPHib5fUS+ToxIW5f/6vANuPD7aWJ/sbhfeTw3xcz/6mCTuqg2LTinA8 cYF6HtqKV/kA6oPDmV+eLaydPOHEBXr1gFNK3wytuqa04qETF1yBqH0Ym6o198//FaA+7GiUI+1I Kx7JSCuelYO7L5PzAJ19xluhbsDpLg6j3YXohPo9ITo3h7caUI9zUcJqQLSsxa8+IJRGOkxyvCs2 TnCI5FEtjieyEHnYgfJQnQcnNo116qL6kFfVOjQDDxMuzYQonnpG2vo8h2NUxNG7SZCLCxv1E5v4 4/QVaRGH7UPP+MkmtA9ZwsMUf6cYBlvcvSSAAknFN5cUH94+yUqEjfzGSnUbJ88AVmr+C+y+FYec 0NmlBXnv65I78XRvZ2OXROAwgch0nY96Ht4u+iHQTByZMENbQI2+NQK/XdAT7jx+1Y2z52D0QOol OCjcWpXHNToHaPC86BRBFfp4Cu7MhHbiIUcJJuJUN2OCZ3haKaus/r1chZ+nlQxArr3QTrxicJSM TS5hnkf0AgVGgagNhqYDfH2uPT2gXp0PW4+NHyXkcy18tocvPP0CFl44fcVmNZcm+t4K4eCSsU48 1POsoEDAd8qwx+Tw1vrw6XB7Dc5yF92ON96Jh5nJBnlNjl/e8P5kvtHcXFCgF8hIJ967ihyYhhu9 E0cpWdm7oA8ztgxOLmtxNGT2FftotqaUdb0qyYTvIjiY4HeYmfyY1++VibtGlas63Axk6W/EESNV 5qVEB5CJRl8hwihZ27t4w/nGikbYI76Dl5lN/Scz9exIZ20xMBJslzTxvUlkvpGRmFEkakUmfcz7 JugpSl+wp6Ikb5/lcKGRjH2KOaEE5xv9o26gQ2Yr+OB08g1wStqKfFH3Md1I+qdbY3m5T5H3dTcN nMxHCmvG299Sz452icv4nEiap+lGwkZ99K8gjyGcjs3KydClq1ubH5e8rRDwYk1+l9FgJmzWp7C6 STKuNO098UtgtK1RTfQ3VxdmJIZRTX09U28m4HrIi+JZj0VNwE4r2p0zn7G/JEY7cAVLW23JPU6k v8lvnJ64HpzZDGbdvFcM3+afWVrX7f24bODrDzj/zzTtD58w2kD6jp9kc1lB53Q7xPWsbB3dr9JZ 3PuPqxt7hidVq8gGhU8/LYb6TU4m/2mUEOJ1G0vTw12vhbm8uBAfd8K53A7jZOdE8qHH3Mwqet7Q OSifXdJot/ewxQiQ15cfX+H/0+fQz2L06Whftw4Z1T8TpLMZsO/4/AsvkI0xgBOLk1nwTNwqGVEo l9a0cH/F4dGxHkdH8J/Pvyzh9Dv8J38lP/8HvuqdDl3PhHRS305iQv0+r9vpOSE7Y67dzisTve3s lymUCyuajU3d9i6GnZ2d3d29A8POlfNRwna0neyP+PG/8FVvomP0JXtpZ/2z/DvJTH+y87leSP/B Tu6UwAg2j19UUfuuq39EPqVULa2sajTrABqNZg38k1a3u3943rl87HzAPR8H0Oyffp5V0RNCTLSx opQPtIufCm4nRwR4uf72Sjpk/5KbN40Ry7mTW1L5qrHj/eDIuGJqRjk3r5qfn1MCzKuWVrW6vfO+ NYD+5R8eIEs64MbAo+/l9OsJoaODnc21hWmZpAUupEuKCDChk/psTgRXMpUeyU7JzCuuqKlv7ujp GxwakUGMjoyMjI59nJpb1uhgenEOhcBUeXdbq1lVr65BS39HSn/S4Aqk3S3NsnJiqKdRVJpzi82E qxD/ZL0j3PzlQCRR/BmspJSMnEdllTXiN02t7Z1d3d1dnR0dHZ09EukY3ChznsVE+jJhd2tdrVLO zgJnVq9v7ewfYEqj34WI7QxcmZ+UfWh7XVl0PzUeLqP704WVcCmgo6unTyAjmn0jLSunoPjJsyrR y1qAGpFI9LLuTUvv8CQy1GmyQiAm+HQI/vqXZj/KRkZk44ppFbKt6kROjw4P9nd3trRrS/NTYwNd jS/L8zNuxDL8LmIFJ3A+YCg3MjUgNCI2kcO7fZefI3hYAJAvEOQXFAtfNHQNTy6um/4IE6bL+1tr C1Oy/u5OYOoPQ+NTykU1Iqc7qJjqtrTr6P7NwZ5mceXj7LTkKDrVw/kilr9i6yjdyFdpQYwIVlzi NQ43JZXHS+VyualpmTlFleg48Z6Js07oOYF9tyDQ9Da/rn1ZK25s6xkY/TiNyClQUail6uVFuCV1 BNmSWirIvBkXDndK2V/Mil790lCSl49fIJ0RHhEVzQKIjopixSWnZhU8f/teduqS4kxOhmwA1nLD PW9flJcUPS59+kLc1CmRjsqhnCrn5uaUs9OTH8eGB953NNZVleVnwYVSfujS4QtaeoguRHeEC9G9 r1L9aP4BgYEB/jT/QDozjnMXVCAfTr+EY2yhEWS0twkXPLytepyTlZGR9aCgtLK2obmzt29gaHgU iumwtF/S3fbudU1FCdw4HMMIuPrn+9l+JAVNZU9wcnZ1I5E8PAE8PDzIFFoIi5NVUtM6oECmO88s QPTijEyKqZVwtUjRPd71xMTkG7eycoue6OUUoKOtubHh1QtkL3Rqckx4EJXs6mR/4VvJEVY2dnYO BIIjAoKjk4sHFXlCAa4IBbJ3ugD5J0JIfqNVK8ckTS+Ksm7GwTWjETFJ3HRUTp+/ENW8rBFVVQjL ivKzM29x2KywIF8vd+LFmuiElQVczm1lrYeNPcxs43g55YbZ76Nf7KQz5N1fUEK69eXZMUmzqPj+ zZjQAKoPlRbIiIpLuoHIaZ4g/2G+IDf7XkZ6CocdExEaSPUi/es71i30QCoQKiMBrtttH5Arl+EW t3+qqr6gm8p2dVq1amr0fZOohM+NoVPJJDc3EtmHFgzllJ3MuclNSeFyb1xPZsdGM0MD/a4iS+Mv 3Of+EeglRTg7Pa/8VYtkdEq1otnchrn58efPJ1UDlgyAnG5vZ2tDvTgrl3a/rS7mc2PpVGAA4MhE Vw8vH1ogPTScGRkVDbQ0kskICfL3vUomIfukL40QdklB9mcmpuWUiRq7B8en55fXNtDV1Ufo5jlY P8BkAC6S29pYW1HNfByWtIkrCrO4sSFUEGlsrNFN5gY5BaDRfH0oXp7ugM9FLUE1nZMlXDBOC08A BUiluKVHOqZQquCCcTQP2EMAkwHdJkhRlxfgjnFJ+xvRE0EGh4UwQjYiw33mQE6Jrm7uJKCkHiSS u6sL0ZFwwft3TQO2Bp4ReyNDUFb9uqWnf1iumJlbWFpRr2nWNyDWYTKwsqSam5mUjwz0tr2pERby byVFBfsgjJAfjMqpLeAF9RT8j4M9oGN94VuSTebk4kmlRyXx7j0sqxI3tvf2D8lAHjANqykE8zAZ mJDLhvp7O5pei4RFD25zYH7jbmCEsIJyaqmXU7jz2Rx0ME42sAAJCIu5duueoOSZSNzYCvMAKcgD xsYBxmQgGRjo6+1sbQTZQGkB//aNhEi67z/kN6iWmoPIKcC8Fu7wDmLGJqdmPCgoEVa9FL9519IG yqoegO6ujraWdw3il1XCkoKcuzxOfGTIReyf/TeBVL/OJG/foDAWm8PLuJ9bUFz2tLJaVPuqDqD2 paiq8mnZ44JcfgaPkxjDpCNbgi8+v7lIILm6owvJmxoYwmQlJN8EecD9B7n5BY8KAQoewmQgE249 TmCBbMAXEHJyACa6iDLh3wOyQd7R2Z1MAfVHWCSSB9zggrIKIgVJBuBu6hCYDZBcnBwuO9j8FoAK 2yBVFZlChXlAGMgDWKwYAFBZRTLDQoORDeIwG7C/uL3o/zKg+9naE4guIGfzplB9kbIKIgAkA1QK sucdyQYuP3r+PrD6wwHkAS6uIA/wJCPw9ECSASeCg1mygT8FUn4geQCsq5wQOKLJgA0SP/9jfDDA POAKlgfY2Jg/GbhAGOqq/wdc/uIv/uIv/uJy8H/8xqkkDQplbmRzdHJlYW0NCmVuZG9iag0KMjYg MCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDIxMS9IZWlnaHQgMTkx L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxz ZS9TTWFzayAyNyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNDA+Pg0Kc3RyZWFtDQp4 nO3BMQEAAADCoPVPbQ0PoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAK4N2FYAAQ0KZW5kc3RyZWFtDQplbmRvYmoNCjI3IDAgb2JqDQo8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAyMTEvSGVpZ2h0IDE5MS9Db2xvclNw YWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9s YXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzgyMD4+DQpzdHJlYW0NCnic7V35 N5tb93/VLMQUQirEFEIMMQVt2pDSUm0UUaWGSktpVKW0ah4bRYSQiinEFEKImQ6r/9r3nOd5Ejpc idblud/Vzw/vunett3fl073PZ+99nr3P/t///uIv/uIv/uIvTMHiCoClFQpLS/hvFpf9m34fFpCL tY2tnZ29gwOBQHBwsLe3s7O1sbay/E/ysoB0bO0cCE5EZ1dXN3d3Esnd3c3V1ZnoRHCAvP5jtIB9 rKwBHaKLG4nsRblKpfr6AfhSfa5SvMgkd1fAy87W2uo/wwoYyNrWnkB0JZEpVFpgcAgjjMmMiIhg MsMZofTgQJrvVW9PkiuRYG8LbPVfIAUJOTi5kLx8aIEh4VGsuITE5GsciOvXkhMT4lhRTAY9wPcq GbKyA6bCOymLK1Y29k6uHhS/IEZkDPvaTV56RtZ9/oMcgGz+vbsZ6Tzu9cQ4FjM00I9CdgOkbHBO CpjIjuBCotDozJikm7cy+XkFj0vLn1Y8rwKorHj6pLSoQJCdlZ7KYccwQwKoZHdnYKlLdT8LJM4g sLD4+XdcsbSxJ7p7+dEj4jm3snIelT6teiluaGxqbm0DaGl+97ZBXPui4snjh9mZPA47mhFI9XIn OthaXwonCyRkWoM4Ywsija2tjY31TwEGOJ2Ds4dPIDOOk84vKKt8Wf+urbNX0j8gHRqSyYak0oF+ SW9XW/ObOlFFacGDjJRkVlgglezqCA11wXSwKGNPAGGGSHQGIBKdHGGAsT7hNVesbAkuZN8QVnIa v1Aoqm/ufN8vkyvGlZNT0zMzM9PTU5PKjwq5bLCvp/3da9GzYkEWL5nF8KeQiA7gRF0kIXBAbOwc HIkuru4enmQvbwqF4u1NJnuQ3FyIjg52NigrC8jIlUwLi+NmPSwXvWnrHRxRTMzMqheXljUrEBrN 8uKiek41pRyTDbxvb6x7XirISmFHBlM9nQm2F8YJ5UNwcnHzAFHGjxYYFExHEBToT6NSvDzcnJ0c oBSD6GpDcPHyZ7J52cVV9W2SIcWkan5pRavTber1W1vb21tbev2mTqdd1SyqVZMKWX93s7iqJPcO J4ZBI7tcFCcLJAtwcnGHQTMoJIwZxYqNi09ISIiPi2VFR4SHBtGo3h4wvoCTBaSOTGMmpuc+ednU I1VMq5e1us2tnd39/YODQwQHB/v7uzvb+o311eV5lVI+0NP86lnh/ZSEcH8vV4LNBZwnhBDIAjwp vgH08KhYdjKHy7uVfvtORsad9DReyo1kdmxUGN3fB0ixIzhmwOvCE9MFwrq2D/Kpec26fnt3//Do 06fPX4z4/OnT0eHB/s725vrq4tyEvL/z7YvSnLREpj/ZxcHG8l/WPQskxhDdyT7+dCYr4Ro3LeNe jqCgqLiktLS0pLjoUX4OPzONmxwXBaTY28PdjeRNC2On5QnFHYMfZ5fX9TuAD2Tz9TsgvI4O93e3 NrRLs8phSXNteV56IpNGdrb/l7XcQIgayIiKv56awRcUlgqfi2rrXjdA1ItrRVVPy4ry7t/mJrHC g2lUH9/A8ARebrm4Q6pUr27u7B99OsHnG8BJWp+ODva2N7SLM4r+drFQkM4Op3k6O8CkD415508I y2sAoTBWIvc2P79YWFVb39jS0dXzXiLp65O87+3ubH3XUFslLMq9y0uOjQxjhEWxeTllr9qlygWt fu/wk5HPt5Mwsvp8dLi3rdOoldIOwCmNHUYjuzoR7JGY9y+UVBZIXuNxNYDBSk69m1skrBY3tnZJ +qXD8jHFx3EAhWJ0ZGhA0tXyprYSSPEtThI7kZP2oKy2dWB8Xru1D13uZz4nWUFSB7t67fyEtFMs zOUlhAdcJbu7ujhjJdW51h4WSF7j5k0LiU5KzRKUVNa+bevpH5J/nJhSzannFxYBFtRq1fTER7m0 r7NJXFX2MPtuRkaWoKym+YNiTquHjH5hoZ9IfTra31pbUErb657k8NhRIQG+PiDmgZLKzcWJYAh4 58IIxEyQ1wQxE7iZgpLn4qbOvqEx5fTcwpJGu7au021sbOh0ujXtyvLC3NQ4lGJxtbCkqKj4aW2z ZFSl2dwzMPo1ISMpaKj9La1aOdBWW5aTzomPZjJCQ0DIAxEPquh5FVQWV6ztHF3JfqGs6+k5xZV1 zd39I+PT6sUVJMrs7O7tQ+zt7uxs6XVazeLsBCDV0vCqRvSyvq1PPr2k2zlEGf0zoWNSgJN+dU7R 31pbJshK415PYrPj41iRYfQAqjfJ1cne9hxKD8jIyZ0SAEyUVSCsfdc1IJ9QLWrWNrZ29vYPjmCY gQDxBSjx3g5gtQTii1TS1d7W3jM4Nr24tr3/yQxGx5z2NjWqsQ+trypKHubwszJBzOPdTI6PBipK 8YAZ7Z+SAsJgTyT5BEclp+WUVDV0fJBPzC5pdSDIHBx9+i7KoAEGSPEmIDUJstGhIblStbSmR93O FCEDqS+fDnd0GpVioKOxTvT8mfBJWUlRQe79O6nX4iLoNAoJZH9/Fq5QRlQ6i5ORL6xtfi8bVy1p N7b3UD5ffwQmxRva5fnZ6akp1QJIGXYPESOZQwnldLQPOM0pZR96OlqaGt821Ne9rBIW598HZysi 2Bco+x+VHsDr7Ike1NBYblZhZX1H/9j0wipC6PP3QfPbd/EFBs31Vc3yMnBP+H/+Yjalb9hx2tat zE+Py2XSwf4PfZKeztbGuuryR9npnLiwgD8rPeA5Inr4hsal8IurG3uGlHMa3dZ3hH4+DBgpoBWb G2hS99l8RignIOU7m9DQM1OTE8rxj2Mj0g89rQ0i4SM+LymKTvVE0vTfcz7IiEQNjUvNLhE1SeRT C1osr/mnGIORQpI2IIJ7MEtF+JvL6JshPIGUD0QFzfISDHmzU8pRqaStQVQmyLgRx6CBNN3u9ziB eORI8gmJS8kufdnyYUy1tL51Iq/5x59kUIqjIyzrPoORjJxAHgsMDQqqzQ3dOggN6inF0PtWcWUR n8dmBni7AeX7DU4WljYEVwo9hssvrW3tV8xqdDun5jXfGeoYJmLsr/48/CsBMQGWU2jI02+saean FdLuRlFZbnpyZCDl9zgBaXDxCozi3CupaelXzK1s7hyYzgK+nUiwj2E+o2M7A1oogL1BRaVf16gn 5X2tdcL8jGtRQZDTmTXiipUd0ZPGTM4setEMGK1u7hqdzpwf9WeUfgwNUDH0a0sqxWBnfUVBJic6 GHA6aylvccWG4EZlsNMfPm+UKGZX9GYz+sWv+jNKaEF1uL+zsaJWyrrfVBXe5UQDO531egJxuyBW So6woUcOUk8jo7P8vPOA0VJI6bE4NdLbCDlFBVLg9cQZjpOFJVA7P+a1rJJXnbKp5Y1LY/Tt+9Jj fWla/h5wyrwWGejl4nAWibhi7QDULi69oLq5X7mo2zm4PEbfTpYeO7rlGcjpUUYydj1hPiVbJw9a 5I1sYUPv2BysSs8YXv4dUgZOvW8rH95ODPfzIJovexZW9sBI8bcLa9qGpo5ruMujZDDU0QHgND3S 0/BMcCs+lOruaGvucbpi7UiiRXCyhW8kH+fXzavhLo7T0pSsS1yekxITTHE1+zhZ2jl7B8elPxK1 y6Y1ejNruIsg9QWpPRYnpe21Jfc5UQFkc13PwtrBjRqWfO9Jg0RhNNJlM8I4wdpjbV7Z3/yiKCMp 3JdkpusBv/Pwj+IKqlqkU7gx0rdjTnqtWiFprBDciqMjrmcOJTsi9Lui2i75nBY3Rvpm5LSn16jk 3a+fZN802/Us7V19GElZ5W/6xhd1e0e4YWTgdAglQtpWA1wvjOpOsDGDkjUBZA6cnMpmxO/wY6Rv hiuXA3CcPn5orBTwYoO9XcwIuBbwKEWn5Is6hlWr24d4YmSUPf0qcD1x2X1OBM3DydakkF+xIZID Y24VvuoeVa/t4MnvvhmP0+7G0qS09UVBerxZCnHFluhNj7td8vq9Yh49SpfN4ySMrqdWvG8QZt+I hGayNEXJzpkSws4oawDqsIFI+GXT+A4G19NMy9priu4khFBcTZ6mK3YulFD23SeNIAnfhOpw2SR+ AKZ66wsf+94+zbkZhZwmU5RcrzISs4SN/RNLOKUEXG9fvzIj63iJmcnqdIHAOyXsUnZHtzAOzPQA nCaSo4nYBBwPUioHjodPSt9OmKmmMD2O7u1sd3qmh56lzLK3H5SoPFw2g59gNNNHyZty/nWmrzvh dIG4YutMoSdklDRIPi7o9nCneBCYmTTTQ20vHvJYgWTi6QIBQq0XyFofi3vG1Ou7eItLCDDRW1OP 9YpL7yYyfEwIhIW1EzmQxSt42Smf1eIte8CAmmlzeXKgqTLnJhSIUz3PAqSttKibedVtspmVrYPP eKX0+WBbqxrprAUCEexFtDvV86xAURt+jf/sHaLi5n/Fu0hATke7UCAanmQlm/Q8SyB5IezMUpjk oYcJf5S+YQIxJW1+ngs9j2B9GiUsFS+oQaqLA1wVTEaA3/T5cFs7KweelxYbZELz4GHyi7iRUwE9 bwMta3HH6YTnlWWyQykudqel4/Bm8ioItiXinlF8XT6cxLHmVWSDaOvmcOphAhUTlPF8eEW0vHnp 18e/BjTT4dbqjKzthYAb5e/hePphsia4U8OT75W97h1Ta7cPcHPt9R2g5+2szY12g8MUAw7Tqamr haWds1dQ7K2H1S2Dk0sbu5d/J/4rQEp78DDVl2Qk0CnOp0emKzYEki/z2r0ycbd8dtXw5QJnnNDD tKTsbxRmJTGuup6qD0AgoJlieILn7/rHF9Z38Ol6QMYPkMhUwb/GpLo5nH4DAczkTg1Lvltc2z6E fAXEo+sh+gCKpraq3BsRfiSC1amUgJmA6EVzHwjre+SqFT0OPjH9DEQfQJrXIQKSR/MgWJ9KCYqe 29WQ+PSHz9/1KdRoeyreOGGSJ++qLUhlBXieruLIB2gnDz/Y9yBqHVAurG3vn63B6UIA84c19WjP q0ewDHQyQQm2CTh7BUbf5JfVdcqmlgyfoC+bxXeAlNbVYz3iwlsxZlCCzRzwqzov71lD7+jsyhna Hy8MQMVRSkVmUQIKYetE8g1PyigStQxOLOp2DnF3DXFGKxkao5AOFUOrAC4pjfbUmXeWECGHCnEt q6S2UzYDewVwRumMivc/rOvGNwx6XpsUCASS6l02jZMwxKVOEZKKn17XYo5n6F8TtUonsR72y6Zx Amh1sTINsoccM7KH/6HjiW4UOoubDWV8WrOBNyvBS6J9/fLkYBPI8cKpbvYmvzLBRlCvwMhrmYVV SAKhx5k8IFd5e7rF8b43T+6yQ01l4khrq4ML2Z+ZdDu/oqF7GIu1OKKEfJIB6gAF7zFyk2fiIxPs endGxhMFT8WdUuW8Fm+hFr2cRI7Si/yUaH/P0+9b0dZWD78wdroADvONq5FuXTwlRKiRgN8pPzQ+ 5V9nUt1NCB7Ub3dqaPytXCEyzLeyYeiovmwqGAwfobWz8q5Xj++AOv30Sy+sazI4JuXBkzpsPNEw l3DZXFAYWgWAkfqbnueBqOTpdPqHQAukozqSc6+ktm0QOUeHhlGYyyYDYejN29evqEa66kruJjGo bib8DtZ/Pgz2nUcvmvu/H0/EAyVjV+i2Vq3oa6zIS4XfzE7/tGlhCat0Fjf32Zv3Y2aMJ14ojnt3 t9cXlYOtNUUZiQyqyS+b1rDtPeku7Kie0ejNGE+8OBg6rA/3ttYWJ4c668r4WAvb6X6H3B+nCp43 IR3VhzhjZOiDX5iUdb1+mseDjYYmjGRh5eDqw0jMLKnrls9qt3B1h4cdo4OdzdX5CVlXfUV+OjvM l+RkqknAxtGDFsXNrYBGgt9i8CPeWAMRsNGqWintbKh4eAf2wBNNNRFh/cdFtZ0juPtihn5K3wNe pxzqrK94mJEcGeDl4mBzekeehRXaf1z+RjK+oNvF1wczNGmAjaDDPQ0VBYBRoLfp5y6A3kG/yzvZ f3zZTIww9EyqFZJ3VYWZ15EJGZNTP1DvgmKN/ce4YvQNa5lcnpJ11Jbyuaxgs+bNLLEWIrTfBmff 0w2teCC1qyq4DcWOaMZUoJU91vUwMLm8ibemyWNKjZVo6zvBNCOkNyXyZm4VLntTDAn4xEBzVT6k ZGZLtWdAdOrDms4RrIPosmmcBCIPe5uwxUtUeAfeOJjIGxBKSB9HWlEd7PPCISX4NXMLVH49aJc4 ycn0HMn3LdU4O0qGrjWk9EM8z5xmfthSTU840VJ92Sy+w3HthzTzX2f6kRxNtR/jvKUavXOAZpoY bK4uSIeaZ2/yUxnsP07Ca/8xVi3Bgnast0HIh6fJVPsxpOTDSL73tAmEJTgWc9kkfgB27bCn10wB 0XsE249dTFQWcHgJJK33nzUNAkogLF02hx9hGGFan1dIGsr518JNth8bKTUPTmrwSOm4/XhK2lpt Tvvxf4QS0n482iMuyWCHmL6VBGcpDL9nCQJrPwaxqfFZNtL4buIuxQ4ZBBS+w6XiITDc8M9gN/we Jm744cRFaOLdcnzGJRTG7zDdr4rM+A5jGMh6g8vsAQP6tQzra4WHycTEBcjx4m+X1EsU6MTFZf/8 XwG2H+9vLk30NwrvJ4f5uJ7+TRN2VAfFphXheOIC9Ty0Fa/yAdQHh1O/PFtYO3nCiQv06gGnlL4Z W3XNacVDJy64AlG7DJuqveyf/ytAfdjWqobbkVY8kolWPCsHd18m5wE6+4y3Qt2Ik10cJrsL0Qn1 e0J0bg5vNaABZ6KE1YBoWYtffUAoDXeY5XhXbJzgEMmjWhxPZCHysA3loToPTmya6tRF9SGvqnVo Gh4mXJoJUTzNtLT1eQ7HpIijd5MgFxc2GiY28cfpK9IiDtuHnvGTzWgfsoSHKf5OMQy2uHtJAAWS im8sKj+8fZKVCBv5TZXqNk6eAazU/BfYfSsOOaGzS/OK3tcld+Lp3s6mLonAYQKR6Tof9Ty8XfRD oJk4MmGGtoCafGsEfrugJ9x5/KobZ8/BGIDUS3BQuLUqj2tyDtDoedEpgir08RTcmQntxEOOEkzE qW6mBM/4tFJWWf17hRo/TysZgVx7oZ14xeAomZpcwjyP6AUKjAJRGwxN+/j6XHtyQL06H7Yemz5K yOda+GwPX3jyBSy8cPqKzWoujve9FcLBJVOdeKjnWUGBgO+UYY/J4a314dPB1iqc5S66HW+6Ew8z kw3ymhy/vOH98XzjZXNBgV4gI5147ypyYBpu8k4cpWRl74I+zNgyOLGkw9GQ2Vfso9mqSt71qiQT vovgYIbfYWbyY16/VybuGlGt6HEzkGW4EUeMVJmXEh1AJpp8hQijZG3v4g3nGysaYY/4Nl5mNg2f zDQzw521xcBIsF3SzPcmkflGRmJGkagVmfS53DdBT1D6gj0VJXn7LIcLjWTqU8wxJTjf6B91Ax0y W8YHp+NvgJPSVuSLuo/5RjI83RrLy32KvK+7YeR0eaSwZry9Tc3MSJe4jM+JpHmabyRs1MfwCvIo wunoUjkZu3T1q3NjkrcVAl6s2e8yGs2EzfoUVjdJxlTmvSd+AYy2tOrx/ubqwozEMKq5r2cazARc D3lRPOuxqAnYaVm3feoz9hfEaBuuYGmrLbnHifQ3+43TY9eDM5vBrJv3iuHb/NOLa/rdH5cNfP0B Z/+Z5v3hY0brSN/xk2wuK+iMboe4npWto/tVOot7/3F1Y49sQr2CbFD49NNiqN/kZPafRgkhXre+ OCXrei3M5cWF+LgTzuR2GCc7J5IPPeZmVtHzhs5BxcyiVre1iy1GgLy+/PgK/58+h34ao0+He/o1 yKj+mSCdzYB9x2dfeIFsjAGcWJzMgmfiVsmwUrW4qoP7Kw4Ojww4PIT/fPZlCSff4T/+K/n5P/DV 4HToeiZZV0NF/u0kJtTvs7qdgROyM+ba7bwy0dvOfrlSNb+sXd/Qb+1g2N7e3tnZ3TfuXDkbJWxH 2/H+iB//C18NJjpCX7KXdtY/y7+TzPQnO5/phfQf7OROCYxg8/hFFbXvuvqHFZMq9eLyila7BqDV alfBP+n0O3sHZ53Lx84H3POxD83+6edZFQMhxETryyrFQLv4qeB2ckSAl+tvr6RD9i+5edMYsZw7 uSWVrxo73g8Ojyknp1Wzc+q5uVkVwJx6cUWn3z3rWwPoX/7BPrKkA24MPPxeTr8eEzrc395YnZ+S S1rgQrqkiAAzOqlP50RwJVPpkeyUzLziipr65o6evsGhYTnEyPDw8Mjox8nZJa0ephdnUAhMlXe2 dNoVzcoqtPR3pAwnDa5A2tnULqnGh3oaRaU5t9hMuArxT9Y7ws1fDkQSxZ/BSkrJyHlUVlkjftPU 2t7Z1d3d1dnR0dHZI5GOwo0yZ1lMZCgTdjbXNGrVzAxwZs3a5vbePqY0hl2I2M7A5bkJ+Ye215VF 91Pj4TK6P11YCZcCOrp6+gQyotk30rJyCoqfPKsSvawFqBGJRC/r3rT0yiaQoU6zFQIxwacD8Ne/ OPNRPjwsH1NOqZFtVcdyeniwv7ezvalbXZybHB3oanxZnp9xI5bhdx4rOIHzAUO5kakBoRGxiRze 7bv8HMHDAoB8gSC/oFj4oqFLNrGwZv4jTJgu722uzk/K+7s7gak/DI1NqhY0iJxuo2Kq39Stofs3 B3uaxZWPs9OSo+hUD+fzWP6KraN0I1+lBTEiWHGJ1zjclFQeL5XL5aamZeYUVaLjxLtmzjqh5wT2 3YJA09v8uvZlrbixrWdg5OMUIqdARaGWapYW4JbUYWRLaqkg82ZcONwpZX8+K3oNS0NJXj5+gXRG eERUNAsgOiqKFZecmlXw/O17+YlLilM5GbMBWMvJet6+KC8pelz69IW4qVMiHVFAOVXNzs6qZqYm Po7KBt53NNZVleVnwYVSfujS4XNaeoguRHeEC9G9r1L9aP4BgYEB/jT/QDozjnMXVCAfTr6EY2qh EWS0uwEXPLytepyTlZGR9aCgtLK2obmzt29gSDYCxVQm7Zd0t717XVNRAjcOxzACrv75frYfSUFT 2ROcnF3dSCQPTwAPDw8yhRbC4mSV1LQOKJHpzlMLEIM4I5NiGhVcLVJ0j3c9MTH5xq2s3KInBjkF 6Ghrbmx49QLZC52aHBMeRCW7Otmf+1ZyhJWNnZ0DgeCIgODo5OJBRZ5QgCtCgeydLED+iRCS3+g0 qlFJ04uirJtxcM1oREwSNx2V0+cvRDUva0RVFcKyovzszFscNissyNfLnXi+JjpmZQGXc1tZG2Bj DzPbOF5OuXH2+/AXO+mMefcXlJB+bWlmVNIsKr5/MyY0gOpDpQUyouKSbiBymifIf5gvyM2+l5Ge wmHHRIQGUr1I//qOdQsDkAqEykiA63bbBxSqJbjF7Z+qqi/oprIdvU6jnhx53yQq4XNj6FQyyc2N RPahBUM5ZSdzbnJTUrjcG9eT2bHRzNBAv6vI0vhz97l/BHpJEc5Ozyt/1SIZmVQvaze2YG5+9Pnz cdWAJQMgp9vd3lzXLMwopN1vq4v53Fg6FRgAODLR1cPLhxZIDw1nRkZFAy2NZDJCgvx9r5JJyD7p CyOEXVKQ/ZmJaTllosbuwbGpuaXVdXR19SG6eQ7WDzAZgIvkNtdXl9XTH2WSNnFFYRY3NoQKIo2N NbrJ3CinADSarw/Fy9Md8DmvJajmc7KEC8Zp4QmgAKkUt/RIR5UqNVwwjuYBuwhgMqDfACnq0jzc MS5pfyN6IsjgsBBGyEZkuM8cyCnR1c2dBJTUg0Ryd3UhOhLOef+uecDWwDNib2QIyqpft/T0yxTK 6dn5xWXNqnZtHWINJgPLi+rZ6QnF8EBv25saYSH/VlJUsA/CCPnBqJzaAl5QT8H/ONgDOtbnviXZ bE4unlR6VBLv3sOyKnFje2//kBzkAVOwmkIwB5OBcYV8qL+3o+m1SFj04DYH5jfuRkYIKyinlgY5 hTufL4MOxskGFiABYTHXbt0TlDwTiRtbYR4gBXnA6BjAqBwkAwN9vZ2tjSAbKC3g376REEn3/Yf8 BtXSyyByAjCvhTu8g5ixyakZDwpKhFUvxW/etbSBsqoHoLuro63lXYP4ZZWwpCDnLo8THxlyHvtn /00g1a8zyds3KIzF5vAy7ucWFJc9rawW1b6qA6h9KaqqfFr2uCCXn8HjJMYw6ciW4PPPb84TSK7u 6ELypgaGMFkJyTdBHnD/QW5+waNCgIKHMBnIhFuPE1ggG/AFhJwcgInOo0z494BskHd0didTQP0R FonkATe4oKyCSEGSAbibOgRmAyQXJ4eLDja/BaDCNkhVRaZQYR4QBvIAFisGAFRWkcyw0GBkgzjM BuzPby/6vwzofrb2BKILyNm8KVRfpKyCCADJAJWC7HlHsoGLj56/D6z+cAB5gIsryAM8yQg8PZBk wIngcCnZwJ8CKT+QPADWVU4IHNFkwAaJn/8xPhhgHnAFywNsbC4/GThHGOuq/wdc/uIv/uIv/uJi 8H9kGKkiDQplbmRzdHJlYW0NCmVuZG9iag0KMjggMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBl L1RydWVUeXBlL05hbWUvRjQvQmFzZUZvbnQvQUJDREVFK0NhbGlicmkvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDI5IDAgUi9GaXJzdENoYXIgOS9MYXN0Q2hhciAxMjIv V2lkdGhzIDEzNjIgMCBSPj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmkvRmxhZ3MgMzIvSXRhbGljQW5nbGUgMC9Bc2NlbnQg NzUwL0Rlc2NlbnQgLTI1MC9DYXBIZWlnaHQgNzUwL0F2Z1dpZHRoIDUwMy9NYXhXaWR0aCAxNjkw L0ZvbnRXZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDUwL0ZvbnRCQm94WyAtNDc2IC0yNTAg MTIxNCA3NTBdIC9Gb250RmlsZTIgMTM2MyAwIFI+Pg0KZW5kb2JqDQozMCAwIG9iag0KPDwvVHlw ZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTAxL0hlaWdodCAxMzgvQ29sb3JTcGFjZS9E ZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUvSW50ZXJwb2xhdGUg dHJ1ZS9MZW5ndGggMTI1OD4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEBAGAAYAAA/9sAQwAIBgYH BgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04Mjwu MzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIy/8AAEQgAigBlAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAAB AgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNC scEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY 2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//E ALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoW JDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp 6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A7ELTwtPC04LXl2OsjC0u2pNtO207CuRbaNtS7aNtFguQ 7aTbU22kK0WAgK00rU5WmlaVhlcrTCtWCtMK1NgK5WipStFKwy+FpwWnBaeFraxAwLS7akC07bTs BFto21Lto20WFch200rVjbTStFhkBWmFasFaYVpWArlaYVqcrTGWpaGVytFSEc0VNhmgFp4WnBae FraxA0LS7akC04JVWERbaNtTbKNlFguQFaaVqwVphWiwEBWoytWCtMZaloZXZajYVYIqJhUtDICt FPI5oqRmkBUirSKKmVa3SMxFSpAlPValCVaQrkGyjZVnZSFKdhXKpSo2SrhSomWpaHcqMtRsKsst QsKloorsKjYVYYVCwqGNEBFFPI5oqbDNNBVhFqJBVhBW6M2PVamVKRBU6LWiRLGBKClWAlIyVVhX KjLULLVx1qu4qWhoqOtQOKtOKruKzZSK7CoWFTtUTVmyiEjmilPWipKNRKsJVZDVhDW6M2WkqwlV UNWEatEQy0uKa9MD0jPV3ERvVd6mdqgc1DKRA9Vnqw5qs5rJlIhaoWqVqias2URHrRQetFSM0UNT o1VFaplatUyWXFapleqatUgetEybFsPQXquHoL07isSM1QO1BeomapbHYR2qu5p7NULGobKQxjUT GnsaiY1DGMJ5oppPNFSUXAalVqrBqkDVaZJZV6kD1VDU4PVXFYtb6TfVffRvp3FYmL1Gz0wvTC1J sdhzNURNBao2apbGDGomNKTUbGobGITzRTCeaKkZZDU8NUK04VYiYNTt1RClFO4Eu6jdUdFFxDy1 NLU2mmi4ClqYWoNMapYxGao2NONRmpYxCaKYaKQz/9kNCmVuZHN0cmVhbQ0KZW5kb2JqDQozMSAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNjcvSGVpZ2h0IDEyNC9D b2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2Uv U01hc2sgMzIgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTAzPj4NCnN0cmVhbQ0KeJzt nMFywjAMBZ32//+5GTT1ZEoIjm1ZK/r2BoTorSUnXEIpAsr2IDrFKLvC94PsOiby9Utelz255Tfy 6lSR+vKoFpvtFhb7+c10Oqci9aNEOhci9YA/48fkrcjxMHJrGkUKftLaRerxTJ27IvVbtI3TJ3L8 LqQ1IyKFNGlTAhB0JpaO3TjT1zCqNR4VQybNr9ZiHe8qyzbOsuXybs2yMfaetMWXFz+dkFuYx8aJ vRdPbE3sb6SJkxYrcswwqEMQMQY3DkfE6G4NTaT0ThpQxLirgxUx2jcOXMRoaU0KkdIwaVlEjItJ yyVinLpIJJbn2BKJRSI0JEJDIjQkQkMiNCRCQyI0JEJDIjQkQkMiNCRCQyI0JEJDIjQkQkMiNCRC QyI0JEJDIjQ+W2TkqbcoXomka8rpIG3RT9518CqtvZ9I5zpnIp2WhFuGv7BoXGp+a24FI+t0RGLq dIc56kxP1cHgqnJaM54BMmmzqofrzK0buHE8FjCkNU7l1k+aa6GVOstKfOTT637n9zjzq3JOrVl/ 2XeatNj710c+vT7lVFNSjWQYbw1BpMyYNIiIMaKDEjH6dIAixt3rAFbEaG8NXKQ0TxpfxHirk0XE uNg4uUSM09ZkFClPk1ZfRufqpObfsb+/ztiUirmYSHSWCSTdI/+EH52rCM4NCmVuZHN0cmVhbQ0K ZW5kb2JqDQozMiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggNjcv SGVpZ2h0IDEyNC9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNv bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzk4 Pj4NCnN0cmVhbQ0KeJztmeluqzAQRk0WCBC27OyL00bVVav7/k93bQNJSgzYY6SmV+F3deIejQfm G4QmeBYrfaZGmHtp7C01FcQy/PqqDvZCAaFHn3/ecLY153BE+J7sE4zjwIAq0UO8061dhsvQBSoh iO0MLdaH4lwc1iAlNQJpSzcscbazAEoaBIEYQVzhJFhJKzFaBCkRc5viKvR0SSV3CNQoOUoqIYjN 7ehEyUlayXcEVeJTJRsJJV0EQjOmJBJXYkRdBFFiH3KixBFUYkTVA4IocSSUcBFySnoQMkpWfQiq ZM+ULAUQvb/DlOT7ESUEEfQfVdP9qMLpsJJhBFWyoUr8ASVjCHL7qJLy1K9kFY8hmJKCKLF7lIgg iBKPKtmaXCVCCKJktUlwFfsG528FEUSJtSc9+sTp0cIIUmrOsThzlEgg+pQQhC/eK7lK5BBUya6r xJRE0B5Nldy9tsxEFkGVhBV9k89aRCmLoEoCqiSolYAQrZKQtVcgon5tveXeXAFBleSX0FBBkP9m d05NhvCgCM0vE1WEVyYWQpYaIqWI9IWYGAEk3CFcMMKdAFGkNkJ2Wigjsh9FILfIXoguwgEjnEkQ a4TWSoj8ORA5ReT5C3FDrMGI9SQIpz3L/4BgN+V3I7IJEIXTNh7gY0+FcH8e4T4HQnsaRKqASBmi VDiFVSMqHIDT0hphpZeMO4mLIUqCWPjZmTuJCyLod+/D2CmPYGMnMC29fX2TsTPGkLT0/gN+bu4g aen3GYBGg1g2Le1MZSwtPWdjOdgQApKWcmbDNgcTLTXuhHrNwYQgPaP20jkWOBfbVfRN69fQZ9xr /8B/TTjGvA5lBk3CMVZqw7EDTThGS82MB5MLkV3FaBw1XmoCidZYCi0Uii0GS00sINSaFJpbaqIZ 40DkKh5T9kauFCF6ref8tZgMomn03bUYTcAl+q2mP5aaJIIoeViLSSPatdit1ACI2w6oTvd7lyuD T70Wa6JsGILdPrbwIKUGRbBGn7BGb4ER13T/UJzBiCbdv3x+bOEI9k3x/vdD4RSI3r5tEtlK+3Wi xDDgi/G75x/riGiHDQplbmRzdHJlYW0NCmVuZG9iag0KMzMgMCBvYmoNCjw8L1R5cGUvWE9iamVj dC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDYvSGVpZ2h0IDYvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0 c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggOTc+Pg0Kc3RyZWFtDQp4nBXLMQuCYBhF4fPe+/2N9kAXkYiinERBLEIhaGmxKef+f37zeQ6V OZuLOZoyxS7RioeYxSiupkhMYgm+wTsYxME8gzX4wSe4Kb935bqxV9CL2jTOeKudOJl9+gMvMQqL DQplbmRzdHJlYW0NCmVuZG9iag0KMzQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt YWdlL1dpZHRoIDE4L0hlaWdodCAxMS9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9u ZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvU01hc2sgMzUgMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggOTE+Pg0Kc3RyZWFtDQp4nLWQORKAMAwD5SMZbvj/a1FgJi1KwdZr2TLwO9VxVlVOw1aw F6R/y2aYAldtK0wId8OaLT8U+2GO5rvs02RZ5fgO5UP+zwtbLzk2wuKcGoJXpVy8cwN7oAFDDQpl bmRzdHJlYW0NCmVuZG9iag0KMzUgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl L1dpZHRoIDE4L0hlaWdodCAxMS9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAv Qml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggNzE+Pg0Kc3RyZWFtDQp4nGNgwA8ELONYkbicusERxjwIvoxrvK0Ekrx8QJAGCxKfxyNY EcU8hVgjVAuMowRR+IzOPuwoApz+TmhuitFHdyUAAyUHoA0KZW5kc3RyZWFtDQplbmRvYmoNCjM2 IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAyNS9IZWlnaHQgMzUv Q29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ZpbHRlci9EQ1REZWNvZGUv SW50ZXJwb2xhdGUgdHJ1ZS9MZW5ndGggNzQ3Pj4NCnN0cmVhbQ0K/9j/4AAQSkZJRgABAQEAYABg AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAx NDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAjABkDASIAAhEBAxEB/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAEC AwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHB CSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0 dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX 2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDtdF/hruIf+PBq4fRf4a7iH/jwauuv ucmH2OR1r+KuZrpta/irma6aXwnNV+I3NF/hruIf+PBq4fRf4a7iH/jwauavudOH2OR1r+KuZrpt a/irma6aXwnNV+I3NF/hruIf+PBqKK5q+504fY5HWv4q5miiuml8JzVfiP/ZDQplbmRzdHJlYW0N CmVuZG9iag0KMzcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE4 L0hlaWdodCAxMS9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJw b2xhdGUgZmFsc2UvU01hc2sgMzggMCBSL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODc+Pg0K c3RyZWFtDQp4nLWQURKAQAhCUVebaaq9/23DToAf8c0TEPhdBhyBZao/HU/hSglxw7mwC+VQEsL6 OBHX+tB1Z/vl+j2WEaYD6LGkdPE2I2ISwb172Mq/X031AnFGAUENCmVuZHN0cmVhbQ0KZW5kb2Jq DQozOCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTgvSGVpZ2h0 IDExL0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50 IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3Mz4+DQpzdHJl YW0NCnicY2AgAMTs9JG5fCZRIfqscC6jkm+spTBCmlEjyksRWb1kmLcoMp/JPloWxXzuIAcWFAHR GB1UF6jEyqAKqEYKoDkSAPDYB6ANCmVuZHN0cmVhbQ0KZW5kb2JqDQozOSAwIG9iag0KPDwvVHlw ZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvTmFtZS9GNS9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaSMy MEJvbGQsQm9sZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2NyaXB0b3IgNDAgMCBS L0ZpcnN0Q2hhciA5L0xhc3RDaGFyIDEyMS9XaWR0aHMgMTM2NCAwIFI+Pg0KZW5kb2JqDQo0MCAw IG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BQkNERUUrQ2FsaWJyaSMyMEJv bGQsQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0Nh cEhlaWdodCA3NTAvQXZnV2lkdGggNTE4L01heFdpZHRoIDE3MzIvRm9udFdlaWdodCA3MDAvWEhl aWdodCAyNTAvU3RlbVYgNTEvRm9udEJCb3hbIC00OTMgLTI1MCAxMjM5IDc1MF0gL0ZvbnRGaWxl MiAxMzY1IDAgUj4+DQplbmRvYmoNCjQxIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9J bWFnZS9XaWR0aCAxOC9IZWlnaHQgMTEvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBv bmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDQyIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDg3Pj4NCnN0cmVhbQ0KeJy9kMkNwDAQAtkzcpSr/2pNnAZ2P+E9IAD4QwKYNHhXnIEj UDExeXfcidQSH/rCwyC1SuSfFV4UU1l+syqPNeFKaOci9uE/LfHV4T0Lh9SHf5pO4AEtDQplbmRz dHJlYW0NCmVuZG9iag0KNDIgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dp ZHRoIDE4L0hlaWdodCAxMS9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0 c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggNzI+Pg0Kc3RyZWFtDQp4nGNgIASk1FC4fEbhwRIILrOab6ylEILPbhbnIYOknMk03ooDWb9Y mCMnioFaMfKoFtoGc6PwWQ09mFEE2MMt0dwIALfIB0YNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTkvSGVpZ2h0IDExL0Nv bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9T TWFzayA0NCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA5MT4+DQpzdHJlYW0NCnicvZA5 DsAwCATHgJ37+P9rgx0pNTSZgorRahd+QgqrJf4LTMrdWLS7EUw4G5uhsX+nSY/wGzawwjWUFHtl ydRnLOZBwe4fPsJRE3VeqvTdsnipWdPWA3xvATwNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0NCAwIG9i ag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTkvSGVpZ2h0IDExL0NvbG9y U3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJw b2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3ND4+DQpzdHJlYW0NCnicY2Ag BJhUvHlRBKQd4z2UkPicRtH+2uxIAlxW8TZCyDoY9eMs2VDM4A/x5ES1RilOGc1iowhhNJeYBLKj qQlyYkYTAQATwQeTDQplbmRzdHJlYW0NCmVuZG9iag0KNDUgMCBvYmoNCjw8L1R5cGUvUGFnZS9Q YXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0Y2IDUxIDAgUi9GMyAxNCAw IFI+Pi9YT2JqZWN0PDwvTWV0YTQ3IDQ3IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9J bWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDUzIDAgUiA1NCAwIFIgNTUgMCBSIDU2IDAgUiA1NyAw IFIgNTggMCBSIDU5IDAgUl0gL01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDQ2IDAg Ui9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9T L1N0cnVjdFBhcmVudHMgND4+DQplbmRvYmoNCjQ2IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDE0Nzc+Pg0Kc3RyZWFtDQp4nJ1YXY8aNxR9R+I/+HEmKsbfHkdp2mbz0W6Vdtus lIdNHwg7YYkWhjBsK/XX914PLONhLrBdCcSCz/X1ucfXx8PGV+zFi/H7i19eM/HyJXv1+oJ9Gw4E E1wIIZUSnnklmDWCrcvh4OMzthwOJJs9jhHCSWGSQV+eDQd/DAfszfsLxloTyO0Er66Hg/FbyYzh whl2/QUjQjgmmVKKB8OMLbgN7HqB08S53g0HN9nHu0lusw3LTTav2YTlI5U91GU+0tn6h/wvdn05 HLyB4DjBLqIJnkvXjniTsdbYgyxVJ0upkgydF9w5pgQPqmgy5Fb7mGX8EDO1RDbOO+6LNvpENnpf lNGWbxlCaLhXxkjTUx/Di9DMqLmU2jFtHHeBSes5/DCFacfvy83EePa6Yn2lMl0SLA8u4cForpgR gXvbqRPmpiS7nt5kt0uKB9HGIsIoHyHPGUkdd0WCQkK0bGaaUjMVihfKpLNFxPcEIAjuTQK4yX6u FmWus0t4fZgvViDCOh+5rFp+RwSRAbWdBqmIsUoobjpju8mN37qeGigJkkuBt/nIZNUCt8RkTnGi LCB0ChxRY53hrjPJEieZLGAblgd59mlFC8lhZyQxqDJrYbmx9NgDqdoeqRbmUKu6iHvgUTkGN/Yx 5UDH0CkM9eb0CZk6LjuoCAAJgWzKde5ARqaRUZHVFTW7hD4DnaIViOZMetjxrjsWBMrgDzT7tM+U Dix38rx8lAtcHRl7UEN3XrsB8lGL2+30+Ws53Vzc5yObTeqaokY6rlMglA4OEahBtSIJNSGS34Y9 EsRQ/f0fMBeaQRW4PQh6hBXfYiXlwQisxf/gYQ8ke+42jQ+ryfIxk6InE6kMl+2Izdfr2e7Tn+8e xb8C3cuAam/PtAdgLAHUaM+9R18AtkDiNzs7kapdRR77Zj7BaCAZlZ5bf2A4nsTtPsSTuJWCJred FUluFbmd5VJlkyU2/jn6on/j/1Hp8F/8qlpO4kquciWxEylxuiLS4EkhddyQZEkUaBoS7c33RElk 1xVS/VvBkdq1GtsK4SrPK9I+CNnMe2ukyBq10yJLBCcx8F/mUmSb36FcPptdIf1YBHmyCCpI7KMB nExxpAZoKk1vPqdKoM9rv8pLNCrdEiwmUV33+EYei77grh0ADsTL/Rn44+eHaOLhHFrWU/iu4tPc o48hWin4WWgUSTyy7VqBEibHHtJhqC6hTMGN2saYzVFwf0Oy5XI5wcUvum5orz3oaAn8LMcL1y+U bBu1sxLoRtcUDCxI0Un2+IItuWBluS72nknAlokp1KRp8hw2bxt3lre33KazNSvdmW3aJYHoXYI8 tVZHrhVsuN7xtapq0N8m9tB7PN1/ur2Ffeuykm4w2iDfrTDnFdkorjqwiPBQYgMv1Zgz6BNvcqUa wcXePYOEwFGW4GSgf4y0yK7zIuCPFrShXDaZUoJU4MxMSJd8nDbSi0gPXq9V6tC46ntywRb2Qopq Sr1az5czpPrL44FV3t+SdTfIWivMqQX0WZhmAdZxuCDuNL69FdQbOn2fgs4SOFzxUlAc/2uU1BJK Gk/punpYz4+sWCcxTq2YNDtS4zsh9Ivqlm5jFk+YPfzMLqbhQt1GYSexsoEJ+NmQUFdwoZIJI+j4 85s+P9WsG67LcncE4AWgvC9Xd9Wy/O1h8bmk26nCy1UChsWOQvYpI+9jlvsUUcAu3r0+5bifXWbh c/MidqnGZxdpHPKa3ljn1tiEZgl/Ry5rQSfIc1iWFMuF5yLs0v26Kmd4sl/dRQO6gdZEPQaReONv o5/kolWvQwM/6pKMjni0O7iZx30Qt+LqOaY9HkPC/+DFb/vmiozjD3XsTzv7UsfvpnkAx4KIu90B LYVsxn9dzY6yuXNgLe+HubMCNr22cJYbfPiVeL/DIH2+RYN6tU4p2Fu34yVOn6xoyhY6MKl2W/AX Qtvw8pxnQtBHoY+1sYfZ/AdruosXDQplbmRzdHJlYW0NCmVuZG9iag0KNDcgMCBvYmoNCjw8L1R5 cGUvWE9iamVjdC9TdWJ0eXBlL0Zvcm0vUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNDggNDgg MCBSL0ltYWdlNTAgNTAgMCBSPj4vRm9udDw8L0Y1IDM5IDAgUi9GNCAyOCAwIFI+Pj4+L0JCb3hb IDAgMCAzODguMDIgMjQ2LjkxXSAvTWF0cml4WyAwLjE4NTU2IDAgMCAwLjI5MTYxIDAgMF0gL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjQzNz4+DQpzdHJlYW0NCnic7VpNryU3EV3zpPcfejmR iMflb7NCiCRkkBAoT8oiYREeMxNgXkLCR8S/5/iju12+t+71jg0a6c091afddrmOXa7uHx4fbMoq uk3j38fGRRX9phW5lP1mXFDebc8vjw+vP3/55v1bl7Zff7/94fGBtvf4ExQF2ozNhfUyGz6g7WiV 4Qavct4NNiZl8BgblUkncspvz4VbMSUVc2w3N0NQOtPWmyKrkjVbf1JHz0dfugF345dNOyZSVOit qR21J5WbmeEWOsmt3x8GXEfVHtsHzB30fMVj3664FaR3jw9a5ZDIbz/h5/bZ48NG25sNf/66/X9m /ocz88Xjww+PD8bhWRtp+CXgSUZ5/EdRWb/9+Pbx4cvtuzLuai7K65fYXafsvO6y+9UTTJ9Wz2sX t6d3RYn1/s1a5SzmTzvlaHt6KUEBjX716jcf/XF7evP48MlTu3+/wXlFePpww1evvhe43qkUDOe+ CNwAX+jMuW8FLsIm0MT9UeAmh6CauD+TuFk5Zzn3jcDNXvm5XSVwSWvlFvtAIKWpD19IXMRijJz7 F5GbsDyvzUWJsDTN8d8lrjPKTXP8D5GbVXBrsUM+Kzu1+93Eff0pFOiU1sRj2kEU0HWMxTu3XQjl aCiIcaWhuqScTpwrhZ3HKuEmrjQ1HtulmfowD/WQCZa7aDn3vSQTDUkZzn0ncZ2auyB1F5xsHOdK Si3qm9v9IHERoH7q7p9vqG9uV1JUTirHifs7UX2prvEj91+iorwKgXOfJa4hLBdrfiCDFcCs+Zcs XXC/EblJ+bXoJYfwzWvuJWR7aQqH34uihjTDoht8vHCZOLSA8M1rCqJ4ORX/FLj7ShL0+koycqX+ lnyZLOdKyvSkwtyuFA4eM1z8O3KlsWElMXrqw39ubM5p4krxgLxN+8S5n0tchI6e/CvNWyorlONc aaOpZxPiXGlVz1HplNf8WzZnPbUrSl5nlf3aXBB2sXls4saIpSRPcyzpGPGrrav7OfKwxv36lURO 2HAzJyc5C3QxrXE90tXVdrHph7ndrz+SIzi7iSxFZYiKNHGul/dCimGNmwhO84tc5A8T9WMpKA0C eJo4krgZyVpe45IO8Nkit6RWq+0iKI1Zm4qyv3nWbstT3u8/Pit3fynuYkHNESJKxWEmp4mUt7ys 9DSCv92RVUkA3Hlo0q3ndwV23iY7dBfYyDV3BDZy7R2Bjdy7AhvJ9wQ2csMdga1wd4EtcZvARuo9 ga3MxS6wFe4usCVuF9gStwtsZSp2gQ3heUVg0gGfrEXCwZ8kC0yrPAWIeKhEmFLkXGmf7XkXMneP VGIWmFiaQMeRkA93ycd3nOWCJc6VMjvvlUX2w7jiWa6UJqZ2b5Q8kp76K2UpscjLc66Y/WA9yFMf pBlEppQxHYwrZWDIlCwZzv3ljewnRc79k6iDWA6fjCseulpsM664pJtcCmVLYyvbSrZr/u0lD8YV s0AEmlmbCkKcgcS4YkUJ6zjFxS7gcJTDYh+iUdauhW/fBaNWLu0VmigfjihNXCdL06IPjCtufU2a jCsti5Bmmvv7iSRNX2XMuP+WpIkjOMKBcW9ULpOb+itWLi1InnOlUk/Wimix3exU8m6tv9jS1exf mZsuuKLcSgk8rc0bUTl9cu6TKHnkTatjQ6rnaM1nZLH2LVIR6zlyrli3KNvQNMWijL27cMOd/dMj gvSezN6pWzDunQoo496pgDLunQoo496pgDLunQoo496ugC51t1dAGfdOBZRx71RAGfdOBZRxf367 Asq48vsHqGJy729vbfJrbiiCj2Zthmn2rVg2MZDPFObipg1N0OQDOa0lFThVzEcgiezXFEFgJbcW YqX6qcPilAVdzgaMq0UuFrLJZeKZA5JwU3+ljZhwTptXHOkMSojzMLUrJQM9yUB2Zo3t3G8Hbnmj FOv1jPTtZTZ8GA0JgzlRjAMIub6hHgyGyuXyis+WrxnChBq5KBAGh8gGcpfAtjfKwBYH3m4oCEfl ExXR9xE2ssYRvRsK0ocDEG3J+5GcVOMarLX9UHMijynpqHGNz8dlLGI2HA23ivTQ5Yh9Jh8DQtSc fsFZJFP3YaNqV0eQKW/ldQA8jw0TsTYgF5qLYQALhpBSuRyLp9CXFA6EBNCnTi6GsqOmNpm2FnYv DOXVho7cQNjVdoTR4UwLlOqjvc21+RJc1YC/ACaU7w7gHSoIR4cOGjUUDxxXY7IDSj7VZih0cq6f MFSD85jBOKJEI/k05P3t+gGM7b8b0RyeBLDXQWM67YarV9HRaik0HU8UAGe2cVxFu7+wPfkzCg6k szlQk+hA7gF0oCrY3nJDQzeagg9QFMwR49a4vYEYucq9+2lGRQ2NbO2hjgkYJqQ+pV3tfbZPpOMo 5x5KXZQ9zE6kMye3hqucXT0tnMhapv0e6v0yhEDHMgLksxm7jNQtpGNAVlFbzarbDGYtDOI3mJh4 zJ2B+Zx2g4lIY2CW4qo7xH+gKv6OTvE3w6B1ggM8N5T1rhsukPe1Ve1bRwkOMsWAxH87kUk0IGc5 12s3XPUxDyj4ndyfFE3cJJS04eRi2LsMhO2Bo+dzfMflOvxraHBXM3w4DeWV6xWDhPhUdUOfyQvU Pnrqs97wDEp0jMyMVKVftNjoyu9Abo+yjloQmuyGyyUkjxvLdzpnqwhgiudFDrJhzFIi3MdxAzFy 9VDfeq6h53NnOt3f964LAwaEXejCcIHKNlk0H+ywb3bDJcrVH8nu++ZgAMrNdxW13XogQ6zNYf1y 2dxPZB3nOvLD1ZIjnMiHiRzs+NySYQwoRU7uhjqiWL8cu4oauRuqr26ggXxORM3OGC6J3C6sG6hn fTmPlzvSZkJnPrkvBgLa15HDUJeZE2k3IDdx6/J1oLq0Hb3YV75u6AtjH9GBzgRrcNa5xjbDkGAd hppg9SyyJ1gw0phgpVr26/lEKx7sSVNLXM+EoWe2x9Vs8oF6DnzmTD1F7slHz6APZEzk5Jput070 TPwSPO+BsSdKPb2/hobs/7yc8yU62j3xDOqBY2DuuA3lKtpddhjqZnugmmOxYxA72vRzUfsamFVh NKR/ZAW3K0Hl45yQOPcXUsWGav8Z97XELWWCtMaNpnzRyKg/ya9EDOU1bjaICrPGLfVRNw1N/grU lZdljCtWK0grFzlX/rITWw+niu/gyqdleW2GS3l0dplcXCkZHefKxRUkxJN7xUpQebW92AUfL7wr zgQi0hPnym9PYvm0bG1o0ano5Kn4L9iYSEENCmVuZHN0cmVhbQ0KZW5kb2JqDQo0OCAwIG9iag0K PDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMzg5L0hlaWdodCAyNDcvQ29sb3JT cGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNr IDQ5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMwMj4+DQpzdHJlYW0NCnic7cExAQAA AMKg9U9tCF+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAuAxmNQABDQplbmRzdHJlYW0NCmVuZG9iag0KNDkgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9T dWJ0eXBlL0ltYWdlL1dpZHRoIDM4OS9IZWlnaHQgMjQ3L0NvbG9yU3BhY2UvRGV2aWNlR3JheS9N YXR0ZVsgMCAwIDBdIC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAxODc5Pj4NCnN0cmVhbQ0KeJzt2P9XU3Ucx3G3u7H7hQ3uNr0x 2hcZkoMBUUsSmQe/kt+wjSPn1OhERtiyzEw8GLFTJ8jSM+iEnLPjwEMckqlpzG8MG6d/rU0NyLLT D1x9HXs9/oLPeT/P+/PZ7rp1RERwDAaj0SgIJtKVIBTGbHhCAqNgNltEUZJlhXQjy5JoKTGb/qlD MYEoKbYyVXU4nKQXh8OulttKFbGkkOFvDcwW2ao6tYpKt8fj9Xp9tPYKc/V63C+6tPWqTRHNgvHx BqJS7nR5qjZtrg0G60kvwWBdoMbvq9RUq1Ty1wqFBqWq5q6ubQw1t7SGw9tJH+FweNvrrzUFa3wu h00yC6veBYNgUVTNF2ja2rZ3f8ebkSjpJnL4YPvO1lDQX6ggmo2rF0Eu13x1W3Yc6Hy7p7fvwzjp 5tgH773T1bGnpbHaZVcsq1ZBsFid7sCW3ZHuvhOnBwaHEqSbL784czLec2TftoaNL5RJ5uUIBpOk VlQ37Yi8e/xMYuR8cnSM9DKavHDu67Of9na1NwfcTqXEuHIbKU537dYD3ccHhpMXU+nJKdLLZPrS xNi5oc+ORtsa/ZpNXIlgsWlVjW2dff3DY6np2blM5irpJDN3ZSY9/v3gx7H20EsuVRKWI4hlFZtC e2MnEsnUzLWb89lbpJdsdv76z1M/Dve/39FS57bLppUIauXm5v09p0fGp6/N313I5RZJH7lc7t7t G7OpC4PxaLjB51SWX2ZBUt2BlkO9A+dTszfvLeZJT78tZDOXf/jqk662lzeuL12JINs9da2Hjw0m 03PzC/mlot9p7T2YbH7x9vXp8W9OvrWryb9hdQSHNxiOxIeSk5lsLs8EOipGuPPLTxeHT8V2veLX rI9FiMYTo48iPOuTPs8eRpgYORXb/eq/RXjW53yuPSmCiRGeoqX7/xxBcfrqt0c/SoxNXb21mH/W p3zOLd2/e2Nm4tvPu/eEqjXb8ncLRniaGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIAR ADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBg BACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgA GAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADAC AEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACM AIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEA IwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYA wAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIAR ADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACAEYAwAgAGAEAIwBg BACMAIARADACAEYAwAgAGAEAIwBgBACMAIARADACgCdFkB3eYDgaT4xOZrK5/NKzPubzben+nV9+ mhg5Fdv9ql+zmg2PIgiM8PQs5Rf/UwRW0NG/R4jEh5LphxFYQTdLDyNcHD4V2/XKXyPYPXWth48N JtNz8wvFCMygiweTzS/evj49/s3Jt3Y1+TeUrkSQVHeg5VDvwPnU7M17i3nS028L2czlH776pKvt 5Y3rVyIYRbVyc/P+ntMj49PX5u8u5HKLpJNc7t7tG7OpC4PxaLjB51RWRSir2BTaEzuRSKZmrt2c z94ivWSzv17/efLH4f6jh1pq3XbZtO7PCBabVtXY1tnXPzyWmp6dy1wlvWTmrsykx78b/DjWHqpx lUvCcgSz4nTXbj3QfXxgOHkxlZ6cmpq6TGuvMNep9KWJsXNDnx2NtjVWaTbxzz/M6wwmSa2obtoR eff4mcTI+eToGOllNHnh3NdnP32/q7054HYqy18tCj+PLFanO7Bld6S770T/2cEE6efLL86cjPcc 2betYaNWJi2/y8X7SC7XfHVbdhzojPX0HovH4x+RLuLxDz84+k5Xx56WxmqXXSkRViIYBIuiar5A 09a2vfs73owWdNLaKw42cvjgGztbQ0G/y2EVzSu3UXEVxFJVc1fXNoaaW1rD4e2kk3B42+uvNQVr fC6HTTKvWoTCKhQqKOVOl6eqZnNtMFhfX99Aa68w1/pgXaDG76vcoFqlEmH1IjyoYJGtqlOrqHR7 vF6vj3Th9XrcL7o0p2pTRPNjDYoVBLMoK7Yy1e5wOEk3DrtabiuVxRKT8fEGjzKYLaIoyQrpR5Yl 0VJiLiQw/L1BMYPBaDQKgol0JQjGJxUgIqL/vT8AVDqaow0KZW5kc3RyZWFtDQplbmRvYmoNCjUw IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA0NTAvSGVpZ2h0IDM5 OC9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvRmlsdGVyL0RDVERlY29k ZS9JbnRlcnBvbGF0ZSB0cnVlL0xlbmd0aCAxNTUwNj4+DQpzdHJlYW0NCv/Y/+AAEEpGSUYAAQEB AGAAYAAA/9sAQwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3 KSwwMTQ0NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgBjgHCAwEiAAIRAQMRAf/EAB8AAAEF AQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFB BhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAA AAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRC kaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdo aWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT 1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A9/ooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigArlvF3j/wAP+CrYPqt3+/YEx2sPzSv+HYe5wPeub+JnxHuPD9xB 4d8OQfbPEd4QEQDd5APQkf3iOg6dzxwcXwh8E455v7d8dSyalq05817VpMoh/wBth98j0zt7cjmg Dnrv4zeOfFcz2/g3w9JFFu2eakJuJAT0JONi/iDj1qEeB/jP4iYz6jrM9megSXUfLGPXZFkD8s19 D2tpb2FrHbWkEUEEYCpFEgVVHsBU9AHzLcfs/wDjm+cS3es6TNIBjdNdTMwH18s06D4G/EPS0I0/ WrKIZ3bba9lTJ/74FfTFFAHzG0Pxs8HK0m/VZ4I25+db1SPpliB+X4Vt+Hf2iZ45ha+KNIAwdr3F n8rLz3jY/wBfwr6BrlvFfw+8N+MYWGq6en2nbhbuH5Jk9Pm74yeGyPagDU0LxFpHibT1vtHv4bu3 PBMZ5U46MOqn2ODWrXy1rnhbxd8FtbGtaLeNNpbPtE4UlWXP3J06e2fxBB4HvXgPxxp/jzQF1C0H lXEZ2XNsT80T4/UHse/sQQADq6KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiivOfix8R 4/A2jrbWRV9ZvFPkKRkRL3kb+QHc+wNAF/xz8TtB8DR+TdObnUWXclnDy2PVj0UfXn0Brw7XPi14 /wDEl/BY2Ak0sXmFt7a0XEkgbG0hz830IwPyrptI8C23g3w5efEHxypv9XVTNDZTtuXzWI2b+Dly xHqFBzgkZGh8EfDk+s39/wDEDWx515dSutoXGdvZ3X0H8A9ACOlAGTafs5aneRifU/E8UV1L80yp bGb5jyfmLrn61ftv2eNQ04s+n+OJoJD1Mdm0ecdORLXvNQXd3bWFpLdXc8cFvENzyysFVR6kmgDx I+GfjF4OZptK15NetVbIgnlMjOOnSTkfRWroPCXxnsNTvxo3iWyk0LWAwQpOCsbN6fNgoenDfmay fF/7QWmac0lp4atf7RnXK/apsrCD6gfef9B7149qd/4x+KGqJPLbSX0keUj8mAJHEOCQW6Dt94/z qZTjBc0nZeY0m9EfUWtfEXwj4fLrqGvWayocPDE/myA+6pkiuH1D9orwtbSOllY6lebekmxY0b8z n9K840n4H6rOQ2qajbWicHZCDK/vnoB+tdjYfBjwva5Nyby8J7Sy7QPptx/WvIr5/gaWnNzPyX9I 3jhaj6WKE37S902fJ8Lwp/v3pb/2QVmXP7R/iZ5c2ukaRFHjpKsjnP1Dr/KvQbX4e+ErOMJFoVow HeZTIfzbNWx4P8MqOPDuk/jZxn+lcEuKaF9IP8DVYKXc8sl/aB12/tp7PVtC0a7sp4zHJCqSJuB9 SXauM8G+N7rwT4pOr6fAxtXLLLY+bhZIznCliD04wcZ49zX0MfB/hlhz4d0n8LOMf0qpdfD7wldx lJNBs1B/55L5Z/NcGhcU0L603+APBS7lXT/2i/C9xIiXun6labur7VkVfyOf0ruNF+I/hDxAUWw1 60MrnCwyt5Tn/gL4JrzK/wDgx4WusG2+22ZH/PKbcD9d4P8ASuR1T4G6lAC+l6nb3Qz9ydDG2PY8 gn8q7qOf4Gro5cvqv6RlLC1F0ufUgIIyKWvj61134g/DeaOMz31pBlQsM/72BsfwjOVHf7uDXq/h D9oLS9RMdp4ktv7OuGwPtUWWgY8dR1T9R717EJxnHmg7ryMGmtGe1UVBa3dvfWkV1aTxz28qho5Y 2DKw9QR1qeqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEF1dQ2VnPd3MixQQRtJI7HAVQMkn8K8D+HGnTfE r4l6j441VCbKymH2WFsFd/8AyzXv9xcN/vEH1rv/AI2aydH+GGoqjhZb1ktE99x+Yf8AfIarXwh0 SPRPhnpCKF8y7j+2SMq43GT5hn3C7R+FAHnn7Q+sz3N3onhSzJZ5T9okiH8TE7Ix6dd/6V7VoGkx aD4f0/SYOY7SBIQT1bA5P4nNfPfxAu/tv7SOl20i4S2vdPg69QSj/wDs5r1n4nfEi28B6QBCEuNX uARbW5PC/wDTRxnO0fqeOOSAC945+IejeBLASXsnnXsg/cWcZHmP7n+6vufwz0r5u1fX/F/xa1xY NsksQfdHaxZEFuOeWP5/Mef5U3w14Z1v4l+IJ9R1G7ne335ur6Tkk9dids+3RR+AP0Bo2h6doGnr ZaZapBCOTgcufVj3NeFmud08F+7h70/wXr/kdNDDOpq9EcB4X+DWl6b5dzrsn9oXI58lcrCp4/Fu /XAwelelwW8NrAkFvDHDCgCrHGoUKPYCpaK+GxWNr4qXNWlf8vuPThTjBWigooorlLCiiigAoooo AKKKKAIp7eG6geC4hjmhcFWjkUMGHuDXmnij4M6ZqIkudCk/s+5OT5LZaFjz+K9vUY6CvUKK68Lj a+FlzUZW/L7iJ04zVpI+cdI8R+MPhRrf2ZvNSEPmSzm+aCcdyp/Hqv4+lfSXgb4g6P4704zWLmG7 j/19nIRvj9x6r7/yPFZGu6BpviPTmsdTtxNCTlT0ZD6qex/n0NeBeIvDeu/DHxDDqWm3Uqwbj9lv owPxRx0z9eCOfUD7nKs7p4393P3Z/g/T/I8yth3T1Wx9hUVwPwy+JNr480opMFg1i2UfaYB0Yf30 9j6djx6E99XuHMFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAeI/tJXSr4b0W0LjdLdtKF9dqYz/wCPj869ms4BbWME CjAjjVAPTAxXhf7TELtB4amCkxo1yjN6EiIgf+On8q9W8beMLPwX4Zn1a4KvJjbbQlsGWQ9B9O59 BQB4F8dUfR/itb6lalUme2huQR13oSoJ/wC+BUnhjwLqfj6/fxT4uuZzDcsHjTO15x/7JH2AGOOm OCWeHPBmp/ECTUfFXiOeQtdRyC2U/wAbkEBgOyL2HfHoOe8+FeonUPANmkhzLaM1s49Np4B/4CRX zmcZrKFGccLLWLSk+177fd8vU68PQvJOaOssrG106zjtLK3jt7eMYSONdoH+easUUV8G25O73PUS sFFFFIAooooAKKKKACiiigAooooAKKKKACqmpadaatp81jfQLNbTDa8bd/8AP/16t0U4ycWpRdmh NXPnPXNF1n4UeLbbUtMuGMG8ta3H99e8cgHX0PqORjt9O+DfFdj4z8O2+r2LAbvlmizzDIOqn/PQ g1zevaHZeItHn0y/QmGUfeB5Qjow9x/9Y5GRXj/g/Wr74PfEKTS9VctpV3tWZl+6UJ+SYD25yPTc OcCv0LJc2WMp+zqP94vxXf8AzPKxFD2butj6lopiOsiK6MGVhkFTkEU+vdOYKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigDx z9oyzebwPYXSrnyL9dx9FZGH8wK4G+1S5+MfjrT7VfNi0axgRpEbtwPMPH8TH5R7DPrXqvx2vrS0 +F97Bcf6y7miigA/vhw//oKN/LvXIfBbTrW28HSX0eGubqdhK3dQvCr+uf8AgVeZm+MeEwkqkd3o vmbUKftJ2Z6LbwQ2ttHb28axwxKERFGAoHQCuJ8FWF7ovizxTp8lrOthLci6tpmjIRi+SwDYwcZA /Cu6or86p4hwhOD15vzve/8AXc9Zwu0+wUUUVzlhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AVxvxH8IL4r8Ot5Cf8TG0BktiAMv6x59/wCYFdlRW2Hrzw9WNWm9UTOKmrM4n4B+ODq2jv4Yvpc3 enputSf44OBj/gJP5Eele0V8teNYp/h58TrDxLp2UguZPPKJxkggSp9GB/8AHvavpywvrfUtPt76 1kElvcRrLG46FSMiv1PC4iOIoxrQ2aPEnBwk4ss0UUVuSFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHz98a55fEnxD8O+EYi/lKF eUo3eRsE49VRM5/2j+Nr4dqNI8T+LPDuAEhuxdQgf3XH9BsrK0IjxF8fvEOrFCY7FpERs91xCv5q GNdwPC+zx4fE8V2E32n2aW38rO/nO7dn2HbtXyWfYyLqSw03py3X+K6a/Bfid2Gpuymu/wCB0VFF FfGHohRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHH/ABM0Ea74JvFVc3FoPtUO BzlQcj8Vz+OKk/Z/8Sf2r4Mm0eaQtPpUu1ck/wCqfJX8iHGOwArqyAykEZBGK8Z+GMreDvjfd6ES wtroy2qjdkY/1kZPqcAD/gRr7PhbFXhPDvpqv1/T7zzsbCzUj6Zooor604QooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAqOWQRRPIeiqWP 4VJWX4juksvDGrXchKpDZzSMR1ACE0AeC/BCOa5/t/Vbhg73EyKWxjL/ADMx9P4hXrleX/AxMeEL 98db9h+Uaf416hX5pnknLH1L9/0R7GGVqSCiiivKNwooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigArw34pKfD/xM0fxBHGMfubg7eCzxOP6BK9yryX47WStpGk3/O6Kd4fruXP/ALJX tcP1fZ4+K73X4f5nPio3pM+ikdZI1dTlWAINOrnfAl6+oeAdAupH3ySWEO9vVgoB/UGuir9GPICi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACuf8d/8k98S/8AYKuv/RTV0FZ+tW63Wg6hbuqusttIhVxlSCpGD7UAeI/A7/kSbz/sIv8A+i46 9Mry/wCBr58JX6el8x/ONP8ACvUK/Ms4VsdV9T2cP/CiFFFFeYbBRRRQAUUUUAFFFFABRRTXdY1L uwVR1YnGKAHUVgXPjfwvZsVm16wDKcFVmDEf985rOi+KXgyaQIutqCf78Eqj8yuK6o4LEyV405P5 Mh1ILdnYUVkWPinQNScR2WsWM8hHCLOu78uta9YTpzpu01Z+ZSaewUUUVAwooooAKKKKACuN+Jvh 688SeETaafb+fdxXCSxpvC9Mg9cDoxrsqK2w9eWHqxqw3TuTOKlFxZ5l4J+Jsvw+0yx8LeLtFvbS ODcI70HfkFi3TuBuAypP0r3axvrXUrKK8sp457aZQ0csbZVh6iuB8ReH7HxLo82m38YZHGUf+KN+ zL7j9RweCa4j4Ca9eafrureC719yQ75YRnIR0bbIB7HIP4E96/Q8ozVY+DurSjv29UeTXoeyfke/ UUUV65gFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAU0gMpB6EYp1FAHzp8Glk07UPE2iSMGNpcKM45LAujH/wAdFes15ZBF/wAI1+0Rq1lseODV VeSMA5Vi4Epb/vpXHsfavU6/POIqXJjnL+ZJ/p+h62ElemFFFFeEdIUUUUAFFFFABSMyopZmCqoy SeMUMyopZmCqoySeMV5Bq2r6z8VPER8MeGC0WkRn/S7vnay5xubH8Povf+XoZdl1XHVeSGiW77GV WsqauzQ174qyXGppovg2y/tO/lby1m2ll3f7C/xdDzwO/IqWy+DfizxWyXfjXxC8Kn5vskWHZePb CKeewNereDfAuh+CdPNvpdt++cDzrqTmSU+57D2GB+tdPX6Dg8sw2DjanHXu9zyqladR6s8wsfgJ 4GtIQk9reXrd3numUn/vjaKvH4JfD0j/AJF/H0vZ/wD4uvQaK7zI8m1T9nzwfejNk9/pzj/nnL5i n6h8n9RXI3vgn4k/D2PztD1H+3NMiGTb7SxCgdPKJJA6fcbNfQ9FZ1aNOrHkqRTXmNScXdHingz4 m6X4qZLSYCx1M5xAzZWT/cbj8uv1xmu5rF+Ivwl0/wAWxy6ppirY+IFAZJkO1ZiOgfHf/a6jjOQM VyPgLxveS38nhXxOj2+s2xKK03BlI/hP+13/ANoc/X4zOMh9jF18N8PVdvTyPRw+K5nyz3PSK5/x L4y0bwrBv1G5/fMMpbx/NI/4dvqcfWud8f8AxCOhyLomiJ9q1ydlQKi7/KJ6DA6ueMD8T2BveCPg vEsq6743Y6jqs3ztaSNvjjJ/vn+Nh6fd+vBrLKshliUq1fSPRdX/AJIdfFKD5Y7nMJ468deMGdPB /ht0t/mxcyJu9vvtiMH25/HFXP8AhX/xh1W3U3XiK2sy4yU+1GNl9iYkI/IkV77HHHDGscaKiKMB VGAKkr66jluEoq0Ka+67+9nBKtUluz5/h+GHxbsSXh8W2spPZ76aT/0OPFVZdT+LXhEGTWdE/tOz VjmREV/lA65i+6OM5Za+iqKqrl+Fqq06afy/XcI1Zx2Z4t4V+J+h+JnjtnY2N83/ACwmI2sf9l+h /Qn0riPhv51x+0NcTWxbyRd3zy4bGUIkAz6/MV/H6V6946+EegeM43uEjXT9V5Iu4EA3nH/LRf4u 3PB9+1eQ/DqSL4VfE640/wAX25tZp4PIiu937pQzAh/dG243fw4wQOcc+Cyqlgqsp0m7SW3b5lVK 8qkUpdD6gopoIYAg5B6EU6vUMQooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigDwr472cmja94c8Z2y/vLeUW8uGK7tpLoPxHmA131tcRXdrF cwOHimQSI45yDyDVv4laH/wkPw91mxVN8wgM0IHXzE+ZcfXGPxrzX4O+IP7V8JnT5WJuNNYR/wDb NuU/kwx6L718vxPheejGuvs6P0f/AAfzO3BztJx7nolFFFfDnpBRRRQAUUU13WNC7nCqCSfSgDzH 4qa9e3Etp4N0VHmv9Rx5qxn5tpPyp+POfYehr1vwL4Ns/BPhqDS7Y+ZL9+4nK4Msh6n6DoPYDr1r yn4NWR8VePte8a3UWVify7XcB8rMMfmqAD/gVe+1+o5Zgo4PDRprfd+p4tao6k2wooorvMgooooA KKKKACvJPjV4DfXNKXxJpCSLrOmLuIi+9LEDn67l6j8RySMet0hGRg8g0AeG/ATQNM1GG98W3c32 3XPPaImUZNvkcke7A9fTgd8+514L4OT/AIV/8etU8Nqpj07V1324GMDgyJ+A+dP85r3qhK2iAKKK KACiiigArkfiB4EsPHWgPZzqsd7EC1nc4+aJ/f1U8ZH49QCOuooA8d+DHjG/drrwR4g8yPV9LyIf NHzNGpwVJ7leMHuD7Zr2KvBvjFaP4P8AH/h/x5YxkBpRHdbMDcy9vq0ZZfote6xSpPCk0bZR1DKR 3BoAkooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigBCAwIIyD618zeDYW8F/GfVvDJBW3mMkUSg5AA/eRkk8/cyP+BfjX01Xgfx40l9H8R6D4 1to9/lypFMD0Lod8f5gMP+AiubGUFiMPOk+q/wCG/EunLlmpHpVFMikWaJJUOVcBgfXNeQ/DL4ha zrXiNtN1y8FwlxG32djGiYdeSPlAzlc/kPWvzTD4GrXpVKsNob9+u33HsSqqMkn1PYaKKK4zQKwP G9y1n4H1qZGKsLSRQRxgkbf61v1x/wAUonm+G+sKi5IWN8ewlQn9Aa6sDFSxNOL6yX5kVHaDZp/A SxjtPhfbToPmvLmaZz6kNs/kgr0+vPvgkQfhFoft9oH/AJHkr0Gv1Y8MKKxfFfiG38KeGL/XLlGe K1QNsXqzEhVH4sRzXmnw1+NNz4w8TnRNV0+3t5Lje1o9vu6KC2xsk5O0E7uBx0FAHstFFFABRRRQ AUUUUAeFfGWNdL+J3gjW4yUlaZUZgeqxyof/AGoa91rwP9pGJ7m58J20K7pZGuVVR1JJhAr3ygAo oooAKK4rxf8AFDw34Kv4LDVJbh7mXBMdvHvMaE/ebkccdsn2rq9P1C21XT4L+ymWa2uEEkUi9GU0 AWqKKKAPMvjxYx3fwtvJ3GWs7iGaM+hLCP8Ak5roPhleLffDPw7KrBttkkXB7p8h/wDQayvjcwX4 R60D1YwAf9/46n+DttJafCfQY5MbjHJIMejyuw/RhQB3dFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc1418a6d4F0eHVNUgupYJZ1twLZF ZgxVmHDMOPlPes7x/YW/jD4V6ibT9+s1mLy1ZeSxUeYuPrjH41yv7R3/ACT2w/7Csf8A6KlrR+C2 rSXHhS78M6iyHUNDuZLOSPdklMnB+mdy/wDAaAKHw21H+0/h/pMhGGhi+zkZ/uHaP0Arx7QrSa1+ HsPiezUm50fWjI2CRmMpFkce+PwJr0P4WodH1TxV4ZZGUWGoM8e7qVJK/wAkU/jVH4R6dFq3w11j T5+I7m6miJ7jMUYzXxb/ANhq4l9FKH3PmuvuZ6H8SMPR/oeo2d3Df2UF3bsHinjWRGHQgjNT1558 JdTnfRb3QL4/6ZpE7QlSeiEnH5MGH5V6HXzmMw/1evKl2enp0/A7KcuaKYVj+KbF9T8KarZRjMkt rIqA/wB7acfritiisac3TmprdalNXVjmP2fNUF78PHsjw9hdvH16q2HB/Nm/KvWa+efBF7H8PfjN f6FPiHTdZx5BOAoJJMX4ZLp9cV9DV+s0asatONSOzVzwpJxdmVdQ0+21XT57C9hWa2uEMcsbdGU1 ynhD4X+G/BV/Pf6XFcPcy5AkuJN5jQn7q8Djjvk+9drRWggooooAKKKKACiiq97eW+n2U95dyrFb wRtJLIxwFUDJNAHiXxOZte+N3g/QIgGFs0c0mT2Mm5x/3xGD+Ne618xeB/HPh6X4q6z4z8TXwszI GFnG1u8jfN8oPyBsbY12++6vXf8Ahdvw8/6GD/ySuP8A43QB6BRXn/8Awu34ef8AQwf+SVx/8bo/ 4Xb8PP8AoYP/ACSuP/jdAHNfEr4LXPjDxONb0rULe3kuNi3aXG7ooC71wDk7QBt4HHUV6X4U8PW/ hTwxYaHbOzxWqFd7dWYksx/FieK5n/hdvw8/6GD/AMkrj/43R/wu34ef9DB/5JXH/wAboA9AorB0 jxp4a16ZYdL1yxupiMiJJRvP/AetbUkiQxNJIwSNAWZicAAd6APHv2h9WMHhTTdFhZvtGoXe4xqM 70QdP++mT8vrXp/hnSzonhbStLZtzWlpFCzAYyVUAn8814rorP8AFv40HWwjnw9om0wlgQG2klOM 9WbLf7q4NfQFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAHj/AO0d/wAk9sP+wrH/AOipar6wf+EG/aB0/U87NP8AEkX2eX083hen+95R z/tNVj9o7/knth/2FY//AEVLWx8bfD7az8Pri8gBF3pTi8iYHBCr9/8A8dJP/ARQByuuRHw/+0Qk oRvK1yx5Y8AMBjA/GJf++vpVP4Hf8iTef9hF/wD0XHUPxB1saz4L8C/ECLeZra4EdwI+Pm/jH03R MPo3vU3wO/5Em8/7CL/+i46+Z4go8tCpV/m5F9zl/mjswkryUe1/0ItRz4S+M1nfD5LHXovJk9BJ wP8A0LYf+BGvUa4f4qaI2r+DZZ7dWN3p7i5iK/ewPvfpz+AroPC2sr4g8MafqgI3zxAyAdA44b/x 4GvmcX++wtOv1Xuv5ar8PyOyn7s3H5mxRRRXlm5w3xN8GHxVoYmtEzqdmC0Iz/rFONyfpke/pk10 Hwm+Iy+LtJ/szVJQniCzBWZGG0zKON4Hr2YdjzgAitmvNvG/gK7k1FPE3hVza6zA3mMkZ2+YR3H+ 129G/n9TkObxo/7NXfu9H28vQ4sVh3L34nvdFeS+A/jTYa5Imk+JVXStZD+VlwVimb8fuNnI2n2w STgesg5GRyDX255otFFFABRRVe8vbXT7SS7vLiK3t4hueWVwqqPUk0AWK8D+LPi+48Y6tF4B8Lut wrSj7fKvKllIIXd/dUjJPqAOxBTxf8Wb/wAY3jeF/AMMrLOMS6hgoxX+LaDyi9BuOD6AcE7/AIH8 D2fg/TsDbNqEo/f3GP8Ax1fb+deTmua08DT7zey/V+RvQoOo/IpWvwl8HxWsUc+mG4mVAHlNxKpc 9zgNgfSpf+FUeCv+gJ/5NTf/ABddpRXwTzLGN39rL/wJnqexp9kcX/wqjwV/0BP/ACam/wDi6P8A hVHgr/oCf+TU3/xddpRS/tHGf8/Zf+BP/MPZQ/lX3HF/8Ko8Ff8AQE/8mpv/AIuj/hVHgn/oC/8A k1N/8XXaUU/7Rxn/AD9l/wCBP/MPZU/5V9x5Xr/wW06aMz+H7qWyuU5WOVy8ZI9/vL255+lcPf8A jfxtJpreBNX1H7OrTrDNNdnDovA2vJz+76EnkkdyvFfRleb/ABg8Lxap4cbWYIh9usBlmA5eHuPw zu/P1r3smzyr7VUMQ+ZPRN7p/qcuIw0bc0D1jwX4TsPBvhu30qwAYD55pu80hAyx/QfQCuirzX4I eJJvEHw+iiuXaS506U2rO3VlABT8lIH/AAGvSq+1POCiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPH/wBo7/knth/2FY//AEVLXrk0UdxD JDKoeORSrqehB6ivI/2jv+Se2H/YVj/9FS17BQB80W9g1j4X+Inw9unO/Tc6nZknkxoVY/moQ/8A AjWz8Dv+RJvP+wi//ouOug+KNnD4c8ZeHfGwjxA0v9n6n1wYnUruP0Ut+IWuR+BWoK+kappvRorh ZwfXeu3/ANk/WvD4ii5YCTXRo6cI7VUesOiuhRhlWBBB71558OmfQ9a13wfOeLSY3FoCckwt/hlT 9WNei1wXivT77T/Heg+JdNtJ7hSTZ3ywoXPlnoxAB4GTz7AV8ZgWpxqYeX2ldeq1X36r5noVVZqS 6He0UUV5xsFFFFAHLeKvAOieLF8y6iMN4BhbqHAf8ezfj+YrkLbR/if4ECx+H9WGq6eh4tpMEAY6 bH+6On3G/rXrFFerg85xeEXLCV49nr/wTCph4VNWebxfG7xhpybNZ8Du8qkhnjEsKn8Crfzpkf7S U07iKDwczyt91V1AsT+Air0uivZjxXJL3qX4/wDAZzvArpI81l+LXxF1phFofg8WoIz5k0bv+TNt X+dUP+FfeLvGM0dz438RSmMc/ZomDFfwGI1PPUA16zRXJiOJsVUXLTSj+L/H/I0jg4LfUy9D8PaX 4csfsml2iwR5yx6s59WY8n+natSiivn51JVJOU3ds6kklZBRRRUDCiiigAooooAKxPGO3/hCdd3d P7Pn/Py2rbrzf4weKItL8ONo0Eo+3X4wyg8pD3P442/n6V2ZfQnXxMIQ3uvwM6slGDbF/ZpjuBY+ IpG3fZmkgVPm43gSbuPXBT9PSvea4H4Q+FJfCfgG1hu4/LvbtjdXC/3S2Ao9iFC5HY5rvq/VDxAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDx/wDaO/5J7Yf9hWP/ANFS17BRXP8Ai/xZp3gzQJtW1FztX5YoVPzzOeir/j2GTQA7xh4ctvFf hW/0a7l8mO4TibGfKYEFWxkZwQDjIrwPwzY2Hw/+LX9jxa3Df2l1Z7DcIyhVcjdhgGIByhx3ww9c 1oJp3iv4skan4hv5NN0Jzut7CD+Nexwev+82c9gARW/b/CPwbDEqyafLcMBy8lzICf8AvkgfpXz+ aZtglCeGm229HZXt99lodVGhUupo7hWV1DKwIPQjmlrB0bwfpHh+cSaVHc2yc5hF1I0Zz6qzEVvV 8HVVNS/dtteat+rPUi31CiiisxhRRRQAUUUUAFFFZ+r61pug2Zu9TvIraEcAueWPoo6k/SqhCU5c sVdsTaWrNCivKLn4p6trt3LZeDdEa4Kdbm4xwOecZAHtk/hVZ/BHinXsP4j8VTFWGHt7fOwj6fKo /wC+TXt0chry1rSUF97+5f5nO8TH7Kuem3viLRNNYC91eyt2P8Mk6qT+FY9z8SfB9rjzNdgPOP3S tJ/6CDXGxfB7QVYF7zUX55HmIAf/AB2tqL4d+FYrZoP7JR1bGWaRy3/fWcj8MV3xyPBx+Kcn6JL/ ADM3XqPZIv8A/C1/BX/Qb/8AJWb/AOIo/wCFr+Cv+g3/AOSs3/xFZn/CtPCP/QJ/8mJf/iqP+Fae Ef8AoE/+TEv/AMVWn9i5f3n+H+Qe2rdkaf8AwtfwV/0G/wDyVm/+Io/4Wv4K/wCg3/5Kzf8AxFZn /CtPCP8A0Cf/ACYl/wDiqP8AhWnhH/oE/wDkxL/8VR/YuX95/h/kHtq3ZGn/AMLX8Ff9Bv8A8lZv /iKP+Fr+Cf8AoNf+Ss3/AMRWZ/wrTwj/ANAn/wAmJf8A4qnxfDnwlDKkq6QpZCGAeaRl49QWIP48 Gj+xcv7z/D/IPbVfIzvEHxq023gaLQLaS7nI/wBdMpSNPfHU9uOPrTPg14c0vxZrtx4n13VotR1e KTzFsm6qe0jAjkDjAXhcD2A7X7DafZnt/ssHkOCrR+WNpHoRXm/ijwPc+H7xPEvhKSS1uLVvNaGI 8r1yye3PK9MflXrZbSwuF92nGzfV63MK/tJ6t3Pp2iuK+G3jy38d+G1uSUTUrfCXkC8bW7MB/dbB x+I7V2te0cgUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAV8/8Aj2RvG/xrsvDUgZtM0lQ865wGJUOx/HKJ+f1r6Ar5x8ITPc/Hvxe8zbmV rtFPss6KP0AFcWY1ZUcJUqR3SZpRipTSZ3Hi7xPD4W022EZthd3cq21qs8myJCf+Wj9/LXjOPYcZ yJ/C8tidPaG219NauFbzLm4FyJPnbP8ACCRGvBwowAB3OScnxh/oHiXwrr8/FhZXE0Fw4/5Z+emx XY9AgI5JI6jGa7OvzuryQw0ElrK7b802rbdFZ7rc9aN3N36BRRRXAahRRRQAUUUUAFFBIUEk4A5J NeP+KvH2o+JtUbwz4O3MrZWW9Q43D+Laeyj+937ds9uBwNXGVOSnst30SM6lRU1dm943+KWn+GxL Y6dsvdUGQQDmOE/7R7n2H5iuK0zwRr/jHURq/i25niiY5WFuJGHoF6Rj9fbvXV+Evh9p3hoLdTYu 9SAP75hhY/8AcH9ev0BxXY19hhqFDBR5aCu+snv8uyOKXNUd5/cVdP06z0qyjs7GBIYIx8qL/M+v 16mrVFFU3fVlBRRRSAKKKKACiiigAooooAKKKKAPOdNkPw2+MFhPbjy9G1hhC8a8Ku4gEYz/AAsV b6HAr6Tr58+Kmmi98GSThWMlnKsoxzxnaf0bP4V7X4V1NtZ8J6RqbjD3VnFK49GKjP65r2sNUc6a bOOrHllobFFFFdBmFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAV86+IHbwd+0NJd3OEstWRcSH+66hevbEi/lX0VXAfFT4ep488PqtsVj1WzJe1 duA2esbex457EDtmsq9GNalKlLZqxUZOMk0XaK8d8M/Ey88Nyf8ACP8AjS1uYZrb92tw0ZLqB0Dj uPRhnI9etehW/jjwtdRLJH4g04KwziSdY2/JsGvzXF5VisNNxlBtd0rpnrwrwmrpnQUVl2fiPRNR ultbHVrO6nIJCW8yyHA/3c1qVwzpyg7TVjVNPYKKKKgYUUVzHjrxbD4S8PyXWVa9lzHaxnnL+p9h 3/LvWtGjOtUVOmrtkykoq7OS+I3iW91TUR4K0Ab7mfi8lB4VT1TPpj7x/D1rc8K+FbLwtpgtrcB5 3wZ7gjDSH/Adh/UknG+Hfhp9N059Y1Ab9U1D967uDuVG5x9T1Pvgdq7avuaVGGFpLD09lu+77nDd yfPIKKKKBhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAFTU7CPVNLurCUkJcRNESMZGQRmn/A7X5Lrw 3d+Gr1h9u0OcwEDvGScH8CGH0A9asVwdzqjfD34rWfiFi39lasv2e89FPAJ9sYRu5PzV34GpaTh3 Ma8bq59E0U1WDqGUgqRkEd6dXpnKFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAYmv+E9B8UQ+VrWl295gEK7rh0B/usPmH4Gvmf4zeFfD3 hDxBY6doUEsTPbmedXkLjliFxn/dNfWdfK3iqY+Lv2gGgRxJDFfR24DcAJCB5gH4q5/GoqTVODm9 kr/cNK7sev8AhjRoNB8O2NlFFGkkcCCVkTbvfHzE/jmtiiivyWpUlUm5y3ep7qSSsgoooqBjJJEh ieWRwkaAszHgACvAkuZfiZ8TFllBOlWh3Kh6CJTwCD3Y4z9favRPi5rTaV4HmhiYiW/kFsCOynlv 0BH41jfCrRf7N8LfbXUCe/bzM46IOFH8z/wKvrMhw6pUJYp7vRfqcWIlzTUDuqKKK9IkKKKKACii igAooooAKKKKACiiigAooooAKKKKACuJ+Ktolx4HmmYfNbTRyL7ZO3/2au2rA8bWqXngrV4nHC2z S/inzj9VFa0XapF+ZMleLO0+Eesya38M9HuJm3TQxm2ck5J2EqM/8BAruK8V/Zw1DzvCmraeXybe 8EoXPIDoB+WUP617VXunCFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAVdQvYtN026vp2Cw20LzOx6AKCT/ACr5f+D1tLrHjnUdauQrvFG8 jNjpLI3Ufhvr2z4y6q2lfC7VihUSXIW1XPcO2GH/AHzurz34I6b9n8K3d+8e17u5IVv7yIMD/wAe L15Ge1/ZYGfnp9//AALm+GjzVEenUUUV+bHsBRRRQB4p8d7km80a0DcLHJIVz6lR/Q16LplqljpV naRj5IYUjH4ACvKfjnE48XWMpX5GsVVT6kSPn+Yr2EEEZHSvvMIuXL6KXZv8Tzm71ZBRRRVFBRRX CfELV7uaxn0XSLeW6bYJNRNuxDwQ5GFyOMvz6naDlSDmrpwc5cqFJ2Vzu6K5Hwr460LW7aG2iaOw uFUKtm5CgY7J0BHtwfauuonCUHaSBNNXQUUUVAwooooAKKKKACiiigAooooAKxfF0qw+DtZZjjNn KnPqVI/rW1XmXjfWLjxXfw+DvDcbXlxJIDcNFyvB+7n0BwSegwPetqFNzmkiJyUYnT/s12Jj0TXt QycTXMUGP9xS3/tSvc653wR4Xh8H+ErLRoiGeJd00g/jkPLH+g9gK6KvcOIKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8I/aU1Tbp+h6Q oz5ksly3PTaAq/8AobflXTeCtM/sfwZpNkU2OturSKTyHb5m/UmvMfiow8U/HKDSVQskP2ezbBxl fvsfw3n8q9tAAAA4A4xXyPFVeyp0V5v9F+p34KO8gooor409AKKKKAPHPjvYuYtHvwBsVpIHPucM v8mru9Iuhf6LYXYBAnt45MHtlQab8RdC/wCEg8FXttGm64hX7RDxk7l5wPcjI/Guf+Gepf2h4ItF MheW1LW75HTByo9xtKivs8qrKrgIx6wbX36o4ai5ar8zr6KKK6xBVS0020sbi6uLeLE93J5k8hYs znoOTngdh0HYCrdFNNoDl9d8AaDr7mWa2Nvct/y2tyEJ+o6H8s1hL4P8XeHsf8I94h+0QLgC1uxw FHQDOR+W2vRaK1jXmlbdeZLgnqee/wDCc+JdJVRrvhOfAzvntSSo/wDQh/497+1Ivxj0Ej57HUgf 9lE/+Lr0Os+80LSNRYNe6ZaTsP4pIlJH41SqUn8UfuYuWS2Zydr8XPDU8uyRb62XH35YgR/46WP6 VvweNPDVyiumt2QBHAkk2H8mxVSb4d+E53Dvo8YIGP3croPyDVSm+FXhaVSEtriEkHBjnJx/31mq f1d7XQv3iOptdW02+BNpqFrcAHB8mZX5/CrgIIyOlecy/BvRCP3V/qC/7zI3/soqhL8FYzITFrzK nYNahiPx3il7Oi/t/gHNPsenT3traoXuLmGJFBJaSQKB+dc/d/ELwrZybJNXjdsZ/co0g/NQRXNw fBnTAq/aNUu5Djny1VM/nmsTxx4T0XQ7fTdL0i2km1a9mCozyFnI6YxwoyxHb1q6dKjKXLzNilOa V7HTzfF7w5FIyRw6hMB0dIlAP5sD+lWP+Ex8R6uVi8OeC9UneQHbNcxlIwfft/48PSvYPC3gzRvC +l2cFrptml3FAkct0sKiSRgOSWxk85NdJXasHSXQxdabPFNB+FfibXrr7b451iWO1cc6VZylVYH+ FyvA6kcZJ/vV6rovhrRfDsTRaPplrZK33vJjALfU9T+Na1FdCSSsjNtvcKKKKYgooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACmsyxqWY4VRkn0p 1cr8R9X/ALE+HeuXok2SC1aKNh1Dv8i/qwoA8A+HjHxT8XdQ15/O2q094u7nG87VU/QMeP8AZ46V 7vXk/wADNN8rRdT1NgwNxOsK5HZBnj8X/SvWK/O+Ia/tcdJfypL+vmz1sJG1NeYUUUV4Z0hRRRQA V47pw/4Qr4pX2iv8mm6via2ycKrHJUfnuT1J217FXnXxd0CTUPD0Ws2e5b3Sm83ehwRH/ER9CAfw NezkmJVLEezk/dnp8+n4nPiI3jzLdHVUVheEvEMfiXw/BfAqJ8bJ0H8Ljr64B6j61u19PKLi7M50 7q6CiiipGFFFFABRRRQAUUUUAFFFcp4r8ZLoFza6dZ2hvtVuyFhgDcAkgLnvknoO/qKuEJTlyxE2 krs2Nd12x8PaZJfX0m1F4RB96Rv7q+/8up4qh8LPCd94i8Qt8QPEMDRBv+QZbsTgLjAf6YJx6klv Q1seGvhPcXOpRa744u01G+TJhsU/494OeP8AeI/L1z1r1UAKAAMAdAK9bD4dUld7nJUqc2i2HUUU V0mYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFeNftF6t9l8G2GmJLte9u9zJ/eSMZP/AI8yV7LXzX8dLptf+JmkeHoZVxFHHEcc lJZX5z/wHYaTaSuw3O5+HOnrpvgHSIxkmWATsf8Af+b+orqaZHGsUSxoMKoCj8KfX5LXqutVlUfV t/ee7FcsUgooorIoKKKKACmuiyIUdQysCCp5zTqKAPCNTtL34TeMDc2sTzaFfHG3rxydmf7y5OCe o/HHqGm6laavp8V7ZTCWCUZDDt7H39q2tV0qy1vTZtP1CATW8o+ZTwQfUe9eH6loXib4Xaq19pzv d6O7cnkoR6SL/C3+1+vJFfaZdmMMbBU6rtUXf7X/AATgqU3Sd18P5HsVFcb4e+JWh60qRXEn2C7O B5cx+Un/AGW6fng+1dirKygqQQeQRyDXbOEoO0kJST2FoooqBhRRRQAUVDc3dtZwma6njgiUZLyN tA/OvPvEXxXtLYm10GI3tyTtEpUiMH2HVv0Hua0p0p1HaKJlJR3On8WeLLPwrp3nTYkunB8iAHlz 6n0H+etVPg34LvNX1d/H/iFGM0jE2KMMZyMeZj0A4X8/Q1S8AfCPVPEOpp4k8ceY0LYkjs5yfMlP beP4E/2f0A6/QSIsaBEUKqjAAGAK9ehQVJeZy1Kjmx9FFFbmYUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXzDo7nxT+0Fq WonHl2880g75WMeUh/8AQTX0P4o1X+w/Cuq6qBlrS1kmUE4ywUkD88V4D8CdOIh1fU2A2syW6Hvx 8zfzSvNzit7HA1Jd1b79DbDx5qiR7HRRRX5ieyFFFFABRRRQAUUUUAFIyq6lWAKkYIPOaWigDzzx D8INA1dmmsN2mXByf3IzET/udvwxXEyfDzx/4alB0W9a4hVjhba42j8UfA/nXvNFexhs9xlBcrfM u0tf+Cc88NTk77HgP/CU/EnSi0d3pdxMVP3prEn9UAFQTfFnxRav5Vxp1hG+PuyQSKfy319C0V3x 4jj9ugn6O36Mz+qvpI+fYfij4uvlJtNLtZQDjMNtI2D/AN9VKNU+KOtyEWtjeW6Y6LaiFf8Avp/8 a99oolxH/JRS9Xf9ENYV9ZM8MsvhF4n1qRJ/EOq+SMdJJDcSj1HXH6mui+FvhCy074wavFAvn2uj 2qhHmGX819vzdMD/AJaD8uvJr1GuV+DEBm1nxvqruzPPqhhGTnAQsR/6GPyFelkeY4nG15+1fupb JabmGJpQpxVtz1yiiivpziCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAPL/j1q39nfDSW2DMJL+4jtxtPYZc/h8mPx rL+Fumf2Z8P9P3Kokud1y5Hfcfl/8dC1zv7RF9Jf+IPD+gWxZ5ljaUxA4DNIwVPbPyH8/evTbK0j sbG3tIVCxwRrGoHYAAV8txTW5aNOl3d/u/4c7cFG8nInooor4g9IKKKKACiiigAooooAKKKKACii igAooooAKKKKACuW/Z/m+1+EdZvMbfP1iVtvpmOM/wBa6muS/Z0Up4A1FGBDLqsmQeo/dRV9fwol es/8P6nBjvs/M9fooor7E88KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+aNSk/wCEu/aNmIJlttPn2jts8hf1Hmj9 fSvZayLP4a6L4U1q612zub+e9vi/mG5kRlG5tzYCqO475rXr4DiWq54zk6RS/wAz1MGrU79wooor 546wooooAKKKKACiiigAooooAKKKKACiiigAooooAK5v4IER2Pim17xa3Nn8lH/stdPBEZ5RGpAJ 7movBngc+EtY1++XUmuI9WnW4+zmLaIWy5ODnnO70HQV9bwqpKdSXSy/r8Tgxz0R2lFFFfZnnhRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf//ZDQplbmRzdHJlYW0N CmVuZG9iag0KNTEgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjYv QmFzZUZvbnQvQUJDREVFK0NhbGlicmksSXRhbGljL0VuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9G b250RGVzY3JpcHRvciA1MiAwIFIvRmlyc3RDaGFyIDQ1L0xhc3RDaGFyIDEyMS9XaWR0aHMgMTM2 NiAwIFI+Pg0KZW5kb2JqDQo1MiAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFt ZS9BQkNERUUrQ2FsaWJyaSxJdGFsaWMvRmxhZ3MgMzIvSXRhbGljQW5nbGUgLTExL0FzY2VudCA3 NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTAyL01heFdpZHRoIDE2OTAv Rm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNTAvRm9udEJCb3hbIC00NzYgLTI1MCAx MjE0IDc1MF0gL0ZvbnRGaWxlMiAxMzY3IDAgUj4+DQplbmRvYmoNCjUzIDAgb2JqDQo8PC9TdWJ0 eXBlL0xpbmsvUmVjdFsgMTI0LjEgMzM2LjI5IDE3Mi41OCAzNTUuODVdIC9CUzw8L1cgMD4+L0Yg NC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9sZGFwLmFrYmtob21lLmNvbS9pbmRl eC5waHAvb2JqZWN0Y2xhc3MvcGVyc29uLmh0bWwpID4+L1N0cnVjdFBhcmVudCA1Pj4NCmVuZG9i ag0KNTQgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAxNzIuNTggMzM2LjI5IDE3Ni4xOCAz NTUuODVdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9s ZGFwLmFrYmtob21lLmNvbS9pbmRleC5waHAvb2JqZWN0Y2xhc3MvcGVyc29uLmh0bWwpID4+L1N0 cnVjdFBhcmVudCA2Pj4NCmVuZG9iag0KNTUgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAx MjQuMSAzMTMuMjUgMjYzLjU3IDMzMi44MV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlv bi9TL1VSSS9VUkkoaHR0cDovL2xkYXAuYWtia2hvbWUuY29tL2luZGV4LnBocC9vYmplY3RjbGFz cy9vcmdhbml6YXRpb25hbFBlcnNvbi5odG1sKSA+Pi9TdHJ1Y3RQYXJlbnQgNz4+DQplbmRvYmoN CjU2IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMjYzLjU3IDMxMy4yNSAyNjcuMTcgMzMy LjgxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vbGRh cC5ha2JraG9tZS5jb20vaW5kZXgucGhwL29iamVjdGNsYXNzL29yZ2FuaXphdGlvbmFsUGVyc29u Lmh0bWwpID4+L1N0cnVjdFBhcmVudCA4Pj4NCmVuZG9iag0KNTcgMCBvYmoNCjw8L1N1YnR5cGUv TGluay9SZWN0WyAxMjQuMSAyOTAuMTggMjIwLjk0IDMwOS43N10gL0JTPDwvVyAwPj4vRiA0L0E8 PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL2xkYXAuYWtia2hvbWUuY29tL2luZGV4LnBo cC9vYmplY3RjbGFzcy9pbmV0T3JnUGVyc29uLmh0bWwpID4+L1N0cnVjdFBhcmVudCA5Pj4NCmVu ZG9iag0KNTggMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyMjAuOTQgMjkwLjE4IDIyNC41 NCAzMDkuNzddIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6 Ly9sZGFwLmFrYmtob21lLmNvbS9pbmRleC5waHAvb2JqZWN0Y2xhc3MvaW5ldE9yZ1BlcnNvbi5o dG1sKSA+Pi9TdHJ1Y3RQYXJlbnQgMTA+Pg0KZW5kb2JqDQo1OSAwIG9iag0KPDwvU3VidHlwZS9M aW5rL1JlY3RbIDExNy42MiA4Mi43NzYgMzYyLjMzIDEwMi4zNF0gL0JTPDwvVyAwPj4vRiA0L0E8 PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3d3dy5zaW1wc29ucy5jb20vaG9tZXIuanBn KSA+Pi9TdHJ1Y3RQYXJlbnQgMTE+Pg0KZW5kb2JqDQo2MCAwIG9iag0KPDwvVHlwZS9QYWdlL1Bh cmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjYgNTEgMCBSL0YzIDE0IDAg Uj4+L1hPYmplY3Q8PC9JbWFnZTYyIDYyIDAgUi9JbWFnZTY0IDY0IDAgUi9JbWFnZTY2IDY2IDAg Ui9JbWFnZTY4IDY4IDAgUi9JbWFnZTcwIDcwIDAgUi9JbWFnZTcyIDcyIDAgUj4+L1Byb2NTZXRb L1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBd IC9Db250ZW50cyA2MSAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0Rl dmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDEyPj4NCmVuZG9iag0KNjEgMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg3MD4+DQpzdHJlYW0NCnicrZpbTyM3FIDfI+U/ +KmaWRHj+0VCVCxhu6yWlgq0fWD7kIYAaZcMJbCI/vqeMxOSmdhWsjN5QODYM9/xufn4BLJ/Tg4O 9s+OT4eEHR6S98Nj8m+/xwijjDEuBLPECka0YuRx0u/98Y7M+j1ObpdrGDOcqcaim3f93u/9Hjk5 OyakBuALwPvLfm//AydKUWYUubzBN8LrCCdcOco1UdpR7cnlPWJK1i/93lX2sXghuc6ui3wgMvKS +2xCcKAyMn0iTzAurnFqlHOXvf6c/0kuP/V7J4BD5BtDW069qjOuMlJbG8gt1uTmoiGzsYwaQwSj XrhKZqqlLeUu/yhlNwlpjDXUuvrTG6SRC2k4eVkoBv78m/S4M0QJQzWBd+CAS0cl+dbvXfR7PeE5 rc1Xw8YK6WvzOGjMaiFWszhozCoOE9IxqnDaGLMcNhZoTkVtQTlsLBD1adGcFBZFXk5Xw8YCJer8 athYwGWdXw3fFtS2p9Z2B8tXkzgI9w7TqxfjoD6Jy91quhpWCwLrqlUQog2lspQDkGmqHOFcgMSr OFw6pKZgr7pPCljJPFHMUumCODob5QOZzZ5HGDrfMGL2ah4HoduVbjQ1MkUnHVmumTIE49R5cLcy cwQpYzS73jFPGip1ijfYMQwcSNgUbDKDlPf0mA9M9rpjrtXU8hR3zYKBE+uVE1eJRlqBPgIHBYSk 9dS4rfxIQoTapB+9f/72T+i33YAKHFdv77gdYZ6KJOz4IrfZlx0TraQ+mRU2WdWsrIrHg8Q4ABmE pg58S8ptpVCcozem9v08hyP+KVdZcU9yzrOj81NMU3OSu+ynQB+dJNHMUChAtjb3D8LWYkoJCD+X iqnjYjabjMut66x4zAXL5rsWwMMjqm1Q25X58fyXQpViKFmKoe3WSpeKwgGZUPoFWPno7HOw825I qBX49mbuyFLUplifcpmBfxsw8m6h3mMJmqCGZ1InmIGsoxPxi3cC5aE+Hl9l09mOudykNbvrPQpI syIFu5xiRrqf7JipJd4EWmZn1zo817KE1nCoiFSWOH/Eu1UBdcf36XyKpWMxm85uu2piTQaDWS0p wyZV+JUqcCNQ9WDxs5ACtAvX1YgUbi1XQqkktac+5J88wukEejCYp9c33proQA1KpZihf7cGQQWh TBJ0vtzbLPTv1kwOSR8SVIK5yaCcNSwqjIey500CeLM12xpUMmpVwP88+ituyVYkz8B3VYoVNWQ7 jqFcJTmnMzDkU8413hLgtjeffodzJ2rSVnRuBF7S4/CNBuVNg0IKECufMpKyaKKIWRRufzoU4AJ2 rrLRtwk5Go+xiiyeS32EJVVrPNcQsCn+RgWIXSlAQPnvQwG+ZrMirGxao6xFp0iwrifoYA+PqPIC bi14MhRQ6YTnf3tlwzqVFOBrvkuSoy5J2mhX2bArdx4r7japSmioWUMBvuTKLiL6Op6z2jE5E1iV J6jRpNUWZMt+Zxw0f8CdTcZTCNab6XiHWEhXwEtgN5pVBWbl4k2EKja2tCrUlV5GDqDyTrBM1mOI nrCj05aM7R+0bZy9ce+62ZIUDGv8t54SJsFoT6kpArK1T4kwHOWCw4ZN5MrbHqkNZbL1rs16D4vD xW7Zc+HMbJVN8HgwPCXERzBz8fyIm5/vD6tvLaJK6CKBgzIhKcFGNdim4xuDNfzC/YyKtxMjfs+9 oFYE+N+wz3NXHh/xXNaCB6pyUH4liBs37Nbt7stry0Lp4FM2KoNCB224H1zJtQUxDFVhwvkVtwwH tLBQmN0/5DqDUgVvUze5gPyHFQukAwaJAPSTcIeWgi0uVQnBUj3OtjDOsIPLsUcZwu5hd9Ve77Dp db1HYkXLDwpg1iUou6yY/13oDk/4JWKxa6TiVMoUMjxLu9LKnnWC9gL1WJVYdmxZ9G/mYQLSUIid 41n2iiV35cHLO+X0v5x7kMhnT9MiLBA7e7bmKZE2Rr5vdlA4t2W2XdQZkMbiZ20ghpbAN1tE/sOb WuKNpPYCwDkhVUqAeKesA8zhzT4BW26x+I77LltGsmwZwcRtPrDZXrz/2l4eozEOEhkHsZEU043o JPZDE8Rb2L6FU/4h5zJysnciGyFKQ8fJmxxesLX/axA26CtD4UjgDOZhOB3NrvegfIFDC0L5blL5 MZnO69TqxSbyYgGlHOhs9eoruKy/jF7nwdMxsYSDSoA3nl7HrtIUw2O4vnQ+vpvcjxLrJdTUxjfW DwKZZEQmrLOErD94wLjVDC5WDKr26kcPDyV+bOBP/NcZeTjgFj7wR4cePx/iZ4zzI/g5qR41H6rP jvnhAJ/VQ1wOv48O1QGT2pev2UZr2F/WSaWF7sG3/n8gjd8rI0R6hOLFGxuMqryejAG1f3o/up0Y QYYFibqi6MqCEILYqbFUkiU7soTjW7NUV5b0azpMs/T2LI436BUMayQpIhszSZjpDAt2lobZtlpU smz6hJ7okizXkRXsy7Iky7dWIn6jGbOYbYTY//UvsZwNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MiAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTQ1L0hlaWdodCAxMTEv Q29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNl L1NNYXNrIDYzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzNzI+Pg0Kc3RyZWFtDQp4 nO2c+1NU1x3A8y9Yeeze9/vevfsCiWljksa0SabtTOojUcfENskvSZra+MJYqqONEcS34mNACAj4 4uECBnbBF4Qoogi7EJCIqAFRsbZpbfsH9LtLuJyg2dAE2Bn9fuY7Owt77hnu/fI553vO3t0nnkAQ BEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEGQceYvK1cGKiq6 Ll0aFfDLnKyssfTAs+x3dQK/f27GjIk+hccKuM7/vXs3SsBlX7RgQZQe4NXoPUBE7wEZO6DA917t oaxF6eTH94CMHUuxwRN193dsu5+2MhIf/jsS/zl80Lrm0PKhPWRnZVlt/r59C3TyL6KHrw8VW6/i 8DguWCm7URuoMZRbKZ6BSMCTO0967j3pvbd9i6XJg9ccpjArI72bM68ku8gebkxzdyxfYjWAxjE5 x0cMyMLQ9bwTCuZIfL1TO24of5vuvTfdC5e9J9k1+JuXo4hGKta1aCEc3ul1Dk739k1zwz9Ak8vo LSywGsTkBB89vqVJwF+pyzsEdq/IhbzmzRTPlSRnf4rn7qrUhw5uVrohrm7OhENOmdo5l9HuNQ+p 4mdOvf6F56wGMGnG8DQfMXKGTbkdChY/87NjuvxXlsqT+evT3NemuaOIRpaa591Gg1Ovc6inTa1c k0s06XOXPlBXixPZRECKdjXgL9OkrTyTydM+XQbRepJcMMrdeWvRqItPKgazWHtEsQan5neoxYp4 xtSaFs5HxSYOcmHle22O31DXMvYske1KcoJr3UlOEO1+RwdZrpOKNQ8rBlkr1SR4Aj/eJBSL9fk9 gpCi9QT8h1Vxn8ht5OhyXR4qQr6a5h4kRCNXc13Ll4Jip8OK6VByFCrCSVNrXfYBLqInGnKgK3t1 dqWurGbsO4WwaFCrX05y3k7x/PPkiQfXyBfcBlQadWZYMZjC/JHprL/2G8Uu4wp6wgDRAj7fN8vq UKhIEaEOSedosAZEu5rsup7sHnz7d6P3NFaEFavSZVAMqs18WbjodnRu2ohVx+RAilbzxz/ArPRn 2raNZ77wmteTXV1e50CKmxTtH+3tzS6YxTSYvGodKgynJ83wk77aQPQNE2QcsYoKWFnnyny1oaxn qXyZ74sUIbBMG/j1S1bKOpcvCXocFbocKewlKBTPufSOzAxUbDIh65Bgft5BRYCUbebo8y79WrKz 02v2Jbu+joh2q662CaYwQwkYClQdxYpQb2rVuoyF/eRjiQYr670id0yToODfL3E3kl2XvSZE/69e hFdbXp/f6jZ8kZK+RJWOqCKk7MqBAlRs8hm1si5VJbAsg6WP63KP1xlyO64lua6uWHbW1P26Uq0r lZpcIAl1htq4YN6IYqmpsT6Pxwtrs/d2MJj/9FOHFWE1bYOVWm+Ss9NjdngcEGedWrkqQdZg8IS0 wgjZP1x14Np58vnWytrvL5aFdJZaz1CHFKHbY7a5HO1uB/j1qS5D1nJFHqawM/Nfw7VzbCG3sI7O mQUF4SrKtltgYWDscDvqHVqpKsJQWSgLMJ1Byr4aVgzXzrGCFO1Lf02RzO8RWHANjDuqijW6XKVL lZoE9T/kK7Qx3Wr8BioWO0aKkAMFDQ7Np0pVmlyqiODaasqWL/GXPWary2hzGT0v/8Jq7Pf5Yv2H P6Zk79o1sou4cN4ph1KmihWaVCDxMCR+xNjX0bZCmW93Gy0uvcvjuFNciANjDCFHxS8yMxpM9Zgm wjB4VBH2CgwUh0cUIdWesJOnOz0OSBnEly+9YB0SQNEmHWt/GKJ+5rOVmliiCuWqmCdykKwSRcgW 2U0ctYaG4ZELuvTzTi3kNnpXLMV1dEwgN4cvLllc71COqWKlKh6S+SyerjPk1owNRbNfKZb5ZbaE bRx90alBQNa6X5w5MqPhhvAk4h/esLoXCgWgLFTFEoUvU4QckS2HVbMiXA/4YYkNI2QGY0+jEvNE ts2pN5lqq0vrfmMBijbJkG83X/xg8WlDLpQ4nyoUiOwOjq7RpJaMDUOvFsx6JV9klyTGrWdsZwy5 2dQaHUrnL58feSsN65BJwdoT7qsNQILAryNyOPYJzFGZPyzzVkZAtJ0cnSuwq+wJOQLT4tQ+dyjN ptr1+nwUbdIgFWuYN9eviQdEtkzhYejbzdNVqngh/WPyLeny996BZC1OiFtHJ57SpXOmArq1ONXB 4Rt1ULSJxsoFKFatiUUSd0jiDkoc5Ase4cdRdxHcCga3stQ+nk61xW/nKFCswZDBtU5CNNxvnDjI W7VBsUolPH/BYAgeZfOMTxE68/NGpQyi9N139vL0+wlT11CJJzTprKGc1uULDhRtwiHXzq0ZH1er YpEYVuyAyO3iqBKZL5vxU6tBWuSjf5ZomYwd6pDlifFgXJNDOaPL9bp8ibi1O3tsHypE/i9yCMXq 580tkfgCgT0scTDo7eHoUpnv+GREMSgqyBQ35+7fyVLvxk9NsydUKMJnugy6nTMUFG3iINfOrekb jisCKHZQ5PIFdjtLQeKOPv0UqdjQUZZoA8FgOm3bzzNLE+M2MXYYG09pEkTLzBHR8Far8YW8VbtM 5oeSBY/gVxZHHZG4dkIx6zNipGjnc/dvZShI2SpbAhzboMu1qtioy33Dt4I89LNpyA+DfCuzcfH7 VbKQyzPFIpvHM1sYe5HIHp87y2ow6o6OnOHdfhDtIypxH0f/KSFuI21rjIyNAVVsfv5ZFG3csRS7 GwqWSlw+z8CV30TbdrHUDtZ+UGB7/TXWZR91LClad031Ho5Ks8WvSIxbY08okbiAIpzRpI4lix80 FPnBkLOYf+7sSpn/MDH+zalT3po65b34nxQITMWc30ZfYVl1y0CwbXtKchZL/X7qFIg3Iz3A/0DT z59B0cYRcrtjN0ttoW1bads2Jvy4j6WyWHsUxYYgReuqqc6gEjNp25ZIJxDZHF0sML0Fn2DKxgsr Zf1tbfU52ZXr1latW3s88ghxM9g2lk0McjaEQxr351QN9wBRSfSD1f6Ph3QkSkS/N2CMnUTPOzJ2 vverWi6PoT4n58TvCry7YBwJf/1UaipMNOHw+axIS01NG/NHIaATkAiqEbKHoT7xO6wQBEEQBEEQ BEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEGQceR/YZOkvQ0KZW5kc3RyZWFtDQplbmRvYmoNCjYz IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNDUvSGVpZ2h0IDEx MS9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4 L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA0Mz4+DQpzdHJl YW0NCnic7ZjPb9tkGMfzvn5tx3btpE66OEnrusFNWrVp3YyRdGtp2nRjaKxih1Wjm6AgxiZACE3s BlJhl2n8EFe0A0MaHNmNA0JLJnbgAmJDaELrCBc0jX/C2OmW5nXi3nhy4P0cIvmRouej7/vD7+tI hMFgMBgMBoPBYDAYDAaDwWAwGIxQturNFvUvO6vWk/JWFdin7rZpbrarm7tVdzP0v/8FWx2d3Wa7 3LsKQb2ztVtHO9VrVLUK6IMaVOvmcstojCq6YwjOB9fo3g2EIgjRAbkchjJCiBune7vLCKFlunSJ wAlhXvo6EBFGmB5G96gAFhHCglIKRLSCV+jClXgULCLECapxke7/FwkEZCZkHk5IVNOBQNxL9OP7 VhJWyCicd/fgoWNBJoT5gX322i97CL1bNAclwGVGZH109p1wn98OTqQ1kYDtjN6YxdKF+TuhQhfn xpIKz8EJYV5JWM6pMJ9vFicygKveA3PRvSK6sN9KDghwAbUj2ujtc/3QpBEDnNItIyJqRv7g9z2F ao6lywKojx+RrI/0nkWfVfIpVSQY0mdnc0zlKx93+zysFU0deMAiO2/8QXPmZLfQlcp4SvXe9LA+ j98f+XK30M+zI5Cb9K4QJpI+cqNb6O/8vgHgGf3YyDuEHOg1qW/7AcH7tBbajz2X/fMi5J7YIUQO 9/Rxb/VlxHyhW72F3NU+CX0Y4uM2+yTUCBNyV/ohFB6Qd+TvQ0SIC/dx3dfg98XgxbnfEaEcbXDz T/r5Gvi79Sta4PMPAhEB740ocE+8cebMPbrSgD0wBpf8+WPHzgYiAl366FW6+/Ujiwu1m/2LqCug 5+Ydp3yarrk5BHcvC8ygTw8VbXuq8kO/IkL4I7p1dTaXzVjFwJG/AbbQgkKXn8lnEom0Xf6EntZw H6xIobPxo8VpM6GqenZ6nRJ6A+zuiol8ebfvPxeefiqlSZI6ZB94r8Pntgp1cPTv0clnv/j19z/u b29/9+3awmQ2LgmCFMtOLbx+9aftBw/u37t79XQ2FgU6WreEcnPLJ14+9+a5V15cckaTikCIoAxZ s37x7bfObhytTGQghWTdnJo/cuLUS+tr1dJ4SvNaYyLGDHt/9YWTGxvrx5dKtgF3ncZcVDNyxfJS bbU6P2NnYhLPIcTxcjxtz5SXVg+vLJQKwwkFbFJ7NzJZT49NFJ254qRl6Ir/iRxhTlDihlUoOiVn 2h4e0gC/U3vDo8SH0iOj5nA6EZN3Ptl7GQmSljCGzVEzm9JVLzbArZoI0oAWHxyMa0rUb4xaVY4X ZTXmlWOqLPrDCOQT8ceHCKIkSVFRIO0gkDezeTEa9cs8gcvniRJHCOE4jDuC8JQ4vx4oAyl5Uv5P SLkfNzMGg8FgMBgMxv+KfwETksTbDQplbmRzdHJlYW0NCmVuZG9iag0KNjQgMCBvYmoNCjw8L1R5 cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE0NS9IZWlnaHQgMTExL0NvbG9yU3BhY2Uv RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayA2NSAw IFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzcxPj4NCnN0cmVhbQ0KeJztnPtTVNcdwPMv WHns3vf73r374hHTxiSNaZNM25nUR6KOiW2SX5I0pcEHxlIdbYwgvhUfA0JAwAcvFzCwC74gRBFF 2IWARkQNioq1TWvbP6BflnA5QbOhCbAz+v3Md3YW9twz3Pvlc873nL27TzyBIAiCIAiCIAiCIAiC IAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIBPMX1asCFRV9Vy4MCbgl7nZ2ePp gWfZ7+oEfv/czJmTfQqPFXCd/3v3boSAy7544cIIPcCrkXuAiNwDMn5Age+92sNZi9DJj+8BGT+W YoPHGu5v33o/fUU4Pvx3OP5z6IB1zaHlQ3vIyc622vx922bo5F9ED18fLLFexeFxQrBSdr0+UGco t5I9A+GAJ3ee9Nx70ntv22ZLkwevOUxhVkb6NmVdTnSRPVxPcnctS7UaQOOonOMjBmRh+HreCQVz Jb7RqR01lL/N8N6b4YXL3pvoGvzNyxFEIxXrWbwIDu/2OgdnePuT3PAP0OIy+ooKrQZROcFHj29p EvBX6/J2gd0jciGveTPZcznBeSPZc3dl2kMHNyvdEFc2ZcEhJ0ztjMvo9JoHVfEzp974wnNWA5g0 o3iajxi5I6bcDgVLnvnZEV3+K0vly/y1JPfVJHcE0chS86zbaHLqDQ71pKlVanKZJn3u0gca6nEi mwxI0a4E/BWatIVnsnjap8sgWm+CC0a5O28tHnPxScVgFusMK9bk1PwOtUQRT5lay6IFqNjkQS6s fK/N9RvqGsaeLbI9CU5w7VKCE0S739VFluukYq0jikHWyjUJnsCPNwnFon1+jyCkaL0B/yFV3Cty Gzi6UpeHi5CvktyDhGjkaq5n+RJQ7OSQYjqUHEWKcNzU2pd+gIvoyYYc6CpenVOtK6sY+w5hSDSo 1S8mOG8ne/55/NiDa+RzbgMqjQZzSDGYwvzh6exG/TeKXcQV9KQBogV8vm+W1aFQsSJCHZLB0WAN iHYl0XUt0T349u/G7mmEFavRZVAMqs0CWTjvdnRv3IBVx9RAilb3xz/ArPRn2raVZ77wmtcSXT1e 50CymxTtH52drS6YxTSYvOodKgynx82hJ/31gcgbJsgEYhUVsLLOk/laQ1nHUgUy3x8uQmCZNvDr l6yUdS9LDXocVbocLuwlKBTPuPSurExUbCoh65BgQf4BRYCUbeLosy79aqKz22v2J7q+Dot2q6G+ BaYwQwkYClQdJYrQaGq1uoyF/dRjiQYr6z0id0SToODfJ3HXE10XvSbEjV+9CK+2vb6g3W34wiV9 mSodVkVI2eX9hajY1DNmZV2uSmBZJksf1eVerzPkdlxNcF1ZvvS0qft1pVZXqjW5UBIaDLV54fxR xdLSon0ejxfWZu/tYLDg6acOKcIq2gYrtb4EZ7fH7PI4IE47tUpVgqzB4AlphRHyxkjVgWvnqedb K2u/v0QWMlhqHUMdVIRLHrPD5eh0O8CvT3UZspYn8jCFnVrwGq6dowu5hVU6dzYUhCsp2y6BhYGx y+1odGjlqghDZZEswHQGKftqRDFcO0cLUrQv/XXFMr9bYME1MK5UFet0uUaXqjUJ6n/IV2hDhtX4 DVQseowWIfsLmxyaT5VqNLlcEcG1VZStQOIvesx2l9HhMnpf/oXV2O/zRfsPf0zJ2blzdBdx0fwT DqVCFas0qVDiYUj8iLGvpW1FMt/pNtpceo/HcaekCAfGKEKOil9kZTaZ6hFNhGGwVBH2CAwUh4cV Ic0et4Onuz0OSBnEly+9YB0SQNGmHGt/GKJx1rPVmlimCpWqmC9ykKwyRcgR2Y0ctZqG4ZELuvSz Ti3kNvqWL8F1dFQgN4fPp6Y0OpQjqlitigdlPpunGwy5PXN98ZxXSmR+qS1uK0efd2oQkLVLL84a ndFwQ3gK8Y9sWN0LhQJQFqpimcJXKEKuyFbCqlkRrgX8sMSGETKTsadT8fki2+HUW0y13aVdemMh ijbFkG83n/8g5aQhF0mcTxUKRXY7R9dpUlvm+uFXC2e/UiCyqfEx6xjbKUNuNbVmh9L9y+dH30rD OmRKsPaE++sDkCDw67A8FHsFplTmD8m8lREQbQdH5wnsSntcrsC0ObXPHUqrqfa8vgBFmzJIxZrm z/Nr4n6RrVB4GPp28XSNKp7L+Jh8S7ryvXcgWSlxMWvp+BO6dMZUQLc2pzo4cqMOijbZWLkAxWo1 sVjiDkrcAYmDfMEj/DjmLoJbweAWltrL02m22G0cBYo1GTK41k2IhvuNkwd5qzYoVq0MzV8wGIJH OTzjU4TugvwxKYMof/edPTz9ftz01VT8MU06bSgndfmcA0WbdMi1c3vmx7WqWCwOKbZf5HZyVJnM V8z8qdUgPfzRP0u0LMYOdciy+FgwrsWhnNLlRl2+QNzanTO+DxUi/xe5hGKN8+eVSXyhwB6SOBj0 dnN0ucx3fTKqGBQVZIpb8/btYKl3Y6en2+OqFOEzXQbdzhgKijZ5kGvn9oz1RxUBFDsgcgUCu42l IHGlTz9FKjZ8lCXaQDCYQdv28cyS+JiNjB3GxhOaBNE2a1Q0vNVqYiFv1a6Q+eFkwSP4lc1RhyWu k1DM+owYKdrZvH1bGApSttIWB8c26XK9Kjbrcv/IrSAP/Wwa8sMg38psTnm/RhbyeKZEZPN5ZjNj LxbZo/NmWw3G3NGRO7LbD6J9RMXv5eg/xcVsoG3N4bExoIqtzz+Lok04lmJ3Q8FyiSvgGbjyG2nb TpbaztoPCGyfv8667GOOJUW7VFe7m6PSbbHL42NW2+PKJC6gCKc0qSs15UFDkR8MOYv5582plvkP 42PfnD7trenT3ov9SaHAVM39beQVllW3DAQ7tiUnZrPU76dPg3gz3AP8D7T8/BkUbQIhtzt2sdRm 2raFtm1lhh73slQ2a4+g2DCkaD11tZlUfBZt2xzuBCKHo0sEpq/wE0zZRGGl7EZHR2NuTvXaNTVr 1xwNP0LcDHaMZxODnA3hkOZ9uTUjPUBUE/1gtf/jIR2JEJHvDRhnJ5Hzjoyf7/2qlovjqM/JOfG7 Au8umECGvn4qLQ0mmqHw+axIT0tLH/dHIaATkAiqEbKH4T7xO6wQBEEQBEEQBEEQBEEQBEEQBEEQ BEEQBEEQBEEQBEEQBEGQCeR/yiCkvg0KZW5kc3RyZWFtDQplbmRvYmoNCjY1IDAgb2JqDQo8PC9U eXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNDUvSGVpZ2h0IDExMS9Db2xvclNwYWNl L0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRl IGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA0Mz4+DQpzdHJlYW0NCnic7ZjPb9tk GMfzvn5tx3btpE66OEnrusFNWrVp3YyRdGtp2nRjaKxih1Wjm6AgxiZACE3sBlJhl2n8EFe0A0Ma HNmNA0JLJnbgAmJDaELrCBc0jX/C2OmW5nXi3nhy4P0cIvmRouej7/vD7+tIhMFgMBgMBoPBYDAY DAaDwWAwGIxQturNFvUvO6vWk/JWFdin7rZpbrarm7tVdzP0v/8FWx2d3Wa73LsKQb2ztVtHO9Vr VLUK6IMaVOvmcstojCq6YwjOB9fo3g2EIgjRAbkchjJCiBune7vLCKFlunSJwAlhXvo6EBFGmB5G 96gAFhHCglIKRLSCV+jClXgULCLECapxke7/FwkEZCZkHk5IVNOBQNxL9OP7VhJWyCicd/fgoWNB JoT5gX322i97CL1bNAclwGVGZH109p1wn98OTqQ1kYDtjN6YxdKF+TuhQhfnxpIKz8EJYV5JWM6p MJ9vFicygKveA3PRvSK6sN9KDghwAbUj2ujtc/3QpBEDnNItIyJqRv7g9z2Fao6lywKojx+RrI/0 nkWfVfIpVSQY0mdnc0zlKx93+zysFU0deMAiO2/8QXPmZLfQlcp4SvXe9LA+j98f+XK30M+zI5Cb 9K4QJpI+cqNb6O/8vgHgGf3YyDuEHOg1qW/7AcH7tBbajz2X/fMi5J7YIUQO9/Rxb/VlxHyhW72F 3NU+CX0Y4uM2+yTUCBNyV/ohFB6Qd+TvQ0SIC/dx3dfg98XgxbnfEaEcbXDzT/r5Gvi79Sta4PMP AhEB740ocE+8cebMPbrSgD0wBpf8+WPHzgYiAl366FW6+/Ujiwu1m/2LqCug5+Ydp3yarrk5BHcv C8ygTw8VbXuq8kO/IkL4I7p1dTaXzVjFwJG/AbbQgkKXn8lnEom0Xf6EntZwH6xIobPxo8VpM6Gq enZ6nRJ6A+zuiol8ebfvPxeefiqlSZI6ZB94r8Pntgp1cPTv0clnv/j19z/ub29/9+3awmQ2LgmC FMtOLbx+9aftBw/u37t79XQ2FgU6WreEcnPLJ14+9+a5V15cckaTikCIoAxZs37x7bfObhytTGQg hWTdnJo/cuLUS+tr1dJ4SvNaYyLGDHt/9YWTGxvrx5dKtgF3ncZcVDNyxfJSbbU6P2NnYhLPIcTx cjxtz5SXVg+vLJQKwwkFbFJ7NzJZT49NFJ254qRl6Ir/iRxhTlDihlUoOiVn2h4e0gC/U3vDo8SH 0iOj5nA6EZN3Ptl7GQmSljCGzVEzm9JVLzbArZoI0oAWHxyMa0rUb4xaVY4XZTXmlWOqLPrDCOQT 8ceHCKIkSVFRIO0gkDezeTEa9cs8gcvniRJHCOE4jDuC8JQ4vx4oAyl5Uv5PSLkfNzMGg8FgMBgM xv+KfwETksTbDQplbmRzdHJlYW0NCmVuZG9iag0KNjYgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9T dWJ0eXBlL0ltYWdlL1dpZHRoIDE0NC9IZWlnaHQgMTExL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0Jp dHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9TTWFzayA2NyAwIFIvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCAyMzY1Pj4NCnN0cmVhbQ0KeJztnPtTVNcdwPMnNEFg977fr32BNs2M aaqZGtum02k1KsZqJ/0lMdb6Jg400UbFR8QXWgXkoTwVcBGFXUBQjCgoxt0FxWcMiEaMTpN08gf0 u+xwuRJFZlyWGf1+5szOHfbsGe/5+jnne849u6+8giAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAI giAIgiAIgiAIgiAIgiAIgiAIgiAIgrywsDSdnprqr66+cvHisJKTlQVvjaYRqAaVf94I/PGtyZPH +hZeHqAzoVd/evBghAIVRm4EwvScLSCj5JldHSlQ7WktgEGjaQEtiwpmf/Zs3fJDWuqP4fLJ/8zS dOKZHW5W+KEz9P2OzGGN/NjZGXk3Oysrxrf24gEzl9nbZ5Ys7vIY9ya57w4UuPh2kvvhH6ePrFi2 Ra5rC+b1TXL1WVq45DbuNdRjvKKIOR7e9PsqFCFbYANu47vXPQ9f93yd7Oyd6Lr/wfynKWYN980v Ngc9xmmH2v9LT+8kV6tT+9Khnnr7NzgeRhfoRrNLvbNm1GnyZ5Q9T2Shz7+Z6Lqa5Oh/d7o5pg1L G6xyXZn//imHUq/L55xarSZB6Fud6o0DhWaF8brBFwyrI/3BYJnM7+WZTSxZpYowpt1IdvZMdPU/ SbFhcoU8RpOhtDgUvy4Xy/wph3ru/TlmhVEuCpDRYFWs8r2/1KjSp5R9J0dfSXJEFIOJ7PsTjcMU s6aFbS6txaE26HKzoVQqQqMuw8DYNzhzoVzRBUwxZzFQrEjivaqYwZBFEgc5w81k5+1kV//fF5id Pz8lxRriWwNyNYflUn2aBB8H0VrnzrbWH+9bfNGw9r9v8aIqRUwnbdsHFOt5kmI+y6qtPSKXIUOY YNqC8fCkodwZlKsbV8pjg6nY/WCwQOSg2zcwxIEBxWAWu5XsfGBRbCjNWLHMlKtGk6B+h0u/smUT poVjjTV/CBbklyvCatKWyVEdbh0Uu5bkuGdRzCrX6QG5ThjKIUWAwMHFnXr/M3dFkOfHolggR2Br VPFzmsgXub6JrutJjhtJznt/eMcarMsrlsJirVoVIZOHKa9U4tucWtfmjShXbLAqdsvvOyhx2zlq C0tBFnE72dntcdyZ6HpUUhSp8CgUgqXWKSOcwPs1qUTiYfEFNc0WcEMjBphZ+rfBQNHkNyplfg1l zxWY3mTntSTjqse4+/tpkQpdK5ZecmleRWjSZcjhIdP40lCsC2SUKwY8tgr2+w7J/BaG3MgQFTJ/ K8nR6dZBtIclRY9CwVaHClrVadJxVTwock0whU39tfnZNFwgx4q/pqQMLZ9nwvI5nNvv45nbSc4r buOy2+j93bTO5Us7nFqVLPg1uVziYeZq1pVrBwpQrthjVey6zwfubKCJdRRRJvHXPUbQpd/wOM45 1FpVBLNgPMwXWBCtJWXW0O7TqlXjfRMvF9blc/mMP1fKwmoicTdHX3BoXW4j4NIhXhWyUKdKxSJX o4h+VeodzOFx9yn2gGLdg4cEILffLzCZDLWWsheJXLfHCDg1kAvGSchGcnjmmCo2zXkPd5/GF6ti 9YsXwSSVTti2seRRRTggsjAM1mtSucTBRYMm9aBc4016aurQ9vvc2S26cljijw2kgp9T9h0sBcNg p0uHrKPbbTxqbMDdwvHF7/VGQtBX7z+ly1UyD2ZBVp/N02USt8qesJOlut36V04Vyo3pbw9tF3u9 4/1vf+mwPjgGuRo16bDMVStCocBCyI4o4UXZp6StUGRDLq3dqXa59fvFB03FYPob7zt4uTCDFdqU 0axLIJdX4WG22sNRVeEcgy4S2eW2+G0MecGhdDjVdody9Z2p5qf8qFgMeezB8dxZtYpwSOIgTHk8 AxdemQ8V5EHgNtJEOpGYLzABp9rmUOD11spluF6OMda0sBPk0sTKcIy4UpHNYskGVfxq4wZ4y/vx RwUCvdQWv56ytWjSBUM5Z8jd06YMzWL4JCUmWI/7gllHZK5cZA9LXA5HlYhshcTe9vvCu8GBwE6W 3M/Tq+0JuTx90aGcNeQOh9I9LwUVixlWudqXLD6hChUwEkrcAYHZwZB1itCRscGsULXwQwjiPxMn /Ju0gYZthnxal7p+O+W/odBPTzr8hkQdU67vgsHjMg+RKhUZ8GsvSx4S2TKR+XpArki5Fwhk0sQ+ lkq1xe9giPMD8TqnS5fnzUHFYsBjC+Ql/2hQhXyerhDZPJ6GuNTI/PmM9cMOA1Qs/PA/LLkoIe4z IrFRFVp1qVkVIXD9g4dtULGxwzzy1OP3HZP5MoEtERgouxmyVGCLBWZYsCKKbaHshTy9EnJ7mmjX 5RZNhNJlOSmK24ljgVWuk7NnwmCYz9EwBuZy1BeU3Stx7RvWW0NgXp/P25/FkAvj4/5lTzgqc2c0 qUkV2nQJFRtTzP4HuWogweDoYp45yNO7aKKIpwu5oSdiaQPPtsw1GiiWQdr2s9SyxAkQ2bMQL0Vo hsxk6lvmR3LwIEdUsS6QT86aeUTk8jmqVGAgl9hOE5Ui25WfNyyFsD7TvFZXB9WWJ8an2RPAxNOq 2KgIrZrUO3iWAxWLItae78hYf1TiwCZwqoCjd9AEXEPszArWry3k7NoV+ePdQGAdYdvHkksSJmym 7GdU8YQiQLlgOc6BBxGjhXVrt3nWjIMcncdSxTy9hyG3UvZygQn9TK4I1kBfrauFwTDdlvCJLR7i e1IV/TLfooo9FsVwEzgqWOWqFtlClsplyY2kLZOyl/B0Dks+Ua4IZqxBsbX2xD00sTg+bo09YR9D Nsi8T+LapryJikURa1pYBtFhyDRb/Adxr0LJIGylPB18ilwRrIp119Vm0cTKxAkLXvvF3+Je/Tg+ bhNpg8Tjm8FDUziLPT/mhsbZ9ev20sRW0raNCpdshthNEwW/mjSCXBHMw299gUu5f3p3J2WHRjIH 2oFX+A9Q9+YbZiM4JD4n5i9vQG+fzs05unZNzdo1xwZeodwNXDK7+mktWBWDRlpyhjfSWXsct6ei hXWDd4Qy8h6Fdfk8QsGHmM9P+JuVg+c0nlae+dVjaOSZP5nSffEiyhUtzN+PChevN1IgBGmpqaOf ccJR27Ur/BNSgy2ES3V19qh/gQpBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEAR58fg/ 4KuRBg0KZW5kc3RyZWFtDQplbmRvYmoNCjY3IDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlw ZS9JbWFnZS9XaWR0aCAxNDQvSGVpZ2h0IDExMS9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVb IDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMTA0OD4+DQpzdHJlYW0NCnic7ZnNaxtHFMA1s9/Srr5Xsi2vZVvrD1mR hRXHUnCMZUtxTIOhMW0aEQglySEfJCFpaK7OoSWk9FxoD05IKfm4FQrFlNqmKTTJwSFQSnGDfEgO +Ss2s3Ica1YrUyg8HTq/277L+/H2zey8WY+HwWAwGAwGg8FgMBgMBoPBYDAY/0N6l1ZrdZaXGsNL y9vh5RKsTqlmvae2G151jQLQkNiyVneiy43REqSPZbmlpoJ34GxQH+2zhurRO7QPgvPBa7TQDGqW LGMoIYT5Cp27hhFylMcSOQQjhBAnDtO5rVmE++nIl4oAVCDiI2kf0tm3MHeXjkR8IpQP5uXAxBM6 /eky/Xw9rkkclI+gBBOfOgq0Tj2+Hur0w/mQ+nTt27D24MJQB5wP6R9/R/rjPXQ2imZMheofUiBR jaYKz1v7XM0nI14Bw+h4PJhXgt2j1ZY6K1MjpH14sA2abEC+2EDh51Y+V/L9UZ8A1D6eekcroZ7c iRY69ybTiYDMg30v6gXS4oOF2+4+l8f6omC74TZkyYeN7HFXne+LgJvPO8gS02Lmgc/dfMrZnrAX 6uO1g73EEpnjb5p1viqacN+K95AOUvXUxPVmn5lRIwReHiJkFyj7bZPOm8JgDL4825u0bj5trs8z I6hArvUdyBILPnBp51f7VRG+PNsd5Lref2tD93jqx6B7rj7W4Xa8LuJTdtex1tvks9bCx5pti89s Kx1yum+DT+vy2AUC10E3W+tYW+ALHuH1PXys00Cz6a6PozyP6McacAchTOf/6eIfdOAurBB2TMdf nLzWzg5CjsuDhwsfLPxKh9YgC4Qddys3pienTzk6KAV5nKdz3y/lc/mplXYVCGHH4vpsfCg1OOYY f2pgHYQ4emv+oThsdHY3jT8m0CZNpsEtKnF5tFcP60bWccNQAbuPEuYa835dGOgIqIGYOX6rMfxY BhrgycFw5HFDM5OBIuyTvSEjs/jLbvjVgpeHeWH29WG89N2LvzY3/3ny45Uj46auSoKk6v35yoXf n758ufn3nyvfkJEZ6MKl7mNOzH9y5vz5s9WjxXQioPC8IAe7hkjw7MVL504dm8n1Qvqoem9u+uhH 1ROL84f2JaM+kcOc4IsY6YNzi9WT1WNzB0eMMNSFFOlnb6hzID85UylPHcgkdU0iB2bMS2rUSO8/ NHu4Ml3I9sX9Mtx9pqRGEmYmN5bLDPTofkXgELJvObVIdyqTy4+NDvd1hLxgUxjiBFkNxRM9SSMR D2tyfdyqC/mCepeRTBqdesAnwU0ZREj0aoFQKBjQvBL/7kcFERIV1R8kYb+qiIBDD8KkfSVZURRZ Eji8kxiRqCjbYUnkOQx4ZLXbheN4nueotLanSxhKCdl/mdC/CjMYDAaDwWAwGP+Nt3Itux0NCmVu ZHN0cmVhbQ0KZW5kb2JqDQo2OCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2Uv V2lkdGggMTQ1L0hlaWdodCAxMTEvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVu dCA4L0ludGVycG9sYXRlIGZhbHNlL1NNYXNrIDY5IDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDIzNzE+Pg0Kc3RyZWFtDQp4nO2c+1NU1x3A8y9Yeeze9/vevfviEdPGJI1pk0zbmdRHoo6J bZJfkjSlwQfGUh1tjCC+FR8DQkDABy8XMLALviBEEUXYhYBGRA2KirVNa9s/oF+WcDlBs6EJsDP6 /cx3dhb23DPc++VzzvecvbtPPIEgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIg CIIgCIIgCIIgCIIgE8xfVqwIVFX1XLgwJuCXudnZ4+mBZ9nv6gR+/9zMmZN9Co8VcJ3/e/duhIDL vnjhwgg9wKuRe4CI3AMyfkCB773aw1mL0MmP7wEZP5Zig8ca7m/fej99RTg+/Hc4/nPogHXNoeVD e8jJzrba/H3bZujkX0QPXx8ssV7F4XFCsFJ2vT5QZyi3kj0D4YAnd5703HvSe2/bZkuTB685TGFW Rvo2ZV1OdJE9XE9ydy1LtRpA46ic4yMGZGH4et4JBXMlvtGpHTWUv83w3pvhhcvem+ga/M3LEUQj FetZvAgO7/Y6B2d4+5Pc8A/Q4jL6igqtBlE5wUePb2kS8Ffr8naB3SNyIa95M9lzOcF5I9lzd2Xa Qwc3K90QVzZlwSEnTO2My+j0mgdV8TOn3vjCc1YDmDSjeJqPGLkjptwOBUue+dkRXf4rS+XL/LUk 99UkdwTRyFLzrNtocuoNDvWkqVVqcpkmfe7SBxrqcSKbDEjRrgT8FZq0hWeyeNqnyyBab4ILRrk7 by0ec/FJxWAW6wwr1uTU/A61RBFPmVrLogWo2ORBLqx8r831G+oaxp4tsj0JTnDtUoITRLvf1UWW 66RirSOKQdbKNQmewI83CcWifX6PIKRovQH/IVXcK3IbOLpSl4eLkK+S3IOEaORqrmf5ElDs5JBi OpQcRYpw3NTal36Ai+jJhhzoKl6dU60rqxj7DmFINKjVLyY4byd7/nn82INr5HNuAyqNBnNIMZjC /OHp7Eb9N4pdxBX0pAGiBXy+b5bVoVCxIkIdksHRYA2IdiXRdS3RPfj278buaYQVq9FlUAyqzQJZ OO92dG/cgFXH1ECKVvfHP8Cs9GfatpVnvvCa1xJdPV7nQLKbFO0fnZ2tLpjFNJi86h0qDKfHzaEn /fWByBsmyARiFRWwss6T+VpDWcdSBTLfHy5CYJk28OuXrJR1L0sNehxVuhwu7CUoFM+49K6sTFRs KiHrkGBB/gFFgJRt4uizLv1qorPba/Ynur4Oi3arob4FpjBDCRgKVB0litBoarW6jIX91GOJBivr PSJ3RJOg4N8ncdcTXRe9JsSNX70Ir7a9vqDdbfjCJX2ZKh1WRUjZ5f2FqNjUM2ZlXa5KYFkmSx/V 5V6vM+R2XE1wXVm+9LSp+3WlVleqNblQEhoMtXnh/FHF0tKifR6PF9Zm7+1gsODppw4pwiraBiu1 vgRnt8fs8jggTju1SlWCrMHgCWmFEfLGSNWBa+ep51sra7+/RBYyWGodQx1UhEses8Pl6HQ7wK9P dRmylifyMIWdWvAarp2jC7mFVTp3NhSEKynbLoGFgbHL7Wh0aOWqCENlkSzAdAYp+2pEMVw7RwtS tC/9dcUyv1tgwTUwrlQV63S5RpeqNQnqf8hXaEOG1fgNVCx6jBYh+wubHJpPlWo0uVwRwbVVlK1A 4i96zHaX0eEyel/+hdXY7/NF+w9/TMnZuXN0F3HR/BMOpUIVqzSpUOJhSPyIsa+lbUUy3+k22lx6 j8dxp6QIB8YoQo6KX2RlNpnqEU2EYbBUEfYIDBSHhxUhzR63g2e6PQ5IGcSXL71gHRJA0aYca38Y onHWs9WaWKYKlaqYL3KQrDJFyBHZjRy1mobhkQu69LNOLeQ2+pYvwXV0VCA3h8+npjQ6lCOqWK2K B2U+m6cbDLk9c33xnFdKZH6pLW4rR593ahCQtUsvzhqd0XBDeArxj2xY3QuFAlAWqmKZwlcoQq7I VsKqWRGuBfywxIYRMpOxp1Px+SLb4dRbTLXdpV16YyGKNsWQbzef/yDlpCEXSZxPFQpFdjtH12lS W+b64VcLZ79SILKp8THrGNspQ241tWaH0v3L50ffSsM6ZEqw9oT76wOQIPDrsDwUewWmVOYPybyV ERBtB0fnCexKe1yuwLQ5tc8dSqup9ry+AEWbMkjFmubP82vifpGtUHgY+nbxdI0qnsv4mHxLuvK9 dyBZKXExa+n4E7p0xlRAtzanOjhyow6KNtlYuQDFajWxWOIOStwBiYN8wSP8OOYuglvB4BaW2svT abbYbRwFijUZMrjWTYiG+42TB3mrNihWrQzNXzAYgkc5PONThO6C/DEpgyh/9509PP1+3PTVVPwx TTptKCd1+ZwDRZt0yLVze+bHtapYLA4ptl/kdnJUmcxXzPyp1SA9/NE/S7Qsxg51yLL4WDCuxaGc 0uVGXb5A3NqdM74PFSL/F7mEYo3z55VJfKHAHpI4GPR2c3S5zHd9MqoYFBVkilvz9u1gqXdjp6fb 46oU4TNdBt3OGAqKNnmQa+f2jPVHFQEUOyByBQK7jaUgcaVPP0UqNnyUJdpAMJhB2/bxzJL4mI2M HcbGE5oE0TZrVDS81WpiIW/VrpD54WTBI/iVzVGHJa6TUMz6jBgp2tm8fVsYClK20hYHxzbpcr0q Nuty/8itIA/9bBrywyDfymxOeb9GFvJ4pkRk83lmM2MvFtmj82ZbDcbc0ZE7stsPon1Exe/l6D/F xWygbc3hsTGgiq3PP4uiTTiWYndDwXKJK+AZuPIbadtOltrO2g8IbJ+/zrrsY44lRbtUV7ubo9Jt scvjY1bb48okLqAIpzSpKzXlQUORHww5i/nnzamW+Q/jY9+cPu2t6dPei/1JocBUzf1t5BWWVbcM BDu2JSdms9Tvp0+DeDPcA/wPtPz8GRRtAiG3O3ax1GbatoW2bWWGHveyVDZrj6DYMKRoPXW1mVR8 Fm3bHO4EIoejSwSmr/ATTNlEYaXsRkdHY25O9do1NWvXHA0/QtwMdoxnE4OcDeGQ5n25NSM9QFQT /WC1/+MhHYkQke8NGGcnkfOOjJ/v/aqWi+Ooz8k58bsC7y6YQIa+fiotDSaaofD5rEhPS0sf90ch oBOQCKoRsofhPvE7rBAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQZAJ5H8a96S/DQpl bmRzdHJlYW0NCmVuZG9iag0KNjkgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl L1dpZHRoIDE0NS9IZWlnaHQgMTExL0NvbG9yU3BhY2UvRGV2aWNlR3JheS9NYXR0ZVsgMCAwIDBd IC9CaXRzUGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAxMDQzPj4NCnN0cmVhbQ0KeJztmM9v22QYx/O+fm3Hdh2nTro4Seu6wU1atWnTjJF0 a2nadGNoULHDqtFNUBBjFSCEJnYDqbDLNH6IK9qBIQ2O7MYBoSUTO3BhGiA0oXWEC5rgnzB2uqV5 nbg3Hh94P4dIfqTo+ej7/vD7OhJhMBgMBoPBYDAYDAaDwWAwGAwGI5DtRqtN44vuqvW4vF0D9mk4 HVqbnermXtXZDPzvf8F2V2en1Sn3r0LQ6G7tNNBu9RpVrQH6oCbVurXcNhqjis4YgvPBdbp3E6EI QnRADoehjBDixunezjJCaJkuXSJwQpiXvvJFhBGmh9E5LoBFhLCglH0RreAVunAlHgWLCHGCalyk +/9JfAGZCZmHExLVtC8Q5xL9+J6VhBUyClvOPjwsWZAJYX7ggL12Zx+hd4rmoAS4zIisj86+Hezz 6+GJdEwkYDujO2ZaujD/c6DQxbmxpMJzcEKYVxJW6XSQz9eLExnAVe+Cueh+EV04aCUHBLiAOhFt 9Pe5fmTS0ACndNuIiDEjf/i7vkL1kqXLAqiPF5Gsj/SfRZ9W8ylVJBjSZ3dzTOWrH/X6PKwXTR14 wCK7b/xBc+ZUr9CV6nhKdd/0sD6P3h/5Sq/QT7MjkJv0nhAmkj5yo1for/yBAeAZ/cjIPYQc6jep b3sBwfu0F9oPfZf9syLkntglRI729XFuhTJintCt/kLOakhCHwT4OK2QhJpBQs5KGELBAblH/hAi Qlywj+O8Cr8v+i/OYUeEcrTBzT/o52vg79YvaYHP3vdFBLw3It898cbZs/foShP2wOhf8lsnTpzz RQS69NErdPfrxxYX6jfDi6gnoGfmS6XKGbrm5BDcvcw3gz45UrTtqer3YUWE8Id069psLpuxir4j fxNsofmFLj+VzyQSabvyMT2t4T5YkUJ3478Xp82EqurZ6XVK6HWwuysm8uW9vv9cePKJVEyS1CH7 0LtdPrdVqIOjd49OPv353d9+v7+z8+03awuT2bgkCJKWnVp47eqPOw8e3L/3y9UzWS0KdLRuC+Xm lk++tPXG+ZdfWCqNJhWBEEEZsmbd4vm33jy3cbw6kYEUknVzav7YydMvrq/VyuOpmNsaE1Ez7IO1 505tbKw/v1S2DbjrNOaiMSNXrCzVV2vzM3ZGk3gOIY6X42l7prK0enRloVwYTihgk9q9kcl6emyi ODdXnLQMXfE+kSPMCUrcsArFUrk0bQ8PxQC/U7vDo8SH0iOj5nA6ocm7n+zdjAQpljCGzVEzm9JV NzbArZoI0kAsPjgYjylRrzFqVzlelFXNLWuqLHrDCOQT8caHCKIkSVFRIJ0gkDuzeTEa9co8gcvn sRJHCOE4jLuCcJU4r+4rAym5Ut5PQDmMmxmDwWAwGAwG43/FvzANxN0NCmVuZHN0cmVhbQ0KZW5k b2JqDQo3MCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTQ1L0hl aWdodCAxMTEvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9s YXRlIGZhbHNlL1NNYXNrIDcxIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIzNzI+Pg0K c3RyZWFtDQp4nO2c+1NU1x3A8y9Yeeze9/vevfsCiWljksa0SabtTOojUcfENskvSZra+MJYqqON EcS34mNACAj44uECBnbBF4Qoogi7EJCIqAFRsbZpbfsH9LtLuJyg2dAE2Bn9fuY7Owt77hnu/fI5 53vO3t0nnkAQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEGQ ceYvK1cGKiq6Ll0aFfDLnKyssfTAs+x3dQK/f27GjIk+hccKuM7/vXs3SsBlX7RgQZQe4NXoPUBE 7wEZO6DA917toaxF6eTH94CMHUuxwRN193dsu5+2MhIf/jsS/zl80Lrm0PKhPWRnZVlt/r59C3Ty L6KHrw8VW6/i8DguWCm7URuoMZRbKZ6BSMCTO0967j3pvbd9i6XJg9ccpjArI72bM68ku8gebkxz dyxfYjWAxjE5x0cMyMLQ9bwTCuZIfL1TO24of5vuvTfdC5e9J9k1+JuXo4hGKta1aCEc3ul1Dk73 9k1zwz9Ak8voLSywGsTkBB89vqVJwF+pyzsEdq/IhbzmzRTPlSRnf4rn7qrUhw5uVrohrm7OhENO mdo5l9HuNQ+p4mdOvf6F56wGMGnG8DQfMXKGTbkdChY/87NjuvxXlsqT+evT3NemuaOIRpaa591G g1Ovc6inTa1ck0s06XOXPlBXixPZRECKdjXgL9OkrTyTydM+XQbRepJcMMrdeWvRqItPKgazWHtE sQan5neoxYp4xtSaFs5HxSYOcmHle22O31DXMvYske1KcoJr3UlOEO1+RwdZrpOKNQ8rBlkr1SR4 Aj/eJBSL9fk9gpCi9QT8h1Vxn8ht5OhyXR4qQr6a5h4kRCNXc13Ll4Jip8OK6VByFCrCSVNrXfYB LqInGnKgK3t1dqWurGbsO4WwaFCrX05y3k7x/PPkiQfXyBfcBlQadWZYMZjC/JHprL/2G8Uu4wp6 wgDRAj7fN8vqUKhIEaEOSedosAZEu5rsup7sHnz7d6P3NFaEFavSZVAMqs18WbjodnRu2ohVx+RA ilbzxz/ArPRn2raNZ77wmteTXV1e50CKmxTtH+3tzS6YxTSYvGodKgynJ83wk77aQPQNE2QcsYoK WFnnyny1oaxnqXyZ74sUIbBMG/j1S1bKOpcvCXocFbocKewlKBTPufSOzAxUbDIh65Bgft5BRYCU bebo8y79WrKz02v2Jbu+joh2q662CaYwQwkYClQdxYpQb2rVuoyF/eRjiQYr670id0yToODfL3E3 kl2XvSZE/69ehFdbXp/f6jZ8kZK+RJWOqCKk7MqBAlRs8hm1si5VJbAsg6WP63KP1xlyO64lua6u WHbW1P26Uq0rlZpcIAl1htq4YN6IYqmpsT6Pxwtrs/d2MJj/9FOHFWE1bYOVWm+Ss9NjdngcEGed WrkqQdZg8IS0wgjZP1x14Np58vnWytrvL5aFdJZaz1CHFKHbY7a5HO1uB/j1qS5D1nJFHqawM/Nf w7VzbCG3sI7OmQUF4SrKtltgYWDscDvqHVqpKsJQWSgLMJ1Byr4aVgzXzrGCFO1Lf02RzO8RWHAN jDuqijW6XKVLlZoE9T/kK7Qx3Wr8BioWO0aKkAMFDQ7Np0pVmlyqiODaasqWL/GXPWary2hzGT0v /8Jq7Pf5Yv2HP6Zk79o1sou4cN4ph1KmihWaVCDxMCR+xNjX0bZCmW93Gy0uvcvjuFNciANjDCFH xS8yMxpM9ZgmwjB4VBH2CgwUh0cUIdWesJOnOz0OSBnEly+9YB0SQNEmHWt/GKJ+5rOVmliiCuWq mCdykKwSRcgW2U0ctYaG4ZELuvTzTi3kNnpXLMV1dEwgN4cvLllc71COqWKlKh6S+SyerjPk1owN RbNfKZb5ZbaEbRx90alBQNa6X5w5MqPhhvAk4h/esLoXCgWgLFTFEoUvU4QckS2HVbMiXA/4YYkN I2QGY0+jEvNEts2pN5lqq0vrfmMBijbJkG83X/xg8WlDLpQ4nyoUiOwOjq7RpJaMDUOvFsx6JV9k lyTGrWdsZwy52dQaHUrnL58feSsN65BJwdoT7qsNQILAryNyOPYJzFGZPyzzVkZAtJ0cnSuwq+wJ OQLT4tQ+dyjNptr1+nwUbdIgFWuYN9eviQdEtkzhYejbzdNVqngh/WPyLeny996BZC1OiFtHJ57S pXOmArq1ONXB4Rt1ULSJxsoFKFatiUUSd0jiDkoc5Ase4cdRdxHcCga3stQ+nk61xW/nKFCswZDB tU5CNNxvnDjIW7VBsUolPH/BYAgeZfOMTxE68/NGpQyi9N139vL0+wlT11CJJzTprKGc1uULDhRt wiHXzq0ZH1erYpEYVuyAyO3iqBKZL5vxU6tBWuSjf5ZomYwd6pDlifFgXJNDOaPL9bp8ibi1O3ts HypE/i9yCMXq580tkfgCgT0scTDo7eHoUpnv+GREMSgqyBQ35+7fyVLvxk9NsydUKMJnugy6nTMU FG3iINfOrekbjisCKHZQ5PIFdjtLQeKOPv0UqdjQUZZoA8FgOm3bzzNLE+M2MXYYG09pEkTLzBHR 8Far8YW8VbtM5oeSBY/gVxZHHZG4dkIx6zNipGjnc/dvZShI2SpbAhzboMu1qtioy33Dt4I89LNp yA+DfCuzcfH7VbKQyzPFIpvHM1sYe5HIHp87y2ow6o6OnOHdfhDtIypxH0f/KSFuI21rjIyNAVVs fv5ZFG3csRS7GwqWSlw+z8CV30TbdrHUDtZ+UGB7/TXWZR91LClad031Ho5Ks8WvSIxbY08okbiA IpzRpI4lix80FPnBkLOYf+7sSpn/MDH+zalT3po65b34nxQITMWc30ZfYVl1y0CwbXtKchZL/X7q FIg3Iz3A/0DTz59B0cYRcrtjN0ttoW1bads2Jvy4j6WyWHsUxYYgReuqqc6gEjNp25ZIJxDZHF0s ML0Fn2DKxgsrZf1tbfU52ZXr1latW3s88ghxM9g2lk0McjaEQxr351QN9wBRSfSD1f6Ph3QkSkS/ N2CMnUTPOzJ2vverWi6PoT4n58TvCry7YBwJf/1UaipMNOHw+axIS01NG/NHIaATkAiqEbKHoT7x O6wQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEGQceR/YZOkvQ0KZW5kc3RyZWFtDQpl bmRvYmoNCjcxIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNDUv SGVpZ2h0IDExMS9Db2xvclNwYWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNv bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA0 Mz4+DQpzdHJlYW0NCnic7ZjPb9tkGMfzvn5tx3Ydp066OEnrusFNWrVp04yRdGtp2nRjaFCxw6rR TVAQYxUghCZ2A6mwyzR+iCvagSENjuzGAaElEztwYRogNKF1hAua4J8wdrqleZ24Nx4feD+HSH6k 6Pno+/7w+zoSYTAYDAaDwWAwGAwGg8FgMBgMBiOQ7UarTeOL7qr1uLxdA/ZpOB1am53q5l7V2Qz8 73/Bdldnp9Up969C0Ohu7TTQbvUaVa0B+qAm1bq13DYao4rOGILzwXW6dxOhCEJ0QA6HoYwQ4sbp 3s4yQmiZLl0icEKYl77yRYQRpofROS6ARYSwoJR9Ea3gFbpwJR4FiwhxgmpcpPv/SXwBmQmZhxMS 1bQvEOcS/fielYQVMgpbzj48LFmQCWF+4IC9dmcfoXeK5qAEuMyIrI/Ovh3s8+vhiXRMJGA7oztm Wrow/3Og0MW5saTCc3BCmFcSVul0kM/XixMZwFXvgrnofhFdOGglBwS4gDoRbfT3uX5k0tAAp3Tb iIgxI3/4u75C9ZKlywKojxeRrI/0n0WfVvMpVSQY0md3c0zlqx/1+jysF00deMAiu2/8QXPmVK/Q lep4SnXf9LA+j94f+Uqv0E+zI5Cb9J4QJpI+cqNX6K/8gQHgGf3IyD2EHOo3qW97AcH7tBfaD32X /bMi5J7YJUSO9vVxboUyYp7Qrf5CzmpIQh8E+DitkISaQULOShhCwQG5R/4QIkJcsI/jvAq/L/ov zmFHhHK0wc0/6Odr4O/WL2mBz973RQS8NyLfPfHG2bP36EoT9sDoX/JbJ06c80UEuvTRK3T368cW F+o3w4uoJ6Bn5kulyhm65uQQ3L3MN4M+OVK07anq92FFhPCHdOvabC6bsYq+I38TbKH5hS4/lc8k Emm78jE9reE+WJFCd+O/F6fNhKrq2el1Suh1sLsrJvLlvb7/XHjyiVRMktQh+9C7XT63VaiDo3eP Tj79+d3ffr+/s/PtN2sLk9m4JAiSlp1aeO3qjzsPHty/98vVM1ktCnS0bgvl5pZPvrT1xvmXX1gq jSYVgRBBGbJm3eL5t948t3G8OpGBFJJ1c2r+2MnTL66v1crjqZjbGhNRM+yDtedObWysP79Utg24 6zTmojEjV6ws1Vdr8zN2RpN4DiGOl+Npe6aytHp0ZaFcGE4oYJPavZHJenpsojg3V5y0DF3xPpEj zAlK3LAKxVK5NG0PD8UAv1O7w6PEh9Ijo+ZwOqHJu5/s3YwEKZYwhs1RM5vSVTc2wK2aCNJALD44 GI8pUa8xalc5XpRVzS1rqix6wwjkE/HGhwiiJElRUSCdIJA7s3kxGvXKPIHL57ESRwjhOIy7gnCV OK/uKwMpuVLeT0A5jJsZg8FgMBgMBuN/xb8wDcTdDQplbmRzdHJlYW0NCmVuZG9iag0KNzIgMCBv YmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDE0NC9IZWlnaHQgMTExL0Nv bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9T TWFzayA3MyAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMzY1Pj4NCnN0cmVhbQ0KeJzt nPtTVNcdwPMnNEVg977fr32BNs2MaaqZGtum02lNVIzVTvpLaqz1TRxooo2Kj/hGq4A8lKcCLqKw CwiKEQXFuLug+IwB0YjRaZJO/oB+d3e4XIkiMy7LjH4/c2bnDnv2jPd8/ZzzPeee3VdeQRAEQRAE QRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAEQV5YWJrOTE/319RcuXhx WMnNzoa3RtMIVIPKP20E/vjm5MljfQsvD9CZ0Ks/PngwQoEKIzcCYXrOFpBR8syujhao9rQWwKDR tICWxQSzP3u3bP4+I/2HcPn4f2ZpPvHMDjcrfN8V+m7H1mGN/NDVFX03Jzs7zrf24gEzl9nbZxYv 6vYY9ya570YKXHwzyf3wD9NHVizHIte1+XP7J7n6LS1cchv3GhswXjHEHA9v+n2VipAjsAG38e1r noeveb5KdfZNdN3/YN7TFLOG++bnm4Ie47RDHfiFp2+Sq82pfeFQT731axwPYwt0o9ml3pkz6jX5 U8qeL7LQ519PdF1NcQy8M90c04alDVa5rsx7/5RDadDlc06tTpMg9G1O9caBIrPCeN3gC4bVkYFg sFzm9/LMRpasVkUY026kOnsnugaepNgwuUIeo9lQWh2KX5dLZP6UQz33/myzwigXBchosCpW9d6f a1XpE8q+k6OvpDiiisFE9t2JpmGKWdPCdpfW6lAbdbnFUKoUoUmXYWDsH5y5UK7YAqaYsxgoVizx XlXMYshiiYOc4Waq83aqa+Bv883On5eWZg3xrYhcLWG5VJ8mwcdBtLY5s6z1x/sWXzSs/e9btLBa ETNJ2/aIYr1PUsxnWbV1ROUyZAgTTFswHp40lDuDcvXgSnlsMBW7HwwWihx0+3qGOBBRDGaxW6nO BxbFhtKM5UtNuWo1Cep3uvQrmzdiWjjWWPOHYGFBhSKsIm3bOKrTrYNi11Ic9yyKWeU6HZHrhKEc UgQIHFzcafA/c1cEeX4sigVyBbZWFT+jiQKR65/oup7iuJHivPf7t63Burx8CSzWalQRMnmY8sok vt2pdW/agHLFB6tit/y+gxK3naM2sxRkEbdTnT0ex52JrkelxdEKj0IhWGqdMsIJvF+TSiUeFl9Q 02wBNzTigJmlfxMMFE9+vUrmV1P2PIHpS3VeSzGueoy7v5sWrdC9fMkll+ZVhGZdhhweMo0vDMW6 QEa54sBjq2C/75DMb2bIDQxRKfO3Uhxdbh1Ee1ha/CgUbHOooFW9Jh1XxYMi1wxT2NRfmZ/NwAVy vPhLWtrQ8vldWD6Hc/t9PHM7xXnFbVx2G32/nda1bEmnU6uWBb8mV0g8zFwtunLtQCHKFX+sil33 +cCd9TSxliLKJf66xwi69BsexzmHWqeKYBaMhwUCC6K1ps0c2n1auXK8b+Llwrp8rpjxpypZWEUk 7+boCw6t220EXDrEq1IW6lWpRORqFdGvSn2DOTzuPsUfUKxn8JAA5Pb7BWYrQ62h7MUi1+MxAk4N 5IJxErKRXJ45porNs9/D3afxxapYw6KFMEllErZtLHlUEQ6ILAyDDZpUIXFw0ahJvSjXeJOZnj60 /T5nVquuHJb4Y5FU8DPKvoOlYBjscumQdfS4jUdNjbhbOL74vd5oCPob/Kd0uVrmwSzI6nN4ulzi VtqTdrJUj1v/0qlCuTH9raHtYq93vP/tLx3WB8cgV5MmHZa5GkUoElgI2RElvCj7hLQViWzIpXU4 1W63fr/koKkYTH/jfQcvF2awQhuzWnQJ5PIqPMxWeziqOpxj0MUiu8yWuI0hLziUTqfa4VCuvj3V /JQfFYsjjz04njOzThEOSRyEKZ9n4MIr86HCfAjcBprIJJILBCbgVNsdCrzeWrEU18txxpoWdoFc mlgVjhFXJrLZLNmoil9uWA9veT/6e6FAL7ElrqNsrZp0wVDOGXLPtClDsxg+SYkL1uO+YNYRmasQ 2cMSl8tRpSJbKbG3/b7wbnAgsJMl9/P0KntSHk9fdChnDbnTofTMTUPF4oZVro7Fi06oQiWMhBJ3 QGB2MGS9InRmrTcrVC/4EIL4z+QJ/yZtoGG7IZ/Wpe7fTPlvKPTjkw6/ITHHlOvbYPC4zEOkykQG /NrLkodEtlxkvorIFS33AoGtNLGPpdJtiTsY4nwkXud06fLc2ahYHHhsgbz4H42qUMDTlSKbz9MQ l1qZP5+1bthhgMoFH/6HJRcmJXxKJDepQpsutagiBG5g8LANKjZ2mEeeev2+YzJfLrClAgNlN0OW CWyJwAwLVlSxzZS9iKdXQG5PEx263KqJULotJ0VxO3EssMp1cta7MBgWcDSMgXkc9Tll90pcx/p1 1hCY1+fz92cz5ILEhH/Zk47K3BlNalaFdl1CxcYUs/9BrlpIMDi6hGcO8vQumijm6SJu6IlYRuTZ lrlGA8WySNt+llqaPAEiexbipQgtkJlMfdP8SC4e5Igp1gXyyZnvHhG5Ao4qExjIJbbTRJXIdhfk D0shrM802/fnQbVlyYkZ9iQw8bQqNilCmyb1DZ7lQMViiLXnO7PWHZU4sAmcKuToHTQB1xA7s4L1 awu5u3ZF/3g3EFhL2Pax5OKkCZso+xlVPKEIUC5YjnPgQcRYYd3abZk54yBH57NUCU/vYcgtlL1C YEI/kSuKNdBX6+tgMMy0JX1sS4T4nlRFv8y3qmKvRTHcBI4JVrlqRLaIpfJYcgNp20rZS3k6lyWf KFcUM9ag2Bp78h6aWJSYsNqetI8hG2XeJ3HtU95AxWKINS0sh+gwZIYt8YOEV6FkEbYyng4+Ra4o VsV66uuyaWJF8oT5P//ZXxNe/SgxYSNpg8Tj68FDUziLPT/mhsbZdWv30sQW0raNCpcchthNE4W/ nDSCXFHMw2/9gUt5f3xnJ2WHRrZG2oFX+A9Q/8brZiM4JD4n5i9vQG+fzss9umZ17ZrVxyKvUO4G Lpld/bQWrIpBI625wxvpqjuO21OxwrrBO0IZeY/CunweoeBDzOcn/M3KwXMaTyvP/OoxNPLMn0zp uXgR5YoV5u9HhYvXGy0Qgoz09NHPOOGo7doV/gmpwRbCpaYmZ9S/QIUgCIIgCIIgCIIgCIIgCIIg CIIgCIIgCIIgCIIgCIIgCIK8ePwfacuQwQ0KZW5kc3RyZWFtDQplbmRvYmoNCjczIDAgb2JqDQo8 PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCAxNDQvSGVpZ2h0IDExMS9Db2xvclNw YWNlL0RldmljZUdyYXkvTWF0dGVbIDAgMCAwXSAvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9s YXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTA0OD4+DQpzdHJlYW0NCnic7ZnN axtHFMA1s9/Srr5Xsi2vZVvrD1mRhRXHUnCMZUtxTIOhMW0aEQglySEfJCFpaK7OoSWk9FxoD05I Kfm4FQrFlNqmKTTJwSFQSnGDfEgO+Ss2s3Ica1YrUyg8HTq/277L+/H2zey8WY+HwWAwGAwGg8Fg MBgMBoPBYDAY/0N6l1ZrdZaXGsNLy9vh5RKsTqlmvae2G151jQLQkNiyVneiy43REqSPZbmlpoJ3 4GxQH+2zhurRO7QPgvPBa7TQDGqWLGMoIYT5Cp27hhFylMcSOQQjhBAnDtO5rVmE++nIl4oAVCDi I2kf0tm3MHeXjkR8IpQP5uXAxBM6/eky/Xw9rkkclI+gBBOfOgq0Tj2+Hur0w/mQ+nTt27D24MJQ B5wP6R9/R/rjPXQ2imZMheofUiBRjaYKz1v7XM0nI14Bw+h4PJhXgt2j1ZY6K1MjpH14sA2abEC+ 2EDh51Y+V/L9UZ8A1D6eekcroZ7ciRY69ybTiYDMg30v6gXS4oOF2+4+l8f6omC74TZkyYeN7HFX ne+LgJvPO8gS02Lmgc/dfMrZnrAX6uO1g73EEpnjb5p1viqacN+K95AOUvXUxPVmn5lRIwReHiJk Fyj7bZPOm8JgDL4825u0bj5trs8zI6hArvUdyBILPnBp51f7VRG+PNsd5Lref2tD93jqx6B7rj7W 4Xa8LuJTdtex1tvks9bCx5pti89sKx1yum+DT+vy2AUC10E3W+tYW+ALHuH1PXys00Cz6a6PozyP 6McacAchTOf/6eIfdOAurBB2TMdfnLzWzg5CjsuDhwsfLPxKh9YgC4Qddys3pienTzk6KAV5nKdz 3y/lc/mplXYVCGHH4vpsfCg1OOYYf2pgHYQ4emv+oThsdHY3jT8m0CZNpsEtKnF5tFcP60bWccNQ AbuPEuYa835dGOgIqIGYOX6rMfxYBhrgycFw5HFDM5OBIuyTvSEjs/jLbvjVgpeHeWH29WG89N2L vzY3/3ny45Uj46auSoKk6v35yoXfn758ufn3nyvfkJEZ6MKl7mNOzH9y5vz5s9WjxXQioPC8IAe7 hkjw7MVL504dm8n1Qvqoem9u+uhH1ROL84f2JaM+kcOc4IsY6YNzi9WT1WNzB0eMMNSFFOlnb6hz ID85UylPHcgkdU0iB2bMS2rUSO8/NHu4Ml3I9sX9Mtx9pqRGEmYmN5bLDPTofkXgELJvObVIdyqT y4+NDvd1hLxgUxjiBFkNxRM9SSMRD2tyfdyqC/mCepeRTBqdesAnwU0ZREj0aoFQKBjQvBL/7kcF ERIV1R8kYb+qiIBDD8KkfSVZURRZEji8kxiRqCjbYUnkOQx4ZLXbheN4nueotLanSxhKCdl/mdC/ CjMYDAaDwWAwGP+Nt3Itux0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo3NCAwIG9iag0KPDwvVHlwZS9Q YWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFIvRjYg NTEgMCBSL0YzIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJ XSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA3NSAwIFIvR3JvdXA8PC9UeXBl L0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRz IDEzPj4NCmVuZG9iag0KNzUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODkx Pj4NCnN0cmVhbQ0KeJydVttu4zYQfTfgf+AjmdQMhxdRAgwX8WXbXTRtunaxBRZ9cB05MZpIqeUU zd93Ro4D0ZJldR8skSbPzJyZM6TY1S0bDq9uJh+nTI1GbDydsL/7PcWUVEqB1sozrxVzVrFt2u99 uWBZvwfs/n2PUhEoG2xaX/R7v/Z7bHYzYaziAN4cjBf93tUHYNZKFVm2WJNFNMeAaQMSF1wsXcIW T+SldPVDv/eVf3lYCsd3TFi+KdhcDDSffLz5XvzBFp/6vRlaJcsHUzZOqoa+clbZWItNB7Fppr1U OozNGqmZSZRMYG9xqFTsR6F34tWA9eoIy+cYujD8jcySFQIivhPg+DK7W24FeH7HRMJ3SBqAWEf8 LqXhepOlBRPHfqPGmMFID6HnYkWZe0ifljUbjbHbxFMSAxvH7g97nTK1vcinY7TOKenjEP28zTEr Mc9XAhTPH7vFHFmQOmqPeQ9tKFNkZXIQzVpo4Pm2LNNdmlFBNrtXKsbTMlve4zt92v8tT6TEICkN odVWKZqaFBtkaPS7sE/LsIFbBcfnqwYRHLaDiyTYENAatj0O+6gDEnKP8sAT5RD2GJrCDnGgoNRE BcknOfaH5Sn1x370jC/N0yIlaWeklB09lmW98qyg+uVr9rLfUGKw6VCY99iD5TR/eRaeFyd1rSW4 MIrWbLgO2dDeSu2+JRtVJJ/9Kwbxnm+aFZs/H9MTJDSCXYht5RB14WCdtN/GoYLkn+a//Hz1+81P F6dCh1KNAaY1dt+hiTQdjv7/N1EVx2+3QmuOZ1RCR1RcP6HeaUcaj6kQ3EohrqW/fq1QCSDGgupz Jahh38pQRfPPM+yBOfbKAtWk+XeM7psfF2IAhi9uBRhF/w0M7kn4a7Z6KNsuz7CJ8hd8nGofY7F9 fOirlXvSQXrgUAxneTdyriD55DMR+m3K6Ja5ZPOUpnQBG756uKAJnfaXbLopyvpihv4pD5utGHj+ yi7pRKEt45fHv07p1zq8j3zouDUBoDoIGDRqybYJ2DQK+AinrAIfKYBrHJtRNMSpw99UQTwZgcE5 zMolS0M1AjXcL/vpaEDL0QdaVpDgGuA8uVYwRhM6HiVDeinjkvPdZZSVsQvCO5Ml6PjZloA0+lyi mr/aQmiEuXLX7wlBdsbh0M1K4sa9JWICJfFDCh3l7brbp6KGskkqbus5+A+vZF/XDQplbmRzdHJl YW0NCmVuZG9iag0KNzYgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2Vz PDwvRm9udDw8L0YxIDUgMCBSL0YzIDE0IDAgUi9GNyA3OCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVu dHMgNzcgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+ Pi9UYWJzL1MvU3RydWN0UGFyZW50cyAxND4+DQplbmRvYmoNCjc3IDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDEwOTM+Pg0Kc3RyZWFtDQp4nJ1X32/bNhB+N+D/gciTXCwMj6Qo 0ggMJE63tli7DPOwh6APjqskzmLHs5Oi27D/fXeSlYpyj/YWQLQC333H++6nxcmlOD09eT9+eyHU aCTOL8bij35PCSWVUqC1KkShlcitEuuy3/vtlVj2eyBuX2SUcqBsJHTzqt/7ud8Tr9+PhWgZgK2B 80m/d/I9CBNk8FZMbggR4QQIUAhqhPVGBhCTBZmpbP3Q711lZ0tRDsBlXwbgs+li9VCKzaqcDo5N 9vsAVLYRA5sB/g2OdQYKFH0qJQYfxeRdv/ca7da2TWXbRaZ1cNJpYU3emL46VTCGUcCP4kKBH4/A 4DucKQhKmTyMurjwDVyrjbQ+ws3aN9qhSUc0FQJ8hOdAamGclXmDdvnTL4Mimwg8Tj4Dnb/iscGn XNPZ9f/FY61lHkO9IaDJJWEQkMQHGG2jvLQd9aRfpuVX7IzVX6l580hXfmKMYqpJ01YQx0qCFpPZ VTbk/ASdy8JHWqrSKL+gqekCjxU+DyW5O3vEY8ExZo30Ib5w0mfL+qxBmgbibDajYK1Sjm99aKvx DttCahcLT1eNm3MyNn3CY/64pEhzzhZO6hCj3G8TCxWZrIAgwcRKSYZyjiEdgiwaiHF106cSjyVL kXEy97HecZqhSHby55ahckilVBP2MKecmFaR2UeYsUoWJgatCOPZwj7nQqyRZMuxbBVeqtDk0zNd 9o4yeT3/6yXaqbhpBVJ1YIbUO86JkOm6aiapXhIK6fJY/8561FCf8LjfBDzNHR70r2dQrMYeXMQo ST4Klo/cSRv+R/a09fZlT1v2xwodn9sn8rJKISklR5fLSTVCSDrqWUeNpZZUQ/zNmCs6cklTgTUF hhrCFoLLBK+l1zYWPmJkg5G56shuqD3dldSVpxsuAM7LYscGsX6FJ2etnneR0jOVyJISvTJLJbIY UoObURDLBRX+hr6mbx/XFONhNRgVl8EBmTK7N/v4HaOQ43pgQofbVHhA7ewHWLl2d0cAvIpzL1NS gbXV1NsXubZePSf3hK+lUM1Uj6W2HoRsOcXXB3T+7ad014kA6jiiJhtGa9GZWOn6HhXKJR7V2pOa TjrvMgOmJuaIixE1dgffICYdKDhgkYMCI+MOrKlIeF9Q2rLP9TL4oVl3Sq6uiiBt51JHQzYQALKI ha/vK/qTQdDeyRDptZY4Pgb1utnWOiQGmmtmYBHvYOLbwvuIb8suqYEsWLrrmdNB3w4Prpc3MYru n+SAXbwBx63/yoFIzPd68Y4UOB4ALP6ui2VvqrSbUzOgLetDMgvrPt2xRaywiVhP00jjXTOPN3w3 0PhjresUm385SAsdypK0s7s/qJzWh/9Ae1thH+1t2dv557oSkfKq9lnK61KO7FTr3xHtf9X6d129 TBPztWmTkXtJitjln/Zie2BxtmX/SddmBJu8GbtoOy3VPmtFLLZj6V84nXi4DQplbmRzdHJlYW0N CmVuZG9iag0KNzggMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjcv QmFzZUZvbnQvQUJDREVFK0NvdXJpZXIjMjBOZXcvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Zv bnREZXNjcmlwdG9yIDc5IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTI1L1dpZHRocyAxMzY4 IDAgUj4+DQplbmRvYmoNCjc5IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1l L0FCQ0RFRStDb3VyaWVyIzIwTmV3L0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDgzMy9E ZXNjZW50IC0xODgvQ2FwSGVpZ2h0IDYxMy9BdmdXaWR0aCA2MDAvTWF4V2lkdGggNzQ0L0ZvbnRX ZWlnaHQgNDAwL1hIZWlnaHQgMjUwL1N0ZW1WIDYwL0ZvbnRCQm94WyAtMTIyIC0xODggNjIzIDYx M10gL0ZvbnRGaWxlMiAxMzY5IDAgUj4+DQplbmRvYmoNCjgwIDAgb2JqDQo8PC9UeXBlL1BhZ2Uv UGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA5IDAgUi9GOCA4MiAw IFIvRjkgODQgMCBSL0YzIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMv SW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA4MSAwIFIvR3JvdXA8 PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQ YXJlbnRzIDE1Pj4NCmVuZG9iag0KODEgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggMTA0Nj4+DQpzdHJlYW0NCnicnVfbbuM4DH0PkH/gozzYqKIuthQUAaZpOtvBFtlLgDxM9yHj OK2B1unmMov+/VJyL3ZiZ7x9siOTh+QhdaTA2e9wfn52M76+BDEawcXlGP7p9wQILoRAKUUCiRRg tIBN1u/NP0HR7yHcvdkIEaPQNaPVp37vj34PJjdjgEoAfAlwMev3zq4QtOYi1jBbeUSCAwSpBE80 aGO5cTB79GFCrC/93jf2a76NULBdhMjWm2gQs2eIYvZbtt2uo4FiRfQ3zL72exMK4IO8omrruIqr qN8YVGyPMpW1TCVQVkLWM9WK07q1PDEl4rkQNhnVEzi7sk2+iTjwZV/3D8+RYSAFiugQA5sw0Bqu D1CGMI40WxdplhPYj8iybEkLsAisAa2NH7zBfgmerutlRr+KyLFdviMmLftr//iY71pYjJXhztYj nmRRHbHYwKCRHRhsYK/ix26owDALlhGB2EhgnTwnualjDGG6IiZWeaRYmi8ePFHP8D27iySyRUEc upLC6+s50DeULTQZFNxhHfwkTboLTRh/jKaKH5umVEBSUkTthyOe3BFPNuHJQXCV6J8Hl0IeOB6F ezd1YZCrtq8NpVSjgWSHVDd0VCnk7iDiEFRbUBVbHru6eV54XQnikm0idGz91KYnJuFoupWnY8Xd QaSMRCvszjLi1g/uv/nuHtxxTxo3f+itpOY49QL5AqfZkoQRLdv6Ub2lEsIieH2UbB/KSjNYFEs/ w08vZW5y+uGTCsUvNt72+TZqG3DlOGI9/MkBNx0GXBp8Q/s/A171Y5dZGg2oWi93HYXAaq50HWUI f0aYsMwrQLbYkoT6vRIz5CLI5vYpS/MVfcxT0oQF7ahdvi78ztoXpKiGbcBnMfVZzK/axJTOIleP 2zZBZZ1ScXy1vGVT6quPOI8U9f17yHBg2FU4GSmNoFaUVWsTFY2lUXXYk02MOx6JXjLwYydixZUU YOMlIL1/bWazBhwBSUy4sRUoGPhrSqypyNT3tk2FlOQ6rvqJ4HCxbuugTCzXppZ0Kzid1ZjUTMPY hONkMrvy02VVm4AI5ZWjLc5Ro5IOuw1p7n7apIYGvbvRjaXIfN6trTk4cA21qgYwhHmEkn2B9H6x 2flXr7rGX1laRtaKQHgF4yQRtgsRaD5ExLtbeXXT4erWhYjy2lYFGIIvaOtF9ykLt4+V1+OUJqQq LkSOOhCloDeK9GZK2/2E1ASNq4Y8yZvruNMTx4X92E6vuLLPeyrpbr8NR6HfEeqXZi5V436n4iTW c1Emob8lSgg5pkNgItCOR6jPwzutjwy9jnFk6ytClobqbZmAXHiitALNZTDzJgk9nRgh+ufnMhbd ijAmHmQZGxNTxsbJKC7NCIGWY3qKI6oatSw2QcuqZB017j8kx8r+DQplbmRzdHJlYW0NCmVuZG9i ag0KODIgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjgvQmFzZUZv bnQvQUJDREVFK0NhbGlicmksQm9sZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9udERlc2Ny aXB0b3IgODMgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAxMjEvV2lkdGhzIDEzNzAgMCBSPj4N CmVuZG9iag0KODMgMCBvYmoNCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVF K0NhbGlicmksQm9sZC9GbGFncyAzMi9JdGFsaWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAt MjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGggNTE4L01heFdpZHRoIDE3MzIvRm9udFdlaWdodCA3 MDAvWEhlaWdodCAyNTAvU3RlbVYgNTEvRm9udEJCb3hbIC00OTMgLTI1MCAxMjM5IDc1MF0gL0Zv bnRGaWxlMiAxMzcxIDAgUj4+DQplbmRvYmoNCjg0IDAgb2JqDQo8PC9UeXBlL0ZvbnQvU3VidHlw ZS9UeXBlMC9CYXNlRm9udC9BQkNERUUrQ2FsaWJyaSxCb2xkL0VuY29kaW5nL0lkZW50aXR5LUgv RGVzY2VuZGFudEZvbnRzIDg1IDAgUi9Ub1VuaWNvZGUgMTM3MiAwIFI+Pg0KZW5kb2JqDQo4NSAw IG9iag0KWyA4NiAwIFJdIA0KZW5kb2JqDQo4NiAwIG9iag0KPDwvQmFzZUZvbnQvQUJDREVFK0Nh bGlicmksQm9sZC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9UeXBlL0ZvbnQvQ0lEVG9HSURNYXAvSWRl bnRpdHkvRFcgMTAwMC9DSURTeXN0ZW1JbmZvIDg3IDAgUi9Gb250RGVzY3JpcHRvciA4OCAwIFIv VyAxMzc0IDAgUj4+DQplbmRvYmoNCjg3IDAgb2JqDQo8PC9PcmRlcmluZyhJZGVudGl0eSkgL1Jl Z2lzdHJ5KEFkb2JlKSAvU3VwcGxlbWVudCAwPj4NCmVuZG9iag0KODggMCBvYmoNCjw8L1R5cGUv Rm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUJDREVFK0NhbGlicmksQm9sZC9GbGFncyAzMi9JdGFs aWNBbmdsZSAwL0FzY2VudCA3NTAvRGVzY2VudCAtMjUwL0NhcEhlaWdodCA3NTAvQXZnV2lkdGgg NTE4L01heFdpZHRoIDE3MzIvRm9udFdlaWdodCA3MDAvWEhlaWdodCAyNTAvU3RlbVYgNTEvRm9u dEJCb3hbIC00OTMgLTI1MCAxMjM5IDc1MF0gL0ZvbnRGaWxlMiAxMzczIDAgUj4+DQplbmRvYmoN Cjg5IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9G MSA1IDAgUi9GMiA5IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJ XSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyA5MCAwIFIvR3JvdXA8PC9UeXBl L0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRz IDE2Pj4NCmVuZG9iag0KOTAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzk4 Pj4NCnN0cmVhbQ0KeJydk19LwzAUxd8L/Q738UYwu0mTNoEx0FVFcTBZwYfhw9xqLWjVOgW/van/ aLe2jr2V9J5zzy+nhcEUhsPBZHweA41GcByP4cX3CIgTkZCSIogkgVYEZep71wdQ+J6A7G+GKBSk GkN3B7535XtwMhkD1BaInwXHie8NTgUoxSlUkNxVjs4OBEhNXBhQ2nBtIXms1nztOvO9OcZp+swO A0xLYAbj/J0JgSm7geTC906ca+X8a6VCy62sW80RarNb8WQjnoRAbsVTAXfnhnigvx2HRCYaNQNU aC3aiDa0OFvep4+LjvgiklxuCHrjBy3x29IHisvo//Rt4WtSnJZMhPi0ZkLi05K5x4dOElt12lD3 kqgdi5DGcLEDSlsRdS3O0uVbma+Zxo9OBsWtaap6GfRubUjlzu1ebdSlOHMFHE1YgJewKFbADiVe xlVBR1O4zYuVe5MX2WsHXWAlF6Lp2EsX7kYnrK5ubR+6uhQTFllcuA9OY8Yi98crXOcOqci66jK2 UjdMtoA+ATmn/sgNCmVuZHN0cmVhbQ0KZW5kb2JqDQo5MSAwIG9iag0KPDwvVHlwZS9QYWdlL1Bh cmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFIvRjMgMTQgMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L0Fubm90c1sgOTMg MCBSIDk0IDAgUiA5NSAwIFIgOTYgMCBSIDk3IDAgUiA5OCAwIFIgOTkgMCBSIDEwMCAwIFIgMTAx IDAgUl0gL01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDkyIDAgUi9Hcm91cDw8L1R5 cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVu dHMgMTc+Pg0KZW5kb2JqDQo5MiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4 MjU+Pg0Kc3RyZWFtDQp4nJ1W224aSRB9R+If6rHbEk3fLyvLD74kSrTOZc1qIzl5ILghSMB4Gawk f5/qAZNpmCGTPDFqqurUqTrV1TB8B+fnw9urV9fALy7g8voK/u/3OHDGORdScgdOcjCawzr2e/+d warfEzDb23BuBdeZ0fSs33vf78HN7RVADUDsAC5H/d7whQCtGbcaRtMUEcOBAOkDC6CNZybAaJlQ KqiX/d49uZt8iXQgyXJMP8Hodb93g4FSsGdvrTiTde97AjXTo4RklpAEJY8S0gojKs+ZMtuI55x7 d5HjJzINvo4f+JKrYk2FIhFoIMviIS6oJiVMqdSkWMO/ZVwD9WS8egA6UOQlGntSPD220cViWZcj nOSrGvg20VWaSfdruk1sa67k9d3bN/BM5sPt32ewZf+IP5LEMq6wDJt0NKaObOZUkWJVtpK1TIkc 4CRZ3bG50nsmOrBtam7dl9x8S+Ks+ESkocj88xz7u0i8Nt9baElpmcvjnGRlDlhJx4LNEwspMW2Z D3tSl6KB1LGr4II5nzlXrAyyCkgKO2lJpMKRb/OSCjyer5DhDBssOMGuauxq8bROf01iuT3+SNo6 yhVzpo4Gg3SlaO5hNLkncXZizL3LHHnlAfSQpWpgqZVjQhyUSDndqUTaCMZVXqJD2J+2jpkcCItI sSZVOdc4B5rMy4j6gFTkJ5x//P5IW+JZ5Zny7dhHYrEdxcItM+5PxVJzJtcxsZtWqoiwitSQr5Cm 4ne1oSxOXKgH76gNhXeiFJnj72hDBcO0O6hIZ23wwFTIK9KqDWEq8ddtsTaBFIvYKgBtcbOZdoAj AbhfCqC6AoW1TMrmK3AX8+5xvNqH9QeLvEFXPA+7PV3Pnr/+qRb6l+0s4IW5efwLJTMcbnD9FcWi ZPOYVsKUWkNYUe2LGW4RNNn6LBdDOtDkYZ1W53i6aSuY5KlgdX5k0GobmAi5bTmZL1v3EWcudAyN osTdldlOkN/uNdDiZVRI91QnBKNdGsaD5NNzSbU/l6wyjMtuABaFYm3dthpIkXSI08X5KRmGnV5+ qmCnD8E0WLxHLKbO/P7xePxy5DXF7VNyggWfq+z5sdgw9FXQH6wzOUMNCmVuZHN0cmVhbQ0KZW5k b2JqDQo5MyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDcwLjIgMTU4LjY2IDQyMC41NSAx OTIuODZdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDApID4+L1N0cnVjdFBh cmVudCAxOD4+DQplbmRvYmoNCjk0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDIwLjU1 IDE1OC42NiA0MjkuMTkgMTkyLjg2XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWNvcmUtc2NoZW1h LTAwKSA+Pi9TdHJ1Y3RQYXJlbnQgMTk+Pg0KZW5kb2JqDQo5NSAwIG9iag0KPDwvU3VidHlwZS9M aW5rL1JlY3RbIDQyOS4xOSAxNTguNjYgNDgwLjc5IDE5Mi44Nl0gL0JTPDwvVyAwPj4vRiA0L0E8 PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2NpbS1jb3JlLXNjaGVtYS0wMCkgPj4vU3RydWN0UGFyZW50IDIwPj4NCmVuZG9iag0KOTYgMCBv YmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA0ODAuNzkgMTU4LjY2IDQ4OS4zMSAxOTIuODZdIC9C Uzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDApID4+L1N0cnVjdFBhcmVudCAyMT4+ DQplbmRvYmoNCjk3IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDg5LjMxIDE1OC42NiA1 MzkuMTEgMTkyLjg2XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSSho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAwKSA+Pi9T dHJ1Y3RQYXJlbnQgMjI+Pg0KZW5kb2JqDQo5OCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3Rb IDUzOS4xMSAxNTguNjYgNTQ3Ljc4IDE5Mi44Nl0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0Fj dGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2NpbS1jb3Jl LXNjaGVtYS0wMCkgPj4vU3RydWN0UGFyZW50IDIzPj4NCmVuZG9iag0KOTkgMCBvYmoNCjw8L1N1 YnR5cGUvTGluay9SZWN0WyA1NDcuNzggMTU4LjY2IDYzNS4wMiAxOTIuODZdIC9CUzw8L1cgMD4+ L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDApID4+L1N0cnVjdFBhcmVudCAyND4+DQplbmRvYmoN CjEwMCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDYzNS4wMiAxNTguNjYgNjQzLjY2IDE5 Mi44Nl0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMCkgPj4vU3RydWN0UGFy ZW50IDI1Pj4NCmVuZG9iag0KMTAxIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNjQzLjY2 IDE1OC42NiA2NzEuOTggMTkyLjg2XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWNvcmUtc2NoZW1h LTAwKSA+Pi9TdHJ1Y3RQYXJlbnQgMjY+Pg0KZW5kb2JqDQoxMDIgMCBvYmoNCjw8L1R5cGUvUGFn ZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSPj4vWE9iamVjdDw8L0lt YWdlMTA0IDEwNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTAzIDAgUi9Hcm91cDw8L1R5cGUv R3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMg Mjc+Pg0KZW5kb2JqDQoxMDMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjEy Pj4NCnN0cmVhbQ0KeJxtkD0LwkAQRPuD+w9TRsHL7t3lcgGxMFFRCCgELIKFaLTxA/3/hYlEjWg/ M2/fIlxiOAzzdJ6BRiOMsxQ3KQikiIi1phixJkSWcK+kWPdxkYJxfGeIHJP9Ch36UqykwCRPgQ6A W8C4kCKcMqxV5CyKQ7NYz4FhiFUCG3kVJSjODeWJmklRBvl13xuYoDr1NigWUkzqnWbrVbbsFflu uwzQyf4cpD/Gg1aG2NhW3hvmP/LOG2X0E2lMjfXKxQmcw64GhvPz9lg1D8mueP3gAblvRmoNCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxMDQgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdl L1dpZHRoIDExNzIvSGVpZ2h0IDU2Ni9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9u ZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NTc2MT4+ DQpzdHJlYW0NCnic7N13XBTX3gbwBbGXa4tBrzXXmGgi1mu8xldzNV6jEk2MsURjibEramyxEAuK 0WDsmqjYOyrSbEgv0pFelyq9N5Hq+9s9MAy7y4oKOwLP9w8+ZObMmTOzm+E8zsw5L18CAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADA OycvLy8sLMzX19cTAOoLLy+vgICAqKiokpISoa8xAAAAAPDmxGLxyZMnf/rpp/79+6upqYkAoJ5q 0aLF6NGj161bd+PGjZycHKGvPQAAAABQLSUlJffv3580aZLQ3UkAEECrVq10dHRCQkKEvhQBAAAA gDKmpqa9e/eW6ct16tRJW1t7w4YNO3fu1NfX3wsA9cKePXt+++23lStXjhgxomnTpjL/40+aNEks Fgt9TQIAAAAAWRkZGfPmzeP33Kg7d/HixdjY2NLSUqFbBwC1q6ioyNfXd9euXV26dOEuAs2bNz95 8iSuAAAAAADvDhsbG36Hbe7cuZ6enkI3CgAEUFhYaGRkNGTIEO6CMHbs2KSkJKHbBQAAAAAvHz58 2KRJE9ZJ69mzp62trdAtAgCBFRcX79u3T0NDg10Z+vbti/gGAAAAICx+cFu4cCGGmAMAjr+/f//+ /RHfAAAAAARnb2/PBbeNGzfirRYAkJGenj548GB2lejXr19WVpbQLQIAAABocKgP1r17dwQ3AFCO H98WLVokdHMAAAAAGhzqg3EjkyC4AYASaWlpXbt2ZVeM+/fvC90cAAAAgAaEel+sG0b9sczMTKGb AwDvukePHrGLRpcuXTIyMqq5VYrXtZ+nTFl50PZFbbYNAAAAoL4qLS3V0tJi3TDqjwndHACoG5Yu XcquG3p6etXcxO+2ZJPGonk+NfOeXJaPi52Li4uDi2dqUY1UCAAAAPBOs7e3Zx2wadOmCd0WAKgz srOzW7VqRZeOzp07FxYWVmcTl1NjJXN8i9YH5tdAA0pyHUeVzzp3xAOjpgAAAED9N336dNb5oRAn dFsAoC5ZvXo1u3rcvHlTYYEU//M//PeL5TvupEr/M95mKxXWHGHInswWW5/5ecpo7hHKGMc/Rn86 ZnT//gctIquz99IC15nl2e0vZDcAAACo7+Lj49XV1anno6WlhSFKAOC1hISEsOg0atQohQX8ri1j Bdp9qB9Z9LI4wYh+n7zHg1Z5la9SF42VBq+sI2PKgljHf52ozmu3yG4AAADQoFy9epX1fI4fPy50 WwCg7hkzRpK41NTU8vLy5NdG2+iVpytRS9FvwSlPF4hE++1ivK79yC3vOuGyNKkhuwEAAAAo88sv v7Cej5+fn9BtAYC6Z/v27ewa4uzsrLBAYUak7a0Ts8aI5M379aiNRww35mSM62ltLcltOEO7mOrs uu5mt9KXMcdX69XIS38AAADQcIwcOZK6Pc2aNSsuLha6LQBQ95ibm7P0dPjwYeUlM8U2G8oS3ED9 S+5vP00AZbdJdTK7JR79UdRINLUuNRkAAACERnmtefPm1O2hBCd0WwCgTkpISGDpac6cOVWVSRJ7 XD+yUVuLf89toOSmm0/0aw7t/zw5LjI8PCoqKi4lu7hm77tlpyfHxUVSzXKhsigtLi5Kus9XtjaL 6pCIjE/OUVig9GWMwTeSBivNbpLDjJJWlJKOqfAAAABAIj09nXV7Fi5cKHRbAKCuat26NV1GxowZ I78qL956ZcXTkgMvWt2ltKVz+QHLLyLpQCWXbBNZYd8Lc2nJJyLR4jOBcjVlOV3V52YEkPea2S3r /JLe1B7acKdFZKrYbNU3fbmqKFUZ+5S9bxdifWYSby+NRfOMPVIV1ih2uDizUjgVtRu11MKnUmEu uHEnpL8U/aZTdsjP3W7tkTnMIdrbbMOq8/4fAAAA1GdxcXGsb7Bq1Sqh2wIAdZWmpiZdRoYPHy6/ 6tbSipxyN7CwJNOEotnsY+GlL8W6AyqyEpuq2/PUNLbkhz99+JWU5HhvUPS63Ntkt6PfvKLCGx7i h0fHKd6Xc5pMbbf1vqqqnk2XAlih0mLx7qqPQnrIiad+rLKA3E4BAACgYYmOjma9grVr1wrdFgCo q7p3706XkSFDhsivYnGsdd9ldpEFLyXDTkrmd+s64XKONMsc+LEP/ef7I06k8gqLKme30uKQ9ZVT zD+++GbR4tmjK9/ket3sduqbSpuri8Yu2bxZ4YAqZM7i2fx7YS1FvyXw6nL4Yyi/8ODJP/7Au4tH DjtT256frzqXiSTzJviW5DpOqroA7TT2TT4cAAAAqCe47PbLL78I3RYAqKt69OghqiK7kfzsbO41 MRfpnSwKa9wjgNnp6fnlqxVmN24haSpabhlY8RRigv/5T8pXvU12+0n/UXl7nj/8Yzw/MU3ceCdB OhpkaXHsacljlmXOPS2bEKE41YRrQ5uP1zlF5rLlmeJH3Lt47HgLs9NT0rODH25jCykt3gvLpMNP lsrJL+Je3/t+00X/uIyioqLnGQEs3jJXniqYhQEAAAAaCGQ3AHh7yrMbHwtiVQ3TIZ/dSku8uARE wc2n8lalL7zedKySiuymvd2uUp28sSt7Tr/LH5ykJNOKu/t2yLbsCUaX8ucq6aCeVH6q8UXEOfnY leN/mCvvU3mOgJJcR4qBhuVv/8nvtE6NpQkAAAA1DNkNAN5e9bOb74WpVFJzhKHCQRjls1tBgil3 V2vN9SiZ8m8xzmRFdpt93Edm1dGKVYFVbTWlrIUV84m3Ef0ZnZ6eHJfC7qPFxaWkpbgtKG/eOfey 7JbBz26yTc6KeyZ7YkoyKh6kPIf7bgAAAA0YspuKlUqVVIFWCd1AgDdR/ez28mURpZqMKuakls9u 6d5Hqrqr9bKGspvMuCivuUr2vbmqLD4TxqpQmt14h1aUFepleXDLTH4lyG4AAAANGbKbirGMViRV wFNYWEhLiouLWYJDiIO65XWymzLy2U150qlD2Y27hffK7Fb6IuL6/p8+UVQJnpkEAABoyJDdVIkS GaUzSmrPnz/Pzc3NksrMzKSf2dnZtISWv3jxgoU4xDeoQ2ovu/Hvu72b2Y17wHL0b87030UK5Ve8 Nsdlt8aiefJHVBD/kD/U5PId1z28rr3peCwAAABQryC7qQwX3CijpSeEWpqampmZmUrRL+bm5iYm 9xye+MSlZubl5bEEV1JSInSrAaql9rKbwuFBOO9CduNmZOv0+QHFk3ZXxmU3Yl/5gPizIQybZRCQ VvzyrcZjAQAAgHoF2U1lKLsVFhZSLktNTQ14sFVUtZ+2nfOPlSQ4Ko+7b1An1F52ozizovx/jXYf 6stMcKYwu5Xk+Bvu27T2Vz0LHyVZqqay28ugaxXTti2SHfaESTX/65DzswL2H9ydRGISWenfZ9K9 95evGcjFOmQ3AAAAYJDdVIONT/LixYvMzMxnz565mm1Rkt2k+p21j6T4hrtvUCfUXnYj4WZLuP8x 3hup7xQen5NfxJ5B5E9mXZ5rKgZ+lIajgip2VWPZTWZC7a90TvtHZhRJHp7MT4sLs7yqz+4bHuGi Ja/8z386v5AuTIt2P75m0VlTA/nsVpxqwlV+xL3wTU8tAAAA1HnIbqrBHph8/vx5amqqWCy2uck9 GCXS6DFi4qQxAwb2lAlvGqLvHWMzKe7h3Td499Vqdnv5MtFgjOiVWHYrfeG/fkDFws3GkVXsqsay 20tJuvylms17Kb2TuKDSmoH9tcp+M7i6m1v6vvY2G09fZ9Pj/GA4XuePDWNw9w0AAKCBQnZTDZbd cnNzk5KSgoKCHlxaw3XGfjlhZmlpaW1tbfnA4sKJzZ/y+mlf7bRmt96Q3eAdV8vZjfJO7Om1I6oT jkpfilfwFk6RDV+cijFG5APa668qsj76vdLWDbwXVnEHMLiKrHfI0Xe9whWVHXZGdgMAAGiIkN1U g8IXRbCcnJyEhAR/f3+LC6u5btjav8ydnZ1dXFwcHBweP35sfG4Tt6rDkN3RmZJbbzKPTSqcJE5h vlNYTEkSlClfWk6+GCupZKelcpTMasevp6qS8i2Rr7aqBkNtq7HsJp25W1TFi2OxXhbbF2srHDyf GAXmsmIxrqe5e1Vy4YuTdb78NbXVF8OqWrX4jOzc3FWvoubd2Tjn/2RaNXD0XIOzNgly89mFWB+b VLnk1IXHAtKKC1LcNnxTsbBlv7nX7V0ubBnOLZm26mIEohsAAECDhOymGlx2i4+P9/Pz42e3X89b +fj4UKDz9PS0t7d/+OjajJ5lqzpPOhCTlpafn19cXMzVw6aHKywspEyXX66goICbHk6mJK3iStIv bCI5mdjFCtPmXHmicNY5fkmuKm4tN3sdW8W2ZdhCDn9uO1aSbctvA3d0rDHc1AncvrjzwArzi+El QRWrqexWU7jxQ1Q/mXVRflpynERycnoOb2oAhWWTJcXoR0pO5XCXJVkYl5KezVsSFxVFS17USqMB AACgLkB2Uw0l2W3bVcfQ0NCIiIjAwEBXV9fHVte4f43vPPFQZHIyN2IJizYUTyinUFWZmZkxYUG0 VVCQT2hEAn9mAa7k8+fPs7OzMzMTIqUlg8OjqDdIC2kVCzgy1ebm5krLZ3KzzrFqKSJxhWkXtIQq oVVcbORWsXpoFRVga1kQY+VzylHNWVmJ4uDgEHF0Zm6uTElamxAVHugTGBAQQOcmMTWTltByagYX Bul3dh5iw4NIYODT4LBn1Gb+ecANOJV5x7JbKhu3//0RJzKFbgoAAABATUF2Uw0l2U33urNYLKYP Ijg42M3NzezMRm5Vh0F7wnjZjQILSytpaWkuJkcn9630wNU/hs83copks3tzqS01Ndb05No+lR/N +vrHXSYO4lzpKCj8EJQY4XbaYP24EVzxfp+P//F3Q4uolIxcabxi98uoPRS7Ts3vJRJJHl5bccaX ZSWuHsczC2n5xyLRsB+vpuXmsjzoeOonWviRSDT0h1PPEhOfWvzxWflumn006a+HfizTUWYMsD// 01e9KzdZ9P2i7WaOwVQVd3RU2NPixDeVT0Kb4XOv2gZTJWyGBdx9U5l3KrsF355DjWn7kW4Ani0E AACAegTZTTWUZLct1xwDAwNDQkJ8vNxundflj1Uyc8/j1NRUdr+JNqdkRKkkMTHsr3VfiKqw5q8n FJRYCEpMfGa4orPCYmqiUQ4JeexpQ4o5GRkppieXVVWnumjiGcuyQETpKSMjg9qwc3zZ2u/07Fmk oubRrlNSUh7sL3vl572hf0amSSQlJd3b9zlb2HniYQujbfJ70TntkZQUdWXb11U1o12PvZHp6Szi ZWTGGG76b1UlVxyxpZ0ivqkSy270s3Pnzpqamu+//36nTp06duzYoUOH9u3bt2vXrm3btq1bt27V qlXLli1btGjRvHnzpk2bNmnSpHHjxlTG2Ni4BhsT43B6zwlb3HEDAACAegbZTTX42c3X19f8vA4X NDR6DRo9YdSoof+SCSCNRfNsgqMoKLEbXhSOsrKyEhISrm/uzy/WZ+T/vvy/HvwleyzEFKCoZKDD If7yDweN7lX+eyPRJKdnWZS5JHfx0qOOL+pWVQ7irD/rKs1haVRzZKTfji/Lln+7/TEX69LT02Nj Y413leW6jkP2hcdL0Nfs9s7/KalcTTTi8hOxzKHJ6PTFPnFiIjWA8qzxb1r8VZKTMLLSSdhlEkyN Ya8K4slJFWDZbfDgwV9/XWX6VkhLSys0NFTo5gMAAADUAeHh4awHhexWq2Sym9nZVco7tI1EU6/a +8XFxdEm7C0w+iU5OTnU/e8Pyss06zb98GXzx1JmV/7g5r/qMETPPyZGLBY73viVq3D14Vu2trbO zg5Wpue3LxgkEvWzikyjzEU5yOnCHP6u520yuHr7tomJyeVzBvP+x890H9/wiKEmRUVFBQa6bfmi bOnkrfcoKkrfX8tKSkoKCwu7um1sWUsG7QmIlAgODr68VdJA9fLWf/bdrjuWNpYWV7cskNyPm7bD xM/2IL8ZX/2857rFAyurRw/v3TltsJHS4D+67QiIjZUkQZ+z3COVzbrNOHTZjJ0Ek0u/lzdK1H7Q 9pCEBGoVnT28+KYC3DOTFJm7d++u/OvN+fnnnylfC912AAAAAFVj3WYvLy87Oztzc/OrV6/+/fff BgYG27dvX7t2LfWRZsyYMXHixJEjR2ppafXq1atjx45NmjThOlHIbrVKJruZGq5U3qc9a+NOnyaF NTauCP2kLnF0dPTlX//DCqiJRh65Y0Wsra0ptlhaWj64vIHb/ICpT2BgoNWlioT41dLDVvb2bm5u fn5+FOsCvHyfpaRQcIsNNZtYXkZNNOrPm1ZOTk4uUs7Ozo6Ojid+/YarpMePZ0LE4pCQkKdPnTaN Klv49WYz+u5RcKMkmJCQEBQUdHFzWY5sP3CXT5iEv7//2Y0Vjzj2m7ibYqS7u7unp6e3t7fxuXPW Xl6HF77PFZile4G+xtQAajB9pemMBfm7ODr7x0rd0v2cOwmHbj1is+Ox83DvYsXsWAfvBbAnTnHr TQX477u5urpqaGgo/4Y3b9784sWLQrcaAAAAQBjGxsadOnVS3l+St2xZ2VtOyG61Sia7mfCy24gf dLZs0vlh0mD+5/KPAWudIiJY9GA33SgfhYR4/jK0rEAT0eKrxsZ3b901NTWlj/7atZu3bh79qnzz 3Tc8aC/O1oaf8ev8fN65u3bBwcGUASlkUTBMTEz0fvAbV2DpAWOKbBSmAqSoBopXDg6Pt03uwgqo i8YauQZKl9uuK5/GSnvTXaqHgltGRkZcXBzFtHObvmCr2g/Y6R0i4ePjc3r96PL9fGBgbE+pjXYR LEVxz9f3CXcjr92wdRZ2dpTaaEe0Njw8PCIigtr87NkzOntRUf6by4+KTsJFI6NbN26ZSN26ZXzb 6Cj3aKa+0VNqGJ06vPWmAjJjlRw+fFjJZadt27ZWVlbCNhgAAABAWNTVnzFjhpIuk4x+/fqFhoay 35HdapWS+24rD9wwljp7ZC1/0MSec8/GSbMboWREyYUCznrZiX8Vm7bDws/Pj+LP5f1zZFZNWLzf XRxHSZCyG9VpYjCFLdcQzbjt4Pz06dOwsDB2eysyMjIwMJAq4d7OUxf996LtUy8vLxcXq19GllWo vcmYkiAFt/T0dGkjfQ03lsW0dgO2e0nTGeXBU+vKFrb5RMfa3Z1FSMp6tCOKZv5+d6dxjf/tOkVI 2jU1gE4XtTNFir7e1OyICF9d7vFQpb7fdY/qz8rKYo9NCv0VqOfkx5mcNm2akk9HQ0Nj2bJl9B0Q sM0AAAAAgjMyMurYseMre7bq6uru7u4Yq0Q1ZMcqOVfxNKPO0Tvsda179+7dPLWZ/4LZhnPe0iH2 c9PS0qKiory8HLjEpNzX28yCgoIoiDk6Ol49ukLm7SMN0fd3veMpcFGdJn/OYwtbdV7j4OFBWZ6W s/ndKC7R14MyoJPVyeHl2647Y0NfG2dnyzfObu2Hb3Lz84uJiaEsRsGKDo22CvQxnVP+Dtvmc5Y+ Pj7UNmoAnTGWXvPy8qRTHqRSdtta5QCTlWhvM0V2Uxn57EZn/l//kh2BR0ajRo0WL15MIV24hgMA AAAILDk5+bvvvlPea9q6detLjDOpKjJzBPDHmVx/5iGlIQ8PDycnJysrq6sH5nKr1ESfPwxPp1hE H2hERISHh92Ksje9RP1/OGhvb8/eCHN1daVt6T8dHBwkb7R5S95oo/5wSEgIhSZJtaanlmh/wv/0 NUTTHgbGUrGLm8piWct/rrJ6+pS2Yg9qsgH/KZRR8rK5WTHmif41excXF0fHh2vLW6I8u3lK5s2W pMgzG8oWtu2/1TskJDExkepne6HfQ/zvlo9bKZqhdycgIIBiF+VHNnMcmzyOvfQnjvDZ+EVZyU9m 7H/w4IGNjc2TJ0/oJFDD2HmgxOrhIsmheGZSZRTO70ZfP/5LtVVRV1dfuHAhfRuFajwAAACAgIqL i//+++9WrVpV1Vnq379/QUHBS2Q3VVEyv9vWy/aUj8LCwmg5BRAbm8e7Zr3Hre0+0zA2OZnCEfVs KbutHVe2vPUnS+45OXl6elJWog0pHFE/2cdHMkQJpTz2alhMTAzV7OXlxVLhzXO7J/C+A19uvUvh zvZaRYrcddMlKioqLS2NIhV7yU6SqkJCzq4ve8FMTTTqkpWLTHabtO025Szait2no5YYbikbx6Sd loLs1k5Ll7IlN28d/aRkGhbmzb3v1mHEZveqs5vkvlv56Cqt+i40evSIjo6NZ0LoDNC+6CftlI6F 9pKbm4vspgJVzc1NFyKZi4+BgQErLENNTW3+/PmYLwAAAAAaFEtLy08//VS+a8Rp1KgR9fNZYWQ3 1ZDJbvd42W37TVcKWewJRkpelIweWxz/gvd57bzlT1mMshsllPPbKmZJm7LhMoUUSmcUr9igH9Tv jYj0urB3h7l3NAWi6Kemf122pzo9KPXZ2dEX4+GjM1PKN28/aLtbUJCLxR9chS16/Pw4QJyUlMRm 96agRAHKyWRHRYGui++5urq5ufGfmXxv5J6w6GjaqjxgOup+r1ke0yqyW8XNOK3tgVFRVDnlsuLi YvpJCUssDtDn3Sj+ab8ZfTPZM5MsSNJPyVR0aWmRkZG39bW5khNXn37y5IlkIMqgoJByoWFuZ/f8 ZuoVmZGRQYmPzjyyW22rKruROXMqvXRJ3xNK04aGhr169RIpQuXp01T9IQAAAACoEvXetbW1FXaH +Hbs2MFtguymGkqy2647nuyZQ4oqFN8ohjg4OFzUm8QVaCJaZBseRbFIssryOH/oyBE/bDezcg8M DQ0M9HNztDx/cN0w6fI9D8MpTAVbbqPf+2uvOXPzsb2TE2U3c6OD3GiP7QfqeQUHU6o6uLji7Uh1 0ZcHLlmJnz2jzcUhHmf1KvW6V5544C3l6up6fNUQbrn+dUdquWRskyD7XfMr/t2gndZvCrLbANns xqY/cDP/nb+vkXN2Wrr5SQZVSYoLD3A3u7B7+lQ9z4QU2ouP6/kRvJLDp2++89DJPyiIToK702M6 Cf8uPwnIbiqjJLvl5uZ+/PHH3OdF/wuw5fS5XLhwoXfv3iJFZs2aFRAQoNqDAAAAAFCFtLQ0HR0d dXV1mf5P06ZNO3fuzF8ycOBA6jJxGyK7qQaX3SimUY/0waU13Ceid9c7OTmZVrG5rcPDwz09Pe3s zFZ+XvGp/XvxpRCxmEIQhaYr+tMV9nX5frcIlLx69mg7b9nQMWP/wy/zte5d2pdkJEmn69++skaR qMt3f7h6e1N5aj/Ft3sX1vPX/mfa4rUrZg+qvAllNy/pbUFKnfyJA4KioylVsexWWFhIB079eUpe /BQpr5Fo0sPwRPrG0nkw/vOHVzZ4/4MQSoXIbqqhJLsR+s40a9aMfS5xcXH8VfTpXL58uU+fPgo/ xOnTp9OXRyVHAAAAAFDrqOt76NChtm3bynd75s6dGxsbO3bsWG6JhoaGTEcI2U01WHbLzc1NTEyk 6GF5dS33oew28UnlzQVAPVuW0axN9vfnfZq/XnSjqOXj4+Ps7HBw1RdKU0vf87ZhkZGRHhbbqirR WDTvnl8YffpisdjPz8/F9tpCpbMPTFryp4OHR3BwMFVLm1CCc3V13r+wr7JtpLfYPEJD2dzcF34t Gx2y/cBd/jExdKRs+Ec6LXl5eSkpKVStt7fjvuXDqqpNTfT5/RDJnAJ0Hnx9vY+tVT7c5McX7SPS 0tKocrzvpgLKsxu5cOEC+2DoE5RfSyn+2rVrffsq/kZNnTr16dOntdl8AAAAgNpFccDU1PTDDz+U 7+qMHDnS3d2dFfv224qbKrt375apBNlNNejDot4p5QjpuBxhDnd2cB+KwYPgjIwMCjLccBwxMTGS POXicv33iltszUSrXSNiQkNDvb29nZ2db57Sm/klP9tJ9Bk8ccPu887+ksmspQnLy/jC73PGD5Ap NmnhLivPAProKUjGx8dTYUr0T544nvlj9X8/kP0uDZ249OS1+/R1orxGDWObUIKTzP3tbH3w17n8 USdaDJiyx/DWX7plD3xqfnXAPyKCjXh5Q7984YR9YdKh+1mkInTs7NYbZUMPD4+7F/bNkDu0xv8a 9tO6Y54RMVSMOv90Duk83D3/+6xxWjIlPxz01Zrtp+yfBlMx3HdTmVdmN7Jw4UIqQ9+iqgrQx3Tz 5s1PPvlEpMiUKVM8PT1roe0AAAAAtcvHx4d/Q43Ts2dPIyMjSgpcyblzy8acp24VxQeZepDdVINl t/z8fPZuF3sFjLD51LKzsynIUAFKMbm5uSkpkre6AgICvLy8qLNKv1C8osxCuenZs2fh4eFs3m1K cLZWFqZ3JMzNH9g6PKEKKSXRttQ9joqKot9piaurq531I5Pbt42NjY2M7ljbuVLsogqTkpIypKha 2sTf359yE9X58J7ZzZu3zU1uU+EH1nYUISklUaqiKJSampqZmUmbSOfIliQ+yfQE9jbmJuYWFhb3 HlnR5k5OTo6OjrQV7ZqaSg2Oi4uj+umQqdlsGEwKsNzwj+zWGyUsqpYKs3kNqJ7HDyxu3Lhx28Tk 7t27j23s6QtPeY2qYvN009ngzoO9zX0zY2M6CWZm9x7bSGZJYIWpDEVC9mQmslttq052o++/lpbW K+fjpg/r9u3bVFJhgtPW1qaPuEbbDgAAAFBbqKe9aNEi+S5Ny5Yt9+3bR70jmfIrVqyQ3LZo3Fjh i//IbirDbjDl5ORQ8KHTTtFDLBZTWmHP9bF7Q2zsDopyrAwFEMoyFHYos1BuonRDhdmIlBSmKLlQ zPGQol8ofFESZENWslEfqQbanIpRBmTFKE9ReqIkRd8iyjV5UvSLZFDK8sJcnbQVlaevDYtgtGsK XGyabPZqHktklODYsPxstgL2k/ZCR0fpiUUt2h3VT+XpJxuYhb6odLClUnTglOOoWjayJW1Ix0J1 cs2gOqltdGhUFe2azg+LnOw80Fpqs6cUbUXb0nljSZNLiPx/zYDaUJ3sRugrSt+c6lRIH5mJicmg QYPkr3VkwoQJT548qYmGAwAAANQK6u7u3buXMpp8T2bJkiVV9Yg2b95MBSjWKVyL7KYy7JU3Fs0o VtDnRYmJ0grlC/bmFwsy7O4bGw+fRTAqRr/TViw30S8swVGWoVgXLkW/0H9SVmK3xqgM/aSkQ1GI vdTGoiKFHRYDqQC1pFCK3exjdVLkoYTF1cnKUwOoNvbiGJtqjc3+RvXQHlkoI1Q4RooqoeVsqxwp ClxUmNrDmseq4ucpFt/oAKkkFaOoSLXJNJuWs+m8ae9Ukp0i7jyIpdh5oIW0igrQobGEKODn3kBU M7u9LvrszM3Nhw4dqjDBjRs3ztHRsWb3CAAAAPCWqANz/fr17t27K+y9KB+HTV9ff/jw4VU9M4bs pjLsBhOLbxQ9KC5RhKEkwp6WLC3H7r5R6GBlKICwu138qEVb0UKKORT92I0t+oUFJVaSytBPFvQy MjK43ES/swzIQg17ZJEN9ihfJ8Uffp3sziB/Exag2FOUtBX9zCpHy9nRFUixQ6Yl3IHIRCr+yVHY bHaXkJuqm0VIfptTpfjngTtGZDcVqKXsxtAneP/+/c8++0z+AkjGjBljZ2dXG/sFAAAAeF2urq4j RoyQ77H06dPH3Nz8lf3SM2fOhISEVLUW2U2VuGjGoge7jSUfLrggw5Iaod/5UYvVwGasZgNUsrtR rMLicvS7fG7iapO57cWvkz1Lya9TppH8Fr6QYoU53NHxG8MtqSpPcdXKNJtVzjWbH3JZAxSeB6Q2 VarV7MbQp/no0SOFF0MyevRoa2trfOIAAAAglJiYmNmzZ8v3Utq1a3fkyBHqoFanEuXFkN1UrFQR JSVZXlO4VYmcqopxAYpfRsnuuMJc+Ve2sDoteeUhc9Xyb/DJ1FmdBrxyF1DjVJDdGPpkKaNRUlOY 4EaOHEn5Dp8+AAAAqFJOTo6urm7Tpk1leibq6upr1qxJT0+vqR0huzUE1UlM8uVrtUnV9I40A15J ZdmNY2trO2bMGIUJbvjw4ffv38eXBwAAAGpbSUnJuXPnNDU15TskkydPVvL045uJiYlhlVMkrNma AaDh6NatG11Ghg4dquL9Ojg4jBs3TmGC+/e//12dp8oBAAAA3oydnZ3CMbH79+9vZWVVG3tMSkpi u1i2bFlt1A8ADUHHjh3ZI4uC7N3Z2XnChAkKE9zgwYNNTEyQ4AAAAKAGhYeHT506Vb7j0alTp9On T8vPqV1TcnNz2Y6mT59eS7sAgPqtqKiocePGdBkZP368gM1wdXXV1tZWmOAGDBhw+/ZtTNEOAAAA bykjI2P9+vUaGhoynQ3qC23evDk7O7u2G8BeVOndu3dt7wgA6iUfHx921aJLmdBteenh4TFlyhSF Ce7TTz+9efMmEhwAAAC8gaKiouPHj3fo0EG+jzFz5syoqCjVNGPatGlsp5QiVbNHAKhPDA0N2TXk +vXrQreljLe3t8InGUjfvn2vXbtWew8zAAAAQP1z//596kLI9yuGDRvm7Oysypbs27eP7frx48eq 3C8A1A9Lly5l1xCxWCx0Wyrx9fWdPn26wgT30UcfXb58uaioSOg2AgAAwDstICBg/Pjx8n2Jrl27 XrlyRfXP81hbW7MGrFy5UsW7BoC6juJPly5dRNJ5J9/NIUH8/f1nzZqlMMH17t37woULSHAAAAAg LyUlZfny5WpqajL9h+bNm+vp6eXl5QnSKuq3UGykZrRo0SIrK0uQNgBAHXXr1i12HVu1apXQbVEm KChozpw5ChNcr169DA0NCwsLhW4jAAAAvBMKCgoMDAxat24t321YsGBBXFycsM3T19dnjTly5Iiw LQGAumX06NHs6hEcHCx0W14tNDR0/vz58v+ARnr06HHq1Cm6VgvdRgAAABBMaWnpnTt3PvjgA/mu AvV5PD09hW6gRHJyMhviu2fPnkLd/gOAOsfR0ZFdzcaNGyd0W15DeHj4woUL1dXV5S/L3bp1O3ny 5IsXL4RuIwAAAKial5cX94/SfBTlKNC9U++GUE+GtU1HR0fotgBAHZCXl9e7d2923bh//77QzXlt ERERixcvbtSokfwl+p///OexY8fy8/OFbiMAAACoQnx8/IIFC+S7BK1btz5w4MA7+FhOampqp06d WCNtbGyEbg4AvOt0dHTYFWPmzJlCt+XNRUdHL1u2TH6GTdK5c+fDhw8/f/5c6DYCAABAbaE/9Hp6 es2bN5fpBqipqa1YsSIlJUXoBlbJxMSENbVr167UnxG6OQDw7uKGKOnUqVNqaqrQzXlbsbGxK1eu ZI+Oy6ADPHDgAB4mBwAAqGdKS0uvXLnCxmyUMWHChICAAKEb+Gpz585lDe7VqxfiGwAoRMGNe1nM xMRE6ObUmLi4uNWrVzdp0kT+Gv7ee+/t378/JydH6DYCAABADXB2dh42bJj8X/y+ffs+ePBA6NZV V25u7qhRo7j4FhUVJXSLAODdYmRkxAW3PXv2CN2cmpeQkLBu3bqmTZvKX887dOiwd+/e7OxsodsI AAAAb4gCzowZMxT+lT9x4kSdm/WVH9/atGlz6dKld2pMFQAQSk5OzvLly7lLXL0MbpykpKSNGzfK P/0uks5Cvnv37szMTKHbCAAAAK8hOzt78+bN8q9INGrUaP369RkZGUI38A1RfOMPjzllyhTBZ6AD AGHZ2tr26tWLuyzo6+sL3SJVSElJoYt8ixYt5BNcmzZtdu7cWXev8wAAAA1HcXHx6dOnuYEZ+aZO nRoeHi50A99WQUGBrq4uN4OthobGnDlzXFxchG4XAKgUXQquXLkyfPhw7hKnqalpbm4udLtUKi0t bdu2ba1atZK/4NNCulRSAaHbCAAAAIpZWVlpaWnJ/xEfNGiQra2t0K2rSe7u7n379uUf48CBA9eu XUt9udDQ0JKSEqEbCAA1Lz8/39XV9dixY/Pnz5f5F6rZs2c32JySnp6+Y8eONm3ayF/8W7ZsuWXL lnd5GGEAAIAGKCQkZPLkyfJ/uDU1Nc+dO1cvswz14k6cOCGT4JhGjRq1bt26Y8eO7wFAvdChQweF zwcSbW1tS0tLoS9IwsvMzNTT02vbtq38KWrevPmmTZuSk5OFbiMAAEBDl56evmbNGm50NU7Tpk11 dXXr/cDRpaWlVlZW3377rcI39wGgvurcufP69evFYrHQF6F3S1ZWlr6+fvv27eXPWLNmzdatW5eY mCh0GwEAABqiwsLCI0eOtGvXTv5v9OzZs2NiYoRuoEoVFxf7+/ufP39+xYoVX3/99dixY0cBQH0x evTo8ePHT506ddu2bSYmJhikSLmcnJx9+/Z17NhR/q9D06ZN16xZEx8fL3QbAQAAGorS0lIzM7M+ ffrI/10eMWKEq6ur0A0EAACB5ebmGhgYKBy6qnHjxqtWrXr27JnQbQQAAKjnfH19x44dK/+3uHv3 7jdu3MCUZ9AQpKamXr9+XehWANQBeXl5hw4d0tTUlP+roaGhsXz58ujoaKHbCAAAUA8lJSUtXrxY /u9vy5Yt9+7dm5+fL3QDAVREV1e3W7duBQUFQjcEoG54/vz50aNHu3TpIv8XpFGjRkuWLImMjBS6 jQAAAPUE5bLff/+dMpr8n91Fixbh3XNoULKzs9lw6EeOHBG6LQD/z959B0R17HsApwiIRp9KbLFG YzRWTGyXcNWE5/UJFowaC5ZYiMYaW4KxFyyIRLFcxRYxdqJGBEFUiqCoCKJAQESKgPTeYdc3cGBY 9qxI2WW2fD9/3BuX3Tm/PbvzO/Pbc86MIikoKDhy5EjHjh35hxINDY358+dj7hcAAID6EAqFly9f 7tq1K/9Qa2RkFBgYyDpAgIa2e/durgu0adMmNzeXdTgACqawsPDYsWOdO3fmH1bU1dV/+OGH8PBw 1jECAAAonsePHxsaGvIPrz169Lhx4wZubQMVlJeX17p1a9oXdu3axToiAIVUVFR04sQJiT8MErNm zQoNDWUdIwAAgGJ48+YNOXTyj6ctWrTYv38/bvMBlWVrayvWIzIyMlgHBaCoSAX3xx9/dO/eXWIF N2PGjJCQENYxAgAAyK+cnJzNmzfr6OiIHUM1NDSWL1+emprKOkAAZsg4k3+rzoYNG1jHBaDYiouL z549K3HdGWLq1KkvXrxgHSMAAIB8EQgEZ86cad++Pf/QOW7cOFy+AnDixAl+72jSpElSUhLr0AAU XklJyfnz53v16iWxgps0aRLusAYAAOB4eXl99dVX/MNl37593dzcWEcHwB4ZWL7vyq5Vq1axjg5A SQgEgkuXLvXp00diXzM1NfX392cdIwAAADMRERGTJ0/mHyJbt25tZ2dHxqusAwSQCxcuXJA4mCS0 tbVjY2NZBwigPEgF5+Dg0K9fP4k9bty4cU+ePGEdIwAAQIPKyMhYu3Zto0aNxA6LWlpaFhYWmZmZ rAMEkBdCobBv377vq92IhQsXso4RQNmQCu769ev6+voSO52xsbGvry/rGAEAAGSuuLj4v//978cf f8w/Gn7//fevX79mHSCAfPn777+rKdwITU1NLCsMIAtCodDR0VHiVf3EqFGjfHx8WMcIAAAgK66u rr179+YfAQcNGuTt7c06OgB5NHjw4OprN2LmzJmswwRQWqSCc3Z2HjJkiMTeZ2Rk5OXlxTpGAAAA aQoJCTE2NuYf9Tp06HD27FmBQMA6QAB55Obm9sHCjRMUFMQ6WABlRio4V1dXAwMDiR1w5MiR9+7d I89hHSYAAEC9pKSkLF26VF1dXexI17hx461bt+bm5rIOEEB+kQEh7TJDhw4dO3Ys/eeSJUtEh5Hf ffcd62ABlB+pzu7evTt8+HCJFZyhoaGbmxsqOAAAUESFhYU2NjbNmzfnH+DmzJmDyfEAqufj48P1 l/79+zs6OpJHSL1GO9HBgwfJI56enqNGjeIewfR3AA3Gw8ND9KcVUQYGBi4uLqjgAABAUZBj1vXr 1z/77DOJP0v6+fmxDhBAAZiYmHz++eeXLl2ig8Cff/6ZdqXff/+dPpNUbaampmPGjGETKICq8vLy MjIykljBDRkyxMnJCRUcAADIuYCAAIm/Rn766acODg44kAHURGJi4unTp8VWOVyzZg3tUFZWVmIv CQoKys7ObsAYAaCUj4/P6NGjJVZwX3311Y0bN3DgAwAAORQfHz9v3jz+weujjz4i48yCggLWAQIo NgsLC9qtdu7cyTocAKjk6+trYmIisYLT19e/evUqZuUCAAA5kZeXt2PHDl1dXf4xa9GiRYmJiawD BFAGGzZsoD1r27ZtrMMBAHF+fn7jx4+XWMH169fvypUrqOAAAIAhoVB4/vz5Tp068Y9To0ePxrzl AFK0detW2r82bdrEOhwAkMzf33/ixIkSK7jevXtfvHhR7HJoAACABvDw4cOhQ4fyj029evVydnZm HR2AsrG0tKS97LfffmMdDgBUJzAwcMqUKRIrOHKUPHfuHCo4AABoGNHR0dOnT+cfj1q1anXo0KGi oiLWAQIooT179tC+tnbtWtbhAMCHBQUFTZs2TWIF16NHD3t7++LiYtYxAgCA0srOzl6/fr22trbY MUhTU3PVqlVpaWmsAwRQWvv27aM9buXKlazDAYCaCgkJMTMzk1jBdevW7dSpU/jNEwAApKukpOTk yZNt27blH3pMTU1fvnzJOkAAJXfgwAHa6ZYtW8Y6HAConbCwsNmzZ6urq/MPo127dj1+/HhhYSHr GAEAQBm4u7sPGDCAf7ghD967d491dAAq4ciRI7Tr/fTTT6zDAYC6CA8PnzdvnsQKrnPnzkePHsWS OgAAUGfkKGNqaso/xLRt2/bkyZO41RqgwdjZ2dEOaG5uzjocAKi7169fk16soaHBP7x26NDh0KFD +fn5rGMEAABFkp6evmrVKk1NTbHDira29oYNG7Kzs1kHCKBaTp06RbvhDz/8wDocAKivqKioRYsW 8Y+zRPv27Q8cOJCXl8c6RgAAkHdFRUUHDx5s1aoV/2gyY8aM6Oho1gECqCJ7e3vaE2fOnMk6HACQ jpiYmCVLljRq1EjiJS42Nja5ubmsYwQAAHkkFAqdnJx69uzJP4IMHTr04cOHrAMEUF3nz5+n/XHa tGmswwEAaYqNjV2+fDl/GmeidevWe/fuzcnJYR0jAADIkRcvXowaNYp/1OjUqdOFCxdIWcc6QACV duXKFdorJ0+ezDocAJC++Pj4lStX6ujo8I/Fenp6u3fvzsrKYh0jAAAwlpSUtGjRIv6RokmTJpaW lrjeHkAeXLt2jfZNU1NT1uEAgKwkJCSsXbu2cePG/ONyy5YtyXE5MzOTdYwAAMBAQUGBlZXVRx99 xD9AzJ8//+3bt6wDBIByjo6OtHuamJiwDgcAZCspKcnCwqJJkyb8A3Tz5s23bt2anp7OOkYAAGgg QqHQwcHh008/5R8URo4cGRAQwDpAAKji1q1btJOOHj2adTgA0BBSUlLWr1/ftGlT/sG6WbNmmzZt Sk1NZR0jAADIlp+f3/Dhw/kHgu7du1+/fh23tgHIITc3N9pVjYyMWIcDAA0nLS2NlGmkWOMfuElZ R4o7UuKxjhEAAKQvNjZ29uzZEi/AsLGxKSwsZB0gAEjm4eFBO+yIESNYhwMADS09PX3btm0tWrTg H8SbNGliYWGRlJTEOkYAAJCO3NzcLVu28O99VldXX7p0KX6yA5Bz3t7etNsaGBiwDgcA2MjMzLS0 tGzZsiW/giOH+DVr1iQkJLCOEQAA6k4gENjb23/yySf8PG9sbBwSEsI6QAD4MF9fX9pzBw8ezDoc AGApKytr9+7denp6/CO7jo7OypUr4+PjWccIAAC15u3tPWjQIH5u7927t6urK+voAKCm/Pz8aP8d OHAg63AAgL2cnJy9e/e2bt2af5TX1tZevnx5bGws6xgBAKBGXr9+PWXKFH4+//jjj48ePVpcXMw6 QACohcDAQNqL+/XrxzocAJAXubm5NjY2bdu25R/xtbS0lixZEhMTwzpGAAB4r8zMTAsLC5KxxXJ4 o0aN1q5dm5GRwTpAAKi14OBg2pd79erFOhwAkC95eXm2trbt27fnV3Dk6L9o0aKoqCjWMQIAQBUl JSV2dnYSL5+YPHlyREQE6wABoI7CwsJod/7ss89YhwMA8ig/P//w4cMdOnTgDwM0NTXNzc1fv37N OkYAACjl5ubWt29ffrr+8ssvvby8WEcHAPUSERFBO3XXrl1ZhwMA8qugoODo0aOdOnXiDwk0NDTm zZv36tUr1jECAKiu0NDQsWPH8lN0+/btz5w5IxAIWAcIAPUVHR1Nu3bHjh1ZhwMA8q6wsPD48eNd u3blDw/U1dVnz54dFhbGOkYAANWSmpq6fPlyDQ0NsbSso6OzefPmnJwc1gECgHTExcXRDt6uXTvW 4QCAYigqKjp9+nS3bt34FRxhZmaGpYIAABoAycb79+9v0aIFPxXPmjXrzZs3rAMEAGlKTEykfVxP T491OACgSIqLi+3t7Xv06CGxgps2bVpQUBDrGAEAlJNQKLxx44bEDGxgYPD48WPWAQKA9KWlpdGe 3rx5c9bhAIDiKSkpOXfuXM+ePSVWcFOmTAkMDGQdIwCAUiF51cjIiJ9yu3TpcvnyZVLWsQ4QAGQi KyuL9vcmTZqwDgcAFBWp4C5evNi7d2+JFdzEiRMDAgJYxwgAoPASEhLMzc35abZp06Z79uzJz89n HSAAyFBeXh7t9dra2qzDAQDFJhAIHBwc+vXrJ7GCGz9+vJ+fH+sYAQAUEqnLdu3aRWo0fnZduHBh YmIi6wABQOaKiopox1dXV2cdDgAoA1LBXbt2TV9fX2IFZ2Ji8ujRI9YxAgAoDKFQePHixc6dO/Mz 6qhRo54/f846QABoICQbiGaAul0gnex/YcGECUt/9yiQenwAoLC4++i/+uoriRXc6NGjHzx4wDpG AAB59+jRIwMDA34W/fzzz2/evIlb2wBUjbq6Os0DxcXFdWjhxV+LyGu11OYEZko9OpWSGejr6evr e9/3RbbIown/+HmRR309H4fE17Sh+GdeXr4PvbwCwjNkEShAzZFxhZOT0+DBgyVWcEZGRvfv32cd IwCAPIqJiTEzM+NnzpYtW9ra2hYVFbEOEAAY0NLSotmgbre4+tqVznSkq7YmBDfI1oMgx3t42aeg oWbkV1kFZ+4dUP7pfNz9SA0rMd+DX9b2JQAyRSo4FxeXYcOGSazgRo4c6e7uzjpGAAB5kZ2dvXHj Rh0dHbFsqaGh8fPPP6emprIOEACY0dXVpTmB5IqavCQ56I8Z34xcvOVqStk/493Xk9e2MzjJlQkR 904smDACl1DWlrDw0bSyT0FT7TuRM5iZdqbln04H4xM1+njevXtqN7m2LwFoAKSCu3PnjqGhocQK bvjw4eSvuP4HAFSZQCA4ffp0u3bt+Ely/PjxYWFhrAMEAMaaNWtG00JaWlpNXvLiwk/lZ+177Iws flfy9kppSrEsnT7Ov+JPVU8ewYd9sHYj1XFta7eavwSgwZDqzN3dfeTIkRIrOAMDA1dXV1RwAKCC PDw8JM7y1K9fv7t377KODgDkgp6eHk0OSUlJNXlJtPt2+pKmaptCk5/NVVOz8ozxvzCLPt5xzJ+4 Wq9WULuBqvH09JS4tiwxdOhQZ2dnVHAAoCJevXo1ceJEfjJs06bN8ePHS0pKWAcIAPKibdu2NEXE x9d0Noyi9EgPhyPTv5Uw6JpjcdDdL6YhL5gUvos5vGK7ot9th9oNVJO3t/fo0aMlVnCDBg1ydHRE BQcASiw9PX316tWamppiCVBLS2vdunVZWVmsAwQA+dKhQweaKGJiYmr78owI97XlFZz+zrNPWNzj lnBwVmm9o+iXaKJ2A1X28OFDY2NjiRWcvr7+tWvXUMEBgJIpLi4+fPiw6OVP1NSpUyMjI1kHCADy qEuXLjRXRERE1PyFiRF+F21/Gdu/yiCr9KRbYPT7VhoQ5mfFlYmKi8uWxmky4bsYa9PyeueDtVud tp6XFBcXn5RW/doJWWnkWdU/jbQTGVW29eQ0yQVufWq3vKzEqKhXUVFkC8mk9adnvkPtBoroyZMn 48aNk1jB9e/f38HBQSAQsI4RAEAKbt269cUXX/Bz3ZAhQ7D2JQBU47PPPqMZo4bzF+XG31taebWk vv3d66ToWP6ni3VFlaGhZnTWI0H0JcLs1/bbp4olqCW7bqZUVDv3D45SK7sbt4+amvEvTvzypiDa 0aTsCQTZqHOkgBZuNJKKv6otPxFSq61zuDlYSAD/mneJ/OXto+PDK56s22finw+5k5J55xeSPaZP HrS49DIjwnG+yIWj5I3vu/Ssaqt5jx0sh1fd9FdjN3jwVl6rW+2WEf1g50LJs/a97yUAcs7f39/U 1FTiV7pPnz6XLl3CrR8AoLiCg4MlXijesWPHc+fO4RcqAKher169aN4g+aQmL3FYVFkuXQ8pEmT8 Teods0OvhO8iNlYsRiZagGS8dhArXihdtTWBZauUCLIDlog8PsPGT3SLwgJ/0b9Ot3lQXBKxQ9Ld dhUvD6SvrcnWOU/tyqdN6Dr1cvBjW/7zLS5GkWLqoOl7t8sLPsFu1nufdvRBlfVZ6lC7+f+1uvpI ULuB4nr27NnkyZMlfrFJ1jp//jwqOABQLMnJyYsXL1ZXVxfLabq6utu3b8/NzWUdIAAogL59+9Ls ERgY+OEXVNxO1eyLnzwjC9+VTjtZur5bxzF/kjJBWBKxb9bn5J9tDY5wq78JMu5WLZ30Z86c2Ufk 3+SZ3CmoknhX0WduuRZZscEE0XKp27xL2e/y/nh/TaRWumDB83e13Po7kdvEJNJQM7oTKxAtpmib C9etW172rqkr4aV7RpDjbfL+BpuqbXojsldrW7u9clwlFoap2Y8zJowQfQi1Gyi6Fy9eTJ0qftKc 06NHD3t7++Li6q9oBgBgr6CgwNraWnRVJmru3LlxcXGsAwQAhSG6ksjTp09r+Kr8rCw6YPItu9xR tAjKSkvLr/izy/pOtP1fTvpUlBIprgen0McPPCivVdKDjokmtFNl97C57BhCH2nZY+ebspaLstKS 07JCXTdwj5PCyjk8g2w3qUx2xeZrtXWudmtUcQffmGWXYrLyM5ODT/w2hvzzx/LrMKvUbsPmnY2p uHUu1HUHfdzscOmTaTk25Vf7oLh0MsjMSw/eJ1LlnXtW+SNbrWo3+mTO/N9v0+s/hQWJ51ca8F8C oLiCg4NnzJjBG/KU6t69++nTp4uKiljHCAAggVAovHr1ardu3fjpa8SIETUfdwEAcAYPHkzTiK+v bx1a4EoeibOFiJ54mm7pV/WPeX9UXHvJnbPjvKoox9TKKrIVP1cO2Eo3UeUyw3fZQQfonwJ504/U duui593+Ne+a6D13wV5eb8uLo8piqvO0E1VvWqu8nJJrkwTQR03tZNVb/0RPBR4V2WW1qt2eV8xG olZZVFZ6jrlKQBmFhobOmiX5jPunn3564sQJVHAAIFf8/f1JgcZPWaSUIwUdps8FgDowMDCgycTb 27sOLXCVgsQyIS2g8q4xK7c3aUlJcdyJMfL/aWmPzszm/tTB+IToa73fc+3ilZAcsfbTRWs3XuVY 262L1G76t2Lfd7NwZTHFnVwTJTo5f1lZlxkXK75XBOmVFeXpOp53K75RcT5RV21NJO+SMawRAEos PDx87ty5/BtGiM6dOx87dqywsJB1jACg6uLj40mm4qepZs2aWVtbFxSwWFIJAJTC8OGVN4R5eHjU qY3ipLi4dEmz7tPaqno6aourrqyd5/DbMLHn7HF6U037Emu32m6dljyi13/yVBZTojOicKopmoTF mS/93X7/TfRSxzrXbpl0CpTx4ucTPxAGgHKIiIhYsGCBhoYGv0d37Njx8OHDGBoBABN5eXnbt2/X 1dUVS03q6upLlixJTk5mHSAAKLZvv62crvHOnTvSbbyG1ZOW2hyxKx7F5hjRVVsjsZiSSu1Gt05L HrHzgFXVunYTFry+aDWvj6RN1/Waycw/Fn72vhjeFwaA8omKilq4cKGmpia/c33yySe2trb5+dJY SBIAoAYEAsGff/7ZsWNHfkYaM2ZMDafyBgConugiIy4uLtJtnFZPGmpGD1NL3hVLlM+bKC6BPw// dBsJS1XS9kvrr/fXbjXces1KntrVboXxrqJTTS7ectHP/wKt4+pau6XYVhTcZodRu4Gqi4mJWbx4 caNGjfjjpXbt2v3++++YeRsAZM3Hx0d0AgHqiy++kPrgCgBUmYlJZW3h6Ogo3cazReaN3O+R+uEX lCoWnVhSVNnyalWInlnz4jVf261LvXYTloStqQhgyHTr4NTS5aiEBf70usk6z1Vyf295xd3m630p dXwjAEolNjZ22bJlWlpa/NTRpk0ba2vrnBzxG2YBAOovKipK4lImenp6R44cwTomACBdEyZMoHnm 2rVr0m1cWPKC3qmro7bYT1L9lBJ60/qkD01tL/6qXPmbvOSyg41oJhRbz1p0NpK/I8VnF6nt1qVe u6UFWFVsX5+WllKp3V45LqRvfCvvTkDUbqCy4uPjV65cqaOjI3EctXv37uxs9AkAkI6srKx169bx fzLS1NRcs2ZNeno66wABQAlNmjSJZpsrV65IvX1u9TeOhprRCeeg9NLF14rzs9Je+rvtXGhIHv+4 e/ncIMkitRipd/4uW+G66iLU5Q9yRFcBWGDzgJubIDX6yeGfzblJKWu1danXbiKnBStrt5KUv2lI tk8qpzSv3fpu78KWiOyUTX96x6dl0R/36LtG7QaqKSEhgQycGjduzK/gWrVqZWlpmZnJu8YaAKDG SkpKjh8/3qZNG36S+e677169esU6QABQWtOmVc58eOHCBam3L3rd4PtwM+qXxLuKzk9i5Va5LJqv yKoBWmpz6Bk00njVGXj1+1WsrM2d0qr51t/J9rybWtuxG9yfPn9w47Do7W+jl+9d+21FqLWp3Yi3 j/d+6J2hdgOVlpiY+Ouvv/JneyNatGixbds2/CoOAHVw9+7d/v378xPLwIED6zpfNwBATc2cOZOm HXt7e1lsQpBybxo/x4kw/MUpryBI9EQSbwqOPLqiWem4q+fGyIrZ40KrnJWrdOBBZs23zp2w463O JlHlAtzV124ZpZVjxAcrRxoqqd24sq7qKueVm+NH9fbRcYnTV1LVvhEAlZCcnLx+/fqmTZvyO0iz Zs02b96clpbGOkYAUAxhYWHjx4+XcLRt1+706dMCwftWhgUAkJoffviBJp9Tp07JaCvCgjc3j/0y XDzb6c9esdc98O270sk3BtFHv156TdLKTCl2sz6nzxFd1yzs3iGTqu1+N/8QNzFIDbfOeXGhfNW0 LlPPVnPe7Y+KtdXMeWtz0xa6Tr1cPs9k8uO1ppWbbNp79kUv3zMiq9dNXmb/OpMLsvw+uKpzZlZu TmJUZW9ty7hvJNdw3eZdwhpXAERqauqmTZtIscbvJh999NGGDRtSUviz/gAAVLK2tuavKamjo7Nx 40bcSAsADWbBggU0BdnZ2cl4a8VpSUlxpZKT07KkOvVS6frgSaWNJ2e/d0En2W39AzLLtks2KvJI XFQUeQSlFUDDSU9P37p1a/PmzfkV3NKlS1lHBwByzdHRUSxvmJmZxcTEsI4LAFTLTz/9RLPQkSNH WIcDACBbmZmZO3bsaNmyJU19GhoaUVHiS5AAvE9iYqKTk9OWLVvGjh3buXNn8l1q3LixDig7bW1t 0cJNS0uLdUQgK02bNm3duvWAAQMWLFhw7Nixp0+fFhUVfTg1sJCdne3p6blv375p06b16NFDT09P V1eX9f4D2SLJR7NMo0aNkIiUHunRpF+T3k36uLW1NenvcnulB8mT/v7+JGeam5vr6+uTLEpyKev9 B8qDDMPo5U/q6uqsw1FFpN4hVU+nTp1MTExIHXTz5k1SE7FOPNURCATOzs5jxoyReI06ACgxMgjZ sGHDmzfiqzIxFBAQMH/+fLGfFABA6ZFeP2/ePFIlsU5ClWJjYzdu3Chx7mUAUG6jR492cnKStzkf SkpKDh8+3L17d7FoSdXfp0+fkSNHkoLOBFSDsbEx6xBAtshHPGrUKENDw48//pjf5adMmRIUFMQ2 I926dYuEx8+fXbt2HTFiBMmirHchAEgN6dGkX5Peze/yBgYGzs7ObNNRcHDw999/z78ZXE9Pj4RH cikOmgBKg9Q7pOohtQ8ZDol1+W7duh08eJBUTGwzEufly5ck/4iGR0ZN+/fv9/Hxyc3NZR0dAMiK UCiMjo52cHBYsWKF6GX2jRo12rNnD5MElZGRMXfuXLFsuWXLFhcXF8y4BaDcSB93dXXdunWr2C/J c+bMYbLoFcmBVlZWWlpaNJIWLVosX76c5MyoqCiSPxs+JABoGKQCInUQqYbEfkkeNmxYWFgYw8BI 5rG1tdXR0eHi0dbWXrBgQUBAAMOQAICJvLy8kydPDhgwgCaooUOHNnCCcnNz69ixIw3A2NjY2dlZ 3q5SAABZI73+1q1bJiaVyyx06NCBlHUNGUN4eLjoz9r9+/c/ceIEftAGUEHPnj0zNzend3CQuonU dEx+vSEbXbZsmei5tlevXjV8GAAgP0haOHr0qK6uLpcWWrZsSVJWw2z6/PnzNB117tz57t27DbNd AJBb7u7uXbp0oZnh7NmzDbPdwMBAPT09bqMkHx45cgRn2QBUXERExPDhlWtyLl68uIHTgmjhRgpJ Gxsb/LgNABySoEaMGNGQ5Zto4WZubp6Zmfnh1wCACsjKylq4cGFDlm+ihZuhoSHJh7LeIgAoBFIr 7d+/n56Aa+DybcWKFdx2Gzdu7OHh0WDbBQCFUFxcPG3aNFq+PX/+XHbbunjxIh2Y2djYyG5DAKCg Dhw4QLPE+fPnZbehFy9e0MJtypQpJBPKblsAoIi8vLzo5UlLly5tmPKNjpRQuAHA+4iWbz179szL y5PFVl6+fElvuUXhBgDvQ8s3kjFkdCtufn5+r169ULgBQPVEyzeZ/prEefv2LZ1QDneUAEA1yNBl 7NixXLpYvXq11NsvKSmhswFs375d6u0DgDLZuXMnly6GDRsmi4lw165dy7VvbGyMwg0AquHu7s6l ixYtWsTHx8tuQ0KhcPz48dy2fv31V9ltCACUQ2JiIr2C6P79+9JtfO/evfSmEjlZMwUA5JZAIKBz BezZs0e6jfv4+HAtt2rVKiEhQbqNA4DyWbduHZc0xo4dK7srJ2/dusVtpXfv3gUFBTLaCgAoEwcH By5v9O/fX4rZKTk5mbvht3HjxpjkFgBqIiIigrtUSUtLKzExUVrNksymr6/PJbrLly9Lq1kAUGKk kurbty+XN5ycnGS0FWNjY24TDx8+lNEmAED5mJqacqnDy8tLWm3u2rWLa9PKykpabQKA0tu3bx+X OiwtLaXVpre3N9fmuHHjpNUmACi9R48ecalj9OjRsmg/PDyca9/AwEAW7QOAsrp//z69f18qDRYX F3PLcDdp0gQrAgBAzWVlZTVt2lStbMFuad2VNnXqVC7FeXp6SqVBAFARhoaGXPaQxRxKK1eu5Bq/ cOGC1BsHACUmFAr79+9Psoe6unpsbGz9G7x69SqXjhYvXlz/1gBApSxdupRLIA4ODvVvLS4uTkND g7TWt29frMENALVy6dIlLh2tWLFC6o136dKFtNymTZvCwkKpNw4Ayu348eNcdjp69Gj9W5s1axbX WnBwcP1bAwCVEhoayiUQMzOz+rdmZ2cnxeQGACqlqKioXbt2JIF06tRJui0nJydzqWn69OnSbRkA VEF0dDSXQxYsWFD/1rhFlDp06FD/pgBABZFhEskhn3/+ef2b+vHHH7nkFhkZWf/WAEDVmJmZcTlE ihMoES4uLlyzWP0WAOpAKBS2bt2a5JABAwbUs6msrCwuHU2cOFEaoQGAypk0aRKXRup/w+zAgQNJ O3p6erhgEgDqYP/+/Vw6cnZ2lmKz27dvl/o0cQCgUriJatXV1fPy8urTjoeHh9SniQMAlUInqr13 71592snPz+dudpPRNHEAoPToRLVbt26VYrNz5szhmk1PT5diswCgOiwsLLg0EhISUp92Tpw4wbVz 48YNacUGACrFycmJSyPHjh2rTzthYWFcO2vXrpVWbACgUujVRDNnzpRis1OmTOGaLSkpkWKzAKA6 LC0tuTTy9OnT+rRja2vLtePh4SGt2ABApXh5eXFpZP/+/fVpJyAggGtn+/bt0ooNAFSKUCjk0sik SZOk2OyECRO4i52k2CYAqBS6JO6DBw/q0461tbVU2gEAlfX48WMujezZs6c+7dCldevZDgCoMi0t LZJGxo4dK8U2udpNQ0NDim0CgEqxsbGRbu328OFDacUGACrlyZMn0q3drKyspBUbAKgabW1t1G4A IG9QuwGAnEDtBgDyA7UbAMgh1G4AICdQuwGA/FCm2k1YQVCVKq+iwt8hJSUlyrdzRN8m998MAxDb ycz3ML9HyElg1UPt1jD4aVOuvr3VkJjtaQaQ58hB4aB2UwWiKaWkTH0yoWhqRVIC6VKa2o3rIKSv FRcXF4ooKioij7Aa0rNFsxDZA2Q/cDukoKBAmXYOzY3cR8+9HaKBA+C2zt/JzPcwt3NEY+PI/+eO 2q0BiPYdid9ebvQih98TiZHT77bchg0KCrWb0qMphcsnBWXEDuJ1a1A0I8koeFA1SlC70dEp6WX5 +fnZ2dmZmZnpFbKysnJyckgf5MYh8tN3RH+NkV373G7Jzc0l+4HbIWlpaeR/MzIyyF4i+4r8ie4c ucotoufRqnkaTbbkXeSVES1MGiBCbg+T7ZKvGdmlZMfSnUy/fuRrSfO/TEOSGB7ZM+RTpv2C++i5 z72BQ6oV1G4yJfr14L695LvKfXvpl4Q8IpYfWEddjvu1hERFehaNnMNPa/KT00BxoXZTbtxAgjuU i44hSUoh/6TjipoP2LgcxdWA5OVIRyBdSlC7cSMQ0jvIETw1NTUhIcHP48aBnZtXrVq1evXqDdv2 nL50MygqkRzN5aHviJ6R536NkVFIdGBGdktMsMfly5cdHByuVCD/ffXq1StXrrt4+kS9Lc1OZBTU MCVP9fjn0aoZNNL0SD792DBvZ2c3N2dn74BY+l5kGiTZNFcWkTyfHBvu5Xzl4O4t5Cu3et3mTevW bdlpfcr+r3s+Aa/jEkkpx+V/8g1ssD1M+0VpeIn/ONrb/LZmyeoyVofO+4XGkcfJX+XhQ5cItZuM iBX15GuQkpLyNirUw/HSgV1ladNiy+bfftu22+bMn9e9HgfFpWTQ3x/k4atCez0J/uVjD0cXl5s3 b94o41jqL6eb7s/+iSKDLu5XO7n9hoMCQe2mrLh8yP0QxI0h/e/fLD+Ur169fuvuU+cdn0fE12qM RHNUdmqYp4uLm5ub6x2/tIrfS5GLoP4UvXajA9T09PS3b9+GPXJY/L9qEhktPOAXmca249Cfi+lJ IpINSAeXRflG9kxp6sjOJsXsta19Je+UCnPXnwp7m0GLC+lGUtuwuVEl2TPcLqom3ZEHyZ/IEI58 +k6W/bn30rKrVUxmJnmV7JaG51I9iY2MDxPf+B3fNrf63fvd3HX2jvdjUlO5HxAaYA/TCEnZ+Oz2 gcGSopq360ZyejpXvsnh0QS1myzQFMT1msTExJiIB//dPLv6L/AU880Xbz9OloP88K6i15d+t9Oj N37x3pj/Z4j5qZtPyfef/mrHNmxQaKjdlBV3rMzJySG5IurZ38v+IzmffGO+zzciiSvfalK7kdEX afO1xxbu5epq/74XlUYeIY8zT6GgBBS6duMO4qQ3kUFIXFxckOexbtWOQP692ZNtx6Ej6szMzBfO 277+4t9f9+6952oIV75JcUPcCI1sKDU1NSoq6tKm9xS0IjTUjB2Dksk4h+FInvtAS88VpgTtmGrw tWGvLyftCErO4Qoxsai4n8vIriM7k5TtNyz/j3sjbb+xikpO5gZsUn8j9Pc0koTJvvW8vOGzD+7Z Cu2+tX2TllbD5F/PIOkPGs+d1lcT0rJTTzNlXOfWGWo3qaMni7Ozs1NSUt68eXP7rEX3Gn+BP/nP sZT8fHm4dKGi14dvH/WBmL/64XhESgqGTFBPqN2UEvdbMRktkKN5xKPT1R/Nv15/m2ROLpN88FYO blz6j/s27rUaav+58zKePJJflkIb7A2CslLc2o0O3bOyssjQ/WX447VVzy4YmkwyM5v09ZeVj0ze cZ9tx+EGTiTg5JTXloblUbXqapMg7fE8N3onI5bExMSwsLAzFt/QnaDZtVQX8h+ffiqWmv6n6+aw jAwSIatBDlfbkkT65vFhGtUulyjyRvg/+NOBKFefXt5cPozTG2j5Kj6ey7EyOptJ4klJjTy1eiQ/ vZO9amBg8K8BA/h/0hu4OzwxUeJ7kUWQpYPbhKeLe1YGMObHHXan7Db/ZEIfad71l5CUFPk89Yba TbpowiRdIzk5OTo6+Mjyf9fqC9x68P54pr/tcLhxUVpaGnkLG7+tDM/gG+NvDfp14YVtusOVpAjy JWdedYLiQu2mfOgQIiMjIy4+eP2wKnmDDCBnzPjOYKBIJtnkllE2QPpgJiFPIMOYpKSkAJdN3Gs1 1IycnkeSR9j+PA5KQ6FrN+7UUkpKSmRkpM+1DbSL9Rq56oLzXS8vr/v375OB352bJ1eMKz2kT97h xfAIXnmpT1pafPzLLQbl0bbssje+bDwv3dqNNEhG77Gxsc+fPz++ZgS3LXW1fx26dvvevXseHh53 7969eeOi9fo5ovlqxR/PcqQdTM1j5k5pkdr2pZclDWnHzVcSzw3R/UnyYXh4+Ln1RtzzW+lv+yc6 muRYqddu9BLNlJSEk0vaiw0RJ/y0+Y/L18mO9Srj6XnP+brD0X2bfxhf/kmTojI0Pp68O6mfZhXD HTjI+PyZ6yYa3vTf/iRReZc59sugioe/uBWRzOoTrx5qN+mi317yxYiMDD9k3k68xlm82d7hhkcZ d3f3u3dvO/51+ZjNlnkTvuae0HqQTVx2NvOvCle7kbT/6tWzdSPLg2/Wa+nft27dvn37zp07ztfP rZvei74vDbVRt8LiSQ5hHjkoLtRuyoemRDKECLy9jWaMniNXnb3hQnIgdzS/dfXoYuNOpYf4jbfJ 4K2GtVt2dvbbt28fOf5WkYW+uf40jDxCHkftBvWn0LUbd2opISEhNDT09rlVtOvZOvuQTBsYGPi8 THBwcHj4P9f2zP352NP8imt+6JwYYgt58C/ME33mB0mchoi2wJ1USk1NjYuLe3B917e9SDFlaOv4 nA6eax6YaLMlFQQiy4hwtdubN2+ePXt2bDWt3Qz/cPUmO8ff358cRDw9Pclo58zOmZUFyEZXUvVw e6maNyjx8sVqniP6pqp5I9wFk6UnjOL8dy8o/Ul9+NQ9/lGJYrUb93x69Vd8fPw///xzZl35ucWW AzaHRP0/e98dH1dx7b8YEkhI6JCEQAIhwWDKM6GFZgtsg7ExNsUNAzZgGxt3ucmy5d7lgptsWbLV e+91tUUrabXalXalLepdluRCf8nL7z3y3nfu2Ts7uyo4+QHBRucPfex7Z++dOXfOmfM9c+acVhG7 DcKofrsxEOGH5PCviFsiGr2/eGBOULKypMQ562okwsQD500mk9FoLFEm7Fzy7O0TjzT19PTFbt/I vX6b8S6JPyGiTTfMsRhfJ2y8SjE9obgY3auqqkKvKk25gYcOBQYeCY7MbD3nid08pt/gTPvuaAi7 fYv0DyGIuq2trejUPHEC//KhuSEZWigEmh4g/APz1iAR5nCFNnW/9+g7Jgf3SNjta2HX+OJn7+Dy 1VddDPRk/Js8NnV1prVOxaa47v6laUqlTqfDV4YkKpXZPhNd3pXtaWZgvb5BF/12aaBJ/k+17Lfz A7UcSKkOQhfPxsHb/Auj+3HSEHa7/IjWSqzIzB5L8eHqYn+qCpoEChBmEjQh1nSr1RK7/Z3FR0q4 dTS4MJL1JT72CoVXUrmts7OTLBOPhbvfvvUrkn3bDK4NBmnT92mDPOG7/RJD9M/TpYvdSEBI7qxW a2H85t85Je+eIKXJbrc3Nze3SdTe3g7zHms3xdFxW5RyhkAS/1Mi/EPMhk3Ub/0g+hW1/7s78VTw fNp/LVTXomSY6An6Q31D52FN0XEM6hUvdoDG1DExwaxHx8SWlPmEOsAjATB2KB8Bu42K1VYC6jY2 NgLvQDup1eqMlAM82vT2iYc7z50Do8ShUaETPmSPntDoeAPehqeIpDa87p5H9SWPsVAKBeBx9Lyl pQXYs7fXhd2+FioC8BR5ra2t0K6n1jjHeOPDm2wtLXgI/0m/jOKlBDwG0u+H5sSCKzqKZwl274jJ m/O0WqzsmIQNDQ34pugzVDT+4t+YhA0SYSz46BekdCWcA3x29cu9r93tVc5AsTGNhf+EiPZWmpqa wtY/SZ381ctbNWVlgJP49PUS1dXVYQ6gkxfkDCqcV5Rxi8tFv5PwOxVtoiHs9i3S13IYLRSOzZr1 pjCBH3x9h8ZgwNzAlMAsbZUI/8D0wDzBhKGpQpqKZi/NzK8HroXkMUn+IRdApNnFideSG0hd0FSn h/M2tK0MtVBbZ1w7imO3FYUlJdB1NTU1wJ4wvWIOuiIKNidWdHd3i9FKombm+k18kYf08ZGKmn+Q kX5jiShR9YkJdflLxVt84P8sG8XR9e12vxqY6P+nrNVlSUPY7fIjzG3yFWOlLsvcLYdb/+FoZrHJ ZCIzCcsoaUUoQLIheeragZZvkiNYIFheBew2Kr7Uguecl47fiiLmsYvnYTSKIukhuR7agMwDsRui VSDe/XufyrPfaMgNKYEfGl0e2A3rdfbphXylHr/0FKQOpjIsWNgbn3zyCRXp4NCGrFNcgXyhQW97 M0wX2N7VDkfPua8o3SKf8FQc7XOZqATShQuddTZbbWPrBamcEOgLiai0kIgLKDkJL0KEzpw9exZ9 a5eI7HnCbiQ4+Dea4eLZM+02aevQaq1t7ezh+a6JOHhhD+xoQTMwwWK3d5/9ksxsSlUBpeSO3UYn l9txEe+FGsGQYeRkpu69U2bdzY9sd0hG2ucC0ZC7muuBiFs7L3DNQzYDLx6HnlyQiOqaUYklrjGo Gb/O+cPHwstLsYzl3d3Qe+ghQBDYRdhNxL9MMbbYDQbY9aVqta64vPzE2udk7LbR2tz8iZQVhH5C jLpwpp22w2DedZz5lGqc0Zci+ptUK0ocOI3aZrO1dpynai/oWNHJD/hM+4liVpJWW1lZCfsWHcZ8 wxC+kIm+Iy7CzsRf/Jxrfo5AaWLQPKS5Ss2ooAw32PgoeP041rq3tdZqpe4RYznABN9wPXrPDOrn 8x8GArngClYichpgPaJpQIn4OHvpQ+AivgI4j56flQhv40nXudfxOxXwIez2bdE/5OhiTEJYI6kH ZwkTeHa2ZKVAF+Fb87qEJIZo39PTgzmPv1Tngs9empOkRXl5NY/aaqKjiVQu1RnkxHbYWxvx9k4p ya2oLkgS2xsc0DkOh6W2sYsUOOlJCrdwOCo4drt+xCqdNBDMcAij0WhMPPI+H+bG2DJIBI9W+odQ Ho6tAj2dDgd7EfR/V8/nfKUQvXzUsrerzSERFHJfVfa1UC+PRieyhUt038ZiQl1R5P8m59rlxhh3 Nops7GlrQpfau1gWOw82fvnpuUZpaDZbXXP7GdLMHu8iRfTleRa+gudgEcHnoD5zPgxZbkPY7fIj wm6QUFgamuhlXF2MWxhgrqnBRag+aMXzEtG6zG1I0Tg809Jgs2B1tdXXN/ec/4ykkiIcdElrZdPr uWiNsb6+vqPJCjuEbS509XK14OG04aq1s6lWUk3m2oZOiKRYqrivUiUztaOlAUJcU+M4K2tjcllj VW+trWWBaI6GC7J0cxtDVnFnGx3MjGRjaTpDxozYw3/3FxsiF1262I0MEgqZw0zTZu0X8+D/+d1D 9p4eEjduS3DvBK6w7O69vW21Jfu9X1G409xNce2f/yetkpQ5Vh3IksDfq1A8OuNES0eHMX3PE3Lj a+57OSDb3NtRNBOG0P33D1coXlqdR0YOvY42kjJ3TlIoHrjvfhhL76mbGTDJ2/cmPfPdQyUkws5S XOfOtbcajm+a7ZHy6Lqnp+8IyGplu0n/xffvOur1/fR/Y1zrJ19QpRLoHyALAbt5JRpraTMLf6FA YBhH7nuH/9ZrWTxDTM1F76Or992nUIwILOro6DTsmfsob/Pq0iCbZOGQfXX+fI8uNXDFrDF/khvc P/zpdxdvzzE0kbZhaPSsdhbnz6pcqixG/PmbVFQla9dkzh9NS09Hc940heLK+5htqWo6i49FBgwe BWbWGzPWvv2YYgC68WG/mqYmQsSkWs+1VR5a/apHszm+EQ29F4jzxNLPzuo/GOEadWdXhTjqVxYd NzadaW62bxP4vfjjNKzpUMhQ8hiUqNhFLxbf2PWYhACU+owg77fHctbdd+/T73y0Jb20Hv1Hz0m7 EsTrMBzDbAGLfnH3MpXNEr7Z7aDi6Lc2ahy9ZCv29jbundk3ZwOj30w8ADO9rTFnmvRfsLek8wJZ oTSpqouTtix568nhw68aPvxegYYPx6cbEVnRzTevv+vdtyHs9m3RP6QIajlEwbj+Jdd8WBVYRLMX YkWuDE40b8m3wMWEprcQQtBTmn4SE/hel+w/O2fZzvzKNtEx8ncpvc+nvWVMvu6/H5IepAEgNO2d 75LiKcuC7b1fEOTB5DdkHJ3snv//+r/MidM1ETzBqz2x2wNrtFVVtMGNv5WVxT6CxIvYjbAkydSF jqojayd7yMj7G6Kazn3KXU+kdjodOSvfdMtlcPW9E9YfTnSc+ZRLvUuoM4NXvjtO4Mkzs5fsIH3I HYOk+nqqTkDd3D9CcY1iifHcV1xFMDB1oWKugtj1YGj5GSfaPVc+7wEXD3t6K/d96ErRNWnJyRrJ K4WWn31iD989d7jCjX755OsbDyY5uj7hlhvjw1n7Cd/XPZgwZ124o6sXs4Kn6PyRW25D2O3yIxG7 GYuOPSzM/5Ez/ataW2EmkbuDe0X48k3Wmk0b+v54z+SUU+dtStPYoVShi4oT19DFKxWvRuZmHvGe IrYc+ZpPTpWrchzBKDoJUpkdMGWE22Ov+8u70epa9JY7ab/6qjvgvbuhCnB3VUS5tTT8PaEzwxQT QpT15yQqSz4ophq/SjE1NN9B0i3H2JwvCvdzT9aieGjMkmTJFOE+23/3FxsiF13q2I3OmcL8gEr0 n++2Ug1TjD+aaqCpTlYEt5kxG7GUVxYdfVTRP12tWFzSypzJlEk7dbvz3NCvxx9Ii/Xt237h0fy9 slBCZJQtF8hfQe8CEuH2/u0Tj1ibmxsbG1O2Ok2o17cUQYhoSw44tKb45PgBegXaW9BJtg1amlUB A/d/kaaRbfARdjvh7TRx2MZ9uQXsglapq6urqioLO7Tid8IPvYPU6FtDdbKXfGVPfOaWSX2fv9DY BcXW21yZOu+pAXv7wqLjtWfOgodAEwfe4Px5Oa+xh74LgejutkJP/jicHRimeDGnjsUqkBMbI8oJ nNfPmwS68aEN1Y2N+AmxtF5/qt/qZqCfKuYX1Z4F82mLrbMxm6fj7HfUP1XMzTEkcB143Ygl+aWl wL8wicWoTo8gc4+wKKdh9uWXZ2zZC54ZcBReCw7bO7rJ+UA43abcMvjAMeEzqntYxa52u++Y/tvc /MiOqqamxpoUL/knuQ3dtFV6obti05v9F9kYJi8I29LrxeOQ36mAD2G3b4vIRMEnhtSb9DF8kt/w 8Kpyefb+TS47K26W8VA6HmNDKpTXQpr/tGIgGrs0qPWTL2jDiNqL8uWfnLvNEzNBq3wErXLmTP2J /jK4Ei0N0JG0SqdcRezmXVxebrVaa2trjaX5295zefKuVLyeXmlHezrXSbtdkKnGipAn+n8JerJA XX+eQCvbxa6JvHeAls9sKBRdHxDqhQMLNfQh9xeRz6qheDvdwqpR0HSO3DWEFs+153Mh3ptbR87/ 7uZcfnEAHi4wdHS3VEb0ueOiLakOmHM0unZzxED6G+our6bznBRC//fvpgjpJURD2O3yI+7UgjVY U1NzaNF94vwfphh3KKEE898jREdWgF3RG/qYCDLd8Psd1vZ2mFKahNUDCyKjKxTPpNmcjl/yFH32 Wcfptc8P1P6jwyqybZgd+EnrtkGMRYkOpxSFbn6231u70qppdJ9/0XBg2oBP2JFcBbuLzukP+XB+ OHRJYzduk7S1tVVXVxcXZ63y3INS3DJ2rdLcQU5Uis2Dpdre3m4zhD7i1vCP48aNE5Pm3/I4y+gO oYYxEL1hAFNYoisUT4VqHeJZ17f8lRQ+xyyWzs6CwBn81uYEg8PhgI0R4+cEAZP98nokAkh0GMP+ 7Pl4N9pX2Aw56q8l6/9dwv9vfmyno6urqanJaDQeXzGKX7/32RcnTJgwceLElyeMvsvtCVis56kc Doy3pjJ6gAKVTnphaWxDS0tNwaFvLA71y7tWlza3M79WlisR6IzdbMgUmgWsoQp+i9/aFF/O+FMV Q8h2mGJslqWZwl+7u7vVwXPdH//HZ8dOev6ph8RLwG7m+no8H4xqt8e7AzdPLt30563gElqiPQDj S4rBaNSCEH1xGDdXf/Xy1lKjERw+L6XZH8QrJeI4Am4tpYF/GuxVEut+v7KstZP8ZphFhkzPSm3D n3vtnXenicO5fcLxhra2xkazXx9BILrtuT1VdXV2S5zM3nHZ1lawt7u7gYPrfunxKS8+8dikKF2D eOjpOxXwIez2rdA/5CwlmEUNDQ169ekn+WyZvL9Wji7+7wFSn4kH2P9HrmyICV+nPvaNlQ2v/4Nv zYXPKTQdc6zBnjS4fD2/JLa+uTl6jRhAofjTMy+Ofc5tE3lHZiPpQLvdsMal2BSPPP306NGj/9hH rmbuTKyvr6fs3LTTxFLA1ScPrhlufnRbgxTq3NPTcvhtt5bP/NnV8LVNhRRODGou+Wahvu7utaYz ZykYCWy0FjodMpDEPHsHnYWhsPkzrdm8mMf2NDM0AFB2a0PahEGf77UoylEVOZC3imhbahUd3jnb lOruaf+TBxNuHLmxurX1nJzO6Ps56PrDpCHsdvkR9//DCIGKMBgK1/RBY7eMWV1Q2UpOFdp0o1Th yX79VFHhdJvXbmtzc11dnTp+lcet4eOmL18xV3Tw3DntZId0MIQEP3XjSLE9DDYPBbg52UbBnF1d dX0KXD7++pw54wYISnr5tfFip5mvrK0Nz+lpyRjEwL1asaCspYWUwPew7g/RRdKli93+V3abYEZh XW5sbDSZTBpN9tZ5/Uzcef7KT6WYEwJTQAeH37uN352+8lBmISOlMmX/Mi9+fUuKHY81m83Bq1nM 4TB5U+IvU7elFWlU+bEbP2AiOG17FvBOlblwgfzmnyo+AGABHGAWS2PZInlFv/Z3i4qkI2zoKs+L OGldBiUHqK21Hpx1O3/7MMX4PUGJquJinU5TmBaxeSEzx7fn1gF4Qiccfd+V4pv3v7Aw2X+pq/+b kmpgrWHRCVjeTyGnPvR4cF412oM5Jn3YC263HtsWmKxWK2OPr3+E+bEnZ5prrTWZM4QW1z/97oHg uIyMjLTk6AOb5twl3Hp0bogVeNCq+kg2KX6ieK+4oaVbota2iiWyU/vaOz9Sms01NTWV5eHjnEx4 PsXgoKQlTbXJopNpwqJ9GSqWjb+goCAzJWrlq85d1xseWl9ZW0vZQk4t7J9LexaP5tc3xpvBUsB/ AEb3EuaPbjuZglHHBPhKo56UpDeXlcZNl6fBuOVhFosFb4HW/ftF1CP4Wk40eq5X/6476/YHxYJ1 6SkxfVh3ulk6F4l5yKMvJLrH52hySUlJcXGxqiDi/ZHOq8MUYzJqGjA9MGk1Go3/fOeNx9/er1Kp YDZU22z4vtWmKJm9L6RVsk1YW5GrKMNNYxYGRielpMTsXOlayTaHFVZVVTU3N8PkG8JulxDRrGOn onp67HZ7sTbmTdlF9cr6NNjwX15c2v+vhTS5bS1ql7eFJvDJmLS0tJTEyP0bZ4sT+MlFCb0XLsA8 wByzGKPcLQSmVVSqwuhj6yT5ejXNZLNoj/Ct32vunHYoMlNSy8q0iN3cEw1UZe/slI7r6ld/k2Kb uDyw0mKBdFPyIoq7wBwOE2p8TPP+mOv/3YJmgP6UMiY5/Gc75QiKPT4vj9VYyc84/bGPF9aCNZnk JjrTqXtHeK/Ik31+bjx5/MOozp4e2EJgPvdoQRLTKxso9Joi51vqU7m62xinb2pqgvTV1sS7e9Ue 3XoiSaUqiDrqM1LSUakVVUfe/S2/jUVkx/GYnPz8vLzspIjjq+cwDbc+0Yhx4V1Ry1xMmLH6aJZS SepRZIJvVDkaE8D/MW+9DWG3y5J42CQmOQyPkpL8bfP7MSDn7sn/RNpep0ihdvNJ8e74uTtis3KV yvz8nJTgA2sgttffubmykZ3kVblht7tXHY7GuoxVW61yrdowqPLq2+lQ+Rl7OPf/XHPndFKAIChA L/n6jSP9zFIivqZmy0bBUJswzz9bKowFm2j3h27+m6dm7cpQlel0OlVR/IpJLiNzR4qJZfNrSidf 79jZWyPS8vC6rJTg+WNcamRPUgXsHKhQ2nr7d3+0IWJ0SWO3/5VFz1meu75egm+a2JPbX/KsO614 fWs2JXhkDhZtEPc3Pv9+gEoizNi8vLz8/Ix1crjJbaP3VdhsULYi9nnglV0lUq51dujT4ciJiSmv Z7kEYS2nHHShmdUhpZSrjR9WBb23L5tScOOZhAdBE1cnQsZhVunz9t4lt/zZnbPj1Xqj0YjGVquV ohwdRqO1uZ0Ns+QUD3R5/v1jsCWkekzQHVij07nv6LZR/kAxeNfRZf1vmnN6cvLSJE01ZeZEZ/TF p71cN+/ZFqmmsgKAKpbS1IgkHcYetcWlNV74cL+6tNRgMKAZXgdMUZR5fIrw/MOZJnAs7dBMfsU7 WIvXwSDRp6/jF2fvycB48ZKK0jAy865QeMWXWtAlcDh5uwtavbImHCY9Xocvjn9g7Ee9nRtiwG5G ux3sqrfEcK+815zDYA5nFNDeKtmpfetzu8xS6kUgViFS4Q9bwpUYi8eowRneZuyiEGj7i7d+/0cq MQDNn/vxyy7WzdtXVFwMWFEhEd6ozT0psi4gtxp9Y5lUo1fyi2uOp9NP0B4KOTV4Eb+1I9kI7IaO ocER+bt7zT+O/9JEYrGyhgjO3sRyK66UpThDO352xzuxSmWRRADFB5c4HYS/fnmPyWyGwUxW3PcQ OzGE3b4V4tgNGhKzQlt0ktvlr6xNBe64yFqxX0tV1Vie1a6u5F0uADHmwwOQfb1E+FKwHCD7rwkT OLSkFes+Jh6E2st1mWkVzF6oOGiGquKksAQNZP/0Kueu4BWKZz9OzFdKU1ES2ILscJcVdDCbZd2p qdGvGhS7/fbNA+gStPQZqa4iHT7FEDrqUzgTnn/vKDSD8KJMl/58bg80g6NWv0a2g65UvHIgMkOt VmMuobd1NQZjDUuKBZ5k7HdtKjKh1ulKZbZAH6qzA6cIHQtS1eMn0FFlqU7tx8o/GWsphTidxW6w J3Eub4gqhpBCB7r7l/6wKSQfD6c6DiZtYmi8xlS0n4NfyHJodiF6CxVBrIYmM6jVVXVNsFTBBK7K XvjgeL5ExAfYbqvljftbnt5aVVeHeUJe9yHsNoTdLieilEFy1UuW8w1im3BqZ18D8rUtmZTKqaen M1DwCc/0C9NqtaWS/QNrATq2zmbQlVolb7yI3e5eH5CKllAdmANonx3uKmvln1ZFWceT5fhGUoDQ e7JIFmaFuQwAgCkoBIejwtfLeeWJt/xh2+CxeDh0jqrgOI+vuHX05iKNBhfJNlNmHOSRDatOqqCZ m20JAIw7InXQaZjnaMOqR6X6PyA3Wxeugr4Fi/76178OYbcfCF3q2I12vWlFhnFC22SSMZ99aIML KRCtDKvADMT6lXXKlVNo/r64rPT0lIyMlJSUuLjouMTEo2tekuf81nJJlgXsc8+RnArgLDyHsiBK 8WbdWAoZ+CqLnyK3u3GkL2zl6uqqnbIdc5XijSS9mVIditjt5ZXxLPlhVVVe5AreKwgLHojhQKL5 Wyg7JSzw/DCX1M/dG5OZlpaamZmampqQEIv+H141lvcf2BMyK2K3GUt9Nm/YsHnzZj+/rbv9A6Ji 07R6I5QMXkSvgE4QsduDU/Zj0Yf9A8uhWTqphwYAMytl79TP75ifXQ4+MYiBNngUOAwFVRDtx1/q tTIOAyzXJ3Cj7ob/8CllZdDMe+VQvSsVr8frjLiEAcLMI2R4hWJ0rJbpQ5ut+qC81XiVYnpyiZ4p ScmeIZzC40KB3QxSuv7SBBcqfG9HWEpCQlJaWmYmuJWUmJJyaKUz2uCWZ/2A9UCGklA+6gem+INv eDJlP8C3bpZCIIy6cI6ab37Sz/DPYDfnGnG+eZP8iJ//dm6aVHaN6guA0A0wSpWwmfd8tHcsuiFO j2GKsaFFOjAZH8VmszF/hfIU7/nG2DL0E8/BdX7OcexHpyAXeD4Ggi8oYLfRgMZorI5wVqwbsywE KwWWGFLgWSFOSbn+IW98L77JOITdLhXi+Xgh2hBSTV4gP+R126i9TReN3f5bKqbJak80W9bIjyDZ x9SyScSggcGAyZMX5QqQHrchB7KDOVamddMqBqkwAeYwVSKACFRWFi+XT/D+VDE/Kjk5NTE1Dcot NTU2NiEh/jBHR7sSLU4tJGO3KxTPLV23bun8WY+6J+lZfCQdzwcUovxRZKRVZWzy0AyJqfSixAQ3 zbAJmgTSF+LrFoYwe82xogpoVhvG5QxlbLWul72BP//tPBJqcIPYAuGFMimI2cifMGZtKn6Ljglp 6Fj5J6h3ns+2tiaex0P5RqjBQKZahb3LEa/uhITiRegh1f7AXzF0f9mxNJhzmPboAH7OjDTJO0d9 tuW6zs+CCfExMTHx8WB1enpySno6XwRvesoHyv3iowsuVxrCbpcl8byO0JAUHgBpYthHlXvETwwu YLQy3AgtiiZ8t+vGJ1ZmSxWCSAaxtlKMEOQLf7Hg8pjJYYoxQTlKKD2qAAuUV1xwjB/28IspgXhC tfrKiAsKMCw+PiE2QRLJ9MTElKSEI9yZsymyRLIky3xkJ9QLi0/odDoCj5IBVrhYjst8YUlwcXEx bkHf4i9uecv24KilESz7dLNFX2ajulHUN3CgKPMIXyl8w5S4BaX0I3fg/KDoMsBu5DlheQI/+6yn pweyAzMAGhLLVm5ywFQhwPdqxSKlzQbxEfcpBqGrFDNSDNUwYjn2odP9WP5og5tyjOAv/gs0hyUy 1Nd1AGNLTJku/yA3JUavYGICAbdJfQha5ZS6l1bEUKXsCPnk+U8Uswpq7JB9PJYKHPDiAng1LKXM 0KUX2f80E8Nux+R9w2GKF07lFlDdSaqFhP5Q6bHz58/TK6BwynUhXvJDVgcWoMMwKsBbKcSanaEz VyTxA1Xvbk+GToBVQLnE0YAQdElJ/lL5SOGoxaHQJxhm+AZXNM6WmNKSgoN3yf8dtZy1gUmGLvGg zSsUo6JUVFG6xEcOIXp6fhCej27gXXgp648c16qQsFu5ZBN+4zFhmUtTwSU2Z4RRrwzIwTMxKIyI sgSwrKRtbdWWFH4I5SeK2XlmFm/J4czgE5UWiK4WFc/p9tbGWHx3luS/tZWfeZS2j7XciH12YRAr jlxRkRO+XOHkyXMxGhM+E5XAY8lCCz/mw/GLLaUKbmLNuxeXRoAh5Nlj5fBkCxDYLU7HNnZLE7xl bkyLLFRRjWOdTrPjfefx7dvG7DDb7d+n9h7Cbt8K8Xy8zn03TRg3AK5WfFTpXvVskIdwAGi3pIuy j2dSoUAQ5MUmBSqo1dlLZNl/3jsWs5HFI6mDufBDq+AKYR9ySUHwYc6s/IYAASdN3ZqD+QydwLHb dSMXR8O+YRS++g23zCInCmwcuxEfyjP6yTfVl6AZUplRVlNhSHvX/WQvFOneSDVV2cAQGuzZU+Rb szbHkVBjdMQW8AcaEiYT58noJWGUkJ/rKEhior4GD/xEIpaJpTqOb7GtC1PhgcyxY4jgMHLZx6lU +ANKAHJNNUOzD8/knY/KV2Lxgh5AB9BJnu2cyn98Y+4joisVryXpnRvuYOCP1us+hN0uVyL4RuFb 586dgxBB0PC5NRpNXsrxN90NSF1Tk92WPlW+8ubGWNhydskmhGIhs5BEGKs5NIDWJeDPhhWUYqmF MLLg59pagzaIZ7b0jVDjlsNRsWHAJCVu9NqGJBauUKXjyZrGLAwmHzvMIckAK+Hx5C8sCIIRSHsB 0nmKEn5MeNziUDLeqGQVCxWrNWcnnFr5vtvR5HUh+egedAhYdDFu6iH6HujywG7kOXHl2G9vxxyG TDH4lhM2R5C+LXGlWM4STyxUXARdqZicYGD7bhz73PKsn00+tslruVKGMayezIouOsG3qh+ctsN/ NTeU/hisqqFSjxBbaAYXdlsehf/iLae2OFXCrc/sqGtpoUKQ/C0so7VUMQQIKP3U4ovr/5TkSrsY 8wkFEqHUQ1rRE9o3hIahdPR0Rh7/xi1xB8o3UkOnnKhmGdXCNuujeMqOTTG6eik3CCUuk1PAMf4H LHUGG93w8Dppl62mXHOS71s9OG2nyJ8TBZUEJN03hkZFFpWbpJCg9VOcAdiERMBwimGgWmYha51d BnYrkwJNi2JdMQaDcmkSuMQAdUkoV5xrQwrRGWhjyhdKn5hONH8851f8tzO3ZBBz0AAG8OBTFJ8S HW5xpHN473M6D/oXUwI6/0v5PCaMPXQ+2Nvp9Lr+Ie8igwEfMTtsmfwRmZlH0J6gq7EsnPfcL6YE sA48xENCfZw8eWl5NC6CY1T0vNoU5bHvVqM/zVP3XHPn9D3HIxPjT62Y7koCM35NPCV8oKwsQ9jt UiGO3ei8G1D59hm38s8695CeEoh9I3bjWaFE2Yc6xfTDk8m/hOnBzrVZLHjLsSVO78ONIzcYHA7o HBG7QavghxAoSpgGjQo5AnbzvjjsNmlDhgd2++V9i5OzswsKCgoLC3Nz09ZNu4U3BkQ1dXVRnRG8 C+pC3JwahEgzOKTOl5akrRTOiRC96pcEHQqeOCrjecd9QwvBAShJcIPYwvIgNTZCbx9f5gxWuOHh tSyC2Wrlbvl/AbutOJGJZ4Lh4ouyjjqrT974xNoCtRrmHAQffKZceaTKqPjURWK3YYqX48stQ9ht CLtdrsT9/zwjLktT0NDAQrmLi/Nyw2cLxQO2J1VUGRLfkj05EHZYNSS2PH8sVVcha42fUiePa6NU dxhyyhRpRSSXZZ/QIrPZXF1dxmMgB6fxq+M8sNvYRSFQU9AGFD1VW2fkW3JjPzoFRQF9i+swG3CL v4Vjty4Ww60PWD+932xL3oFZaDaE3X5QdOliN89y8F99dv7Lv/GFiRKSwFpjR69PLOCTEDKi1Wrj j38oXxgZmK2t0OuhmYE10J4OKWCqW62w/2sp/pnH4930H1vqOztpn4VXWaWgTRjwlNRx33v3KfrQ bybttUpxiaC6ujo37LYskk4tHV/jNER+ophd2tLB084TkeVP2C3Nhd1GBmSoyqWTXyA6cgJCN6qr K202FjuHh/P+Mwuh3NoqpQ7jhUt4DWtKoOSB3fxiSylghtd9hvEv2m/LjiuhMcBzSnJLUUl4iNGo 85GR2e2T95ulmB+om0Nz3cuWSPTriTurqqvBQHw4aBKoNRG7YTgVFYXLZXQxfk0kGSSEFqGs8K3D fJzwhbAbNKoyhkeWPnQgLlNVWAjYzo+VEaMqKsqqq21S6LhDxG6+EeomqUgcpeCjT8yQV0uLmDkK /Iwu9awR4JFonRd6Q1dZyJk1hZ/RWXggFROMAqUokQLZ2HV1lo3ykbhfT9yhKWOU5cJuXsnldiqr TX7CynIXdtsQrSPsBmOP8+SlFTEYDiWn8sBuCaXVtAWQuH/ANMFXKWamlVv4Vx7CbpcQeeSZxMxP CfqIf1lWg6PelXzGo7wFrxRAKaEIYZlKXGHDK05qKJEFGS10Go6FR5ap1soBf7dPOVglhVMCu3nJ P4RWobNdhCYIFVospUtkCPTgTJZdhw5qkbRqpWP4UHEWkwUDkXaWS7lv+br7V+RptdDh0BUs5Ekd L7rsxqxKJJxIKlQ4g/zw/rgMtZLtT3m8qLy8xGJxOsnxOmnjTBeyd6FH3cTpW7LYXUM0Txy36FAW 1Q3hVSlpdDU1Fbyy3m9e2WNkVXKrVReN3QD0CLvxmMlVwXl03pZeROZixr7xssxOjVNpoW8JdvG6 cvyIgb1oq/ykkbsjkrIzMoB8wXCD5CkiPmi1KqyNeG+ntOoRdvtxWm5D2O1yJdJy/++vX1z46r/I gCQBJH+LRqNJDXS5+mEYGEoi+Wo7Y3syHaelbX1eDIjnPxGCokfF6cwQcGhRqvFkrYrhsrw2pBDv Ys4oGXA9MG1PTk6OUlJNJJL4hySS2rJidthWio0s5QBt3JIwklPaVW9sNK+Xe0kADZ2Rsub2NDVb xFsUwtRkihQTSU2dvyv49BZePWrFiUxKyzaE3X44dEljN46bYFe063yvVWxySEm6pPOkPWw+mkww AHIyDvHAXWA3rMspJ1wxhysC8uhgAma+5Aq18qMBZADDEuC1rW8aua1JChsTE8KLVULYdk/SdkUf 2hlXhjUUxjOFFMLAEPfdIJsQTAGRKfZl1PEFV8xMSzGTOSGu827LjmZjgRb7j38DjDRJhH/g4fzc 0zDF8+mVDPVQsUVazQlxcHiIX1WUurJ2bIovp9JIVObJWeHXVsKD+m55ZnuNdI6VSkZCiTkz7mqD uI03YVUihYIDJujSd/flz9ZIDbpK+4AsNNEFLvi+m+nYInkr6uFl5XV1YCY57clc5HtMwG566YNq 41yRUQv3JVDIN31f3CVeUYw6nT0xloVzP9iGqGJ8LzyfMmPTJ8bQ2DkRe6lQckHxs9+/nW5oAIuo ujFBMCLak6UCbZ92WeLjCmqxIjQZV8upD276C4OZeBGUOZl5GA6rNW+K5Kbg2EWnKeOBsO/mlWJw UJEFKngBi+5fxW5esBh5+8T9/SRxv+Z3M09ns5PRlPDhe8s0NYTdvi3itVSo2qNKlbZAqMt27R/n axo/EQsY8TJGlNwDM5O5ozvN0VHZpoYGo0nJY6FvfW5XnZR/jMIDaPbCmCktOsGTQUH26ShcqcZ1 KnNzgoHSX5Byk0ss6VfK3p5fjJifIR0koeMh+EtZjPAoOoIqBSKWreb13UasKpZChiDI+AsFq0re JeKsgMKGsxKBCWVJrqO4C/YyzUB5PPiLKEMUXgFhoYy1eCkd41UVJm9b5BKTYYqx8aV2s1njLevD m5/aZLQz1wr5u7gVV21wlRd5cWlEtTt2Y9tbpcw9QjGNLJbAnMStKcJubKuxIlK093CFlDl9LHyI moLNvG/rgvJF7Ma/LGG3+qI9vOXcnZG5ublaieHoFfFBcuxX4b20tUpV3n60ZtsQdrssicISMLHP 6P2uVWyuk6JfqIQuZFByQ5UV5BzlSRt9QpV6vZJv99/8tK9Jxm6i/uwPuzE3KTQJnbVhURCWuL7Y zUf22f7ifpbSlo63kEhCKUmHRxhqc0gEhcmxG1QKjBny6EKBNDdX8/DLF5eEU8QjOXtbW61+sqEz dlEInlnnyONFcx+EvlYZ2bHlIpe6XnGCJZGj4yFD2O0HQpcuduPVsiiQr07DENMv/+BdZD3TK9Vl w2oLg1+tVp/wcRW72hjOcvoV5AfxY+BXKd6MKWbHvupkItvArArx3Z1QI+1bnZSx282PbG+W1kqP Yl7k2XYeFivXrHTPhX39Q97l0mru9HtI23MCdosmX3FOtOuA/08VH6jrz1A045eyPsEwmQ1QXS0e WrlK8Ua0xiL2n4BnVdFp3z2JQKFYdDj2BHbLqm6BCPNaq6KbnWM3MQZvc2JFt3QohqwseZ/Lumum K7/0ogM5UEr8xBxLqGIr8XvtDt5gyYliOmzFGGvW+7jnub7ugaVaycbAbynkVcRu8nk3c4K/K33d ogAlnRFzph8Xznbd+NAGg3SOr6oykZ9Nu1LxanB2CZ4DjVcnkLEgeP2epMbWVjZbhMoIfjElHpqK sC3trurzDrq73+/ddDK3ub0dnaEwTjoFic/HuNFUGXNwxb1SwGqmvb2hweH/tiv4at7OpFqpogHF ybPhtFZtn3onb/CBfwZtCgvn3dywGzgvRl/809itnNlm7NxcRfw7ruzIdz//0uR5S30Cw1P0UloG /IoA5vd2VHkIu31bxD0PzC1gs5WUlGTGuHyqEo3YE6u/IIXVcYLmoY2q7taahCOrhksTOLkS+kS/ dZpL9pcfVVHlVgp4YBG/tpINU1z5pRcFaGACsX0rrStH65YkExVcI98RNCr1LWKTCxZNWhlKSTZE zdbUbArduSm1giXMh+nCD27c8KAPpB46gQ6gUWxDAPdiKxQ3PbIRlpOUaqDFYk7mVdKgGU7llHq8 iP08P2iDf3I7C3BqyQgKU9vZiTw0A/cKCwtD/LhqYX4ek8mwc4ZLqBf6Z0JeKM6cdtsh1NumuvTh /AM55DsSz+TuiNVDcuncKwZSnr3nLvmWT2hRX+wGQAeGUPI32tyHvqrTHeUPvEoxPUEK06KYSTTj 4fdQHR1tSq5Pr1RMPJbENt1EDckSDuecWLcrvkXS7bQE/GjNtiHsdvkRT1QCiWgtYy7l6+5Zpall Z9ZAlLocK2/w+lddwh6iKitTbZzMLyjm7sum2APxHA2EBVc8sBuddKBykBBJcWMdkJBSl8dvd9Vv nLD0JNY+WD5k3dVKVFdvCN62IbG0Vlriy9d5ORuL2A2vaGmpGQi7tbXZNgrYDUZyeQoPJbr3ZKER UxRrZbHKlVqKsBtMOPR8qEzAD4QuaexG9YaoZFtVriuL1+ItoUqd0WSxKPOTdyx21QRj5xfKLezo lFZ7eNGj/PoViie3BqZXWKy1tVaLyVCYGrZ6FrNib/jdVoN0bovjrJsf2dEimRwe2I0yUTjjCc3m NPfzaB9+nEenoiirCYs7Mpl4bo3x3rH4Ca7odEpfoTTkFYqndofmO5raejo725rqyrUJW+a/5hNU SmGQRxc/JrR8Qux/fnLo6rcelfq/zVhfD2B40oXdXsixMQHsa4Fz5zzrnpAtf0uikRKJ0yYdD4ms UB69Sxjj+Lm7lWW2pra25npHUdqJaUKNlF/c6V3R2AhNSDUaYBvkRiwX+fPB3nQKPKB4IeaBr4zm 2C1GY5LyTNqMpqTXhV99tDeqzGSBdmUpIg0G1/mahzYAbKCHuM5Tjkv0mN/heH1lNXEpLylkxYw/ E5dq2tpgNVWWh3O7aGNsmUeEgJiuAb1NPTpf4U5X3zPJ71B4rlpXWV1ZVVGhKcqMCNo9f4br7PEw xYtZFrbBV6U+LmYgHjtna46mEvixralel3PqLaHL196xqMBgoOnB80wCcKUaa3kMGNhlMUaJqJOO VWL4vIbg+BWxlHeFihoL7GXZ7XALtmLKNqfZ/LPffBCRlpaVlVVUVETJNtGAIlS/T709hN2+LSIT hTwP0rGySrVaHb5HrDEoffd739gZlKQ1VNrr7VazWafJiT7lv+AtV4rFYYrxaZX1LI4oc5/ou5i4 YL+uqqmrt7ejpVGdEThdlP07VpRJWIAlgxWw29ZkN+xGji+IhnheGPT0TL+0gnI720qzVpQUhh1c RVvvW7LsfbDbOqMUqUh2l1S5216qj50qPG22fz7MD1bN0Gbj50klemzj0cTyqpp6NnAj9P/KmZL+ /P32WobdGrazXfD7vXdFFOnNkAilUvnxUtfBPN8INatUkvuxyJPx83arDLWdPT29XW36/NBZolD/ domqspIsMbM+iu+w3zrOVyMlHgHpM/Y/IjwNpl0/2C1cBa3FD9vSqcYzZ5r8p4tf9bHNASmW2obu jo7O1kZjSfL2hW9sivw/9u48rqpq/R84onATh6+WqZmVXzO11HKsvl5v+YPLJfWGY1fLebpazt0c b5mJ4qypKZmZ5pwgg0ziBDIoyCSJguQIOWSpN80R4f6ecx543J1zQI1zWJzN5/1Hr6Jz1n7O3ms/ e621917rMO1tyhtb/61dIrj1lIUbouOTaFcfSU3cHbDuw3c5Pc7MMO5V9N14N6HvphuyNjddRjMj veRMGDd7U2zS0eMnTiQc2LXww/sj/44OnbZGGxZC0k4ETf7S32tf8rHzly799NO5k8eSQtbP7t1z VtI5w6iy5n23B/TdqONmeCj64FrNMxEOr70zxS8sJt2whtSRQ7G71y7+kO8AfhqUZqW+2zeGRQH8 5RnyRivC4mKN65tEh96/Lz96ZQSlOEq55fyl1zLF3vtu/BYGnSMH/O4/RliUXp+F8fTp1NSPitzw zoM+/0SrudR3o7ot/awnWnoX1XfjObTplKRNxB3YIe+3VnLoE3r4CL/cUbDo6unT1P6R+0SdP9pu mCziyBGKau/22c9ZDKXQ3z7ZxW/RRu/f/MD4a7WZl2Rc8076ng/TdzOEl3D/6cHPtidr+278+gYv VbDRu3tRm9Z44Yuww5yy+A6pofzU3YNbyv55xz8+kdIC7RnaP/zKjCxjxBMh8goFtIvC1j54gs2a L39CDSOeDP9wapDpPL9m6CinnT5t2Kuad0mmfxdv8mauNID5yVXKtFvm9ymuXDMVHF4PSDX0qujn bFvQ6yG+8fz8bdGc0umfsr6bYSmo5ONF9t22HuC+G21l/dSCP7/1oWnfrXD33u+7hSy5fzTbvz1i 1uLVQSHhVHnoisA3VfnRLPTd7JF2lTfDFGfGeZy+ntnT4VFUcGhPFZjn0F470/PBX3B4YVlIMj+8 bRhxil0rfTevwFR+yprfs6PMQ/mBKiFltq1zi3zvUswJNVTa9PT4yYU31mo0n5ZinFyIcgjfATTM p5qWtmPNSM33mqyPy+JJ3pISAx549lJmSM/OzsnJmKF5lLjNXzxeb3j/Pw2LmMSkFkyiO7vbAyOn k3qBXywlz1NGdC3Szk5Ap/Y/P/yw79/bmHyHmnY8R/H3yZukvcfzvcjdcOkCHz+wymxxqt/x+HRP wd3JjIj+xX7SwXjJO4r7bui76ZE8kEAX07TQqUWfBAW6TfXlRxYTE+MXDnuimE9WdOgSftzwdky0 diLZhIIOFE/rpF0EZOr6SH4anPJkwOIHtlkM+ZP7bpI9PMZtzMrKogRIzTPaxJkz6dJB+9u4jfwG Lv0v47Nbx6YXNnT+OmotXQtito6Xkv+nff+lX6/zmfsvbReybfd/9m/rMDMgRe7yl9s8UHboo+9G F8G0hICRHR2K8cYQn6PGpTeo4U2nCaXiqOClxX7Doe0/16RnZdHZKs+e0dX8tPFaadJ3+2/h2rWF L92nbV9cMPrZabLfycLXwXgWI37uUe6J/H1KoLxbR4k9dIPXa5bDMXCfEs7LZxtW9QpZ9oD4R3yT YVzPTuZgdHT4a1imoUtise9GLXNq+Rhfzdgsw8rcyuITVu518poItGc2zDe9/aTl6NB5VXDCaePM nDxnJq+iTt3boKUFCcrjoy3HCl8PoZJ5sg5Ka38pKOH/+SYYVtPjGcipzRO2dlqDYn91zZc/TTVO qUR50vC6cdRq12I/32b46uOnTxuG8Q9tkV/9mV8SxUnBaHcUp3o6iNwDpYO487uF3VsWW7rGoElf pRp/CLUq6Qhu+/yDYj7s6PDWct9InhGUl5aTqwB1wKkJzV1dntXzaNJ3EvkM30O8IB1l8s0fF+To LhP9+C3pgluf338nu9cvKZObkelJa83DqNSw7cBRn34bFHXG+HYhz9yC993sjsyDbXhYLieHUw11 3/y+8fJ8xfywWzb84295lINOfNqZa+cMLbYCd/oy6CBVQtocpRTDyhdx66U9MCsojW8Y8ZPb/CJt Yb/y4Ofj3iymZAeHF9ftP8EdH3kosmaLj5M067jxMBqFSnl+yftN5JvVn52aYEy2lEkORqwsfkLu wszw/Sf/V+Rnes/w5ddPKIklJSWtn1d8Pnxr2bZ93xsnZeIVvQ0PMOxZ2qDYMByMj0fyq3zpiVvl TP94Uwyd6XRB4emDZPCN9vbB4M//XHRpbh8F8Xt8htWsYte6F/1J0nrol1nGp9n55cRy22ZD301/ pO9meDwyLWx0sQ2F/+u78ODhw3Qh5qYatR/nvv9qUR+u4PDn4PQzJgs4UkuGO1A8hp+Vtl3O5X9v jKaSeRnZI0cOf/Gv4tssTb7ezcuxJU4qTGEe4zfTX3jKX2MSODbN7f7/4lty9L+MzyRkyP9yH/Ot YbmolNAHjuEYgtySLC8pl9s5i8oOu+678bJuPK06XdqoO+O7duGgt9ubVLkqrXos3LiHrlO8Vhev ksaX2ph9AfMmvvuyaSVt3G3ApK3hh3jBC8NdkjkF983rvb30R+OL+ebNV8kDxkl+DHd8jAPTjb87 lMUdE37xn04fXv9666yC86fPzDC+jtOZy53K6Kgdc//Vx/wGXIduw9ZGHONp3o3LIaUciNoxf+J7 5vF37f/RlrAE7qgaugneBfFXdOi+7wcL7+tp4zeElx7YrbCsZRHHtc0Dfj6cJyXgVlzMzg0fDnAz DcGh7bjPVscalxbi5QN4ahS+b2W4bXckhPfP5rij/DY9T/TBz2SeOh7yVkHAniGHDZNP8nz4vIBU YlzYoslDO7RuaLZRg6d7LjppvM1Hx5r2quFhyPiIRVP6mTVRX+jy7rh1/ob5JHlxE+2vXhJ29JKl G6zcw+URAz5eVIsCNi0fP7hLETdMW3ft9f4Cn00xyYcpk/MP4ZfO6Agm7Ns6cdBfzb7SZtQnPvsO HaI2oaxhR8cxOcy78CB2jcjK5kmJ6UAY3rI8tkMiXxxypHC94DN+3gXtsn98GsZPUxSsRZgZ0r2w qOAjhiXXd33zgFnTa7T56MAPP8l0mphn0u7wswGUMHl+G378YP/+/bt27dq4ev7o/m89a/nIt+76 zgeLv9p6KD1DljPLMo5o0XHZHbh63HvmHaDWo6f7RBXeseUz1zDWkewrj4Qv3ZnJc6tyG0B7R5tX 5/T9elafv7YwKbdx684fzfwm/phhNSLjhL1p3j0L3gyt9edZ6ZrVOjhH8SxG8Qe3vatZne2DVQfp u3RmGV7B2x8876N3TTdDmaHP2G/89vGMT4YlS+J2zps8qOXvP+T8nPtnyw2rLNHeOGPE16Co0LUW 98n7//4iIi6O9tsJ4wPkPKUA7UzaS1E7Vr77t/raT3f/59ztgWtkd3lvP0h5zHDH8Mj9HDVveyLt B3kDRZ794IG1lOS9Cya9Z56UXu3U7wu/g7wkHG3dsB+S91J6NLuINOr0j9FfbgrjR6blJmm5bbCh 76Y/2selDKd5auq2bxYMfPt1kzOh8stvz1jpS80tHomiHMiXfjqU/mvnmqcpp0bthvzri/jME4bX 5UIKZq6r5PBO2PeGpZTkwQC6Csu5PHe74dGj80YnjePtgevmvutuelK+0PKtcZ98GZmUbnjz9+TJ rKyUmYVPdPadvYMHyamtZUx9x70Ln4zo+ak/v/RqmDPNMNibNbfwfb3uH39H26KUm7x/S/+O9zfk 3OCtGStWTen7ovzF9R/TdydlaucrK7epoIyw374bT6/B06rz7GF0meZFruOiI4MDAgJDQuifEZEx 9HeeB4OqNJ2n9Hm6aNI5SJdmqrfGeULidoWFhYSEhIXt2rc/7ojx87wMB5+nvNgxnRo8rlvUdFvc AqGtcFsllQI5kMJ3yfmGhTT76ZpLZxNPisLXcTqn6O8cFV3fjQsWRO7c4U+/Ynd4+L7oA8eOn5RP Sq/EcNIlJyckHKD4g4ODQ0Mj9kTGHC5s81O0PG0jvxRGjQSZccJi35OfuuEZUahwHgjSvujEs5rw z+TlhGhDlMQMu/3AvtCAgB2hEbTPQyP2Jqak0Bb5OT1u8MttO75vZZgdMSFuf1wyL3TOz+Nx547v JfHNJl41gD7Pj1NKr4daFJRp6djxdNaxsbE8yzf9nRc84gleqCjaaTzMnpKSuDciItggbOeeyEPJ yXxXi/Y5zw9AJfPMnPRHHh+z2EmXX8FTUdGHaaMUycGDsRFhwQF+fv47dvj7+wYEBIfv2kf9BZ66 jfYnT0hinAnVMI3V/SN4KDo8KIh2HX0tJHz3wUOHeMYA3vlXjXjAgecQ4FEIOii8jgyvcMfLbvIi vDzlC/3wM8Y5WHi6PM7qsgAfT63JDcKU4PvvipJX3uzad9Cgfr3fevn3neN6XZafKqz/pZC60Xez Lj55te8I8wLu8fHxhrngIyP37t0VErh92+bN27Zv9/U1rHRNtZFOK8owdI5T9aPayG+TcQODH/M2 zFwdGR64bdv2oBB/X9/AkPC4+HjKYDxSwRWeazufhoRqnUkbQPsQBWdyOqHouO/fF0YnBQkJCY+M PsDnBXcheSlq+s80I57wh/uD/PKXtpdKX6QcJachL4HEA0G0IfoFlD2N29kREr7rQEJCSmH6ok1w /qfvJibG74kI2b49KMDvu+1B4RQeFcsF8gyWsksNa77sjwjy9eV94r8jNNo40bfccaM46cfyM+Qc IWWJfREhBkEh+2INa4LQjqW0Rv9CwdCpzXfKKBjOfkeNr/TyswHa3cizfXLSM0ayPzTAjw5o0Pbt AcFhUbEHDdPKGUvTZgkqLTn5EF1EAgMDaSfsCN25PzaWKgYdetrDsgwE+m7ou+mJyXAWj70Y085u Om19/f39tm6lSzKdg3ym8+u0/MSjfN6wENXO0G2GBGiwNyqGTk9u2vH1lzIev/hA/8mL9lIGpkI4 XfB8s7zuG89XxmPUxiczE6Mjd1KDyt94Tu6OjE4wpiZeBpcC4NTEk2bTSc0r3vJCvbzUJr9twec7 Fc45h1/b4f/F2ZiXQaFy9u/eTRkofPc+WTAlIiSQdgRlX+66csMDfbeywN77bjwdK18Eqeryytdc mfkFAV52kOst3/rhNch4mlY+uegc5Dn2qZLT56kxz8uf8d1nnhySTiheArWYSxi3QLj7RvFQU4e+ wlPH0995qS+JlvsL/OQbr5rKUUmTm6ey50dleH0BPjH5k5JA6Kznn8y/l/6TW1n8WDWhbfHaBPRP 2g9yrTffn3xPjQeF+CdTeOY/mTOeLFhGu4u7PBywrLDAfS5Z90SWi+Iv8oyUhN+D48/wSlK8H3i4 nn8IP2/Ji0HwgeN+Fs8Hrt1R3BPkAnmKfr4zZRIkv0DHM1VyNubHCWhztFH6I+/qonaULE4hhXNP k0rm6bUJJ0Y+ItnGKShlEQEOzOIR5F9BqZUzOS/3ySuD8+OOhOshr8ony4ny8eLWNUXFI2xcdfl2 My8yLvuQCuF7KBTA2gkF9ySdn3170Vr/8PDwXbt27TMK3LSkW8uCvpujg1vw0bOXC58ZRt/NHnGO 4iXVONUY3qL6/ntqhFDnIr4QXbip5UDXa6rPclpRreOGgSRP/i59LMmI/oVqPp1i3EORfMUphaeZ pW9xZtC+PyWPdFIt5ZOCNsrTYlOZFBtHkml8j5XrMydYzgN865xqOz/Po12TjjtHdIpRgTxQQ+Xz nEj8dW4+UduMFyKRDfE5yMNfvEYAnZ4UD/9SnjyfW1xUFI+K8LJQlAq4R6ndLbQJLpOnh+UVGSSF yngUL0/AzbkjRrQzadMcNp/OnG1oP5wrnEJEkjNnZhlY44dGKBL6XRQG/ZP+nQeFOAyeSlR2OP0i nhZJYpYRJM6opXPDvWxC302XpM2jPQ05GfJikbwAE8/SzEMucjnmyczprOFhZP4wJ0wqilIBfYWf TOZRIO10r5yaeDVbaaNSGPR3HqOWURqTwjONywTztZ7OYh7POW18G4ibW7JiJqd3btByo4gHezk5 UCGSRrh9yFuU5ZOIdnEWHvmXvI2+m3L223djsjwH1SjuMfHNMqqKfOOMb9lQZZbVtPmyzicg9yD4 K9xo59kg+QzltY34yTS+0/3A932kVc+vbvGpxFVdFvLmM5fLlKWxGb8RxlHx4LBExV08XkOEP8n3 UCjn0FnMrXqejILbErzaGrfV+aYVl8CX4KJ2JregzMMz+cnayXW5e8i9Hg5YehAcsPaKL/0+2T8c knTupG3Ju51/iIyl8wLi3DGRjfJ25bfLYZKVVugv5kFyt5GDlB3FzxtYjNzk52v3lfT7uDeUY8QP LnL3nKKVmsANS64kxR9BrrTyK7iGa+shl8OVnyOXxdZlWa5rRtpqxvtQNn3u/NHJhQ+J1H/nc+61 xcTE8Mi/4Zm67XOeLei7FSwOaPIaoI2g72YjkoW4S0XnAlVXXjHt/kzUxnu43CTg8Q2udZKm5Lt0 QefXdfnFTL4pxkNSsjylzEv/s5EMjJiskikphcciOKqThXiRES6Zu5Cc8GUIiIeJZOkTfiqDbzLK mAwnUk7vsiF+Nt58Q9y74fuGJr+UPs+323hoi9dz5JEi+iLfE9TuFvquDJ3Jyav9vXIUuHtLX+c0 wv1HHuDiYHiyOA7PfHzJ5OByJPzkJy8FImFzXuW8Z7LD+cOyH7jVV2ovupZN6LvpkjbtaE/zH4z4 lNGeBXIN5U4QL0fFydPkrOHBfz5b6Yzj4VMqga/p3GE0P5fJA7MrFUUlSzag/+T1vjkBciEcHheu zd6SpvhbvGl+cZ4H+Xk4V/CDB9pUUM7HcMoOe++7/dd4teILFldLfiqSB0L5Gi29Nu1yZtyD404W f0U+L4tWS3+B8R+LH3CQwrmHpf2KtCh40yZlym2poqLiU97kk3wHR/tJ7olo4+dt8UktK3EXE7/F 8Mx/stx+4myj3e18G1ECNvmu+f4xOTpSLJMPyIGWHy4dQJPfrv28xR1lEqR2R8lGHziyZLIHOBjp /WlrINcok59pEph0sor6FSb7xOQHcvCyS01+kexn6TlKDqc22+ZJzbk5Ua3ZiI1he6njRg0MHnuM jd3/+YSCWfYMi8ElGaby4+k3bd2QQ9/NRrjeykMC3AniNsBPhbixQX/UDuBo756bfFcaCdRg4GEK OXOlvvE5oq3eFjMDnxQ8HMErGPJdNm6ucI9DuoScBMwTjnmSlxQhXzf/+SYb4oYWb4XHf+SX8p6R YSU5s2RghMdzeHYgk92oXVjTZE9eLcRDbTxQIzlEbtkXsxu1lxhuBFqMRDKSPA0iO1yagtx11Y6t lecGG/puelXU+cKnjIy7mlx2taOmMiqlPWtkBFUSlHmukJSoPR+Lyq78JBUHw805Hnu5WUibciWL anOj9n9JYJxVtPcp+HkzE0gFZY0O+m5MLoXSL+DmazHVTC5zuRrmvTw5W/k/Hz4e+ZbFUIsqU6KS wPjfLXaCpB9UTPwm23qYn2Dyqx/mw9JZkIAf2PHhL1r8WDEBmPSCTX67xe0WtaPu/X518kf61eY/ RMrXdqC0h6Oo7xbVk7W4FfPwtMHnmzE59Nq/80Nl1EqP2fS7GS/f6jfq07lzlyyZN3XswPaaSR5q tPj3oYwMfsUGfTcdyNOMI2mv5ny553VmtYMn2lonFZ6v+9KbkIGvPLOxMqnkFms4y//96BZHxUyC kQC0J475WaMtTbt1k4EdbRNIuyHtBcX8l8pGtaeVyYdlT8qmizoK/BUmPTWLAy+PtBu1v84kEpOw uTFpcT8UlcHKD/Td9E2bKEzOAovpRXKaxTRlMoJqcYxaelIWz0dtdjU5ebXZQNuq0eYi7aCuxf+l TSNSjvQHzfGPKibnQCnTTd/NhD5ql939CrsL2Bb+WDunlFtH+ZrJ/c6cOfH1lOJnCjdMb75hb/IP P/wgs4Wj76YDJn18uY6bDFgV1UEw+WIxY1wmQwePFJV5MEUpvqiivpVnpqiPaZtMxf9S2S0PORxk MYwH/uqH2Y0WIzH/evG7ovgNlQfou+mexTO9mBxo/vmHSVPmX/8D5+PDJISH3672hxSjqP0ASui1 7wYAxcsrXK/54sWLJ06c2Ov75dBuHUz7bA4OTv/7l9GfLt+TkJSRkZGTkyPTb9o6h6PvVvr+8NW5 nFzTi2omFfN5W4f0kMpOJHYKfbdy5VEzYTlJgFB22K7vVqFCBSuWCQDWla9Z7uH8+fO82MGhg5Gh AYZ54gn9I2TX3oSkJPNppkrhUrVo0SLr9t1KWA4AlFuHDh2ybt+thOUAQHnm5ORk9b7bO++8w9np XhHzGQJAWZBfuMANT5l19uxZ7YIF5msWyPzApRDb7NmzOY0kJyeXpJxly5ZxOVFRUdaKDQDKlejo aE4jn3/+eUnKSU1N5XK8vLysFRsAlCvUcuM00rNnTysWO2DAAC6WGoRWLBYArItvn+VqFizgxSl4 pQP6Jy9bIIspWJwe0EamTp3KaeTYsWMlKWf16tVcTnBwsLViA4ByJSwsjNPIqlWrSlJOZmYmlzNp 0iRrxQYA5Qq11jiN9OvXz4rFzpw5k4uNiYmxYrEAYAt5minpeLWC/xTiWcplfuNSeM1NdOnShR+9 pj5jScqJjIzkdOTt7W2t2ACgXJk7dy6nkb1795akHMqljo6OVE6nTp2sFRsAlCtxcXGcjmbMmGHF YmWEasmSJVYsFgBsRKaZyv39Oney/l1p9to4ntq1a1MOadGiRQmLou4np6MePXpYJTYAKG969erF aeTq1aslLOqVV16hcmrVqoXZLQDgD1i6dCmno5CQECsWe+nSJS72vffes2KxAGBr5hMFK5kZODs7 m3PI0KFDS15akyZNqKj69euXvCgAKIeeffZZyiEvvPBCyYsaPnw4J7czZ86UvDQAKG/69evHOeTi xYvWLZkTXd26de/evWvdkgFA99asWcOpycfHp+SlSaLLzMwseWkAUK5kZWVZcTh61apVXNrq1atL XhoAlCu5ubn16tWz0XD02LFjOTtt27bN6oUDgI7l5+e3atWKE8jZs2dLXqCvry+XNmbMmJKXBgDl yrhx4ziBbN26teSl5eTkVKhQgUp75ZVX8NgkADwSPz8/TkejRo2yeuHHjx/nwt944w2rFw4AOnbg wAHrvqF29+5dHqeqUqXKtWvXrFImAJQH169fr1q1KmWPp556ylrPEcnbc7GxsVYpEADKiY4dO3L2 yMjIsEX5Hh4eXH5iYqItygcAXZKGTWRkpLXKnDVrFpe5ePFia5UJALon0wLMnDnTWmXu37+fy+ze vbu1ygQA3UtOTubU4e7ubqNNhISE8CZatGhx584dG20FAPQkKCiI80azZs2s+EDRTz/95OTkRMW6 uLicPn3aWsUCgI6dOXOmSpUqlDcqVap04cIFaxVLmY3aRZzoAgICrFUsAOgY9aR4llpCLSUbbYWy U+fOnXkrH3/8sY22AgC68csvv/DSANa96ca8vb255I4dO+bl5Vm3cADQGcoSrq6unDRmzZpl3cLl 1tuTTz75888/W7dwANCf6dOnc9Lw8PCw6auy586dq169uoNxgd3o6GjbbQgA7N29e/e6d+/OqWns 2LFWLz83N7ddu3Zc/rx586xePgDoycKFCzldtG3blrKH1csfP348l9+1a1fKflYvHwB0IzY2luc4 qlatWk5Ojq03t3HjRs5OLi4ucXFxtt4cANgjaroMGDCAc0WjRo1u3Lhhi61kZGQ4OzvzVr744gtb bAIAdMDHx4cThZOT07Fjx2yxiZs3bzZu3Ji30rdvX3TfAMCigwcP8sPbZP369aWwxfz8/JEjR6L7 BgBF0XbcqlevnpKSYrttbdiwwaEQum8AYE46bmTdunW229Dhw4dr1KiB7hsAFEXbcRs+fHipLSyS l5c3YsQI3u5jjz22YsUKvGwCACw7O9vd3V06bqUwLS01xqRhNmrUqN9++83WWwQAu0DZYMyYMZIf 1qxZY+stJicnS/fNzc3NKitaAoAOUDdt5cqV1G/i/DBs2LBS7j1pu2+coM6cOVOaAQBAWUN5iZpG vHZSqXXcmLb71rBhw5iYmNLZLgCUWbGxsc8//3xpdtyYtvtWpUqVr7/+Gmt2A5RzZ8+epb6SpKPS 77gx2uiCBQt4mm5SuXLlDz744OjRo6UfCQCodfv27Q0bNsjMIaR169alnA1CQ0Pr1KkjAXTr1m3P nj1oMgGUN3TW7927VyZKIpQZgoODSzOGjIyMNm3aSABt27Zdv3495cnSjAEAyoJjx46NGjWKekmc DSpVqjRv3jy1zytS84ySkoOGq6vrypUrExMTkaYA9O3ChQs7duyYNGnSk08+KRmgYsWKXl5ed+/e Lf14Ll++3LdvX206atq06Zw5c/bt2/frr7+WfjwAUGroHI+MjJw7dy6d9dok8N577/3yyy+lH09u bu6sWbMoH0oktWrVmjhxIuXM8+fPl348AFBq7ty5Q/0gHx8f7b020qZNmzJyk4sS1OLFi5955hmH 36OuZatWrTw8PLp169YDAHShe/fuf//7311dXevVq+dgxtPTMzU1VW1GCgoKMhlQYo0bN3Z3d6cI Ve9CALAaOqPpvG7SpIn5KU/NJOUrZaelpXXt2tU8NsqflEW7dOlCGVX1LgQA66D+DvV6WrduTT0g k1O+fv36ixYtssXqJCVx7949SpImHUwAKA9q1qw5adKk06dPq85D9yUkJPTv3988fwKAvlWsWLFf v37x8fGqk9B9lBsnT55MeVL1vgGA0ubq6kr9o7LWazPx448/UpDTpk1zd3evU6eOi4sLLz8HAPrg 5ORUvXr1F198ccCAAcuXLz948OCtW7dUJx7Lrl69unv37jlz5vTo0eO5556rWrWq9hEmALB3dEbT eU1nN53j3t7edL7TWa868Vh2+/Zt6lFSzhw4cCDlT8qiMmMAAOgA9Xeo10N9H+oBUT/I39+/FNbd BgAA+8Ir3Hl5eakOBOyPq6sr9X1OnTqlOhAAAAAAAJ3Lz89/6aWXqO9WrVq1K1euqA4H7El8fDyP FQ8cOFB1LAAAAAAAOufv7y9Pa0ydOlV1OGBP3n77bXnOJyMjQ3U4AAAAAAB61rp1a+m7Va5c+eLF i6ojAvuQlpamfU2jV69eqiMCAAAAANCtnTt3mrwoPXbsWNVBgX3o3bu3SeVJSUlRHRQAAAAAgD51 6NDBpPnt5OSUnZ2tOi4o644fP24+Q1rnzp1VxwUAAAAAoEPR0dEW5ygeOnSo6tCgrBs8eLDFyhMb G6s6NAAAAAAAvfHw8LDY/HZ0dMzKylIdHZRdZ8+eLWqVwzfffFN1dAAAAAAAupKUlGSx7c369Omj OkAou0aPHl1M5YmIiFAdIAAAAACAfvTo0aOY5jdJS0tTHSOURRcvXnR2di6m5rRt21Z1jAAAAAAA OnH06NHiO27E09NTdZhQFk2aNOmBlScgIEB1mAAAAAAAetCvX78HNr9JfHy86kihbLly5UqVKlUe WHOaNWuWl5enOlgAAAAAAPt26tSpChUqSDO7cuXK8u+PP/64tgXu5uamOlgoW2bMmKGtITVq1JB/ r127tvZ/bdy4UXWwAAAAAAD2bcSIEdy6fuyxx6ZMmRIWFibt7fbt26enp/ft21c6d3v37lUdL5QV 169fr1mzJleMJk2abNu2bciQIVJ5Vq1atWXLlubNm/N/NmzYMDc3V3XIAAAAAAD26ty5c05OTpUq VRozZsyFCxfoL/Hx8dL8bteuHX/sxIkTw4cPp4+99tprSuOFMmTBggVUSZ577rl169bdu3fvv5px AOLj40N/yc/PDwoKevXVV7k3pzpkAAAAAAB7NXHixCFDhpw9e1b+ol0soFWrVtoP5+TkjBs3Drfe gNy6dYuqx4oVK+7cuSN/HDVqlFSe5cuXaz+/Z8+e/v373759u9QjBQAAAADQgx9//NHkL2lpadL8 btGihflX8vPzSyU0KNOuXLly8+ZNkz+OHz9eKs+SJUvMv4XKAwAAAABgLdr1Apo2bao6HLAnH330 kVSe+fPnqw4HAAAAAEDPjh8/Ls3vRo0aqQ4H7MmUKVOk8nh7e6sOBwAAAABAz06ePCnN7wYNGqgO B+zJxx9/LJVn5syZqsMBAAAAANCz7OxsaX7Xr19fdThgT7TLvU2fPl11OAAAAAAAenb+/Hlpftet W1d1OGBPZs+eLZVn2rRpqsMBAAAAANCzS5cuSfP7iSeeUB0O2JN58+ZJ5Zk4caLqcAAAAAAA9OzK lSvS/K5evbrqcMCeLFq0SCrPhAkTVIcDAAAAAKBn165dk+a3i4uL6nDAnixdulQqz5gxY1SHAwAA AACgZ7du3ZLmt7Ozs+pwwJ6sWLFCKs/777+vOhwAAAAAAD3Lzc2V5rejo6PqcMCerFq1SirP8OHD VYcDAAAAAKBn+fn5Dhr0n6ojArvxzTffSM0ZNGiQ6nAAAAAAAHSuQoUK0gLPzc1VHQ7YjfXr10vN 6devn+pwAAAAAAB0zsnJSVrgt27dUh0O2I3NmzdLzenTp4/qcAAAAAAAdM7FxUVa4NevX1cdDtiN bdu2Sc3p1auX6nAAAAAAAHSuevXq0gK/evWq6nDAbvj7+0vN6datm+pwAAAAAAB07oknnpAW+KVL l1SHA3YjODhYak6XLl1UhwMAAAAAoHN16tSRFvj58+dVhwN2Izw8XGqOh4eH6nAAAAAAAHTu6aef lhZ4dna26nDAbuzevVtqjpubm+pwAAAAAAB0rkGDBtICP3XqlOpwwG5ERkZKzXnzzTdVhwMAAAAA oHONGjWSFnhWVpbqcMBuxMTESM1p37696nAAAAAAAHSuadOm0gI/evSo6nDAbsTHx0vNadeunepw AAAAAAB0rnnz5tICT0tLUx0O2I2kpCSpOa1atVIdDgAAAACAzlGrW1rgycnJqsMBu3H48GGpOS1a tFAdDgAAAACAzrVr105a4AkJCarDAbuRnp4uNefFF19UHQ4AAAAAgM61b99eWuBxcXGqwwG7kZmZ KTXnhRdeUB0OAAAAAIDOvfHGG9ICj4qKUh0O2I0TJ05IzWnQoIHqcAAAAAAAdM7V1VVa4Hv27FEd DtiNs2fPSs2pX7++6nAAAAAAAHTOw8NDWuA7d+5UHQ7YjXPnzknNqVu3rupwAAAAAAB0rkuXLtIC DwkJUR0O2I2ffvpJak6tWrVUhwMAAAAAoHNdu3aVFnhgYKDqcMBuXL58WWpOjRo1VIcDAAAAAKBz PXv2lBa4r6+v6nDAbvz6669Sc1xcXFSHAwAAAACgc71795YW+JYtW1SHA3bj5s2bUnOcnZ1VhwMA AAAAoHP9+vWTFviGDRtUhwN24+7du1JzHB0dVYcDAAAAAKBzgwYNkhb42rVrVYcDdiMvL89BIz8/ X3VEAAAAAAB6NmzYMGl+r169WnU4YE+0fbd79+6pDgcAAAAAQM9Gjhwpze+VK1eqDgfsSaVKlaTy 3Lp1S3U4AAAAAAB6NmbMGGl+L1u2THU4YE8qV64slef69euqwwEAAAAA0LMJEyZI83vx4sWqwwF7 Uq1aNak8V69eVR0OAAAAAICeTZw4UZrf8+fPVx0O2JPHH39cKs/PP/+sOhwAAAAAAD2bOnWqNL+9 vb1VhwP2pHbt2lJ5Lly4oDocAAAAAAA9++STT6T5/dlnn6kOB+xJvXr1pPJkZ2erDgcAAAAAQM9m zpwpzW/qx6kOB+zJc889J5Xn1KlTqsMBAAAAANAzb29vaX5PnTpVdThgT55//nmpPFlZWarDAQAA AADQs/nz50vze+LEiarDAXvSpEkTqTzHjh1THQ4AAAAAgJ4tXrxYmt/jx49XHQ7Yk2bNmknlSUtL Ux0OAAAAAICeLV++XJrfo0ePVh0O2JOWLVtK5UlOTlYdDgAAAACAnvn4+Ejze+TIkarDAXvStm1b qTwJCQmqwwEAAAAA0LPVq1dL83vYsGGqwwF78vrrr0vliYuLUx0OAAAAAICerV27VprfAwcOVB0O 2JMOHTpI5YmKilIdDgAAAACAnm3cuFGa33379lUdDtgTV1dXqTx79uxRHQ4AAAAAgJ5t3bpVmt+9 e/dWHQ7YE3d3d6k8O3fuVB0OAAAAAICe+fn5SfO7Z8+eqsMBe9K5c2epPCEhIarDAQAAAADQs8DA QGl+e3p6qg4H7AlVGKk8AQEBqsMBAAAAANCz0NBQaX537txZdThgT3r27CmVx9fXV3U4AAAAAAAP JT8///bt27/++ut/7Iq/v780vzt27Kg6nEd27dq1u3fvqj74JZWXl3fjxg3V+/KRde/eXSrPmjVr VIfzyGif055XffABAAAAwOao1ZeUlOTj4zNkyJAWLVo4Ojo6gCKVK1fu0KHDhAkTNm3adOrUKdVV 48Gojx8eHu7l5eXp6fnUU0+p3n/l2tNPP92tW7fZs2dHRERcv35dddUAAAAAAGuihveyZcsaN26s utUJlrm5uQUGBt67d091TbEgPT39/fffp86m6p0EFlSpUmXMmDGZmZmqqwkAAAAAlNR//vOfcePG ubi4mDT5ateu3alTp759+w4ZMmSYXfH09KxYsaKTk9Of/vSnZ555RnU4j2zw4MF9+vTp0KGDeW/o 2WefXblyZdl5KC4hIUG7IJp46aWXevbsOWDAgKFDh6renY+madOmlSpV4srTsWNH1eE8GtrbtM9p z9OvMD8o7u7uKSkpqqsMAAAAAPxBERERTz/9tLTuqMk6cODAgICAnJyc/Px81dGVd/fu3UtPT1+z Zg11IrSNcPpP5U9R3r59e+rUqSb9Si8vr+joaDykVxZcu3YtKipqxowZ9erVk2Pk6OhIf9HB25QA AAAA5crNmzdHjBghjbqnnnpqzpw5P//8s+q4wDJ+LtHZ2ZmPl4uLy1dffaUqmLS0tObNm2v7kmX2 eU7Izc318/Pr0KGDHK+WLVsePXpUdVwAAAAA8FBu3Ljh5uYmbbnhw4dfu3ZNdVDwYJmZma+99poc uM8++6z0Y0hISKhatSoHULNmzS1btuAWbdlHx2jdunXVqlWTA5eamqo6KAAAAAB4AG3HrW7duuHh 4aojgkeQm5s7d+5cmQK0lLtv2o5bly5dzp8/X5pbhxLKyclxd3dH9w0AAADALty5c0c6bs8884zy 16bgjwkMDKxYsSIfR29v79LZaHJysnTcBg8eXHamTIGHR33/d999V7pvR44cUR0RAAAAAFg2ffp0 dNz0Qdt9i4mJsfXmbty40ahRI3TcdEDbfWvevPnt27dVRwQAAAAAppKSkipUqEANtmrVqp08eVJ1 OFBSmzdv5hZ4w4YNf/vtN5tua/z48bytHj16oONm76j71qlTJz6g06ZNUx0OAAAAAPzO7du3X3rp JW6tffvtt6rDAeuQGyijR4+23Vb279/PW3nyyScxGak+nD9/vkaNGnxYExISVIcDAAAAAPctX76c 22menp6YGFA3Ll++XKdOHT6yx48ft8UmqLa0atWKNxEYGGiLTYASmzZt4sPavn171bEAAAAAQIG8 vLzGjRtTI61SpUrnzp1THQ5Ykzw5OXbsWFuUHxcXx+V37drVFuWDKtQrl2knMeckAAAAQBmxa9cu bqENGDBAdSxgZXfv3q1Xrx4d3KpVq9pinT55LDMqKsrqhYNaoaGhfHCHDh2qOhYAAAAAMPD09OQW WmJioupYwPq8vLz4+K5YscK6JV+4cIHXkmvWrBketdWfvLy8hg0b0vF1dna+fPmy6nAAAAAAyrs7 d+44OTlR86xNmzaqYwGbuHjxIs8g2rlzZ+uW/O2339qoVwhlxMKFC/kQ+/r6qo4FAAAAoLxLSUnh ttnkyZNVxwK28vLLL/M8kNa9OzZmzBiuPJmZmVYsFsoO5AcAAACAsuOrr77CuLruDR06lI9ydna2 FYt9/fXX+U06rOmmV3fv3uX78m5ubqpjAQAAACjvhg8fzq36M2fOqI4FbOXLL7/ko7x9+3ZrlUmt emdnZyqzY8eO1ioTyqBXX32VjnK1atXQQwcAAABQy83NjRpmlStXxlwTOhYTE8N9t4ULF1qrzJyc nFJY+BuUGzJkCB9oTFcCAAAAoFaHDh2oVVa7dm3VgYANpaamcvN71qxZ1irzhx/+P3t3Hh5Vke9/ vEFURsUB3PghLowL4AaoAw7qFcUMV3HUcXB0kMHB5aIiDAjIEpYIwiAILlxQQJRVlkCALEAgCQSy h+whpLOQPSQBkpCFBGT5fdNFF03SoFdDziF5v/7wSU5Xn/7Spx6f+qTOqUpV5xw3blx9nRMmNHz4 cHWh2fwRAADAWH/84x9lVHbrrbcaXQguoaSkJDX8njRpUn2dc9++feqckydPrq9zwoRGjx6tLvSB AweMrgUAAKBJU9mtQ4cORheCS2j//v2XLrtNmTKlvs4JExozZgzZDQAAwAxMm91O25yyOW138ca1 2jdktSZHdsOvRnYDAAAwCXNmN53CTp48+dNPP8l/VSK7eHvHxhdv39SQ3fCrkd0AAABMwmzZTU+f SQo7fvx4VVXVsWPHqqurT5w4IaHMaRxT7aWBNJPG8hZ5o7yd+KY1kezmOPd60uYXztviIshuAAAA JmHC7KaCmESwsrKy0tLSkpKSo0ePVlZWSjSrG9/kVzko7aWBNCuxkTdKiFNxz6h/iKk0+uymopma eJXrLuG92k5+liNqQpYQ9yuQ3QAAAEzChNlNhtkS3CSIHcyK3uLh4enpuWmTz/7sEklnMgivm92k vSQ1iWwpkf4bNkjz9Vt9wwtLS+WgvGTUP8RUGnF2c5yllSteUVGhIn+xncryclxPyF5oAhdOkd0A AABMwmzZTcbhMsAuLy8vKiqK8xlvsZvmmSID8urqamlQt31N0Dt40MPtftW4maXX9tRCGbHLS4zS zzTS7KYfclSpTfrA4YLU3Vvc5838ZNSoUR/VGD9hyox5S5b7BkYeyCuUHOc4IUvH+IXIbgAAACZh tuwmg2oJaBLTcnNzwzzPZbfpnvGHDh2SgXet2yDl16qqKhmWZ2VlrZvioho3tzzrm5RTUlIiL9XK ek1To8xuarpNTdEW5UZ9N3Ww5aJeGTx+tVdo/pEjlZWVEve4n/YXIrsBAACYhDmzm2SxzMzM3e5j 9MD7kw1RBQUFMuqum90k0EmsS01NXen6jD27Pe0Tn3H48GGym9LIspt+KFL6g3SVUPdP77l4bHPQ 7pmvcoqL1ewbU2+/BNkNAADAJEyY3SRwSexKT08PWDNKD7nd3CMOHjxYUVFRN7vJAL6wsDA5OXnZ uKd1dvOKSSsqKpIh+ilnLrRgheNChY6N67ap2+xC7c2gkWU3NeMm1/3IkdwfXHvXyWd3/fmFgW8N GTL4jb+94PL4Hee/dkP3/6QUFKj7acn1vwTZDQAAwCRMmN3UPFpaWprfj+ey25R14fn5+eXl5bWW H5FfJdAVFBRIPPlh7NlhfDNL783RKRLo5KUTNmrhwSobteNArU0E9JIXaq+BKju9uoVOfHojuRMO 9MKG5tyeoDFlN3WZpJMUFxetGNX1/GT28OiZS7YFBAYHB4fYBQcHeK7/4ZPRg7uezW7T9+flOX12 Ek6R3QAAAEzCnNmtqKgoNTV1x48j9aB88tqwvLy8srIyp9nt4MGDSUlJSz5+Sme3TVFWOajWpqis rHRce1B+kAyo16zQ24Gp7eTkJbUxgV6iUG1PoBKcSm3yqxyUzy23U+cX6hPV41TmiW+NLLupJyLj fVwdY1uX58Zt2rk7PDw8JiYmMTFxv430Cvk5Li5ODsbGBq/5csRzg75JLyg4evSoym4XUXdytu58 64U2HdDNnL6kXj19Pt0PNZP8BYDsBgAAYBKNOLtJ+8OHD0v+OnToUH5+fur+hHCbfdb0wsKaVQfl jWqaTC15IRFM2tecKiZSmoWFBUVEJclJ5O16gzmV2mqWNDx8WE5SYCNvyc9Pj4uKiorbl1tQcOTI EXVm80zrNJrsJllGEnfNTGth9NBO54LbA3+fEbBnT3R0tPxLMzIycnNz8+3k56ysrAM2mZmZckHV BVLTr2rOVHOcctWTszpVqcZVDvTmcY5ZTAV8dULHSVt1Hr0DnXqjomd7K22O2dSd9m2w79kR2Q0A AMAkGml2e2pjxH4ZscvQXd61L8z9g7886jhHc/W9fcfOWZ2Yc1glMrU9nKSwQPc5/To5NrRc9+jr S7ZEyUnUCvNCWu785l/y0t0WS7f+X+2zWoPcpz167swuX3tGSjpQu8uZYd7kTGPJbir+qGVFIzac u5/2SssbG3bvluAmfUauuHz5Eq4dp0TlkknWlgyusryadVXXXe0Hd9TONt+al5KUtD81o9g25apj nUr30kY+/YhN3TlcRQV89elqElaFO70JnXpJbTkn1BFVZJHNIRs5v3ycambgvgZkNwAAAJNorNlt Q/i+tLQ0GW0mBH37B4tzj7vuUIN8GYHn56fMH/lfF2hoeXf2ltzcXDWils/ynPG4On6Ly4y1S8fU bT9sUaScVk29mSG+NY7sdsq2tqRc7sLCvG/+dav+tod8sSkyMjIlpeYJR+khOunoxxLVhJqazFKT pyoxydXfs+gtOcO9Fssjr3+bmZu71/OzHvbTtuz83De+CSpk2QLgoRDPRR8NfFavadn53l7/HDrV OzRFzeGqaTI5uTTOiZjfyWLpcp+lpWVY1OFKNccn/5VmxQUh8pFXdulisTywNDxfBcaM0M/lhJ06 dbrXTj6lRadOf3tj2MIf/TMPlaiJQjUB1zDftkZ2AwAAMAlzZje15v9vyW7uIfG2x52iZ/R3DFV3 Pd69o/7lr24Bhw8fPnLkSEFBwZrxDzq2u/tPzz7T63bHIxPXRGdnZ0uCy8zM1BvJOdXM8qd10bn6 iSqyW31R2U2+2JyswNft3/bvbh3sFRwsxUj3kJfUk4b6Rked3VSqcpxEk75UVFTk/Z8n1Hna/ffc zWsm1L2awxfvlUiYFes5pNcFr/jT78/fn1eo5uDktNJ79/l/ol5qbnk+ILNYTe+qHQ1yUn2etr9x 1jarnFwqj9k2+aI96vH5m2PkXydlN/zsG9kNAADAJBprdlsXEpeYmBgfHzH1Hw+pg1da3tzg5xcU FBS2e/uq+ZNk/NxrvK+M3iW4pUcvvsv+QVd3+NtXK739/f0DAgI2r5jZ2368TbcJe63W9PT0lJSU Hyf2qRmW21Ngz799sjkgMNBv3eS3a+bj/vHZdjUBxLxb/VKrlEj8yUja/KT9uvz+vlG7IyPT0tLU dn6Oi89IalNPkJXZSVdRT5NJyJLMLmHc3e1nYvjK0PREv6/uvkgjm1YdR4dl5amZ2ZycnAjvs+uo NLf8OSCtZmkUNc0nnS01aUNf+7s+3RwnNUinCvYY+3OfYHnjPwHqDwINHN/IbgAAACZh2uwmo/Hf kt3WBsXaFhjc/dEjZ89wheWFeWu3hYSExMbGSv7KSo2Pt2ZLyMrNzV3r+rj9jb3mrt3q5+e3a9eu wMDAnTt3+iw791zVzA2REoIksywbr2dOLPc9N213WFhcXJy8VJM33d3jsvMlX0hGMM/uz40ju6m9 /yRzpe330InrmQ++lQualZVVWlqqvnC9amhJbkpwcHhwcPBuuz179uzevTfrcM2KozUxyr6fe3P7 bbU9/zZ1k/8u/22rXQfXdIn+0zyT9m35h0OA+n2vQXMWr/Hy8vLcuHrulH/d6fDSo+8uO5CdLcFN Trtn/cf27Pasb1KOuqmypKREXk2MWf2s/S2frN8r/Vy6rv/qj+zH/uD6v0s3bNjgvmrJV7Pc/vXi edPBS8JyGv5eXLIbAACASZgwu+m9uR33d5u8JlRC1kWym0SJ+SP+qLPb6pA4GRInJCQscchZ4u0J i0ISEuTkkgSLiooku2VmJo6zP+N0leWdpWvXerh7eNt4eHh6bJj/Z/t73VaG2uby4peO661H2p97 BEp2kBG4lCdxQK2GodaZNM82AY0mu6lcb01072O/AA/89fOY+HjJREePHlWLw0iukS9fLoHvzIcs zny6rWb/iOzsbPkn6Lwv7nt+WmBoaFRUlFxQucqbly/fFZe45lP9UZZn3v08ICgoLCws0kZ+CNy6 6GWHMy/wTZDgJp1Ed93mlmd84jOkZum60jcyMzNjIlY8Y28/aU2IXBoJ/ttWjLC3f/a7bfIhQaGh oZI6AwMDv3N7VZ+//Qvz823L4DTkg29kNwAAAJO4XLLbtPURF8lu+fn5+/aFj7CvNXL9g8P2JCSk pKRYrdaYaJ839Q2RZ4fHfT7/cY/KbjKGTz8Q53pevLugV6ZsrpXdrr9/WEBEhHyQnKe0tFQqUath 6J3jyG716Fx2i13/uP2i/P7+j8PrZDe5BPKr76wXnF7HqR5RkqGkg8mlXDxaZ7c/zNm0R1Kb1XZn rOQUSWFJSREfn/17gOWaW9/xDAqSZCf/8FQb+WHv3r0717npM/cetVZ6SHR0tO/KkfbO9oxP3AGd 3TIyMqLClunuNml1cFJSknyozm7NLE+uDAiXNCfHpbyIiIjAwIBpA25Wr15pGRCSWah2qCe7AQAA NDUmzG5nn2nKyNizeboeFQ+Y5i3j7ZKSErUAiGqsdvuS0JSdnR0XFzLK/hDUDb0mRNn2+crKypJg FbV368cvn1uWUHlxontmbq6M+VNSoif0vkBaO98LEz0lBMngfNm4s6Pvto+NCYmJkcKkYLVQvOG7 cTnVaLLb2Xsm03cOtF+UKywvbQiNUX1D3Uyomsmvfl8+5/Q6SmJSuV5Ck85u198/fFdUlCQyFeoL CgqkU+2P93rR/q433NZGRkYmJyfLcbWvX02D/fsjI3cN7362zZPvfyfBTZptWfZvdaS55Wnv2HSd 3ST+7A1drrPbxB+D5GuMiYlxyG41y+xIeJSeKY2ls4WFhXksGGI/27NbknOlwzfk7oFkNwAAAJMw W3ZTN7zJwFtiV3T48j/ZR7nt//Jlkm0ReH07oloBXj8ctzfKZ6D9qaXWXcfKKDw3N1fdGicD7Kio iBVzP7zj/DH8a5/4SL6zWqPG9D575P7XZ2/fvn3Pnj0REREyopaxfVRU1N69e+W/8dHxerZFP+/W +oFxEQkJakJQPWylGP0t1tY4spuaUKtZUT8jY95b7fR1fNl1vVwX6QZqTz210/rRo0fVU5ByKXft 2vXjF2/p9uOX75Tj8p3I9f1uzNns1vaxsRGJiXIp1S2vko8knVlj1z9hf9eEpX7x8fHSLSWCqQ3a 1D2QcXFxC+036/7+wVEBkTUbu/ucn90kDEo9UmHt7LZqT63sJu03RVnVLnXS26W9vOq9dLj91We2 7ssqLi5WK5Y0zNdOdgMAADAJE2Y3tQ68jKLjE7c53O5499feNbe6yYC5zLZpstpYuWbR9ZwcGQB/ P/Hcg0v/NWSJDO9l7K3uipSfpYGM4Xf6eUwbqhf5k5Gwi0dEarJ1r+vzZ49cd9+7Hv7+Yba1R5KT k61Wa7KNuo9OPl2GrzLmXzHhGXt2G783KUk+Qt3GZvSXd0GNJrtJbFd9I2jtOH0dm1meWhWUKN1A ApfeZE36hnQViVpSZ2hoqMeiD3T7sT/4JSQkqJsVdXZr/aBrjNWq/zggHUw6T0rcBp3dhn7lLW9R OxGo7Qbkh5qd3/dFTfzvs23a9Zu+OywsJCTEIW097RWTprOb9KLIkGW9L5rdVHvp5KpvS6nbHZKg Z3yGxDq1ombDfO1kNwAAAJMwYXZTj7DJKFpCk7470TZwfX7p9hgJYpKVZHArI2FJZzI4T0pKWDH3 3KyK+N/tNSN5OUNRUZbn4qU7EzMlvERHR+/Zs2f79u1LdFSzLfQnuWzTzL/oI8//e7HObil2qWmR 30+fvDEiTT79/OxWc3Mm2a2+znlx5/UNa/ioc2Hdcs3tb/tE1axAombNJHmpdR1rnmdMT6+Zuvph mNPsptcqafPgxHjbRgNq8k7dnHkgI3qM/Xm3Gx6bHJFY06/ktNJG3ZZZk60iluud31w+XBoRESH9 R8+7XWHptzm65nFItbKl9KXwoBUXz26e0anyD5Ssp3YxiI+P/+qDHvaz/WVrcibzbgAAAE2T2bKb WmtCBsYyQLUtyrdGL8qnvPjexJWbfCNjEhL3J0ZFhLgvm/3qo+c1uO21b5PT0vLz82UAfPBgqlvN wLrz8Knfbw0MDwwM9PX1nTtML3Rh+WRDVFpa2r6olU84nKFn/7FrPXdGx8XFxu4NDtjy3ewR6hPc vBJk+CqZbpXr2bUH1WSNjMklKZDdLjXpG+pZNtU3IrxnOl73ZpYen6/bLWFKcr2kHmkjQUy6gWS3 msVA7BNhKrtJIJLsJgn9XHZ7aHLigQN6SkvdnJmVlf75wPb6jUNmbk5NTVU3NMr5JZGlpe+d2r+D bvDunC3qebety0fogzM3REu10jgrKysxMdHf3U1v+l43uzWz9PaITlL/Cvkg6ZxBnjPutLe/6YkZ adnZPO8GAADQNJktu52xr0BSXl5e88CR1bprwxTLL3Z9tw92Ju7Pzc0tssnNS57ssPdy917P9ux4 7tfmlj4+cQeys7NlUOozb9DPnvzTzXHSUkpSe3Nbagb8k+JSa2ZJKisrG2we5FdoHNntjL1vqKm3 lJSU9XMH1LpG9/UesmD1lpj41AO2lSJjIkM3rfl+4rBBXf9wrs24pQEJCQnynUiC+/7jp+2XckqS bc0Zld3Ujbt5eXkJQYscuozFZfCnvnti0zIzs9JT9vgs/scfz7107a3DA6KibLsKxoXu/P4x+/Gb /zxpd1KSREj5RL+1Mxz3LdDZzSHrPTJ3/S7pYxkZGamp+72WuTl+upt7hAQ69XAl2Q0AAKCpMWF2 O2NflaK0tFRSmIx4A7d89+aTlp/16sh54UlJksXUJmuHDh3Kzk6a0POC7d+c5atSXs0ESlryorEu F2xao9P3/smZmZlpaWnrppxt2barW+yBA/JxMuBvsLH0r9CYspuaFFN9IykpafPCUXc4v14XNPqH XfLG5ORkSXB6u4c2XWtnN0mI0jdqLvfs/r/grHd/7hEip5X2tht094xx6LHNLU+/M2LE6891r/Ue nd30upTKVXf17te//5P3nNe4w2tfy9mlV1dWVrJHAAAAQBNkzuwmQ3S1hqSMpWWInpKSEhsbu3H5 rMEvPm5x4u4BQz9d7xtutVpzcnLUYibl5eXy3ry8vLjQ7Z+N/Ve3899wdcd+ny/zl5QnI+FSG3Vz 3Y51Xwx6rlZbyz3dn//I7bvghNSsrCwpRt7l/eXL6qV2z89Osa1M6LhzgQk1mux2xqFvHDlyRC63 xKXwgLUj/37/BUPV+e7t+o+V/nGSsGrd/tq229R9tmfZ1KXUfz2QLiTN1sx9/yLnbG55br7HbqlE or20l//KFx68Zc7Phkq1N7dkN5/zs1tdjw+aHZmcrFdKachNKMhuAAAAJmHO7HbGvuBkZWWlWnFC LRISFxcXFbF7+xYvT08fX19vLy+vbX41D6bJSzKwlPwlea2ioqLKRhJcUVGRBC7JdPHxMUG7/Ldu 3eG3zdtvZ5iMxmWArXbdOmYjn1JQUCCfIi/FRO4J2L59q7TeERActjcxMVHCo1r8RN4i51Tjc2ks B+WI5ES1QYDR39kFNabsdsbeN+RCq/hWswN7TIzvhsUfvf3Cnc6jz10u/QaM+3Tueh9/6UIS3ORd EsOlz2ycdXYDt//3/OfpBw9KMlKPkql1UaT7qQVDJJeF+f04alCfOmd+5MMp3wZERkoD6WnSQ6QH yn/V+pa7PBe80fc2x9Z/HTJrk/fSl+2/fu4To/4ucZHsdk23v/5nkU+SbUJZbSOotiBvsG+b7AYA AGASps1uZ+xDdElhEo5kCK1We7A9xpSqln9UsydyUF5S0216g2xRXV0tRyRbqaiVnp4u7eW/0l5S ntqlS9qcsFFZTw7qT0mzkR9kzKyWp1DTeULdkCnkoDqJmR92O9PostuZC0R7CUGRkWE7tnp7uLtv 2OztvXnzJm/vHTt2hoSEhIeHR0VFSc1yQVVvkcsnl1V+rVlHNDVV3WqrbkdUm/TphCjHVUKU3BcZ tmvLpk2ePr6eHh7eW3eERUbKQccJXzmD6nW2FVCTJFQGBezYLrZsD4qIUtsFioSEBPVQmxQQHx/v uJf3/A1e2zw3eotNm3x37lHn1+U15JNuCtkNAADAJMyc3c7Yhujq4SPJVjKKVgunq8kvtU2A/CoH 1VybNJPGp+xUfFNjaRnhq+G6tC8tLZXAJSlP7fGtGtf6lOLiYpXO5AfH9oo0q7RRBxvy4aNfp/Fl tzP2LQPkEqtoL0FMErqksOTkZKktwS4xMVH++XJcgpKkeJXB5SqrDK6ediwoKKgbw3V809Oy6vxy tn026rTqTwfSQPqDdAZpr3aXkxPKx6lsKOFLJUT11wP9BwS1d7xUqNcqaWZ5fNGW3ZGRkWo1FXmL WqNSnV8Ftwae4SW7AQAAmITJs9sZ+xBaZSsZFUtukrG0jk7yq5o7UynMcVir1rWQl1TaOman2suw X151bK8+RcUB3V6fX7XX1Gxd3ZOYU6PMbmccLrFcKbWZtcTtwsJCiUW5dhKg1C7t8qqamVU7awv5 WfLaURvpTnK81u2Iqu+px+vU+eU8crZ8m1qn1Z1Q/qt291Z/alBvUY2lvMM28i6JYyrfJSUl+a4c ac9uT/4YuFfipwp3tc7f8MHtDNkNAADANMyf3TQ1kNbTZI5TbBca0J6202/REU9x2v5UHacv6tL/ 03+rxprdztgvmZ42VbleElmZnfysduvWM7M6YUkoU9FeTZ6q4xc/v9r1W5251mkdu4RKfHqKtsJG /bVB/01A5UHJdHJ1tq/6yJ7dem8I3+d4B6bjhLIh3zDZDQAAwCQuo+zm6FeEpssoatW7pKSkxprd NB26dShznBt1Oi3rGNV/tm/ovwDok+u45/SNjn80UA9gnjyfel6vqKjIarX6/ThKP+/mHZt+6NAh yXr6nl5jOy3ZDQAAwCR69eolo7JbbrnF6EJwCcXFxanh99SpU+vrnGbLbrVc0qheL2eWXHbs2DGJ aWlpabvWjbZntz5b92WZatcJshsAAIBJ9OlTs+z5ddddZ3QhuIRCQ0PV8Hv27Nn1dU6TZzfzU5uM FxcXZ2VlhazX90z+aas1X29VYHSNNchuAAAAJvHPf/5TDcwKCgqMrgWXyrJly9RVXrlyZX2dU2e3 yZMn19c5mxSJZhLQysrK8vPzU/eFeW3c6OW10W9nWF5hYUVFhXl2DBw9ejTZDQAAwAy++uorNTDz 9vY2uhZcKh9++KG6ylartb7OmZaWps45duzY+jpnkyLRTG//nZeXl2WjtgOoqqoyz46BuvNIxjS6 FgAAgCYtODhYDczc3NyMrgWXSs+ePdWdsfV4G56M5FXPee+99+rrnE2NmnqrqKhQ+wWozQr1dgBG V3fWoEGD1IWWIo2uBQAAoEmrrKxs1qyZDMz69OljdC24JMrKyq666iq5xL17967H00q4kDAop5Vg WI+nbVLU7gOOu73rzQpNcsOkePDBB+Uq33zzzeYpCQAAoMl64okn1N/VU1NTja4F9W/+/Pnq+k6f Pr1+zyxhUE4rwVDiRv2euelw3Hre6RbzxtJ/2+nXr5/RtQAAAODMmjVr1Nh+5MiRRteCeiYpoHPn znJxW7RoUVhYWL8n//jjj1XPiYmJqd8zNym1toM3T3A7wz3VAAAAJnP8+PF27drJ8KxVq1ZlZWVG l4P6tGPHDjX2HjhwYL2ffN26derkM2bMqPeTwwwmTpzIWkYAAACm4ubmpkZoQ4cONboW1Juqqqou XbqoKxsWFlbv5z969Og111wjJ+/QocNPP/1U7+eHsaqrq2+66Sa5vm3atDl27JjR5QAAAKDGkSNH 1NSb8PPzM7oc1A99T+NLL710iT5Cwr76CA8Pj0v0ETDKihUr1MUdM2aM0bUAAADgHG9vbzVOu+22 21gMvBEICgpSF7Rt27aXbuP1pKQk9Sm9evUyz7L2+O1OnjzZrVs3duUGAAAwp8GDB6uhWo8ePUpL S40uB79edHR0mzZt1NVcu3btJf0sFxcX9UHz5s27pB+EhjRz5sxLPWkLAACAX03yWqdOnYhvlzvH 4CZ5/FJ/3P79+9X+cS1btmSbicYhISGhRYsWck1/97vfpaenG10OAAAAnMjPz9fxrXv37lar1eiK 8H/j6enZunVrdQUHDBjQMEuIzJkzR0f+ioqKBvhEXDpHjx7t2rWruqDffPON0eUAAADgghzj21VX XfXFF1/wHNNloaSk5M0337TYNVhwO2N7Nkrv8P7UU08R3y5fEtx69uypLqWLi4upNpsDAABAXQcP HpQRuE4BvXr12rx5s4zPja4Lzsl4e968ee3bt9eXbMSIEQ28aH92dvadd95JfLusOQa3e+65R/4/ YHRFAAAA+HmnTp368ssvr776ah0H7rjjjlmzZlmtVqbhTKK6ujosLGzo0KFqkzV9mXbu3GlIPVlZ WTq+de7cOSIiwpAy8OsEBQXdddddOrjl5+cbXREAAAD+DySp9enTx3K+6667rnfv3qNGjZo+ffqc OXO+QAOaPXv21KlThwwZ8vDDD19xxRWO1+XKK6+UHFdWVmZgh3GMb82aNXN1dT1+/LiB9eCXqKqq Gj16tO5IBDcAAIDLV0JCwnvvvdeyZUsLTKlDhw4zZswoKioyuqfUKCwsfOWVV3Rtt95666effioH ja4LTkhGc3Nza9eunb5er7/++uHDh42uCwAAAL9JSUnJsmXLhg0b1rNnT7UmPAzUpk2bvn37urq6 +vj4NPCjbT/r9OnTK1euvP7663W1LVq0kFCwYMGCyMjI6upqowts0qqqqsLDw+fPn//qq682b95c X6MbbrjB3d3d6OoAAABQz06cOGG1WqOjo0NCQoLRgEJDQ2NjY7Oyssy/AGBeXp4k/WuvvbZW6pQc 16lTp+7du/fs2fMxNBT5tuU7v/feex3zmtKqVasRI0YwNwoAAAA0ZWVlZfPnz+/cufOlm4LEr/bA Aw8sXLiQRUEBAABgTuafsWp85DvPycnZuHHjhAkTXFxcJMrdeeed7dGw5Dvv0qVL3759J06cuHnz 5ry8PKP7BQAAAHAx//M//8M2BwAAAABgZrt27bJYLMuXLze6EAAAAADABbm4uEh269ix44kTJ4yu BQAAAADgREREhF6l4dtvvzW6HAAAAACAEy+99JLObu3bt6+qqjK6IgAAAADAeRISEmotkD5nzhyj iwIAAAAAnGfAgAG1stuNN95YXl5udF0AAAAAgLPS0tKaNWtWd2/iqVOnGl0aAAAAAOCsd955p25w E61atSouLja6OgAAAADAmZycnBYtWjjNbmLcuHFGFwgAAAAAODN8+PALBTfRsmXLgoICo2sEAAAA gCatqKhI0tlFspsYNmyY0WUCAAAAQJM2fvz4iwc30aJFi6ysLKMrBQAAAIAmqqSk5LrrrrtQXnP8 9a233jK6WAAAAABooqZNm6bTWa9evb7++mv962OPPbZw4cKOHTuqX5s1a2a1Wo2uFwAAAACanIqK irZt20ou6969+5YtW+RIaGiozm49evSQIydPnlyxYkWXLl3kyGuvvWZ0yQAAAADQ5MydO7dz587r 168/ffq0OhIZGamz28MPP6xbSgMPD49HH300NjbWoGIBAAAAoInasWPHqVOnHI9INNPZ7aGHHqr7 lqKiooaqDgAAAADgXGJios5uXbp0MbocAAAAAIATycnJOrvdc889RpcDAAAAAHAiLS1NZ7eOHTsa XQ4AAAAAwInMzEyd3W677TajywEAAAAAOJGXl6ezW7t27YwuBwAAAADgRGFhoc5uN954o9HlAAAA AACcOHLkiM5urVu3NrocAAAAAIATR48e1dnt2muvNbocAAAAAIATlZWVOrtdffXVRpcDAAAAAHDi xIkTOrs1b97c6HIAAAAAAE6cOnXK4uD06dNGVwQAAAAAcMIxu508edLocgAAAAAATrRo0UJnt+rq aqPLAQAAAAA40bJlS53dKioqjC4HAAAAAOBEq1atdHYrKSkxuhwAAAAAgBNt27bV2e3QoUNGlwMA AAAAcOLmm2/W2e3gwYNGlwMAAAAAcKJ9+/Y6u+Xk5BhdDgAAAADAidtvv11nt4yMDKPLAQAAAAA4 cdddd+nslpKSYnQ5AAAAAAAnOnXqpLNbUlKS0eUAAAAAAJy4//77dXaLj483uhwAAAAAgBNdu3bV 2S06OtrocgAAAAAATjzyyCM6u0VERBhdDgAAAADAiccee0xnt+DgYKPLAQAAAAA48cQTT+jsFhgY aHQ5AAAAAAAnevfurbObv7+/0eUAAAAAAJxwcXHR2c3X19focgAAAAAATjz33HM6u/n4+BhdDgAA AADAiRdffFFnt02bNhldDgAAAADAiVdeeUVnt/Xr1xtdDgAAAADAib///e86u61Zs8bocgAAAAAA TgwYMEBnt5UrVxpdDgAAAADAiUGDBuns9sMPPxhdDgAAAADAibfffltnt8WLFxtdDgAAAADAiSFD hujs9s033xhdDgAAAADAiaFDh+rsNm/ePKPLAQAAAAA48e9//1tnt7lz5xpdDgAAAADAidGjR+vs NmvWLKPLAQAAAAA4MW7cOJ3dZsyYYXQ5AAAAAAAnJk6cqLPb1KlTjS4HAAAAAOCEm5ubzm6TJk0y uhwAAAAAgBPTp0/X2W38+PFGlwMAAAAAcOKzzz7T2W3MmDFGlwMAAAAAcGLu3Lk6u40cOdLocgAA AAAATnz99dc6uw0bNszocgAAAAAATixYsEBnt/fff9/ocgAAAAAATixatEhnt3fffdfocgAAAAAA Tnz//fc6uw0ePNjocgAAAAAATixfvlxnt4EDBxpdDgAAAADAidWrV+vs9vrrrxtdDgAAAADACXd3 d53d+vfvb3Q5AAAAAAAnNm7cqLPbyy+/bHQ5AAAAAAAnvLy8dHbr16+f0eUAAAAAAJzYtm2bzm59 +/Y1uhwAAAAAgBN+fn46u/Xp08focgAAAAAATuzatUtnt6eeesrocgAAAADgPOXl5dnZ2SkpKfub tlWrVuns1rVrV6PLMVhGRkZhYeHp06eN7p4AAABA0yUD8sjIyC+//HLgwIH33nuvBbiAtm3b9u3b 19XVddOmTZWVlUb3XAAAAKCpOHbs2JIlS7p162Z0JsDlp3Xr1qNGjUpPTze6FwMAAACN2YkTJ6ZP n96mTZtaA/Lbb7/9lVdeGTly5Pjx4ycBNq6urqNHj3777bcffvjhK664olafeemllzIyMozu0QAA AEAjlJiYKINwPfZu1qxZ//79PT09CwsLjS4NZlddXR0RESGB7uabb9Zd6Jprrlm4cCFPwwEAAAD1 RUbXc+bMadGihRpyX3vtta6urjk5OUbXhcvP8ePHV61a5XjDbd++fYn/AAAAwG8nwW38+PF6pN2n T5+srCyji8Ll7aeffpoxY4a+kbJLly7ENwAAAOC3cAxuV1555YIFC7jDDfUlPj7+gQceIL4BAAAA v52bm5sOblu3bjW6HDQ2xcXFjzzyiI5vpaWlRlcEAAAAXH52795NcMOl5hjfBg8ebHQ5AAAAwGWm vLy8Y8eOakS9bt06o8tBYybx7bbbblOdzcvLy+hyAAAAgMvJBx98oMbSb7zxhtG1oPHz9/dX/e2W W245cuSI0eUAAAAAl4e0tDQ1kG7Xrl1xcbHR5aBJGDp0qOp1EydONLoWAAAA4PIwatQoNYpesWKF 0bWgqSgvL2/Tpo30uptuuqm6utrocgAAAACzq6iouP7669Xda8ePHze6HDQhY8aM4Y8GAAAAwC+0 ePFiNX6eMmWK0bWgacnIyFB9r0ePHkbXAgAAAJhd//791fg5Ly/P6FrQ5Dz//POq+5WUlBhdCwAA AGBqd9xxh4yc7777bqMLQVM0c+ZMld38/f2NrgUAAAAwr6KiIjVyHjBggNG1oCnSmwVIiDO6FgD/ v70zj46qSvf2AbrV72vbRr32d/UuL6LIoOLcNCIgDgiiqK0XsO17pQdtWVdsBkGmyKAgg8JlcGSQ MCehkkBCEpLKQOa5qjKPZE7IxBgQCVz7+9V5UzsnlaQCCBbK71lZWVXn7LP3u99df5xn7XP2JoQQ QsiVS0hIiNw5r1q1yt2xkKuRo0ePyi/w1VdfdXcshBBCCCGEXLmsX79e7pyDg4PdHQu5Srn11lu5 XAkhhBBCCCGuWbt2rbhbdHS0u2MhVyl33XUXfoH333+/uwMhhBBCCCHkymXlypXibvHx8e6OhVyl 9O/fH79A/Hd3IIQQQgghhFy5KHdLSEhwdyzkKmXAgAF0N0IIIYQQQlxDdyNuh+5GCCGEEEJIl9Dd iNuhuxFCCCGEENIldDfiduhuhBBCCCGEdIlrd/vewf8aOGfAeBzFfvz4r0KMI6IGyHVhp/I/ZrTn A92NEEIIIYSQLunS3UTWzp49e8bBdwbkyFkd6tuPgLIwGRTRZ9fu5lT4ChwmuhshhBBCCCFd0pm7 qcma5ubm06dPnzx58sSJE8d0jhrAVxzH2W+//RYSBzu4Mmd2fjS6nAj7gZVjRMSjMSjIOfQZAyRp 76w8CqAYCuMSEe0rTd/oboQQQgghhHRJZ+4mkzW47cc9/9G6nP2BgUFBQYGBgQEBAXt1AnQC9eMh ISHm4GBb6WHRN1zrru64C6fpMDXJdWlbUSpdnBYdEh5uNgdFpRScOnVKWbNTSDKCp76tjY/YbwbB 5oySBgyo6N6lje2HQHcjhBBCCCGkS1y4W4u4HT2aF+ahnQdDP4iER8i0jru64xbU9JaaDpNZSKTi 0k5voULUf/xE1YJ7W3J+Y6+lpUeOIO1ovb27oTwiOVwVMtgxRo/PDTt27BgO4tQlDOwHQncjhBBC CCGkSzpzt3PnzsE+Tpw4cejQobSg83K3VxZFoTwk4mpzN3mOEVbVdDhn8YQhQ4f1f/jVxTmNHU+H XTSoB7ltamqqbzj48bMtOf/tE0uLa2qgY999951T2vFVRrCmLPh5xxi9OC+4rq5OhunKeWyS7kYI IYQQQkiXuHA36MCRI0fKyspids80Olrv3r017S79r4/+d7em9cXxN9fFHz9+HL5wEe72fVsuXf9+ DMRzT548WZnyucrSstAKeTrxUpks6sGIQNOqqvMXPtPSyk0PLMopLW1sbERbTo9B4it0EiNYWrhn tCOq52f6VlRUHD16tL3ruRG6GyGEEEIIIV3iwt2gAw0NDcXFxead05SSTF6522w2R0dHx8XF4ZKk pKS0tLSsrKySkpLa2toTJ05chLuptRC7XDXxykQ8F95aGLNEJerj4JKmpqZL7m66TWd7POl4ZnKg h7WgoK6u7tSpU+3dTUawMMc00hHV6GleGCm4HrSO7kYIIYQQQshPiM7c7ezZs9ABSEFhYWHo9lZ3 m/rFXpS0WCyZmZnZ2dm5ubkFBQWlpaU1NTVHHC9eqdUmjZuLdTitZlzK8tvTRavfmW87dkZqaC9x HW5V1lmZ88Rpf7rOZv1c16BeDKypSl/25lPI0vAJy20VDcpkndo6n4baF8ZnZAnadbAkY+6IluHo ed+c9Ly8Q4cOnTx5sr27yQjmZ/k4pum0UVO2FxUV1dfXI+DOAnPd/c6G8jyT3+GPkO5GCCGEEEJI l7h2t9ra2vz8/JCtU5W7zdwUBmvD/X95eXllZWVVVRWsDS4Ac4E+yCr0zTpnDKid4JSXCWgFp+A4 R47mLx+v9dBeiKq0bzogq9/LsifGwlLJaR21tZzRJmTyDgebDRgjcTp42oFEiOOqUZUKqdZFnbKH AtQVDlVRUQGTxX/k5Pjx49ILKS874qkUOa3V/71j8lEVVlHJqpWy8EhDQ0NRkXVOq7vNTs3JwRA0 NTU5LT+Cr4gKI5ib4f20Y/ie/ce2An2eDqeMgamUGsVZyZrqvjEqp5LGYh1mSXrRocHR3QghhBBC COmSC3W3uduji4uLISmHDx+W/d1gKLK/m/IgXCj7wR3XQZnK0qK8vLyCg+XHdL8Tc5HpKhSorbN4 jLJX3l0bHZRbicrhQWJwUlIUD19xsLI4L9eOLb+4GsKi9pUTZApPAlCcOFF3MD+/sKTiaFPTKQe4 FoEdcSB9kQpl0zTljPI6G44bq0XJuooSJKei+oj0EQlBuuCzsFooLSQLxyUt0lxtVRmSgNDLqmql IaPJSiuigVUH8/WStvyiKnQZl4su4RSUsLDQMvuJluH4zb2zUrKzq6urUaxDd0Myc2xeTyl3e3cr YsZBSS9qbjhUKVGVVNTIUCIG8SyVUrSOksfqqqVkZl5eda1zSTVGbbNUXwJXPFh+xNGLDmdU6W6E EEIIIYR0yYW6m8eO2JKSEhiE7MoNBzGKGy6Biq3/8x2aZl/F/p0vY/Pit7z2uLpa66YNW7w5+ph+ CS6EMR2qTZ89UjPQr2/fvv369cOnSWtTUKEsuQ+tSA/64qUBxpLabx6b6BVThDBkzkgUI37j3+y1 aNqjr6+vqq3NCP70947y1/V/7ouQjMbGxrKkT0UW+jm4W9N+2b//f/zpH+t3RZY12OcQxeDEXJoO p751r/ZLu2LcuyH6EGTzk78/qsIYO/lra3k9clVVEjZB03r0136pTTxwsAG9E3utyAme/h+DjZEj Eo91voV1J2RCqmWZyqYmS/CXL7ft4w2D39h5oADZRkioSn+K9Ye6G8rDNKvz988c/5ixrWv7PTdn tXd2ZaOyRfy3TylW2T6b9bLWlr967EAXpaRYW9LmNx2Z32DPfEhr5q/tO+bL/ZkyUu3X3qS7EUII IYQQ0iUX6m6zN0bhSGVlJSSioaEBCnDkiH3iCd6BO3PYSm1t0cJnNde88qEZV+Hamqrk9x7rvNii SJkRO3ykbMPMJzsrNvmzGJSRAFDn/hXD5PitY9YEmz5oX/6/P4+zhc53EV437fHP91rRKTFH+7L8 5Wb12OGnfqGLX3K+5Brt7fiD5SUF/iP0r9210SEFNUgRJLfM5nl3Jw3JjnjyIOKxY5XfzOq0j++s PQDltGespqagIP2HuFtubm55eTmi6ttJW0PmhCLtYuWo9mDq5kGdlLxWmxRddFgUHnYZvnK4HO8s 81M2pKOkegdQhUp3I4QQQgghpEu6dLe8vLzgLVOMd+B9+vTBjbamDXD83dPjHhy+95uEGpQvLc2a /7TTPfvdf5g4cdzofzce2hBfVlNz8JM/dGIFOiPfDzukY/IYaDzed+izzwzrZTzyUUBho05VVZX/ R6Nc1NlNG/xNVE6C/2xXDev8aandHOVhyMqSwDEuC494Z1tuYWFuhresxt9dGxmUaX/rraKicNUf jQX7DHukt/ryyqIo0V60smf+g677uMg/F+KGGvML0i7a3Ua+uyU7O7u4OHv1622ievzhO9SXlzz2 wzrFyg8V+rUVtz4jR468w/D95kcWF9XXI/O4JGipqyR10x7zTrNvT9B+6o3uRgghhBBCSJd06W65 ublBbd2tM5YF55WVleXkJCuzAAPGzPWLiI2JiYmKitqy4q/q+IsLQ0tKSrItqeFRsZuXKZG4b+F6 7+CAgLCwsPj4+Ox8+4ooxWnr73Kcvu728Wu27wvX2btt2QjH8ZseXphbZae4uHjXB/ZVFbvf2XLq 969+6GeOMgftnPPnIfj66gI/i8USvvM9x6W956z5xsfHx3vbhjXLF/z5xTaSuD62FBmAGRXl+rad S3zkw698o6LMOz6b/aCm9dDG7knNAulJW+Txz+7aU/4peQUFBfn5tqX/+YBcc432F5PZfODAgdiI oC1r7UtFDpmzv2U2LXermpu77vYJHffxofm2kpKDBw8iw7Mu2t0me2ZkZOTlWT+d+KAjqr/5hIai rYiQPRs+mTlc0wbP2INM4kKoouc7t6o+T3hvjYQVEeG/bHLrGC/0zUZ5jJTfh3Zr7u4YrUGvLvQN iwzbt0MyP+6jQJRBZ+luhBBCCCGEXASX0N0W+GYVFRXZbPEzWx5a1G4eMT04JiZJJy4uLjJy37tD W079dvjyjKKi/Pz89PT0wI3vyMFu2uCv9pkTExPhQbAw3OqXlpZ6z3vccXboGl8z3CEyMjIiIgIf grYoBdNW7cuC1yDarXOUqWj3PPdRVHx8SkoKWrFarXs8PaOsmXC3sB3TpUB37ekvA/bDK2NjYxEh HHPTonHq8lvHrCksK0MMxqUaNe3OhZ5mpAvVoiprnN8239js7GzEnJqw5emWUEfsTrDvoZCZGTvd 8WJcD+2FNbuQj5jU1FScOphnseWV1tfX19XV7Vk4TPVxtSnMbDajg+gm+hi8dYZqeIV/OjKWlZX0 Q9zNZrPl5CbMHqSiGrtqWwAaQgbS0tKyLQlJ1ny4GOosyd2tDO3Jv3wGoZao8N9s3vf+WDWUK5B6 DL33fLUXgTZg1ILw6GhkCZ1FlpD5xLwi1Ml5N0IIIYQQQi6O83G3fZ7/UPfkT/913po1q9atW/fF F1989dVX69ev37x5844dO7y8AtLySgsKCiyW2Pccgvb0lM3JycmQhczMTHgB7OCr6S2vRN30wKI0 +7RUPs7u2/yuw1we9wyNy8jIgLhBHyorK4uLbbMclnGN9vdtJpPfbr+9e/fu2bPHx8d3t89a9Xzk Yh+716ChzbNGKMlaYYqCO8CqcKqwsBDVIkLUr9wNLW4MOoAgLTr4EBMTtfhPt8jZX2gTwjIL7Zek 7VD6c8+LS+FfkEH4F07BWVAt/ufk5KTEez7VUu0TXrFWBIPebWiNx85f5n4VY7XiwoqKCqQX4lZd XeDhWMgEfdy6e7fJ24QOBgQEmEz+vrvXqSm/hdvtVgs7njX8AtwtO3nHEEcNQyd7wmER+bYPnjFG 9V8z14YlJCBaCQwV4n/antZ31v7y8VY/Hx+EpSfftNvff+2Mlhr+ZdjCdH39yZ0eSnB7L9m5Pz4+ HilFWuwrTR48iNFsbGzk+26EEEIIIYRcHBc67zZ1rb/ZbIa8oHxSUhLMCCoEMyrTgR+lp8dMd7jb yMmeshkcbt3z8vJgRl+/1zKTc+P9C3DDj/KQEbUWSjdtmFeMBeXhDg0NDTU1NYWFFrUPtWteXbgP SgIx2TizpYkb7nkXPoKDJSUl8hAgKC8vR4/UM5PdtKHbIpLgF6JgKIwg93w5Sc521570Ts7GWUvy VrWMyJTVe1HGvtR/WRkilGcLYTowlNSELUZ3Q9fQ/cQEv/+8s02o3bWnV+6KQx9l0q2iInf+U9r5 8AcPf+iV1Ro3zeFuNw1+PyUrC71z4W6JprmqhinrglEDgs+whfy1T5vKu2kjPvYMF2tGbOhd4p45 5xPVL7Rxe9Ps047b5rZ049cD/jsgMhK2jh8GEo78oJuy/olsE8B1JgkhhBBCCLlQLtjdvgyAssHX cFwms2BGlZWV8l4YHM047zZq6g4RMRhEaWkprEGJ1Y33z4e74SzqMe+c5tCHJ3yTc1Db4cOHjx07 hquMayq65vm5e5zc7cbfz4y3WBAexEH2bsN/fIaeRPnMcLQ43DvOhjJoC12AsMC29m+bqnQGZ+2T homt7jb96yB0H92BXZ7QOXr0KKpF39OT2rgbugZjRUixMX5TX7jNKeCXF+6tqa+X1V3mdbrAZBtG z9qtu1viwpf/TY78Qpuwz5rpwt3gTakGBXt/UwQkC6MG07RaQme+9G9OTbww16dMf3MQOYnznXU+ UfXQxvq2dbeeg6aFxdqfI4XSNjY2IjbZSEJ24uP+boQQQgghhFwE57POpHGPgFmbw3NycmAuYmQo UF9fL/t0w190QYuf4XjfbfR0L9hQvb4OIXQAN/PfvN9iKeJu0CgIYMQu9fbZmD1p+dAN2TzOvkNB QZpjpk6797VPwsLCYvQX6JKTkxMTE2NjY6Ojo+Pj49OS0vJ0oDab3m+5oOd9c+R5QtQmG8ChR4gE VnKg1d2eMCVniy3aN5s7dAjxRLXOyj2xPcaCOlMTtii7mrkpDA0hSER4RgfV4nL03ZK8Vbnb7oRM KBKETt7pi4uL3rR8UpulNjXt9SVh+voqtvdHOPo4fnlISEhkZCSGA32U9wRjdJLjk+FHSL7+XOjv VCX/sy8dSUbwiEQ5ET40Nzej47Cn0I1vtg7fxggEj1BxCfQtPT1l68rJvdpGNWHhPqQIwUfvnuk4 dv9K78BIsxnBSPIRHkJC/jEINlsW6kRg2+e1uNtv7plxIDkZYo6fhDwkKXvYyYybk7j9k+5GCCGE EELIeXCh+7vN2x4DH8E9uWw8rbbnBtCi8vLyjIwEtVbJc+/5yMyLaFFubq56GQ3uZsnPR1UwiEiv 1iVHtie1uBsqF3ebPbrl1PX3vOUXEQF3sFrtr5JlZGRYdfAZNUMDoRvG9916DpyHJmCO6IiIw3ff fXfkyBFoi7ISmemD38l2ACiMSr74x2CHSz63Kz7dyd1me0bCSlDy22+/PaeDatFB9N2ask25mynJ vnYKuo/moDbQN5iOOXT34smO/ujbwAVYywoLLfMci+tfP+Bvu8PCoEgon6mjT7RZ7QuM5OQgNpmp DFjbusT/wHErcvR4MATwNQkJ/UV4DQ0NxXmBhp3PH94QloIaIIzynCcCS0tLizkQ0DaqZ3yTC9Bc jHfrw5aTlvtAk1NTU+XtRUk+PkMnMYLi4Dvmtbzv9pt730cHYIjGVSU7tDaB7kYIIYQQQkiXXKi7 feidChlRD8LJ7tW4P5e5pw7dTaa0ZArPc7azu8FHonao+R3ts7DWWTD4BVr3+ug5dfaFqZtkkUYc 11fgt1NUnLpp8Qd+yfa36nBqy2zH1N5Aj4yiIoQqkgVxOHPmDKp1cjdTahZalH3GIZhW86dqA7ab By9IsljgKWmJW9UbaXO3HSgpKUFhKNv/6nTmbihWXV28d/3myMxSCBciP3DgQFhY2OYPnm/Np186 OuL7ceuRMVM2JCYmyluEqo8FhSnSR7QC+TK+f2fP88zNRfry+/BoNRwIqTQ3bJJhfcx/HbMcIgql qq0tDdq0LaG4FhHal1hJSYmKivKc/4Iq+cGueASQmuKtUt9De3FjcDx8DR0pcICxSw3bMG+5b7H+ qqNaq6TnfbMTbTYMvdNsYGfQ3QghhBBCCOmSC3W3l6Z9ttfXNzAwJCQkPDQ0MiwMf1Fm8wGz2Rwe mynPTF6ou6XGbnzMUf/L73nm6K/I5afvX/zm62uCrCkxGwZrrTw2YZ6/OTGnoCA3Nyslzrx51XR5 fHBRUI6zu93/QZfupmmPfOpjn0eDvlVVlUX4LDUuKzLbMxIKgzrVw5B2d9sefZ7uhniqqvM/sm9x MGDqki3m+PS4uDi42/+8+7hqYpEpDRmwJXkOMbQ7ePwc35A4CKpTHz8MzkNm0BCEa7NHm/cA/8+d f1y6wZRkta8SWVlZmm2J+nzRRK0Nd600xeFC9LSurvhj+zuJ98xYvjMmLcdiscTGxq6dOkwVhZ/a bDYc/3rq7ww1PDr/M1OyNauwMDfblha+Z8uMPz6Coz17Lc4qL6e7EUIIIYQQcllx7W51dXVO7uaC nr2WWIqLrdY45W5jZvhWVVXJ44hS1ZY5SqwW2AoLoVH25U3S/ce0qalf336tagOD8Fo2vsvWP96X re9bnaP2d4MeQp8gWe3dTb3vJlxz15Mvjh8/ol+bCm979ZMki0WWZMlI26Hmrzx2xKIGJ3eTN8tU MbibT0JGob2D2QsNu3o//Pizg3u3fu2uPbXXUijb0vmvan0MsjOWBeXKspbFxcXwrfntVhpxwdvL Tenp6bhQX/WxeEnrZKb2u+HPDbmr9Ws3bdiu6JYnNlOSTRO6qvlfHlmeqc+77XLsO9DzvjnJmZmQ RKSF7kYIIYQQQsglwYW7QXnk/a/Q7dPOxw5ufmhZWkGBzRavVrB/fqavbMd8/PhxqUotRXjTAwsh eri9hwdlZWV5ffJah3XO25WOs8nJCaunuF5usv/mqELZiUCtmHHjAwsySkthjqdPn5a1DcXdSktL o9q6W3t+//qSyJQUKNVBnexUL8famfbnCcvLy1GtcjdUiw6iL1mWnTKj1k0b4ZWQCekrLrZ5DO60 lT8tCZQtyEtKSjIzrZ9Nd73cZH/P6GJZHAZGjJ6mpMSs9XjDdUfANbePXeYZmKJ3B0Hi8vqGgx89 3mn5cfN2Wq1W1F9QUIDkJ+z/3HVYj/59U0FpqXFv7p4D5yVmZyNIpIXuRgghhBBCyCXBtbs1NjbC XA7sno8C3Xv10rTe+t+dmnaX46+P/tcXBW4dszo9Ly8jI2G+Y05n3AdBNTU14m72dTOKi32WtrxU 9a+jV+bq+6NB7uw7o6Wmbls1ZVBbKXgW16fYDSIzMzM5Odm0aclrzwx0Eoe7H3pu+sINsRmwh1IY EArvXjZWTv2/0R/nlZejdZGs83S3//vAS4vW+aK57OxseCUExL53W/aelxwFlvumwoBUtcrd0JHc DD9ZGKSH9oIpOVv2UEiLCV46Y+IDbVu5ptfIxV/uhUyh8rq6OuQB7mOz2fw3L+2oj6Onzv862ore lMsqMRgXXIjLEWdUiNfiKf9lnM5rvXDwOI8VG8OiolAsJycHl2MUYJ12j7bGrJr75kNty//y35/x WLUrMTERhZFMh1RmJkYHLnvvNeewtLuf/+OUb3yjMKxIKX4n/p+0JOm3Iz9M15fipLsRQgghhBBy qejM3dTyifbppKwsnI2IiNi/f39oaGh4eHhkZOQBHdmkOy0tDaYjqyCKasm6iGoTtJMnT0pV9ucP MzJQADf8hw4datTBcVnKIyYmaq+v7z47+5NSs1Ab7AmSgnpQwGq1QiuiI4MD/OwEBgaHR8XiKoQn O0rLLB6aQP2IB5erlfw7c7du2hOrd/kG+HqjQn+TaW9IGJpIT0+XrbchSggPpiNLMkq1aKu2thbV Njc3i7vhAzqIYhKnvCKH1kt0EA8iT0qKDw0ONJn2+Ju8fPeGJCUlIWzZQOHYsWOyMAv0x/6YYkpK TFSI9DEgIMgcFQPzQg1Ir6yH2dTUhNYlb1I5YsZABAf4e3l5mfzRgpe3yRRkjoyNjUVDFosFxdAF GQtcfvjwYaTLvsWbNS0iLNjfPxDXmPxD7DsROKQVfUR5ffu5Ugwl8hwfHxMcGChx7QsJi9drRlrE cBGMvG8oe//J0CMtZ8+epbsRQgghhBDyw+nM3YxKAgHBPTkELVEnSSdFBwfhDqIq5eXluIGHI+Ae HoKDW3rYGcREVj6EMogE4SwqhKrAIGRva5lFEq2z6EBhoCo4KAaBC1Ez6oREwArhVlAJaRpHRNzq dVBempAd6ORlN9GHTtxt8BpTcFRUFLqPOlGhbF0tpnP8+HHZ0Rs1yyQUrkXkEChjtfiADso+CPIG H4rJOvyIQXQSXVNhowtiN3BDNPGtjizngoMiiUhCqg4+ICQlX4jnOx0MDcJAE4gKtaFO1IwRSdaR oZGGEI+kAtee1kHO0SPZvMApMHExMUqUl4dd0XdRcuQHhVFStjCQreLUGCEYmYBTQy8bBHT5I6S7 EUIIIYQQ0iWduRuURKbe5D4f6iT7NbeuWq8DZcO9Ou7tcd+OG3hYGP7X6eCDiFuzjiiDTGPhFFQF 9iEqgQ8wC9QgfiQ3/9ANqaFJR570gxDBDmQrN5nYEr9TGgjXwGdpApegZjXp1uFaJd20IRuDDsB0 ZJ8yVSGuPXXqlFgSuuAUOU5JtZIr8VwcRLSqGMJAJRKMhI2AEbZYLY7IPgvovlN+ZCVJWYFTdvfG VxzEKRE32cHN6RLUiZrV6KiGJI1iiGqPbFwoUoZhdQrMaHkoj+Yk+XAxZAb5QbEiHemFsjxEgsyI xCEkHERCEGSXk27/pLsRQgghhBByHrhwNygJ7vNlige34rilb9CpNyC+hnt7eTBSIRt24/5fNsWW 3aJRFe7nZVc4cRZRCXwQP0I98hQl2oJcSA1ndGTPMhxEGYlBmoYvyKZm4llSTGIQbTRuDN2Ruw3d HpksT0iKA6KnLiKXU6paY65EpoytC/gsRqnClt6JG6IeefASHxCe5EHeaJMMq/SKMKrynV0i4iwX 4iBOibUZLxR9Mw6rsl1VXnVfku/0G5DCxjEyJl+NrzFLLqC7EUIIIYQQ0iWduZsggoCbcGVP7ZFH InHr3mwA5eXWXc15SVViasoLjDYhTYjvqArPGVBljE2jmFE0JFoBB6V16Usne3MP946zb1cNeZFZ MNVuh5GrkJyURKYpnVpXZqrCVl6j8uMkgFJeJvuM6VV9NLarYhN1kkvEHI3JUX3pcFhVQyowacip ++1/A8ZeGMfIRZY6g+5GCCGEEEJIl7h2t3/qgmC8h+8Q8a/vO8Gpnvan1FnVhIsKncJw0W57vYJr yEZssab3He42wi85V1ZEVOtGtjcO1zW76KAxbFE5p5g7rMRFHzsbI3WJaqW9snUYrVziuqEOk+86 8y6ibQ/djRBCCCGEkC5ZtWqVWExcXJy7Y7m8QCWam5vhaFVVVQmm6Q53G+RnKayvrz916tS581hV g1wO+vWzb4sOg3N3IIQQQgghhFy5fP7552IxkZGR7o7l8iLu1tTUdOjQoYKsRD8fH5PJa29QZFFp qSxHSXdzF3fccQd+gQ899JC7AyGEEEIIIeTKxdPTU9zNZDK5O5bLizwfKBuOl5eX5+fn5+XlFRcX Gx+YdHeMVyMYlxtuuAG/wKFDh7o7FkIIIYQQQq5cUlJSxN3mzZvn7lguO7AzOBpMra6uTraik23m zn81e3LJKSkpkV/g22+/7e5YCCGEEEIIuXKBy/To0QN3zqNGjXJ3LJcdeWxS7UcAZEcAWYyR7uYW fHx8xN02bNjg7lgIIYQQQgi5onn44Ydx53zjjTdeDfKiNq2TtfFloXuKmxuZObNlvwabzebuWAgh hBBCCLmimTRpktw8x8bGujuWy873hv3aBNkXwN1xXaUg83379sVv79prr21ubnZ3OIQQQgghhFzR REdHi7tNmDDB3bH8GIi+KS5oJzJyaQkLC5Pf3htvvOHuWAghhBBCCLnSgbncd999uH/u3r17dXW1 u8MhVxFjx44Vd0tJSXF3LIQQQgghhPwE+Prrr+UWetq0ae6OhVwtZGZmyq9u0KBB7o6FEEIIIYSQ nwYnT568+eab5UY6ISHB3eGQnz/Nzc0PPvig/OR27drl7nAIIYQQQgj5yeDt7S030n369Dl16pS7 wyE/cxYsWCC/t1GjRvF9Q0IIIYQQQi6I8ePHy+30xIkTufQiuXyEh4d3794dv7Rf//rXlZWV7g6H EEIIIYSQnxgNDQ233HKL6Nubb75JfSOXA4jbtddeKz8zT09Pd4dDCCGEEELIT5LExMRf/epXSt/O nTvn7ojIzwqjuE2fPp1PSxJCCCGEEHLRGPVtyJAhRUVF7o6I/Bw4c+aMh4dHt27dKG6EEEIIIYRc Koz6dt11161bt44TcOSHYLFYBg4cqDmguBFCCCGEEHKpKCoqGjp0qLrZ7tWr14oVKxobG90dF/kp AeUPDAwcNWqU+iH17Nlz+/btFDdCCCGEEEIuIbjxXrly5TXXXKNuvPF53Lhxn376aXR09IkTJ9wd ILkSwc8mJydny5YtkydP7t27t2bg+eefr66udneAhBBCCCGE/DwpLCycNGnSddddp7Xjpptuuu22 23oRonP77bffcsstRtlXDB8+3NfXl9NthBBCCCGEXG6OHj26evXq/v37t78tJ6Qzrr/++rfeeisj I8Pdv19CCCGEEEKuOhobG0NDQ5csWfLKK6+MGDFi0KBBjxCi8+ijjw4dOnTkyJFTp07dsWNHQUEB twgkhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEII IYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGE/OT4/7FdloYNCmVuZHN0 cmVhbQ0KZW5kb2JqDQoxMDUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy Y2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VC L0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRzIDEwNiAw IFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+L1RhYnMv Uy9TdHJ1Y3RQYXJlbnRzIDI4Pj4NCmVuZG9iag0KMTA2IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDUwOT4+DQpzdHJlYW0NCnicnZRda9swFIbvDf4P51IqRNGnJY0QaNJubNCy 0kAvyi48zy2G2MkcZ+znT0rSYcUfKb0z8nnfcx69B8H0O8xm07vl1xug8zksbpbwO44oUEIpZZxT DZpTUJJCncfR0xVUccTg9X8NpQmjMih6uYqjhziC27slQKsBOzVYrOJo+pmBlIQmElYv3tHZAQPO GBEglSHKwqr0XQ6tvsTRM3osyu06h8em3uMJR1mzrzHjKMc/YPUtjm6drbd+81LUkMS0zZ4RtGo7 8/FgPg6Cd+aTgrhzQ4lQR8cZpUbPwwE8W49W0zMtugYs0ZFht/EwBmU5YIuKHRbo0wAXd/cmdOg0 yiXOuLgmNglHs340YYmL+w1rwXqwulJGGdEmEKPrClKcoAYzgZq6cJA/980BE/BEoQxrtKkc5qEg Laq8HkAVShAhQvNRVPk+VG4N0eqDqG0xuk/LHHbbNMt/DcWlFOE2VI0yqJ417NlC7u4mYZe3sGcJ 21IflgsodZm4OHQ7L3nI69I2JpxYHVqO4iXvjIhxH/0HI2qJ/bPh5t+usTzt36aGzK3npjyeeeq/ QwvIKDEq9Bul0z10RnbxmGbux2W8M+2Jr612fBVW6NW9jA6s3LvvdeOAi8HAlH8+AovJUK0WxNiw 9g9mCqXrvWsxuPNCWsJEqOtc2z+b+FIcDQplbmRzdHJlYW0NCmVuZG9iag0KMTA3IDAgb2JqDQo8 PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GNyA3 OCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFC b3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTA4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMjk+Pg0KZW5k b2JqDQoxMDggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMjIwMD4+DQpzdHJl YW0NCnicnVrdbxs3En834P9h4adV0dAcfi6Nog9Jc4cUSHAfLgqcmgfVkRvdSbZryb4Uh/7vN8Pd lcjVDrXxg4XxijPz48xwPriqLv9Wfffd5fs3736o5PffV69/eFP9fn4mKymklKCU9JVXsrJGVo/L 87Ofv6nuzs+g+m2/RkoH0mSLbr85P/v7+Vn19v2bqkoUQKfg9fX52eVfoDJGSGeq61uSiOIqqJRW QlfGNsKG6npDWqKqv56fzeu3X2YQ6sXmYb28qma2/mm7fJx9rK5/PD97iyJJbC/HNF40qZx5XSVL j6CpDJqv4BgaWC+UqowGAU0n83+MenBWuMHaon49on9cPX6jW5HVK3SAwlU3KLzikHiUlLPJyHHB MTRKmIxhXm9vZrr+vJyBqjcLJLcMrzK4X53zXsxA1uguXc+J4tQqVNuEnPXpEbnurkjhDelebZC8 2hJ58xnJJQlsAdGim3v8eKRnS/oXBC2UXIAEDDQYQP1IHN8yHBa80AOERZ+axKcDL+rghf16L6Zs k7zI6Fl94thCGMLr9FyRaaoLtKtqiIRAFidjK4WU5tyKAl1IBc7rV8xaLRshB2v9LQr3pMZxXBhz 1k/UYIIIg7XG0nb0gmNptDB2ovgAwlvO6AECZ3ajrNB2xOycJqP1QBNuBOJGGjSYi2SQSJpoO0MP yXlscFspBqYvxrYtxHYjhX9BbCds02L7wDCvl19wc7uYoR7vkFysiXzHGVw5JxTkIg6Jis1RXTCn XL/+mxLRHWnbLildcbGBpUj7oXHAtMa54Pyi0ThBjxin6B1X8I7TIrzAOwnbNO+M69ksd9xJU2Ap BA98lHUqrsIqPMoGRnAVDeMLhjG+r9W5YXjTBCmanLEzzc2+EC32YfmJjt8VPWyzKB1OAM7tylA1 TEQXsg7mAvAcftmcyIVH6Fk9XQSnmCTtB65pK0Q1VHcVVYYryjiBnglPlCYT/KuYgTD7h8GWi75s JrdsWkuh3cE0upns24TzRNh3lfPAMK/XixmYervDVvX9PZGfVkjezgDq1RIpNjt1eSaVhQXYUuSg FAwdWwgdTG3O5sysS70V0rL24WOnK3RH1mHrlcRcNwAlAbdxTR8YNrStgCTGDZJBIOnJThg4luLG nqpcqeRi2ISpnbYGLax7SUJIGLugWWPg39NpuIkJYUWn4f4ulpp90aGOdrfDjwd6xrXYfbtz0DGv ry6R6zLmGyqDi9gWPyC1pookbnrlG1r3HHuDy59iG08s1GRvL9vGrjvHgViwr6N+gsHhZKBWIcMh YsctSqfcWRDa5GxFd4HkU7YKTviXeChlnHSsE4Z5/dy2GVvc5uqeSK7mK4TZQM68b6S5ow9ChZzl 53KayNb+8ku5uc4WX3JrwQkzWXBbqvJNUhDd0lxgZax9n5Bs6KGhfl46auqhHyC4EKPpvdETYRiH IaGHMJi1mPbswC/lIIRCEHqso2NBWG6oErZ5/Sd3XChefaZiQpMDqoAW+yV4AdqErTswscve9FP4 BVX+U81aIuXUFnRhC8Zl1Wr6qU8Yp536A8O8vo1H/ZF2vNgRuaPkypZwtBsdoXGs2NdyqvtzeoT1 PeUbEfvH14ThkTD8uug7zQXVkB/jRzuGUA2JVBUnoXdIviu3XhxYtvLi1OrHoJZdayb3bUphjTEv 6dtSzmmuPjCgq2PftqFmbf0HkR8WSG6oH1mWr684xCWHd8n2CDH6EVXfbVH1kp0q22aPVfstZ6eu gzvWWvadndo8KVDCm5cc0oRxmucODPP6t9hZPce4/0Bkl6HKhzSV0CYyamFe789We8oWJI/1Yjun Z6LKpizM6BBwEh4zXjlJJ2wnS0qqYorjC4MzYHWCF6BN2CbdKCQM8/qJsuEy5sAP5J0N6+O29GTM rY8n3EZnXP1Nj6a8Wuj6ug6dMQt/04PdjrIjZik7pik4xinqtb/aMQnbNMccGOb1A40x9/E+bPkB yadNrFPL/iyxrw46i49jxvw5L+RP7UdQl+0WCnYzNsumk3NXythiYN8PYe6CdP2p11OFKQhUIzyM SBl5IZWsHW6N41TSDznLUdHe42WonumIrp9iUJRnpYwteelgLX2US2jGy155tONKttZSYFpWentR Nk16e0eWrY1zj/b9eww2ARjswqzl3XkcFIWpBABEmBoUh7VfGxQJ56SgGNe0++PhVPo+VnTI4f+l jEO3GP9hqzM63XveKMemLYxQWDkB1DTTJmsHpi1nkpSv3e+fxUzCYjreWWGy8hi8o2jLBSNla8F+ LBQMna4/BbbwCtVhld1LYa3TuiFbW9bYd7jxdweIVDYaT2ag0ozcgBMsTmdGarr8WtMDRX2fkUDP 8YH3GGIeHzjqr/HB546LDjjuXrdiJMUjLUIbRzENfd2SUih6R9nQ5UQr4HYMad9AIkirQgQJnXSD g0GE3CM0cVIITYfQeIjKG58gNKjUNRhHrQxFs532inqZDiHKiKQNZFSNtvW+hNAPfu9B9/rJqGDx NOLgaGD/0jEafV7/Y6aw0/p99grbhxV2Db5esi+skRmHnUTGKQc3AwfrYHHoBgGhdzANVLhv73vz NQ4fSGE66zmJC9A9WK4O1lO0BghEZz1J9zaWgqOzHororYdfuYR/1Hjh4F6CqHCHGURomhwiNC6H iMPZECI0PocIARKIKOIAERpThqj7pqRTCDrsIbaIHH7Rym4hY8SoqKzbFGh3DBEDFZvKzR6Gi1J7 hG5/7GTb9MlSCOqxEoklBaOX7q9tGnVv7umHRdRxfGGDTcX7/QPrqV/1jJURi0bAAoOtn+5k/HOF mgtzKkhDfWLGU9Y7luQ1pk3sLjBz7UU4/Hvl2CJGtddkLFNshLnODfSUoI6l+BYqHsr+t1ubp/Vu xWjEQ4ZJNF3NdWfxJXq+9DleEqyf+ASjAv3cJ+U52s//AZQUpbMNCmVuZHN0cmVhbQ0KZW5kb2Jq DQoxMDkgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8 L0YxIDUgMCBSL0Y3IDc4IDAgUi9GMTAgMTExIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdl Qi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxMTAg MCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJz L1MvU3RydWN0UGFyZW50cyAzMD4+DQplbmRvYmoNCjExMCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxNjY3Pj4NCnN0cmVhbQ0KeJydWUtv20YQvgvQf1joRAXNemefXCPwwXZS pEDSFHXQg5CDYtG2Wkt2JTlIWvS/d2ZJSkuGSyq+0MvVPHa+mZ0HzU4+sFevTt5dvL1k4uyMnV9e sL/HI8EEF0KAlMIxJwUzWrBNMR798YKtxyNgt3saISwI3SC6eTEe/TYesdfvLhiLFECl4PxqPDp5 A0xrLqxmVzckEcUxYKAVl4ppk3Pj2dWK1ARdP49Hs+z11yn4bL56vC9O2dTg+26aZ8V6MX0ps2LB pir7uC0200/s6pfx6DWqIVW1bOMsz20se5axiPa788rGeR0e7vvzGselZMoD97XMfxP6wRpuW7S9 +lWH/m71znAoRbKX6BWJVNconKVO4lBSk00EjskWIby+w0cxBZGt5rjaTqYgs1MCd0abkydcbdb4 OA3UtLdcla9I2OY+JZoHYqG9gl6BE6GY4PKnlK9ETiBFJxzASkdYtdFBh6u9ELIjetCh6lc8VLXZ fSiJsGnflPcMNIqv+NgFNIhvuyTChyBiv7krSOxjDduSZCN2SIjgqUwER3zqAdAa4Eq3bO8D0PQA qKG+MT8UXhFbFV5LPPFiUlvKaCXzYJWvwZMSVyrlAe+59bHkWfYyQaswhESL1t2gcEdqbIqLyN2R GrTnvkWrDZmj5imWXHFtjhSPicKZFPoe/CLBqKXhynTgn9KklWppQkMgGJIjYDYsvcClDthp2uy9 vkbwFvS9wWd7gk9q7p4RfBFbFXwphlxy3WCYVVe0ILPD3Z7f0/JtCnBpLZfQFDEhpELWTCmugznm +vwnXfQ1adtSClinYoPutWuDA7oEZ5Lyi0JwvOoAp9c7rsc7wtXF7Ie8E7Ed550Dwyx7CtlwQyC9 p6y6KlII4wXV0GSenNZpP+kXVJn7JlftF0VuQb1Jv1TpoxuWtF/QndJ0wNLrl/zo/kRiKgF3OI/K j/NTzFf56Qn7LrwThlI4ZNtrXGG9A00Fz1AKh+yuwBXWO0P1zlD5gww7NRMCW1PBM9kDba5Py01D d81QqYPscUMSt0RY0M9Am1zgakKvLNVdGeO5ig88AJ4/trmiqq9cR4inwfOC503GgSDHTNDUhClo RXH2eI8h9/CNlgXlg/cUuE/UX3wOHUIqnsBSp9IQOAntQ6i5Tuxrbk4CdV8u1ygrV01ZvciCSOcL iX/Ms8CMGI8D88AwowaUMuoOzbwo7++u7stSEFZZoCGmzB0EVlUdqSSmLzVWBWuaEvqBgx7gtODu WcBFjBVw+278lrLnOvSf/8zrpnRJP69Dk1ZWL9z7SJlv+SWE4YaSIG3OKTbZ78RHTfBiz1xODMl4 8pJ6+uhcQ7DIHlikohbsGbBEjBUsC7KRjPiybLblUSm/wscd3bxVaNVp78M8tAl/1YRJuwUWaBMr HrJb9diNlQKeZXfEGNkdrsIjxcBmR+asyuYDN3eHSCDjH0ICohhgv4YEVdTBNKcrVQbPdhALrHcO 4sMMYaGPrnVkKE4+HbVuCJuYs8JmhSVnHkoVlbPbgsrSZlJXv2QxojIkfSxwyD5zbDkCp7jRnZ5P 2kc42yZrfw6VYLB/j+hn5fy6DrF+u/d5uiOuAIglHLKnDFME0KeAMP15Wpr+MaghKjnIlHcsgZEV OMP0TkDfI5TUpGVL06wajiDM5wkuZ7hVR9qCo6KHJm3u6ruqU20QOBr4j9JgcE50LVpNTcEir6fx Ob3eBCeJvE7yyYpntcJb2RTYH/Y9gx8Yy90zAz1iPSrQD/SzbBGy/yOZfE8x/41M7p4zTt6A6Lip 1ZeHWOorIYQRAi7PFC3VGYhqS5ZbRgqhz89A0hoCCW0rW1IiodAXJaULlLQ8V2ftA3VlDgpuirrY yn639Ex8oDz33W4ZyK4RY+mU/3o6OIjph46b9xwXyy10Hbd/8InZBg6LfaKK6YcO63sOK+yhXiQV lp+RG7T9n7Hrfjx8Snd4Q1weJk6hGHKDxUYXZ89cUHTc04YKnzldzpWkjbCg76ioGGjjriTC0q2c 56YUg/MXJhOFcBgoxeRBaC7LN8zi5SdnaSsZN12Hbf+TAPLm3UKgcMpGzO3h3wOz7LK4vp/abL6Z SsCCbbNdGDJTYzpIwX0eyxnCsKsHtXQWSV9iahkft6lPEV4jELpJ3a9Rtb1mbRjCMDoPXpPeVT4h hxgqvAhw7TSMD+mg5bQcaXA63PvMhQ9RytQ+I5F1IED5M5Y62fLZ/1ijMBwNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoxMTEgMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1R5cGUwL0Jhc2VGb250L0FC Q0RFRStDb3VyaWVyIzIwTmV3L0VuY29kaW5nL0lkZW50aXR5LUgvRGVzY2VuZGFudEZvbnRzIDEx MiAwIFIvVG9Vbmljb2RlIDEzNzUgMCBSPj4NCmVuZG9iag0KMTEyIDAgb2JqDQpbIDExMyAwIFJd IA0KZW5kb2JqDQoxMTMgMCBvYmoNCjw8L0Jhc2VGb250L0FCQ0RFRStDb3VyaWVyIzIwTmV3L1N1 YnR5cGUvQ0lERm9udFR5cGUyL1R5cGUvRm9udC9DSURUb0dJRE1hcC9JZGVudGl0eS9EVyAxMDAw L0NJRFN5c3RlbUluZm8gMTE0IDAgUi9Gb250RGVzY3JpcHRvciAxMTUgMCBSL1cgMTM3NyAwIFI+ Pg0KZW5kb2JqDQoxMTQgMCBvYmoNCjw8L09yZGVyaW5nKElkZW50aXR5KSAvUmVnaXN0cnkoQWRv YmUpIC9TdXBwbGVtZW50IDA+Pg0KZW5kb2JqDQoxMTUgMCBvYmoNCjw8L1R5cGUvRm9udERlc2Ny aXB0b3IvRm9udE5hbWUvQUJDREVFK0NvdXJpZXIjMjBOZXcvRmxhZ3MgMzIvSXRhbGljQW5nbGUg MC9Bc2NlbnQgODMzL0Rlc2NlbnQgLTE4OC9DYXBIZWlnaHQgNjEzL0F2Z1dpZHRoIDYwMC9NYXhX aWR0aCA3NDQvRm9udFdlaWdodCA0MDAvWEhlaWdodCAyNTAvU3RlbVYgNjAvRm9udEJCb3hbIC0x MjIgLTE4OCA2MjMgNjEzXSAvRm9udEZpbGUyIDEzNzYgMCBSPj4NCmVuZG9iag0KMTE2IDAgb2Jq DQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9G NyA3OCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVk aWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTE3IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAv Uy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgMzE+Pg0K ZW5kb2JqDQoxMTcgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTQ1MT4+DQpz dHJlYW0NCnicrVjdb9s2EH834P+B8MNAFQvD44dIBkUfkmZBC6TrhhR7cPPgNU4bwE48uykWbP3f dydZCeWIlGrsRabk++bd745kh+/Zy5eH5ydvXjP56hU7fn3C/hqPJJNCSglKSceckswaydbz8eiP F+x2PAL2+ZFGyhKkaRFdvxiPfhuP2On5CWORAtgqOL4Yjw5/AWaMkKVhF9ckEcUxYAqcKEtmrBc2 sIslqal0nY1HU376dwGez5arxfyIFYafrQuw/O6+OFB8VVyyi7fj0SkKJwWNRCuVMCaWOOUson1m pWpZ6Rg8txKsE0oxHUCERuY/Cf1QWlHu0Gb16w793eqdFVCLZAe4FwqpPqFwlrLEoaQ2m6w4JptC 809f8DEvQPLlDFebSQGKY5Q1n9LHyT2u1rf4OKqo6dvNsn5Fwl3uI6K5Ixb6NqdXEEQoJ7i8pI8/ pzYMU0CH2MyegJkoYLshwl3Xe4QoYtuG6AbNviLbj8h2RivlySEITTiUwpVOSFYhiDLEkqf8IEGr pRdyh9Zdo3BHasoUlwFh3UANJoiwQ2ssuaNnKRavhbEDxWOyO5uKfoBwlWA0ygptO+Kf0mS03tGE jkDliMeAldUySFyaKnaGPtLmJbPPSrET+mzy2Uzy0YbskXwR2zb5Ugweoa3FMOVXlKibFbm9oEp8 eEfL2bIqz0Rqol4T2mImVLFVll9QFd9T8NYEBmf3JO/mqin3TS6YBkrhdVtyNpplJprKCLdHNCO2 bTSrWNDjzwqb1rtol4/Sk7weX1zGF+maZtD2Je1NkMK3GWtvkm0H8QZi+h5r/eCup7C4wT0Zr/2T 9Un7cY6gLhjzNrkNwL/NCssXmFmGzye4PKKPjFaIsZYg1hLEAkGsTUJsVbQu1pFBqLIUpW3TIsRa glhIQqyRUoAdpsEgiFubjJaxSaQ1Ru1o6QNBxCyjk6pyeIugHuBHVAUlNLQjQHhrCG8t4a0luLUE t0Bwawlu8e8URJQyCFO2BWYTNQwdj6hgtessst40jVjzEKzAYruI6DsQmFDmHa2WKQTeNvyWmBqB q9Er3/BbXMezBtc2KS6cq6Rtc6XCse35Ldq3FWjSILiZ4+M2i//bxEzpen5CkGnQVPhj99zPiPUR diT/+oC2r+a0U1G0PzSurZOBpx7gYql9bkHGLSNJ2I/3gohxyr+ntoAiYFtK6gDk7VUZe5Wm0XEP eyPGIb0rou8zV2fMRf9hz6yJWKOs+UYltqjGoPmzA4Eeeh5omtWTjv5mFdP2nweaZjVEQ9OsuoM1 oFc9C1Vfr+rWNKBVDde0bVWx/+2jge44GeDffa0qFpjPSzN4qKIa0Wa/oSrmHdKtIvqqW9mqWxnq Vpa6FVC3sr3dqiUG8dMSfgKfnONqdksCrx6aj+/nuFqt8IHjtuU39O3qM71mhwPaQtjRlI+4HTod gNPCmr1wIWb9/7pJJLXPycwpCWwpXLdbeXSOGWunvmfROaLvMzdzEAIdROgyN3+oi9lqYy8zR2Qd 0/cZ6zPGYkOCRkoyOvV1X4s2r7EZaKuLTsCENTgNV3dfyEzBJujHDoA5sqAPXngEoZLo6B20oPFZ CQ/0/qXmUURihfW1ECxY7DUlRkETkcKaQAm1PCvor4j/uutSVO7c3YJvVZXRgk53jrrI463tlF8U xvEHLIoDqoeSf+SJsHnEVGNiCVP+YTNf/0tXvJrf3aeud4GuCdt8H4tkMkiahWLa/E1w19jmqKvg Bhuaq2ohv64Kx78SkN7dzhasOLD8p5QJFoTzLe68CV2TWGOCIjSvhfxeKM3nM7oITzVQQNh2ocWV ap2Uhdg6Y9K728VDitpYQq6YOu+Tbmc8JjDCX+mFCk22eot1AcJvUz4IS7tXtd9FXSRaV6XmfZT0 mJOEZihtuU1slBtQPDRJD0HVEl31ny+F9jtZ/x9XZ+LBDQplbmRzdHJlYW0NCmVuZG9iag0KMTE4 IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1 IDAgUi9GMiA5IDAgUi9GMyAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VD L0ltYWdlSV0gPj4vQW5ub3RzWyAxMjAgMCBSIDEyMSAwIFIgMTIyIDAgUiAxMjMgMCBSIDEyNCAw IFIgMTI1IDAgUiAxMjYgMCBSXSAvTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTE5 IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFi cy9TL1N0cnVjdFBhcmVudHMgMzI+Pg0KZW5kb2JqDQoxMTkgMCBvYmoNCjw8L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggNzMxPj4NCnN0cmVhbQ0KeJydVk1v2kAQvVvyf9jjLg3Lzn55XSGkBkib qpFScNpD1AN1IUEFTIFUyb/vrAOpHbBr9YLNeObNvJm3H6RzTbrdzlX/ckBEr0fOB33yKwwEEVwI AVKKiERSEKMF2UzD4GuLrMIAyN2LjxAWhC45zVph8DkMyPCqT0ghAewTnCdh0LkAojUXVpNk5hER jgCRznD8YBw3MUmWPkue6n0Y3NLrDQNLsx2LaZayiGYL9o0kH8NgiIAe9ICilSli3FJScDwqS5bK kkTJo7K04mh3giNwjtgVwkW9cnZP6URsJF7F0tGQgaJjZmnCQEh6RpimHxLWBkmTawbSeFNbogsI +rRK75G4o9kqe9hWMFYxcDDlNLWk1QnSpzgrzWX0b86nKBdCaX90M2CKkjdkPPXMJsjI0PS+hZbB fJt6otlv35bpxn9/Qvs5BjwsfmJvWhWsjbLcqXKmWta64ailcxwa0D416mIsHc+Xa6SxmJKr5BJf nufaz9Cq0cogoo+5KfOG3Rx/stWkUtcWl5wqZ6jla5pNWWq0x/815WIoHT6ytqK7fIyrrSfzfTFt nZEvTMd+sBBTtCqkOP1RJWSruFFl2FqKthlFiA2PXR1FVUWxHKrMsFF3nORS6lIwTW9Gn1iTvIBb o7NHmS9wt1U9gC7uzE6A6wswg57GvzAUEFl8vhNgLwT0m41QWs2jqFxkbbejht3WMa/Q0x5yvJ6s XlDdq4OhahAvqM/Gzd3hbZSfD/fMefFFdLd+i9rrdHIlZtliy73qpn6FzZiNKM/yk+QO1YpuXrN5 6HLR+bHx8RM8XGa7qkUY4VYbFynSdpWrA79ei67bdL6s3M3QzTQCNujjSm2mk7XfRuZVAS7mWjbD jmMubcGVtHHX0VqRJL2lQtTJI94P8u989oPTXFliLPhHPtzDPeH4kiAKYjjUZBVwa0sCOFwL8Luv q1a1ACcwnysTyjeyQvl/ANJz15wNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMjAgMCBvYmoNCjw8L1N1 YnR5cGUvTGluay9SZWN0WyA3MC4yIDE0MS4yNiA0NzEuMTkgMTgwLjM4XSAvQlM8PC9XIDA+Pi9G IDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zY2ltLWFwaS0wMCkgPj4vU3RydWN0UGFyZW50IDMzPj4NCmVuZG9iag0KMTIxIDAgb2Jq DQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDcxLjE5IDE0MS4yNiA0ODEuMDMgMTgwLjM4XSAvQlM8 PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zY2ltLWFwaS0wMCkgPj4vU3RydWN0UGFyZW50IDM0Pj4NCmVuZG9iag0K MTIyIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNDgxLjAzIDE0MS4yNiA1MzkuOTUgMTgw LjM4XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWFwaS0wMCkgPj4vU3RydWN0UGFyZW50IDM1Pj4N CmVuZG9iag0KMTIzIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNTM5Ljk1IDE0MS4yNiA1 NDkuODIgMTgwLjM4XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSSho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWFwaS0wMCkgPj4vU3RydWN0UGFy ZW50IDM2Pj4NCmVuZG9iag0KMTI0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNTQ5Ljgy IDE0MS4yNiA1ODkuNDIgMTgwLjM4XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWFwaS0wMCkgPj4v U3RydWN0UGFyZW50IDM3Pj4NCmVuZG9iag0KMTI1IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVj dFsgNTg5LjQyIDE0MS4yNiA1OTkuMjYgMTgwLjM4XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUv QWN0aW9uL1MvVVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2ltLWFw aS0wMCkgPj4vU3RydWN0UGFyZW50IDM4Pj4NCmVuZG9iag0KMTI2IDAgb2JqDQo8PC9TdWJ0eXBl L0xpbmsvUmVjdFsgNTk5LjI2IDE0MS4yNiA2MzEuNjYgMTgwLjM4XSAvQlM8PC9XIDA+Pi9GIDQv QTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zY2ltLWFwaS0wMCkgPj4vU3RydWN0UGFyZW50IDM5Pj4NCmVuZG9iag0KMTI3IDAgb2JqDQo8 PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA5 IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNb IDEyOSAwIFIgMTMwIDAgUiAxMzEgMCBSIDEzMiAwIFIgMTMzIDAgUiAxMzQgMCBSXSAvTWVkaWFC b3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTI4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9U cmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNDA+Pg0KZW5k b2JqDQoxMjggMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTExMj4+DQpzdHJl YW0NCniczZffbyI3EMffkfgf/FR5I53x7/VWIVVD6PVOvSZNOPUh6gOFTQ6VX2WX6iqO/71jQ8DL etltpFb3ggjxjL8zH894jDp36PKy86H37gbRqyt0fdNDf7ZbFFFCKWWc0xjFnCIlKVql7davF2je bjH0fFhDqWZUFhY9XbRbv7RbqP+hh5C3AdtvcD1otzo/MCQloVqiwZP1CO4QQ1xTkhgklSEqQYOZ 3cbt9bbdesS3y3QVsRgPoxjnk8U8i35Dg/ftVh8cWqcvXqRKCOO+l0eMvLUlZbygjCMOynhRmRSE I2FikrCdx0tKTXxVFGCjCtjG9MQW9yAOgdNhZHAeMYpTZD+7KFL47hY+HiKJBwHJD8vh/KBaeKoP CWScJP5eu59Xzy/f7l0mP0WM2Z0VzpeRxtm3nU7EOU6tqs8RM3g4W05TMooSvJh1QMzmr21nA6I1 TrPF2lEYpdEbjrfn8ir3Co8irD5jQKAggF5IQxKNGFH6cHJKTlQgTKUZSWQxzuM5Octal1gHOCtB hKrjHGDs2eH7PWJI0hjZfANeid/2a7nGgYCZUURJf4NKsPQAVu3BslOw0RuBAS4sBboltMqhFRh+ nozP8jUlvk4nJEImhALmhBEpa/gmIb5xDL2hGG5Dvow2AcwMiZNXAPbs8MfleLivI1fBEgjffRxA 2usIMxYqXZoQWdjia0DMeLmGrVDQKR3pJohZqFVpSl0N+/E2ZSwbNmxuJOGvbNi+Lb5Jp2nuCnrf qW/6P/UH/VrQoebFhd3R9/+fN+l6zLqMWUjE48Q26GaQQ31Lc9e3CrE2hWwaFDKHRqNf0al9O3zh KjkpFnIUa/x9FCd4YJPe+9GWSy3uUC/jIFQJf8evoa45LQMHodKAUGXLuwlyHupjWih3vP14GyLn 5UEsgJyB/1f0bt8OXzxAniQeujls9AkB/S46uZuLc5UkzHfxPzD8ztPiT1DSXq2cUWIAEwzMMOoW MBUvUklEWHcdC3Eyrlf1WGYoUYEp25fhAPgLnybT3La3dNW1sW725Qd5W01+X+/+VYWCc8J1wdsW 2SxvFkv4YqANukfCdJ1u0TdVigQkRicFL9kCKn+VX4OUv6teFkITE3tW9hEkNBqMHnF3U/kc0USK gpEzCMX883BWFbe9L5UJxF2I8ch3l/NYE26QUm4eKx2TqlphipG4dF6yxSq/tTmKmMRjeIuFhTIN Pd9zYXMEfeVsjuzcCAOfb7TLUbYrhvl4Mn/+Mk79P6vSTaV99h1duTxBmivPghTGPiN8i+ww2A1X +bv5eF/BYXslYFqNC/bdTfbytgMHW3sJ17OSse2/Stt8VZf0bi2377xTQCPYc7GeR4zjvDrV0N/h aj96eMQz+xD9fO9OYLae5lUPa64UMUnBdHsmHpjsNBy6xHWJqnC4hltHVQR0vkM1nQKNIYKf3kT/ dhw8OoHb43o9/aNmFuCh0Y+Bd8i9Lyh0jZTC/gch+rBaDQplbmRzdHJlYW0NCmVuZG9iag0KMTI5 IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMjEyLjkgMzgxLjQzIDU2MS45NCA0MTAuNzRd IC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZXhhbXBs ZS5jb20ve3Z9L3tyZXNvdXJjZX0pID4+L1N0cnVjdFBhcmVudCA0MT4+DQplbmRvYmoNCjEzMCAw IG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDE4NS41NCAzNDYuODcgNTc3LjA2IDM3Ni4xNV0g L0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cHM6Ly9leGFtcGxl LmNvbS97dn0ve3Jlc291cmNlfS97aWR9KSA+Pi9TdHJ1Y3RQYXJlbnQgNDI+Pg0KZW5kb2JqDQox MzEgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAyMDkuNDIgMzEyLjMxIDYwMC45NCAzNDEu NTldIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHBzOi8vZXhh bXBsZS5jb20ve3Z9L3tyZXNvdXJjZX0ve2lkfSkgPj4vU3RydWN0UGFyZW50IDQzPj4NCmVuZG9i ag0KMTMyIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMjM0LjA1IDI3Ny43MyA2MjUuNTQg MzA3LjAzXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwczov L2V4YW1wbGUuY29tL3t2fS97cmVzb3VyY2V9L3tpZH0pID4+L1N0cnVjdFBhcmVudCA0ND4+DQpl bmRvYmoNCjEzMyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDI0My41MyAyNDMuMTcgNjM1 LjAyIDI3Mi40NV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0 cHM6Ly9leGFtcGxlLmNvbS97dn0vcmVzb3VyY2Uve2lkfSkgPj4vU3RydWN0UGFyZW50IDQ1Pj4N CmVuZG9iag0KMTM0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMTI0LjM0IDgxLjg0IDEy OS43NCAxMTEuMTRdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0 dHBzOi8vZXhhbXBsZS5jb20ve3Z9L3tyZXNvdXJjZX0/ZmlsdGVyPXthdHRyaWJ1dGV9KSA+Pi9T dHJ1Y3RQYXJlbnQgNDY+Pg0KZW5kb2JqDQoxMzUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSL0YzIDE0IDAgUj4+L1By b2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcy MCA1NDBdIC9Db250ZW50cyAxMzYgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5j eS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0Nz4+DQplbmRvYmoNCjEzNiAw IG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA3Njc+Pg0Kc3RyZWFtDQp4nKWWW2vb MBTH3w3+DnqUC1V0dLUgeDSXlo6VdSSwQdlD5jqtYbksl7J9+x05bbDjy0L3EGJL+h/pf87Pxya9 e9Lv9+6GtyPCk4QMRkPyKww44YxzDkJwS6zgRCtONlkYfL0gyzAA8nRcw7kBriqL5hdh8CUMyPhu SEhpA3jdYDANg941EKUYN4pM5z4ihiNAhJXMEqVjph2ZLvwuxVY3YfBAR/k2jWK6ihR9iYDTbBNd avon+k6mH8NgjFF95LdQShmmyqEeKCktrZ1OVE4niBS10ynJcDxWDF4j9jmPbVLd3ztr0Fp+oqU3 YzQyJb1J+pwtZtsWG0JrZm1V2elDnvgQljlTPYrzR8H0CHu0MYAGG3UpcGA2rojp7TJydLeJwNHV dp2lO+LLgveKZtvVHi80TbMtjmLNZstHvFB0Flm6i0CiMMc0/NjjjaBZIc0isPS3X7XDyNlym0ea rpZtGTJgamfqzJBqqHRTobli7oxCN9W5JMU6TyNJSa/l+KCACVOVTDzaMX3J0+we82fo6iXHGI/Z Zrjy2Z77u6e2hCjpmNXViJ0J0echI4xlXL8TmbKYThATkvqqLtY/sfz5bJlmbQ+AA6agqu90Y07d VAsEoJnAUamY6KyurCmlbFDqMYeB5hC7w8+O8H/IwV1hb5SJ6WMbjRPB+8cpHObArw8yg/9myKXW xfK4f4jCReL6PkgCXgnYjPXVcZXyQ+PDtDxMS+2aynHCNShmXcVBdy7teWSAi32N3kdGWUyv9rvn bFk0hjxF0os+kSP0+ARhA5F067tl1oa+tJrFrhqy02B8FixgNDOiuxU0w1JW0s++x3mH0b9Zc5q5 +GTjt/IjU1wgR0Yll4As4AVyaD0WfvrSI+H54gIR8eSMXhH5P3ok9jYrq5Y6k+vOpEdgv1Lvpack pqMZfh8Ur5UZmUdC0tVmUQy1vl2V812lEqTTEvAaMIw3Q+NMceRuZuriAzclMZ3s12v/0bPBN6uh 3+4+fWhzgwUyuqKtmfkL6fUH2Q0KZW5kc3RyZWFtDQplbmRvYmoNCjEzNyAwIG9iag0KPDwvVHlw ZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjcgNzggMCBS L0YzIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxMzggMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0OD4+ DQplbmRvYmoNCjEzOCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxNTA3Pj4N CnN0cmVhbQ0KeJyVWFlvGzcQfheg/0D4aRXUNIc3DUNA4thtAuRoqqJAjTwojhw7iI/4CJoW/e/9 hispS1lcqQ9L7TEH55uDMxJ7b8XBwd6rwxfPhRqPxbPnh+LrcKCEkkop0loFEbQSzipxOxsO/ngi roYDEp+WNEp5UrYgOnsyHPw6HIijV4dCdBTQXMGzyXCwd0zCWqm8FZMzlghxgoTWeKeFdVG6JCaX rCbr+nk4OGkOb0dkmtl05Jv7EVEzEyPXvBtRaGZfH0a7upndjRI+vReTl8PBEdSwqoVsm5xMviv7 pBEd2kf71cV+g6BY7NWT1MJ4Kx3Npb1989soNBOBZe8b8fo7ljtcs1teRWVnWmvpSlG/sKDJW5bB giQuqnAbFaVdYe+1y3TsKo2xWqblDq55yzUw4XNpugxiV0nSYnJ60uzX7CTtZIgFl8ocs7+ganqJ 5QbXlxmbe3qN5bKGmDUypnLDvTbbqs2apFmIeHp6ys666TN8bkOXrW6wDVL7knh6szDzgpVN77Fc XF+xp2vGBi91KqV8ngcWGCtRQUmSKZl6EXI1hHRKMiwReuD9nrNvbi/+Xu6/bydaEed0IWafs+EZ Yz29zenRlx0pSO9K/nMbwaE+Yvl8l7Cacyz8GGvZr730oZTSi4ev4hGiVIsC8k9FXVih61UVqqqc l3YpogZQ1DJqWxLvVGiTkU6t0N5xHJ7POP2md7VI9lGGRzoCQv8Ea01bW9gKpgeOnCv2f1bLkXO5 z5F8yh6cXU75C3/mr9e3M9aRK6CqlnUgZR7v7P1PFQanjTRpBds+98Sqe4zlKrSle7rEm9zTpc3F 8T6nyBWj8wXXi48bkq1Uxn7qcxOfxFQyfeAKM7tanF99ZUa7LmvnINipucBYJX2hcH4Q9PohVf1A hgvkln7oEm/yQ5f2oT3IXy+OqlktVUKSdmVTO/tV7IlkKInn0PfirqOXqeDbCve2VehybYE7qUeN EGLMPm6GCKno/XI3iqxtpW9wSZev3c8Gv3QYTjgpYnNZ9Ybx0sWSY54QsVq95y4smPohoi16RQrA ZJ24lYOjpBM9R2PbhRX0NeSIrEyxpD3LcXzBBeU7rte9Yd3W8hVdjGM1sr3jAltwvOR6notKvaLo JNOqUdWAdiQt1ZF97ChdKyJkkRvbeKeg28I7XfpN3unSfrr4tijBbc2peiaXkFJPbrB2uMPKDdaH fDPtOQPmJbmKwmMkq2MEodWKfstyXBD/uyHtC8G9m6v2+6Qct+T9+sIKXb+uReecR1UoUWC3qLSY bcEduM1A9w57EdZf8AJR4TAURGIKvMBAmnQES5DG84tzECF3dMhcqNQsBh8dv/BzIh5CcPGdAr/P tG7OfrZun35l/l6pURhssG/EEsrlcvI+ad7coPXQ1OSp+wIDd7XRR2vNx0JHxCbkQhc5DcRVWMAA boqJEfoBFMXAc/ISSa3y3Rzr1nKKGO+7wBGCR4Uf6BAiaA4cblsF/gfwa5Fb1wESSo9eB9i7kTb8 T8Suaa4fbkdk0crihZiMrG2+31SzGP1odP8HvdRFzyBxOSSc4f4P3Ab12iPujJaUDedREA2CQdNF +ZmHUzy7XHpa65mGeQxTZiGeZ2SDApMBMogZY9RCnEPdMIHrRh08rdaAx1xoG5EH7IAOeMcj0mj7 8xhQG8EN4iIVzJv+yKEuUtazDY7BBqs1imPIoCVy2Qyr26gjx1Mnv/CeR0beMvK4NZS5kLIGZRvO ymIsx5AhzR1DFpOf8i2IcRByq6xiH1LrziZrkZYIX/w410UKk/j5n7WZCAipgmkTQqaoYQob5lnZ MM7gdhgQYJZGjGWLnM05pR1azraEpShjBIfjhr41kYkiiGySFFopUSJ+NOIuulaMwpNfSOSmGeHr +1JR26KImdUi5qznP/n4P4MCrgNl3JFSPipKShEdjXfNgaJ4ON61hj8eK6XMmMKBUi6MtcVHpceU 8HsYFPnjMdOH5/wa/E/HJfJr6ql3XK06O1njg/8A7dg8Lg0KZW5kc3RyZWFtDQplbmRvYmoNCjEz OSAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg NSAwIFIvRjcgNzggMCBSL0YzIDE0IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn ZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDE0MSAwIFJdIC9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9D b250ZW50cyAxNDAgMCBSL0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZp Y2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA0OT4+DQplbmRvYmoNCjE0MCAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAyMjg1Pj4NCnN0cmVhbQ0KeJylWktvGzkSvhvwfyB0 ag3WNN8PI/AhjrObwSbIZLQIsJo5aBzZ8UCys5ISzGCx/31YxVaLLVVTEdaHdptufqwq1lesqm52 +Z69eHH59ubNKyaur9nLVzfsP+dnggkuhJBKCc+8EswawVbz87OPP7Cn8zPJHrpnhHBSmN5D9z+c n/10fsZu394wViwg2wVeTs7PLl9LZgwXzrDJPSAmOCaZkoJHw4wN3EY2WcIyuNbfz8+mzc1qLFUz n41dsxlL0czZ2DQfxtI38/WX8YVunp/GF6pZz8e/ssmP52e3aSFYbItuReTSlejThhXPHkisehJ7 Ji2Priewk1wx7QOXW8B/TECGyXu4Xkq48vFFaCSDWyXgKmGA3cDtag7X2Qaucxj+NCC7spp73V+K DTybhUpaxvwk7JRKhr5LJnx+2syfNgMTpUqWMf2pOO1iaIJO4vQmTJvJn6DMl6RN2qIrVHv2BYcW cH0ELe9mcLt5hOszDDxdDqygpeRaD2jz+zrt+MA8E3mwhCp1o+nI/VaRfz6DeIeiXsEt4Tc/f5k9 da6jC9fprGU916ZcJI+vHrZ3H9DPP2/Qdhu02hqXu7zsPOQPFGiJ/1zAwJyjnCjtEp/7hh6Ht/9a dxNXeHup4Bpkze9NK/xOPBQd7GO5Tb+E5yHtg43pp+P8AYwlbGCcBQfu2WDHcKQK5zXZHAUaDVe6 v3tVYnsCJDuAEtvYUPjZ7WT2UIMLBFyM3KXpPUAEy5T4CJpe1kAj5UEt33ag02ZUA5GCQjGe+z2U OYaqAFIJjEnzAFdzD1cBw85j7PotR7DampJYU0XFpT5FckWgaCExCpYo1Y2WFA/zTicovcX4bxXD EBheJAb0MOpyUFxAOVRIhvH7HsfqaBQJguCmj4ZII2T93ecuDCwxfqxHcL3Ck2gKt6OveB49dcPr OwzXy72Bz+gdLQgMX+Hw86pb4CqfenjUjX6F69+qylBkNN7wKEt1jhmY4mA2sFM8nmpginzZwCVa NjAeDZ8Ke+KtCt1RH9FCCgOvruYbFFuVMty5cuH+eXyIQvJPpxC5h+JBuHuktasCUlRUXvEgTxGL oiJssNlDMSCW1Zg4VAEpXkJoiPoUsShmap0CzB5KRLeO+0naISBFTu0iF/YUsShWQPbn9lCMzG6V xAoOXS5iyDZ5W9OwweFRlYSKoo+Vmps9K9TzZYo2mYQmpa8nklBTbMgkLNEyCatAFCFiFqOASofg H5jr5dQ1h8IZJq1vju66pjgig0PSkcqPrlhdapIvbTA4MMBvv6PQ820FlK5PVXSKPO0hPSBv1YE0 SaOcvB9KW993ikDZi5L29lQvooiUvahEyyriYTff5NCTtnyUc/1qeqAp6kjnU3FbLnFM6WHqCMs1 oXRdbUORp81Je4hZcTyhVlhNzLYcSIdaYYPRXv1aLyDIIyiVsE6Wqx+JgYY8d5zmSg5YRYQqXu0E OrBJXbQafUoFBYbnCZ798qoL1Qpvjen6AwHTBfXv46HaDJVVes+2df8YJBkErVRjnOpvFM1af+sh Hg/XhiSUiFz1hJs2ixnGvDXy9e1z57GPWLQ8ti5cW4kiXRtieysBB9JKp5HAUhRsK5geetXTLEWl NrDSW1UngSXrqpzvHG5UXTSKT9oIIEFPQSBBMl+dBaErQL+HBZYiYJuw9Naueq0dLMukc9CJPJEF lmLVlgUlYmbBomsqHXaZcj2BvYIRFm8bGO71hLCFgF5e7wnhc9/Q9tWeEHo0TuT8O3aAYrxNJ6sP pa7HdmCwbmu7FKfuAEXp7Q6UiHkHvu1Z4vE5Z057597HakeqUrUVS06bX36pwlTKth5MtWvkyDMT Wu3yJGHIozIf4D2YEfqfDEjw/7dz5ChSG+Gh2XOK8OQJKT00HmmvGlUPJEf2HLXjVhI+VXVPN9h5 bHvvJ+W2jiIP5rYF2rT5X5XHboAx3pi+UMe18xQTsnbp+NYnaucpQmTtSrS8gblYW3Z0zuytJu6e LNms58aVKxzTuWTK9iVRMIdviVLBKVVnAQEvkr4jnnmKEm08KxGPp1WeYkWbVu2Qps09Vj7Lx8Wf 75DUs+W8CkuRA/LQZMUSdnQ1+nF8EVOFuoYiNQHXjxdPNkBy3lPi1q0XiM0h3uB5waM69ajxlaOm BDy+NYHs0uet2SFNm4dHNNy3XN6/68rU+g4FikcyWh5cDz1TZvSyg11hxJ6tduVwdZlKw75cpmrT MNivtwmI2KIqGMUdDCA7sGPRMVCsaaNjKdLx4BgGKy6t4KXaaaoNdjVKsO/wPPLVVZZihzRtvuaU cYX+9y5nm3WnI19f5bSwBB7hG4OqjJFkR/bfEgpaYGrbAcMkuNoBi2S+lbsLfQlrIEOt8ah7INXN jINOn+oZ3flpFWLwHVUJUZdi6+n4QlbqyIVnRgnuDFvCG2DDLdPRgGoL+FtxnTYgangABlJClP5l ZITxNPAZHsKCDGapmFFsnhXah6SFvwTemoBmi7BQnn9Pyel6MR26rL2ALoWGuGmU5jbs3jBPmw9j pZv5Gj4U+brYjHXD7saxef409LmIDCm1K3GOGdCXBtTKoxgpACalljCQ353nWLiAAc0FfNIhoVWI AwYCihEKTJ8tAGPK51kxwwQu00b4pGVoZzHtWoC0Wx7/52LNhBTrVZRZYLtnt9fw1c3zajkb+2bo yxFtNI/l3GO2iqWtWi+D1xtoKsRJfmHx8FjAQPLikAbwTQQMyMANaBohP82aGmFwDBzTZpgApz0M uDxLJPub0N5yA1+uOGiYDZtKCtFzN+gu5BhduJz2lsMuJIextjDdC6HtrRCpUlb6hZDyVshwI6S3 QgolpHt9bdOwfXVt0i/v0shNmvH6um/j7OMHixqHzC4WPfaKVMjS6NY7qFA1fJCh0FwRu+I+eT16 kwkh5TJpIILfLmCG4SGAs8Gv1ughQhmk4M2UySgaYjzCZEunMK2SgUToQJkKGl6H1cyu6iy3qZxD Xti+yZuf37PE6oexwZNAw5mlUhKbvxmzzfwTDLI3r4Y+A0pRO4YSl7DqX6JC10oNCmVuZHN0cmVh bQ0KZW5kb2JqDQoxNDEgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAxNTcuMzQgMzM0Ljk5 IDQ2NS4xOSAzNTMuMTFdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJ KGh0dHBzOi8vZXhhbXBsZS5jb20vdjEvVXNlcnMvMjgxKSA+Pi9TdHJ1Y3RQYXJlbnQgNTA+Pg0K ZW5kb2JqDQoxNDIgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDUgMCBSL0Y3IDc4IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxNDMgMCBSL0dy b3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3Ry dWN0UGFyZW50cyA1MT4+DQplbmRvYmoNCjE0MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCA5MTI+Pg0Kc3RyZWFtDQp4nJVW227bRhB9F6B/2EcygFc7s/fACFBf4qZAkJuKPhh9 UB26dmBHjiQXbb++Z1aUTcqi7D5wwCVmzs6cPTNLNfmoDg8n74/fnSjz5o06OjlWP8Yjo4w2xhCz iSqyUd4ZtWjGo99eqe/jEak/H3yMCWRcz+ny1Xj0aTxSp++PlepsQO0GR9PxaPKWlHPaBKeml4II OEWKvdHeKeeT9llNb2WbstfZeHRenTW1rVaqdtXnmmLV/LivD7hqlnWqVvXvavrLeHQKbMHfALqQ tQ9dwPNKdXyfJMm9JKOi1EswkGZlCVlSi3Z2Oq1jD7O7P7jRth8wGXIlp3Pq+/5FE4D/uoRp8CyW suQEQ/lCXhnGDgByjjr4PuDBgK81Sbst33gJ8BiGIjxpRy9ED6x5y9d5SX02dG7Ga8ovQ3fkdYp9 30wZ8F+HIiCH/EJmREFh6wgdWaCnIOeAJxsHG4rR32CXc5jvA4DB87Yk9irSPlGkNuyeqpJT0mmj 8Z/nyzoPdsValZ0AdWA0WYBenFevB7XMXsfUCzMlovkbHTi7hblD3TeNxtYXcyxvh5TprED0Mt7L gXtBV3KImjdoP92vkMqVnMPi+l/Ymayv8cyHzoUNgdg+zGtp7SPpvtlC7GJPq7ft1ou/ctKr5ivM t6Uo0l4VWUI8Q3LjoEPso+ylxrfUlEEJIkzEgPJOY7IiOAbtMvqIIXirbvABJ4+BaDmKBz5IKzDG jrfaBvlwBSevHccShSQEJiIKHyy3TtCB5RIfDeJD8fVt+OWONMPW8N86QUhL0o7a+8exf159uAPl TNWsDtXquvbDp5dz6YoOxDO8xS5vjHGDq64lAcGUsvDzSBMlAHd4ZMPy1jK9rpugZ9+ljbItsBtu KIUNbXgtGzwwOsBb6vD20IgYvbyLrs81W7kPD2w1v1/U5KoL3JiNmtbOVf/cNUPK9UEn/z+4y13u bGQZC9ZFaR8EW4fSRHNBUynbOgxzLjRQWcd1/i7JhbeuXXxy4ZvWIPgTkBCMnLDG4A114orRaS3p QHuoI7ODOyuzQmo1Qn+Huy8r4Wv2x02j3slvxcmeBpWb6RHgGbKIumz5jIsWKnClPQPALK9lVkoJ KNiEUrcrdXtMFdnOkU4bnYlTS7C3axi4u8KIKeoM1mzYCkzl/mIn2tzDFu9gy+OkbLnq+0J7WxNX 88XtDJNs6JIJbMv/zGPwDqL+A5+IEAkNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNDQgMCBvYmoNCjw8 L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0Y3IDc4 IDAgUi9GMyAxNCAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTQ1IDAgUi9Hcm91cDw8L1R5cGUv R3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMg NTI+Pg0KZW5kb2JqDQoxNDUgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTg4 ND4+DQpzdHJlYW0NCnicpVndbxpHEH+3xP+wuqcjqpf9/kCWH2I7adImTVOiSCV5IA6OHYFJwbFS Vf3fOzN74DtgD3BfTsfezOx8/OZjF9Z7w05Oeq/OXpwzcXrKnp6fsb86R4IJLoSQSgnPvBLMGsHm 487R+yfstnMk2ZcVjRBOCtMgunrSOfq9c8QuXp0xVttAVhs8HXSOes8kM4YLZ9jgCiWCOCaZ0p5r w4wN3EY2mOI2tNfzztGwfD7u6vKOdW35tit9OV586x6rcnaLz8W4+5ENXnaOLkA67rAUaYLiriFy WLIa7YaaqqGmZ9Ly6BpaOskV00FzpSuBPw9Qh8EbfPYkPnn3OJSS4asS+BS4wH7D118yqiphuQ1N ySxDm3Rw4EJJlBgNBc68HJZns9u78e1dhlEqcIRpshLbcY5BBy4bDMNy8Dfa8W3cPZai7JOVIwrG twk+b9DWyxG+3t1QjHDhtpfZQUvJtc5Y83UBAc7wmciD3WJKu9MAd2FpyK8zVG9T1T6+smtaxoU7 sm5By70ePse4/IMYp/RxggtjTvJI6pTo7gkI9PpusWKc02tP4TPIHHSd5TI2FSZccZ7jiAah0+Bo d4ay3G34/GIw+pLhipE7oGrwEU9CwXtUr1eQnZQHARfEmBYCPs3VKhucx1f5iZ65nIiKS13fb1gW OTwIyf0abbv1wnGzpPwnQ+kFD03KVpkqeK42PMpyPEFw0+Qh+oLwcXm9AsyUkLYgz/aplAzxtfiO z/ntanlxSQk4XVu4pghUQnC5T8uz+WqDfipbVKuKj/j8KQcyb3iUdaU3XbIsnMFsVk7lPHxYeUhg dd3tojpTctHN56JPBYgVCnII3+KlUjqHJGW4c3VB+ZqnNOTRGi2A1ZdX3uVYvMKc20889CSzRmtQ vNWjHLaV4FHvJ15rwe0abZQRo/w5x+IiF3ZP8T5wt0ZrpEbxwclICDIOfxpX5EBkpeZmTccciLZ0 X2UC9+HALKvzJAjlilwSWWMYluMf1AxSy0sJN6Jm96LNrzI4AtJWdYs+y2mwBOuGyp++kgLj5dAD z1x7rEpnZu9cYKpmvLlze9VTEUeXw+JR50lKUdka35Fz0a1F6sO50iwBPcLVBe1SUwqut6iZVbRq dw2+pCrVzzn1/NESGQpw8KB18TD8SRoCcnGyGvtVbY+WyuE0Ft3tdoiwo95sWJHdpoJOXSVBDWJA I4skCynlFb0asxp6A7V59Sc1kmwPgdFGr9ncGjkZJZePiFyDrzXppYhcNTYalpMRZduCEPlqtorw DQ0xN1XIW1O4IW/VsPaERjXRNGRky3JK3O2OykKj6hWbbspuYwRCo6GSSN23HRthNQ7uwEbVGho7 HDJfSC+pZ2zMFzuxUmdMWJnM0lHm7mZGJt5SzcaBqjoWLPo9+tAb/xhNlycgPAdczqbpw73svVsW axz8eyrQB8k5L9rmLAtVEkpwTauDWqS0inv3iIyp8yUv3K+dW25mqe+s1br3OzLhQfCw/PChffRq EOcOjsrQyW9PwanMNogLymCZAvI/TilGeLxd2E8RIz0e67bHp8iVJ6Mdt3JLdNrLptbcbgFBW1+u 8QzLf3PoBLR4Y5ob7KGPNFwfqk+dJzkpjV/TFSwTCrNjgvXcuLqcHVpGOHc/InPqbPu0mgf6YXmV Os2U7iAmdL3yGi1bGpm/MQLL6oKSK4qXW8ZEdNSOsa8u6ZCa62FdP6bmNhj3cVqNYVh+oZum+/Ht 68p9OUdJMCy4JnPRL54mtvmn0Ty97bhaaPAfUIutA+4DYV/j2Z2GjQ32uAODcnWoPg2efY5PNYZh +T3dfc3Jy6/TtVk2WM7xuMZf0B1FFhspvA0OPCmpZQZQT84elNJQvbZf/pgP5/AGbXvFC5BXqzC2 3TE1KFuvqHV1RU2X41LD0d0zowIXmgGztIZbaEmKa8Um+Fth3TMAYSDABWglYINRABqDC9dIREMX EjmfpNjEZbm3SQw4OHquI/2C82FM9CFWMq62qGrWLv1xoruqJ7XGpDYwhUb/cOE/LN92lS7HEDdd fp/cdXXJLruxnH3OYiZ47utydrjQ1l2olSctoMKAy6a4YLlVdNMBp5QJLmh0Hi4YmxYM94kFCnCy H9eUT1whiQlcWqYhf8CpiQs+68qHeKcD6zpAYEKLD13Nhw8nNEkqS7XmuGddifd601HXl7n/ALTR PNZ5dzjL151lUGswI1juIlqJEEFs2MglAc5AUMEB2sHhjpxlANoGDQXcqcpQIwytWSxgSUzA2olc wiUxEAFEYax+cYN/Q2icf/LOCg3A6XXAaSjhGIRosMQ8+O1EaHshhPWnSp0IKS+EDGdCeiukUEK6 Z0La81MLn7yDn2dA/ux0vf5vwNuAtoCo2m47PB3rnraaBkUEjKfMBmW4wWtrsgGdAuUfKxfeTuNv C8NzRAQaHpaIskIgiJEpqCTFVDfaOskI1N4qN8cEWcC19y1ulmILKC1MtpgAQTWdW/7xhkH2vjjP nXSgYiFgHvi2uOk/S9uUzQ0KZW5kc3RyZWFtDQplbmRvYmoNCjE0NiAwIG9iag0KPDwvVHlwZS9Q YWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjcgNzggMCBSPj4v UHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAg NzIwIDU0MF0gL0NvbnRlbnRzIDE0NyAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDUzPj4NCmVuZG9iag0KMTQ3 IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NzM+Pg0Kc3RyZWFtDQp4nJVY y24bNxTdC9A/EFkEM0FN801OEKeoEzdN0SBpoqALowtFlmMHsqTI4yLu1/dczkgeSuLIXYiwqfvg PTz3QbHjD+zFi+N3r96+ZuLlS3b6+hX7PhwIJrgQQiolPPNKMGsEW02Hg7+esflwINnXjYwQTgqT CF0+Gw7+HA7Y2btXjHUcyNbB6Wg4OP5VMmO4cIaNLskizDHJlFLcM2MDtxUb3ZCX6OrNcHBefJqO yyNdrEqpi8kVK03xsZS+mH6/K49UMb0tQ1GXf7PR78PBGVyQm7VdU3muQtfwecE6sjtnVclZPZMh OaeTXDEtBbeytfbmbFT6xGbXPyDiOlU4zolKw6uQyv4js9IGgblU+vMtTjLFZ3X7M9bLayyzOm5k rCjvuKpSKyeQr/G5rmdkLheZtpIbmaouVwwq4zmWix5QjHLc+VT1Lp59hWV0v4xh7Ne1EkTZcpvz Y5XmOomOHQkuFRtNzsGenBbomSqJqJD1Yi3fCuYJAji7wbKcLbDeT9t7eZIx4ZzmPTHtkFTvkJQL ZXaJqkLgYR/tu879ltzTjFxQPMBJIkuXtlhR/p3e9xM1UTupoULsrGe5e1ZSAtVsADuQmEfkrXKe 2H4Yjq7cITi6si0ciOs9rRd9qSd9xc2Wr5MxWZiQ2vyC8Jl/zcETHK98PqIdfGwHnxQUY7l7DChd uadjCpKqxOr6C9a7umX47UnuwEKCo6mVpspQkZr+REY25WtO5m9y1GgrT/bgO7G7bOwKnegxsXfl DhGiK0sR1RTMqn4bL7WN8EeOFJXgasvfiYSCzMGKvqlDPpAdLHwWC6G4eQwWXbmnE2L8HYVWU9+Q IheYC9ybvJOdc4bcOWUQPLjWxG+LiHBv8+0odMr/82zHVijnIdFq6v/0B/W2WNUjZTmlKpX3m9zd GE3FKzlwb8xVNmZbUQ1tTPwyIdCny77A2xi6avmAmwKdCI+X6zCvydk4ZuqC+npuHmknicTKNyoI RJB5LpNlxaVOlXoRkiILkfbcbSCK9ehqEevTv5sA+o7S1qfEzHOaYU4J7PFqPZ3kUFQYNJ1N9a9M gIagpP92W2HVV+1kFPono8RKPyDr2TrOy0BCIEW1NRzzNbRxKabCMKMCrzSbYQMZYTE2Kk8S2MBg XGFA1hajkqONKwhZdCYftXClZMZDCxtatUIgl1ZR3wvouyhrW/XLfedUW2+Arf4MwtK5Pbf2Yfw/ L94vAbqSxbh0RX1d2vz9VVUcgTomDiGnu8gpYQHdGgZoy1ARQg9AyQDLHSSplOGvFusmcolxxXaB k5WOZtfoyODWwOHP6GCDaQ45s4fyEi1Q7QPsY6k0vYjwXFrc4cFkikmJDTYqjSnul9lpyzoe7P9B z3bR015RvdGoJMghaGvjqDdr0FnGwDWaNSovASHj/74JwAR68zTRk0wVEZeNESuIFFTLXGNDrcEj UYzKWkvuZB94+1q/poJBwQq6gA54nz+CYX+w6Zzgm5RSFAuMcHhiXrDyKOA9NcP3dSktlYLce9PF J8eD7UNA+i6QBqQSNPYarmSDAXhN07NsaadtJCBJmLhhhGw2HL2LWiRJqMIenhUhmkHIuA+FmRP8 jGZokgeDVfyPECF5T8564NzXlY1A9faNbd2F89NiVYN81/hk51gDz9p2lQ/hVaV4IXjqtL5NuBg5 6CzoFmYtfpiPrKJWPGsRhoSpuK+24EJSNWUz4tGY9WoDl91g5XFiSxUrD5Xa16nWUBnFnepC9aFU phhv4BrP2Cr+whET+W5G+7e556cI3OmuzUO/cMgdBG18brUI4hUaN8yaKvhKIHzpiZprCGlDdyCU 9GSzmIAbG7GMktEmuzVxWDZZjO/ovGj9JvQBqHoAFC75nei8eDuPeTqlpM0N1wZ3Tlx7UD4vjnKy KOvBp7Jf8Do7MsX0gi6F0Y9Ry/FX2okMH5fmQIuyGASRjonNnZv6D8PK6LQNCmVuZHN0cmVhbQ0K ZW5kb2JqDQoxNDggMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDUgMCBSL0Y3IDc4IDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFn ZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxNDkgMCBSL0dy b3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3Ry dWN0UGFyZW50cyA1ND4+DQplbmRvYmoNCjE0OSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAxMzU0Pj4NCnN0cmVhbQ0KeJydWN9vGzcMfjfg/0Hw07lYFIn6HRQF1rQbOqBD1mbd g5EHz3GaFInTxclehv7vI3lnW5ec7pw8VL3I5EfyE0VKEocn4vXrw4/HH94J9eaNePvuWPwzHimh pFJKA6ggAijhrBJ3y/Hor1diNR5p8XUro5TXyraELl6NR3+MR+L9x2MhMgO6MfD2dDw6/EULa6Xy VpxeECLCCS1AJemSsC7Sf6c3ZIZt/ToezarPy/n0wFR3U22rxaWYuurTVIdquf4+PYDqdkXjejk9 E6e/jUfv0QpZ2kA7raSNOfSsEpnsE3eh5W4Q2snkW956LUEYb2S0DeB/BeNBydiW7DVtMtNtY8iZ B4Yg+gHRFoglCmYjhtzWYfnJmphaXNK4nB7E6mbO1E1oPKIJMaPPyQONd6vt9HpBn1c3jyYulzQ2 IDR9xNO3d1sDR5o+pWLUMxp/Krhsg5VJ504PcGWLXIGT9rlc5To1VwXxVENmCrPq/pYiu0cetKqu P3H0TPUDcXB9X/PTjQcKgXwbb3JEGgIYr0QYOCODaSv2EuaKhCkv4bmE5To1YVnctxT3A6fBYrnN jiasWSkg3Gg65sgDAflSQBADhvE0oGJIKWHS2bYe65T2tcZ6ZVoKA76Goq8+yNjpa9FbrSOptDSb nEWWr855s9VcM+28KQ3vUvA0ntP0uSmtA5Yr0Dn8rDooyQaQ8ZEsBM7buSroGK2lMfvhG1AymQJJ 9ny5KOm5JK3roKhoyCepXMHQHOYlQ1YFaiv7G7I6SJ3a0dd7BLhW6iWzp7lkugsaEy1XmPRVT+e0 TLGN2puPsZiPdtsnn5uPueYuH++vuDheb3tCk5ocz8/rbXW4Wm+KKFQrVhT0+eWE07kUuLFJRpfb Hgg8FQMH3NIvCzzX7G0eGtBNmyvMqgeOe8nF8neKe35TU9XbL7q9nRyJkmmgU5fu8PXvb2xutV0I /OzfuLn3JXMGNO+nXLZ3XbQqLgwe4HTnwgxU853erPpRSiBaw2TbRmoDvd7qkrcaDwjpBd629Pbp PZnCkLNQdDZoGV6U8y3NvubD+9nWzcft3Xwy+MHm05LV+zWfvfCb5tNNkj0v9oSm+TylaKD5dBsa bj77G2qaTyv6ruYDu+bj9m4+LdT+hDQdV6xon96xtAPpwpYRRfewfRM0V90kaMBudH9dB0m18guF dcKZO3DMzuCGgrP73R+1MdKEF+29XHOffpMpvLTfdHs73G+e+vqN7d/UpwKyf1naFUoz87nzxXbT bOtctn+Virchra3UnesyUMBzPdb5MVDAdwpDzhZvOgkvzT4+7+rW0mH5s/JdV9uWwpCjxWtOcDJs MUrE8GtJS7Lf2uYQy29FeBCknFF0HETdYKQPDmt4QOvX+LeTTjXX5UQTDos74JEZl087mrhEIStd TCjkaYEIhRgARlGBYfCCalQD6MHzQQe3d61/0eVlevT8hXfcvBiQfxCSdGb37jWrTqZgq/lXfnaZ mmo1n1o6STt67SqsrZUGa2gGNfTOpXL6IIH0GLpXdAlHbUBCE13HQRqOD2yQKeCEIYppAvPD0/OW ln7DAB3EGyHNKFg+bWCUmGoUz5yruMG09JoQiPAyidB13gJsOOC4ezqXk/fnGssbqOKbC1WLqHPF Iaogp8oZS696CKI4SRwG5+kxwEqwdWrxTxC91EyMw7qEWaRhlyokQ8sVHf7CICwM0WBakoyl+1yE DZ6h3xLx3cNS1/uhxUQFXAFsQ22WPp+IaapQbXrgsfy76l/8t7wT3/mdlR5yDN0FDFbpbhq9ijLY HLmDxv8BSGhg9Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE1MCAwIG9iag0KPDwvVHlwZS9QYWdlL1Bh cmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFIvRjMgMTQgMCBS L0Y2IDUxIDAgUj4+L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxNTEgMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1NT4+ DQplbmRvYmoNCjE1MSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4MDI+Pg0K c3RyZWFtDQp4nJ1VyW7bMBC9G9A/zJEMYIakKJICggCxk25AgBRw0UPSg2LLjlBZcr2kSL++Q9lJ RS1OmpuWeTPzHmce4fQGzs5Or8efL4Gfn8Pocgy/ggEHzjjnQkpuwEgOkeKwToPB9xMogoGAxUsM 51pw5QXNT4LB12AAV9djgFoBcSgwmgSD0w8ClGJcK5jMXUZMBwKkFExqUJFlUQyTpStT1foYDG7J DTUhuaCWkwkVlow/QVLMYLTLf9IfMPkSDK4ws8v+nE7FlllVT3dLoBbbalF6LUoIkaP0W1Qhw+9W Mmn2Gc84t+bcb8DR68Aa3sA+UzKxoxQjpR4mQhknjIc9yiRsMJGa8UYzsWsG6ZjohchIdBBpQwUX zFgPTC7yvKSK/KaCkw3QmKzWVEhSUk0es1lWLIBGZJWst3QoSZbksFvNEmrIllqSIkCo6rGEtXtM N+Wuepimmx5JImNwfvwmjkqi3igJ1ywU75WkBibXCRWaPCE3Qe5Txz9brkpUAHklBUq0hWwOy3KW zZ8OAiWQJ5VuC6djCstdvs36BNC4LH6/ZNgbGzOh/NjHqo98l86AdlPUnRyliRh/XqfE0aAiJNt1 dr/b4mkjURGRsoAEaEjW7t/hNDWeJjhed6SnzTAyzMb1CjDENRIxvkxvSbrow9nQAeo4XiHazMIu ZqFFo4g8Zmc8NKrn6BtohbrY0NelWfhfrGFG+LGLatLL3QpwH5Ypqra8T/faWbK5o31niqSV7C/b WoCo5W5tZ5OhZPGrztZ2tTqOoCVj+32ujNdKNUZ1xNG+dcfi6o7NFbFygry6ud1jXUfv3SxybiYO bpau51TiKa2X6HLVtmqyxC2WAjfcOR9GuPOqFiIri40LqF6gLKZp715KprVf+6gW5m0mJiLNYvtO E6uDybdN6lZ2vsvB3VAHEYAOQ7JxfJ+K6cPe6YvsT6ULzvLsYAsSDS0r0Nb31p7ABkUaWrwRnBM0 7gj81S2SVpaFym/rqEj2DYMuhGJW//+g13FkVG4fINl7XNtqdDOBsNwx8FKUK1wVNzBJ3uHCjQTS otMIP0FLib9DCA6kDQplbmRzdHJlYW0NCmVuZG9iag0KMTUyIDAgb2JqDQo8PC9UeXBlL1BhZ2Uv UGFyZW50IDIgMCBSL1Jlc291cmNlczw8L0ZvbnQ8PC9GMSA1IDAgUi9GMiA5IDAgUj4+L1Byb2NT ZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDE1NCAwIFJdIC9N ZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxNTMgMCBSL0dyb3VwPDwvVHlwZS9Hcm91 cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA1Nj4+ DQplbmRvYmoNCjE1MyAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2MTM+Pg0K c3RyZWFtDQp4nJ1VTU/bQBC9W/J/mOMuEpv9Xm+FIhUIVSuQKKTtAfWQJoZacuw0cQpVxX/vbALB juOAevHHaua9eTNvbOhdwtFR7+Lk4ynwfh+OT0/gVxxx4IxzLqTkDpzkYDSHeRpH3w6giCMBd5sY zq3guhF0exBHn+MIBhcnADUC8URwPIyj3pkArRm3Goa3ARHhQIBwkikP2iTMeBhOA82K60Mc3ZDL ORWGlBX1pBxTR8ocBg8VTUhaLOihItmPLM+qP/Q7DD/F0QBpAtUzttGOuTr0DYFaaKtc2ShXgpKt crVieJ5wpswa8YjzxPWb/EHqjlzHt3LJV2oESedUcrLIqCJlAdSSDK+Hkny5Ou/QJY1liWlC7RWm toRJx7xt1uZDbcozHP+zrmPRb2Fez0bFBlZvjbcNK7hgLqkDr8/nd89PV6s5/6SCk4oKRaoZdmDx rtejwpOUCkcewmU0neUpdoiNKfphGmbf+/s7ZGH7MHKRlcXj+nRlmXRR0kNNlvhiyTh93Ncd8yTj pbRV2RbL1tgV7SzTIFiysXoLwdYasTGfS5i0Tekvxt47LrfDhztsKL1iXr1uwx0urKeSs9D3Ms9L bO09dHhOWMkS20y8GlAhyTUObHi7zDvN6pn2zcQuEmkd46YZO5tnBdVknM1yvKWLjlTlZdjyTppW k5O37YQ0klmzeyde9X09mbyfTDLscIVORSOPclzyBJc8mPYcRuGGZtXkbjlNCyoEqbqlJkyIJvhe qf6NUgV+itX/Sq0l75a6Uod7uVwt6DjFQ4ff8ckMx1rijNFKnZJ1+HO4JklL8j/fK2zwDQplbmRz dHJlYW0NCmVuZG9iag0KMTU0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMTAxLjc4IDMz MS41MSA1NzguMjYgMzY1LjcxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJ L1VSSShodHRwczovL2V4YW1wbGUuY29tL3t2ZXJzaW9ufS97cmVzb3VyY2V9KSA+Pi9TdHJ1Y3RQ YXJlbnQgNTc+Pg0KZW5kb2JqDQoxNTUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIv UmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4vUHJvY1NldFsvUERGL1RleHQv SW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIwIDU0MF0gL0NvbnRlbnRz IDE1NiAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5L0NTL0RldmljZVJHQj4+ L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDU4Pj4NCmVuZG9iag0KMTU2IDAgb2JqDQo8PC9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDU0Mz4+DQpzdHJlYW0NCnicnZTLbtswEEX3AvQPsxwGMc2nSAGG F340aFEDbu2iAYIuDEdOjMaWKzVp+vcl1aQQZUs1spAEPu6dOTMUoT+HwaA/G7+fABsOYTQZw484 YsAoY4wLwQwYwUArBkUWR18vYB9HHO7+7WEs4UwFmzYXcfQpjmA6GwPUAvCXAKNlHPXfcVCKskTB cuMdnR1wEEpTaUFpS3UKy50PU8W6iqMbvJ59hMX6PiM9ibsV+QbLD3E0dW7e8dVCGUWTusMNQm3r UVYiyEqAFEdZKUndvGVU6r+OA8asGYbxPdEJrWENbUVxTbjExaQFgVtNkyRUdTLIBoMwNE3CNFKf hkypa+grwoifQDiWcsapsYEYx3lBuMKsDUArakJFZ/6qmX9YQ841FS59JqmS3R1oKqVsKvGzr31W 5o8OQeO6Ok2XQHiCX0riVgpihZu4KvxU/nhoYZTKlVSH1p2Q+ixIkVhq/3PMTkPWlTgnQuCK8BR/ P+SrW4fH8Ffhx6vDwSELrBpYOnCD08INOOYVcdnGazTlJozSyZucxysVFembeGtKXKw9032285+V b6fG0ePD90towRHumnDtC01eCtNzxXrarrN5VaPcVehpe5sVY7+a791ws71ru32spYaHtp1VMuf9 ujzVlIk3/rp1MU73JMWf7smKQ0EUbsvMnXogPY3TZ/+u1vbllmgP23IYHF9qQuNmpds7x3Xqb/mW 6vwBb2tVOg0KZW5kc3RyZWFtDQplbmRvYmoNCjE1NyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVu dCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAv Q29udGVudHMgMTU4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2 aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNTk+Pg0KZW5kb2JqDQoxNTggMCBvYmoNCjw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTA1Pj4NCnN0cmVhbQ0KeJyNk19r2zAUxd8N/g73 USqtoqs/tgQhsKTd2KDQbYE9lD2kjdMZHGuzncH26XfddF3U2FlfjCx0ztXv3CuY3MB0OrlevL8E OZvB/HIBP9JEghRSSlRK5pArCdZIaIo0+XIGdZogPDyfkTJDaaJDm7M0+ZgmcHW9ADgogE8F5ss0 mbxFMEbIzMBy0zuSHSCg8cJbMNYJ62G57cs81nqXJrfsc3G/a8ruF/CvsPyQJldk1Jv9VWuphVOH 6lu2CPxCsbot10W/aDh6tuI568pQtyM+NpcCTexzWPOITEVkCrQ6IjNa0L6TQtu941RKl8/iC/Sp DGjpOrGW3RBHxkLHUbFwTzihGmHB3At0sfokix5gGULRRqj8/yhDJAdS6in1puOGlT97mALKmiOy DVeGhWa74o5axTULNfAL1Gx1F3b1eqxzJrPCY1zhJK15ZeeUcwJfgTvUuUMte7Mj1u5baIip/P1v Gmn3EdHu/znSpym5ZXc7+rGsaEen3nmhMK6yavZhkr4KoS0qsh99Nlbngt55ZECvxbNNf6u6WI/o Mp0J9QLvZNj2RdgqFz6L8/J9XiYTzj9nPceBrI+lKFHkLhKzT32+oSrac0obHvaPZvedZ6w978dJ sVW9poVhBU2dpDZ0dLAqtvR92hmfNCksxuWO4P8Ai7Qfsg0KZW5kc3RyZWFtDQplbmRvYmoNCjE1 OSAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg NSAwIFIvRjIgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMgMTYwIDAgUi9Hcm91cDw8L1R5cGUv R3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMg NjA+Pg0KZW5kb2JqDQoxNjAgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNTcx Pj4NCnN0cmVhbQ0KeJydVMtu2kAU3VvyP9zlTNQM8/RDQkgNSdtURaXCUhdRF8YeWqtgU3Aq5e9z x0BlAyaoG8szuuece+5jYDCF4XAwGT/eAx+N4O5+DH98jwNnnHMhJQ8hlByM5rCxvvf9BkrfE/Dz XwzngeC6E7S48b1vvgcPkzFAS0DsBe4S3xt8EKA144GGZOEYkQ4ESB4xrkCbiJkYkpWTabQ++t4T mW6oCEhV05hUGQ1JtYSZzZ43Rf1Cf0Dy2fcekNrRH/iMECyWbb4nAq3YkxxlJ0cJSp7kqBXD+4gz ZXaMQ86jcNRNwPk7gw35EZYkX2YwoYokjz0WRCiZPAJdtKDOWDjnQGkmw7cdnDPQgpJZTYUgaZmn TXdyoLeGfErorUBTU8ioIVW5LXL0aDEiJil2ri7wiNeQrtf4t+ztnwqZMV3Bi+b1lf2TUcTEFe7P 9a+NJe+fqSb1L4suSpxLNKZJRqODS40um4oUW4yAvNhmVHBS4eGv+8GSSE7S+dK+g54a6DBwne+o fnU130v3lS7A/TxKtk/CBCHTQTd2bl1DXdOOURcmQ+qYhQeG2sGr31RpYss+aWE4i4IuEHUlsc2G r1a2zG3eAjcPQoPSiMK5ABFzpvHgMjq8P20JpQVTqi3RcLwxSea6NZJcsSD+rzVqQ1sbM0/dqBQZ FFvY16Aqly9QrJpVsVgR1/2muna3bgsqcdBOGtVRE4FhMtirFaUbvh3F7lFd75dzXiydeo2fvqWU yBeYLuFJKV8BsphS7Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE2MSAwIG9iag0KPDwvVHlwZS9QYWdl L1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjcgNzggMCBSPj4vUHJv Y1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIw IDU0MF0gL0NvbnRlbnRzIDE2MiAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5 L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDYxPj4NCmVuZG9iag0KMTYyIDAg b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE3MzQ+Pg0Kc3RyZWFtDQp4nJ0Za2/b NvC7Af8HIp/kYmF5fIpFUaCvDSnQolszDJhRDGnjtB5sJ7OdPjD0v++OkiLKEynFH6Iwyr1fvDux h2/Z48cPXz8/e8HEkyfs2Yvn7J/pRDDBhRAgpXDMScGMFmy7mE7+eMA20wmwT3cwQlgQugN09WA6 +XU6YS9fP2csYgA1g2fn08nDn4FpzYXV7PyKKCI5BgwEcO2YNiU3np2viU3g9ct0Mi/eLTazU1Xs lvvll5kvFmymi7PNzBRXMwnF9XZ9MbPFfnm9YcsNI8jfd4vt7D07fzWdvESmxLjhZAFZxIzmBYtA /ye87AjvGKDwB7KXwKVkWuF/ZE3y3wR3KD23B7BZ9ipif8gQHP0iIuwUfSJRrI9IjqV4+5KYxmgi YJwsZ6q4PMHHoxmIgtFJljOQBXg8fqSXUuJJJSgrqbj1MeV5cZqCVZKLA1h3hcQdsbEpLGu4cSM5 OMX9Aaw2pI66SKBo4UL4jSGvwXBnUtb34C9TiNpzZXrsn+Rk3AEnVASCIiUazIajF3jUwXaaXpLz fkoQNE7zA9Nng09ngk8Iro8IvgitDr4EghSWICOEebH4hsrtF6T2doPHixUdz1IGl15wCV0SJ2Sp RwyRU4ybYI6xPvyNCFiEkNtugcdNCreUXLlD44CujHOS8otC43jTY5ysd0zaO6pUTXm7j3ditNo7 wcxr0p4Md/IITyxV3CQmnoaYyoAGNqOBtdz1aZDUQWJlLruIAxGGju5ymhdXF+TjNRXE1Xc6vrnA 45p0X6Sch4Fa+i6Zyk6Uiq9CtG52d/GTDAKqQVgeOnSy1nMZ62Gp8UdZL0IcZ70WYV58WpKGX0KG vKFjHTmp9Cy59l0KreGekeG3ZPgP4RQck8zZKoE6pLK2KzO2U4rDEbnTos2LHyknk5ldh8WIRPcZ YcFydYSwEdqoMhwhzIvbEM3bNj2SHq4LQoxceTgUk4GEirGaAqyo/lJC5fuEhFnSBRjrtjQ9Zsn6 BUTaMdL7YypwjFY75oYqMFl8R0b7ek3JcBmSYawlI6LzYk0e+/6BzPkXUblZEf2QuJt9U+e/7VNF Crs3Y1LapWsbJqZUPdrl7QsZ+6LHnLu/fSO02r5bVPp61Wi+C20wI3PMU1GNEmCDEJEa0kNm9MCA 9X16DFXqGLHSJHktY6WGGH5I3MzMIdGR0C9uWmCF9jId1KbmoMG/UDyubsngi+4I8tvTXJemBXVa EdEhrTLNrFShbTvCCRFipdOPvBNa+CFxM92dhFDk7h37Ldq8eJ+/oWIWYzLV9kzJhyN+JTwJ43Qr vCrHSR/j1eHzaWaK7TU+MHqguNnhCWsi6IIlUxcnAhw+I1pDirmx4z/98vqIGIoRxyRyBD8kfKbL ASwH0C/uUCLHqKMSWdK0OnaVUE1QEY/MoI/etAeww6sELTUHM45Dfd0ljKVNeqGAXTz0mSrJCUdz rVKcMlsFg2ODh3twMtTkQFd/H7Y90tECQeFDkLNMaC1SdcKKkquySyYfjZk2FjQSOzIaI9QoGi9p hNvdkFqr0PG04yuF5DtqdW4DYJhW9iOmi4jT0M4w0xgCim2OqhMR4pi7JoIfEjfTZwFdB33iDlTr Fm3wrolZjLhrZN9Gtv+u8Zga8v5XTYRWR9QCrxaMEVMs6abZr/C0WNNNs6At9J5eYuNoqHE0yb6x blla6kOKqrF3Dz6hbxc3FFIR3pibpwUfkjzTa1nNVb+sQ5keYY66dkJmr+ixD/sbWvrh6EqA22ac SqV8fUm0LIc0zrRr2nFzjHcivDH53oIPyZpbuwnu7r/VjbAqSd9ntgkqAh+SNLPiAtWmUcow9deW GDTPr2mYwscn0Jpby5RyWF8YYkNZhl2I8NwBW9ELx2nKdjTV0t9a0Q2hlKYODV98rmAcUsHrEmN4 Xb2waASUCmzA8kSzOpaKoMLcXuNf9cnpD76oQdkpC45WcySHp+7l7mvavHg7k5qWCacSw18XX2dl cb2dgS1S3QVoybWNKQ19rxIdE4KkhRzY0G+T8h5rmELHlhQCQXlLRU06RwsCeoGTh6D2BF/Yxobe VFiORthARnBTkYHK8r6kgbyhiKML7Z6czhhRNbceoCcMdTI4SpYVdclLLLdYqU1FUZHDSQrQlYya AgGwyat4fq6AJI0WlkpG8DMGH5L1nvSpZaSfyuWcRhqgviIjorwTUdOugezoy8aOeJsBBopwjYzY PgosWxUzVEqqYEbRiqgJGoShIaimQnpgQJvyTsQKnsR3qI8IX0MyMvZtC8h5oTXsRN/TW/o2u//8 ZyrYAELvcIfXE2v/AT0l/igNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNjMgMCBvYmoNCjw8L1R5cGUv UGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwvRm9udDw8L0YxIDUgMCBSL0YyIDkgMCBSPj4v UHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAg NzIwIDU0MF0gL0NvbnRlbnRzIDE2NCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDYyPj4NCmVuZG9iag0KMTY0 IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDMyND4+DQpzdHJlYW0NCnicjZHL asJAFIb3A/MOZzlxMTlzy4wggibaWpRaGuhCuqpRAm3sRSh9+07shYwmrdvhv3z/HIiXMBjEi3SW AQ6HMM5SeKEEATkiCinRgpUIRiO8FpTc9aCiRMD2V4OYCNSBaNOj5IYSmCxSgEaB+C4Y55TEUwFa c0w05Js60ceBAKENlxa0cdz0IX+qaw5dF5Ss2GUZz3fvEGk2LdfFY7n/gHEZKVaty2r7Ft1DfkXJ xKfXDT+RxmoeJK4YNKQnlDKglKDkCaVW3L875Mp8JQ4QnR2G/fXCFq/FIy+bZ5GwbLTs4BfK8n7o +JNftfC34Std//S/+G30DSu7jRI2WvgjzLv46zMfmf4coM88gHSOizMWtB2g6WXXz0U18wuyrgWJ 41aHHujS2sQ3htp0V1WFz3/Yd5ikU9yZ7oLDF30CzGC58Q0KZW5kc3RyZWFtDQplbmRvYmoNCjE2 NSAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEg NSAwIFIvRjIgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0g Pj4vQW5ub3RzWyAxNjcgMCBSIDE2OCAwIFIgMTY5IDAgUiAxNzAgMCBSIDE3MSAwIFIgMTcyIDAg UiAxNzMgMCBSIDE3NCAwIFIgMTc1IDAgUiAxNzYgMCBSXSAvTWVkaWFCb3hbIDAgMCA3MjAgNTQw XSAvQ29udGVudHMgMTY2IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNjM+Pg0KZW5kb2JqDQoxNjYgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODY1Pj4NCnN0cmVhbQ0KeJydVstu2zAQvBvw P+yRDGCKS5EiFQQBmkeDFAiaNi56CHowHCUxakuO5LQJiv57l5Ifki05QS8CIe0uZ2c4S0FwDUdH wdXp5RnI42M4OTuFp35PghRSSlRKWrBKgtES8qTf+34Aab+H8LCOkTJCqRtB9wf93pd+D86vTgFq G+Byg5Nhvxd8RNBayEjD8N5XpHKAoKwVUQTaOGFiGM78NuVeF/3eLRty69go5xiyB25Zwg1bTNIH /gOGn/q9cyrrS69qaa2E1vVatwxqsTv4VAOfglDt4NOhoPdOitBUFY+kdPa4CcD31pJr5VYuu6ZW IpbNsyK5A46KOkLDXvhAs4VvMkkLHrJJlnZ0GKpIaNOsubfDsKXDtgZDLZR9u8G2/mqp7MOUazbN 6PGb5CpgBLQsktw3+IujZEkOPKp6zYAPQjavGOHo2Msrxd+cXl6VH/KSnqfnpOBI7MCijCs/jYC/ n38VG+FW+MqNR+WW1XnylT1SriR75Y4WFFBJMevQQGkjFDbr7tVAb2mgrIijJtDYAzVamI0GJ9ii wW4qShTWNZLZxfmQD1QbqJv5KF3jMjVc63JGibherXqdP6xWX0tfPnotS5oWc9KzOAwCjrE/zZZO Mz1GMy/53B+HRIwpJJt55QIytGkYmgQoAq/+OJ8F3/jAlMeFahVl/J/J3d993EbLHjYwfQeOCNGx sAqMdH4koHDrQbVTw7bwEEUotGoSsRlLe+V277OckrG38v9Yrp7KPs9pYiwm9MjS0XT6WjpkTNyS 0nSacWm23C8ToAE69bHpT69gAevJUzlr7Q9T88doPPbB2XNKBln4AbXtvwY6tCikWqLLUlg8UkYC Y9p6jYKs/ex17nCYUwJts9BeyuP3UY5Ki1i3U95mEJRb91eHHrW6XXZxnlpLbjkkSoOgojybFsKL UdJ8zyPLRLacTYOQwrwiZepsGtzlpa1IlPtF1/VHfGHc6JINumIdcRs2Yx/90CCR6Y7tyDJ0wSK+ bwdjUMSuGVuMJ11Tlf4pxB7sG14rxpEcQFtIb+5SlJW737oOXCSM2pKq/V6Y0KPzVwOdFaperZsI jC1BqYXCgP6jjAc3vmVS7jvYiDvzrerCT2q6NLaa381XLbNNKSIvajCxGm303YPaMds//h4cjA0K ZW5kc3RyZWFtDQplbmRvYmoNCjE2NyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDE1Mi45 IDI0Ny4wMSA2NjEuNDIgMjgxLjIxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShodHRwczovL2V4YW1wbGUuY29tL1RhcmdldHMvY3JtL1VzZXJzL3tpZH0pID4+L1N0 cnVjdFBhcmVudCA2ND4+DQplbmRvYmoNCjE2OCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3Rb IDcwLjIgMTE2LjMgNDcxLjE5IDE1NS40Ml0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlv bi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1zY2ltLXRh cmdldGluZy0wMCkgPj4vU3RydWN0UGFyZW50IDY1Pj4NCmVuZG9iag0KMTY5IDAgb2JqDQo8PC9T dWJ0eXBlL0xpbmsvUmVjdFsgNDcxLjE5IDExNi4zIDQ4MS4wMyAxNTUuNDJdIC9CUzw8L1cgMD4+ L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWh1bnQtc2NpbS10YXJnZXRpbmctMDApID4+L1N0cnVjdFBhcmVudCA2Nj4+DQplbmRv YmoNCjE3MCAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDQ4MS4wMyAxMTYuMyA1NDIuMTQg MTU1LjQyXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tdGFyZ2V0aW5nLTAwKSA+Pi9TdHJ1 Y3RQYXJlbnQgNjc+Pg0KZW5kb2JqDQoxNzEgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA1 NDIuMTQgMTE2LjMgNTUxLjk4IDE1NS40Ml0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlv bi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1zY2ltLXRh cmdldGluZy0wMCkgPj4vU3RydWN0UGFyZW50IDY4Pj4NCmVuZG9iag0KMTcyIDAgb2JqDQo8PC9T dWJ0eXBlL0xpbmsvUmVjdFsgNTUxLjk4IDExNi4zIDYxMC45IDE1NS40Ml0gL0JTPDwvVyAwPj4v RiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVudC1zY2ltLXRhcmdldGluZy0wMCkgPj4vU3RydWN0UGFyZW50IDY5Pj4NCmVuZG9i ag0KMTczIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNjEwLjkgMTE2LjMgNjIwLjc0IDE1 NS40Ml0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVudC1zY2ltLXRhcmdldGluZy0wMCkgPj4vU3RydWN0 UGFyZW50IDcwPj4NCmVuZG9iag0KMTc0IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNzAu MiA3Ny44OCAxODcuMjIgMTE3LjAyXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1Mv VVJJL1VSSShodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odW50LXNjaW0tdGFyZ2V0 aW5nLTAwKSA+Pi9TdHJ1Y3RQYXJlbnQgNzE+Pg0KZW5kb2JqDQoxNzUgMCBvYmoNCjw8L1N1YnR5 cGUvTGluay9SZWN0WyAxODcuMjIgNzcuODggMTk3LjA2IDExNy4wMl0gL0JTPDwvVyAwPj4vRiA0 L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHVudC1zY2ltLXRhcmdldGluZy0wMCkgPj4vU3RydWN0UGFyZW50IDcyPj4NCmVuZG9iag0K MTc2IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMTk3LjA2IDc3Ljg4IDIyOS40NiAxMTcu MDJdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1bnQtc2NpbS10YXJnZXRpbmctMDApID4+L1N0cnVjdFBh cmVudCA3Mz4+DQplbmRvYmoNCjE3NyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAyIDAgUi9S ZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4dC9J bWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vTWVkaWFCb3hbIDAgMCA3MjAgNTQwXSAvQ29udGVudHMg MTc4IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdCPj4v VGFicy9TL1N0cnVjdFBhcmVudHMgNzQ+Pg0KZW5kb2JqDQoxNzggMCBvYmoNCjw8L0ZpbHRlci9G bGF0ZURlY29kZS9MZW5ndGggNTkxPj4NCnN0cmVhbQ0KeJydlE2P2jAQhu+R8h/maK+0xnb8EUuI A+xSdSXUbYXEYdVDtAQaNZtsE+i2/77jQNsEEop6ILHDfD3vjA2jRxiPR4vZ+zvgkwlM72bwLQw4 cMY5F1JyC1Zy0IpDlYbB6gaKMBCw/WPDuRFcdYw2N2HwMQzgfjEDaCUQxwTTZRiM5gKUYtwoWG58 RAwHAqSOmTKg8KUdLF98mibXuzB4IoIJoIp8osKSNE+TOqWfYfkQBvcY0Uf9HUYZwbRsh3ki0LI9 K012SpMQybPSVMTwe8xZpA8Rx5zHdtItwGP1+Fp+4usZ3IEBgdI1UEOyAh72OW5/Ar3VRHJcComP Zrsv1jQiaQUfqOBkNR8g11wy57q5LpJHPeR94JFi0v4bvI+75UoWSVYcGJ/zpMo2Ga6fqSUJ/nYZ EpZFjbyKJMW6edcvibfPm01aVVQYUlZAY7Lx5j+o1CStB9QwXDB1UsFFNdSJGtIyZ7pIDpGkQ5X/ qjEVPWqcuwqsxsYdZ9SjoCJGOcoN7L6kddpwvqEaKaIiMWyo5KQ8tB//dGS9r1CQrMDHFoYOQGyZ ibqp0ENEZEddE9qR8nVohrBtous7lEdbw/QJUpOhbnIdihxqjo6YVcN5zpqjrxtVqSyLrzijPaPa diWrLM+95jXKdRuR7/7cpZDUgGwSKREwqZqZLbbNEX0tkdeRXdNCbJvyg/qGk1pWX4/t2qLyGrs5 JL3RitluGRclMVdK4ifv/05v25XMsyLJARnE8f4Fv8TZxHvJa3T5bopix7jrRjyj+wXT6mEPDQpl bmRzdHJlYW0NCmVuZG9iag0KMTc5IDAgb2JqDQo8PC9UeXBlL1BhZ2UvUGFyZW50IDIgMCBSL1Jl c291cmNlczw8L0ZvbnQ8PC9GMyAxNCAwIFIvRjEgNSAwIFIvRjIgOSAwIFI+Pi9Qcm9jU2V0Wy9Q REYvVGV4dC9JbWFnZUIvSW1hZ2VDL0ltYWdlSV0gPj4vQW5ub3RzWyAxODEgMCBSIDE4MiAwIFJd IC9NZWRpYUJveFsgMCAwIDcyMCA1NDBdIC9Db250ZW50cyAxODAgMCBSL0dyb3VwPDwvVHlwZS9H cm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1MvU3RydWN0UGFyZW50cyA3 NT4+DQplbmRvYmoNCjE4MCAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4OTE+ Pg0Kc3RyZWFtDQp4nJ1WTY8aORC9I/EffLRHi6nyd69QS3xMol1lpGyGaA9JDgh6GJSBntCM9u9v uQdI99B0WrlAYVzleq+qns2GH9loNLyb/jVjkKZsMpuyH/0eMJAAgEqBZ14BswbYPuv3/r1hu34P 2fq8B8AhmNqmh5t+759+j93eTRmrHIDHAybzfm/4TjNjJDjD5g8xIoVjyJTRUhtmbJA2YfNtPKY8 632/92UE4A2gHQOCSu0IMBmnA02GtpPUJnEhJqTTaHoHiLcpGrKnLh2ocj9oM0u/sfnf/d4tpfGa CjalYryT3lVT+cKZ+Ol6AU/V4Cmm1WVMLWk9gNT2NSJBCr4hnwZfD298+X2WMRH48nGxPwi0PNuz B6E8z/dsKwzfPAnNs0Kg5of4ke/oR/2oc14I0vh69Fas+g1W5WXi6ukmMV2dSOqgE9QJphcx758X u3NYUwuLDWERUPpQDfy6vl+frE+xVfijQHiFfXj+k8gYDlcL4qpcWQjPD3uhyFqKgebfhQYijzyA y00mHD88CGe5zGlN8TXtoQD/kdfRFOh5sdxsyUiO9AcKMGxjzB6h/Uy3hOIIiiGmLP0IhtHHeYQu QrgKOyc+HGjp63Sc56W9hL6hXRu6VSVaJvrX3drQrFVX/rmI3ciE5UsiclFkBaPvVb582WY7kVBl mltTaysD1mO14godcRkvQ4cpbMJVceWTzY6ArTa7NYu9VAEUAdOa5V/5h5lAx8cfqZ0c/4MWFb+n Nhvf0ZYPX8UV6BbKcawd1wo96Qg9Np7/PegVVz4XPuGLfZSeNdUyozE7bAgRUXGioRzCa4Wl+8PW I7aiQ+gGD62Vzv0WvKorn+a7qBglohfq3IHhUQPy/XcqueFUb0OayorlY7ZdsEUs6m5Vbnvex3Ln h6ge+ZIKnT9dIcEplFg/tp0D7Ca8iEbq0F14UXVV3krkrsob5TIOfb7KpBiEslnyfP2UySXJQU4y GjmjbYFUNQ4MKeumKKL1khXDp00RiTy08qKvyStCIi1d4wHaxRVNg7raQD6ujrmjvKJtjBdIravF 4TetQZolX0lXL/EvUnkr9bG4wVx2jTflVDQ1zenN1uB6bIy6M5jjC2ycmlH5JhvEB5une25iU00m 3bbxKVf+hfr4n58BhmmKcS/e0rsuaRjehhw0XYPOVnOoUdLhPSG9usbl/6hoTGQNCmVuZHN0cmVh bQ0KZW5kb2JqDQoxODEgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAxMDEuNzggMzMxLjUx IDYwMy43IDM2NS43MV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkko aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3NjaW0vY2hhcnRlci8pID4+L1N0cnVjdFBh cmVudCA3Nj4+DQplbmRvYmoNCjE4MiAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDEwMS43 OCAxMDYuODIgNTgxLjg2IDE0MS4wMl0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9T L1VSSS9VUkkoaHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL3NjaW0vaXNzdWVzL2xpc3QpID4+L1N0 cnVjdFBhcmVudCA3Nz4+DQplbmRvYmoNCjE4MyAwIG9iag0KPDwvVHlwZS9QYWdlL1BhcmVudCAy IDAgUi9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFIvRjIgOSAwIFIvRjMgMTQgMCBSPj4vUHJv Y1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdlQy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgNzIw IDU0MF0gL0NvbnRlbnRzIDE4NCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJlbmN5 L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDc4Pj4NCmVuZG9iag0KMTg0IDAg b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDkxMz4+DQpzdHJlYW0NCnicnZZLb+JI EMfvSHyHuqzUHolOVT9tCVkKj4wyUqRdJdo9jPZAZp0ZS2CzQObx7afaBmIDdqJcwG3qX9VVXfVr 4OpPGI+v7qa3M8A0hclsCv8PBwgoEZGUQg9eIViDsMmGg38+QDEcEHw92iA6QtMyevowHPw1HMD8 bgrQCED7AJOH4eDqhsAYic7Aw1PwyO6AQKGWiQVjY2kTeFiFMFWsj8PBZ3E/jUZK3N5BpMW0DM+b iIzI4O/IGrFYPmfb6F94+DQczDlECHPwa8k1nX4W0DA826hqbVSBVmcbNVry+9hI2nscI8Y+bUcP SV7QejzRivt8teacljl/fMl3kRG/OhKhxEodt9W9ueiTXJSXiWtvJwnbMU4qf0xlQmep6AtSQpI+ PhFrO0c0BglVOlJjJDdNNfI38XvUSHaWOl4m1/USFT+HRtLpyI+rZzZB8jY1vIwT9nBTPdYO0lEy bqpqEz+rlQc13lQy25CRHtfvJzZET3l5dOdd5aJam9c2QfE0JcSQapx6Fb5vLhz9eb2cctXpNerV f3rmZGRUu5OIrFR8eKSlpaM/JwAi33LcaiHtpI3bolGXLfd5cuq/yzSRum06z4ttlIhdRCiyvOgQ Ki7KeRI9RbFvHE/l+fOd49nUivty+T0vvgLTxopssexKhBLpTqRdhVUqkca1bX9EsSg3y/8YAhBZ seZwXpSPy2zFQOgim9F8QknbUW/13IXqXSqeJon29eJdql1DKuYRObHYZqEtyycIhFutl/yZrbKi bg4tFtyuu/BTWUA0SsRjICB84SKUxfZ5lW0ipTorYB0jsR20twD+AhFjc45ESrSk14l4It0jsS2m uAaUdwE62k4O9EtHgUne1jwLoKQWKF8oybyiANHKzWz/+3WtCzgKfqjhU8WpUnv7eLr3gUd8jQIY pxXkaqrhCyfdHnhspqhyUZk0ra+PjiqLA75J7QHJdrpGfLXJve1lRJ4U0HEPmVb1+48zfls/kyUZ q3f1c1Mq7p/X63Kzg923DGL8A/Kieqx6lQeWRNY5qHxlU9tZb2LJ225uooDonja9dBEduvRFy4Pa wXW+Y5hUTdOf0cjw4CYiK7Z5PaQQXj2FMS03kPEkf6+gv/lVmX7LeaAZoGGRLbdh+ruqZFB6akXr LRLhGy8Dr6R731XwohS3RciqQhYzicFWrgObUCwe8yWn2PvXTXmS2jfdnWX2G5swWqoNCmVuZHN0 cmVhbQ0KZW5kb2JqDQoxODUgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3Vy Y2VzPDwvRm9udDw8L0YzIDE0IDAgUi9GMSA1IDAgUi9GMiA5IDAgUj4+L1Byb2NTZXRbL1BERi9U ZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9Bbm5vdHNbIDE4NyAwIFIgMTg4IDAgUiAxODkg MCBSIDE5MCAwIFIgMTkxIDAgUiAxOTIgMCBSIDE5MyAwIFIgMTk0IDAgUiAxOTUgMCBSIDE5NiAw IFIgMTk3IDAgUiAxOTggMCBSIDE5OSAwIFIgMjAwIDAgUiAyMDEgMCBSIDIwMiAwIFIgMjAzIDAg UiAyMDQgMCBSIDIwNSAwIFIgMjA2IDAgUiAyMDcgMCBSXSAvTWVkaWFCb3hbIDAgMCA3MjAgNTQw XSAvQ29udGVudHMgMTg2IDAgUi9Hcm91cDw8L1R5cGUvR3JvdXAvUy9UcmFuc3BhcmVuY3kvQ1Mv RGV2aWNlUkdCPj4vVGFicy9TL1N0cnVjdFBhcmVudHMgNzk+Pg0KZW5kb2JqDQoxODYgMCBvYmoN Cjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTAxOT4+DQpzdHJlYW0NCnicxVdLb+M2EL4b 8H/g3sgFTHGGL6kIBDRxWrTAAm03wB52e3BtOTHWr9rObn9+h7Jj60VbhwK9KBY1/GaG833DCUt+ Y3d3yYeHX8ZM5Tm7Hz+wv4cDxZRUSgGi8syjYtYotiuGg0/v2Xo4APZ8tlHKgTI1o/n74eD34YA9 fnhgrOIATg7un4aD5CfNjJHKGfY0D4gEx4CBRWkzZmwa/jytgpvS18/Dwec7pdDlgHcK/FhB+kDO Nf22b+85GPoGj8d1O851MHV5WMU0x8rOcpfC3NFS9mMwPn7yTmmb5X+yp1+Hg0cK9BgsdAVrnZe2 GutnzsRlZyt/rOWPTGML0mhJ66mS2h4RKefUd4TTsderxl4OUmgObLwTqPhEeD4/CMP3TIw0/8L3 L5tX+r6c0bvjfxVss6bXagbB2Ru6TjOpsjr+bCJSfhCgS/ADuUE+mX4V2vFiF8Gx2kto4MR8Wjp0 9HXb/Waz/iIiGxwQuImDt0qiGyVB4nTjVLNwqiaVRp8rcg95C/PjdrI+w5oaLHTAggLp0yrwcX33 /Pbrj0B5/iJAhSNGftj+EOqWiBHS47p/W/F/kZYjtlYz4fvpYiUsl2JETp6JGptNeC4L4sE0vM4K ORUZ36wSgZrvA42+rZPD7nUtRoZ/TQRYvt8W030yCwtEAEdUcIFnkYpSgZyuRzGK2aKWviviiLlT 0mFPaOekN3XbyXYRs85AGtcTOaOekNZtFYTCSYGGH/45XKOjO9XtwoWSJ8G3kWlKgsDwBlLjudO2 QHxH8R3trx9Opa9el0jaUyKQhcr2lkjWWyIX4P9SIqDiGqmk8j9qpBrFLY20Ir6ukV7QJ41UbcuE dwIML2IdWKHUadxDm9ngpCJmKyfpPqsxu0qN5pxw5AZmVjpocCOcwEuxolAnkSDBGQm13fFjALpW dd2UfIeb7oaWAWJixgxDygBW2ltiBuygKRJDtKln31PN0LzxwiDRMYMgDWIuMoN0yql55bVxy/mk ghtTczlS+FLMhifJ9yDp08NRG90vaHm1XZL+iuly8zqTi6D3Na3OQ4vd3BJ+1+VojJc+q2Xd1UEq 59hu1cf8CIhqG6Yl6tflGcRr29WpDUkUbP2c+ta21aq9zFy7VSMQ53x3qz5rrrX1TXKVzfzjgkoF nEZHamjfQh8udi+T1yU1TBoqLfULT41xEWrzXE6ZYXp7F1GaAcoc6g6u55v1HKiBWhlifzKj6iBz 17RdAY6xObuw2RKbaWQ+3lbdMzP9S8Lloghf5sIDl6HbOrp3Rprute+kjdNPAVlo9EEKV3mK7S50 ipxugpTY5m/zFLt6kNVp4GntBHryFHXz7o+RDdDIzMS48C/KngTjDQplbmRzdHJlYW0NCmVuZG9i ag0KMTg3IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgMTAxLjc4IDM0My4wMyAxNTYuNSAz NjcuNTFdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9z Y2ltLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9zcGVjcy9kcmFmdC1zY2ltLWFwaS0wMS50eHQp ID4+L1N0cnVjdFBhcmVudCA4MD4+DQplbmRvYmoNCjE4OCAwIG9iag0KPDwvU3VidHlwZS9MaW5r L1JlY3RbIDE1Ni41IDM0My4wMyA1MTcuNjMgMzY3LjUxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5 cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vc2NpbS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1bmsv c3BlY3MvZHJhZnQtc2NpbS1hcGktMDEudHh0KSA+Pi9TdHJ1Y3RQYXJlbnQgODE+Pg0KZW5kb2Jq DQoxODkgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA1MTcuNjMgMzQzLjAzIDUyMy43NSAz NjcuNTFdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9z Y2ltLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9zcGVjcy9kcmFmdC1zY2ltLWFwaS0wMS50eHQp ID4+L1N0cnVjdFBhcmVudCA4Mj4+DQplbmRvYmoNCjE5MCAwIG9iag0KPDwvU3VidHlwZS9MaW5r L1JlY3RbIDUyMy43NSAzNDMuMDMgNTYwLjYyIDM2Ny41MV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9U eXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3NjaW0uZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5r L3NwZWNzL2RyYWZ0LXNjaW0tYXBpLTAxLnR4dCkgPj4vU3RydWN0UGFyZW50IDgzPj4NCmVuZG9i ag0KMTkxIDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNTYwLjYyIDM0My4wMyA1NjYuNzQg MzY3LjUxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8v c2NpbS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1bmsvc3BlY3MvZHJhZnQtc2NpbS1hcGktMDEudHh0 KSA+Pi9TdHJ1Y3RQYXJlbnQgODQ+Pg0KZW5kb2JqDQoxOTIgMCBvYmoNCjw8L1N1YnR5cGUvTGlu ay9SZWN0WyA1NjYuNzQgMzQzLjAzIDU5MS40NiAzNjcuNTFdIC9CUzw8L1cgMD4+L0YgNC9BPDwv VHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9zY2ltLmdvb2dsZWNvZGUuY29tL3N2bi90cnVu ay9zcGVjcy9kcmFmdC1zY2ltLWFwaS0wMS50eHQpID4+L1N0cnVjdFBhcmVudCA4NT4+DQplbmRv YmoNCjE5MyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDU5MS40NiAzNDMuMDMgNTk3LjU4 IDM2Ny41MV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDov L3NjaW0uZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL3NwZWNzL2RyYWZ0LXNjaW0tYXBpLTAxLnR4 dCkgPj4vU3RydWN0UGFyZW50IDg2Pj4NCmVuZG9iag0KMTk0IDAgb2JqDQo8PC9TdWJ0eXBlL0xp bmsvUmVjdFsgNTk3LjU4IDM0My4wMyA2NDQuNjIgMzY3LjUxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8 L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vc2NpbS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1 bmsvc3BlY3MvZHJhZnQtc2NpbS1hcGktMDEudHh0KSA+Pi9TdHJ1Y3RQYXJlbnQgODc+Pg0KZW5k b2JqDQoxOTUgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyAxMDEuNzggMzE0LjIzIDE1Ni41 IDMzOC43MV0gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDov L3NjaW0uZ29vZ2xlY29kZS5jb20vc3ZuL3RydW5rL3NwZWNzL2RyYWZ0LXNjaW0tY29yZS1zY2hl bWEtMDEudHh0KSA+Pi9TdHJ1Y3RQYXJlbnQgODg+Pg0KZW5kb2JqDQoxOTYgMCBvYmoNCjw8L1N1 YnR5cGUvTGluay9SZWN0WyAxNTYuNSAzMTQuMjMgNTE3LjYzIDMzOC43MV0gL0JTPDwvVyAwPj4v RiA0L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3NjaW0uZ29vZ2xlY29kZS5jb20v c3ZuL3RydW5rL3NwZWNzL2RyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEudHh0KSA+Pi9TdHJ1Y3RQ YXJlbnQgODk+Pg0KZW5kb2JqDQoxOTcgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA1MTcu NjMgMzE0LjIzIDUyMy43NSAzMzguNzFdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24v Uy9VUkkvVVJJKGh0dHA6Ly9zY2ltLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9zcGVjcy9kcmFm dC1zY2ltLWNvcmUtc2NoZW1hLTAxLnR4dCkgPj4vU3RydWN0UGFyZW50IDkwPj4NCmVuZG9iag0K MTk4IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNTIzLjc1IDMxNC4yMyA1NjAuNjIgMzM4 LjcxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vc2Np bS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1bmsvc3BlY3MvZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0w MS50eHQpID4+L1N0cnVjdFBhcmVudCA5MT4+DQplbmRvYmoNCjE5OSAwIG9iag0KPDwvU3VidHlw ZS9MaW5rL1JlY3RbIDU2MC42MiAzMTQuMjMgNTY2Ljc0IDMzOC43MV0gL0JTPDwvVyAwPj4vRiA0 L0E8PC9UeXBlL0FjdGlvbi9TL1VSSS9VUkkoaHR0cDovL3NjaW0uZ29vZ2xlY29kZS5jb20vc3Zu L3RydW5rL3NwZWNzL2RyYWZ0LXNjaW0tY29yZS1zY2hlbWEtMDEudHh0KSA+Pi9TdHJ1Y3RQYXJl bnQgOTI+Pg0KZW5kb2JqDQoyMDAgMCBvYmoNCjw8L1N1YnR5cGUvTGluay9SZWN0WyA1NjYuNzQg MzE0LjIzIDYwMi4zOCAzMzguNzFdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9V UkkvVVJJKGh0dHA6Ly9zY2ltLmdvb2dsZWNvZGUuY29tL3N2bi90cnVuay9zcGVjcy9kcmFmdC1z Y2ltLWNvcmUtc2NoZW1hLTAxLnR4dCkgPj4vU3RydWN0UGFyZW50IDkzPj4NCmVuZG9iag0KMjAx IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNjAyLjM4IDMxNC4yMyA2MDguNSAzMzguNzFd IC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9BY3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly9zY2ltLmdv b2dsZWNvZGUuY29tL3N2bi90cnVuay9zcGVjcy9kcmFmdC1zY2ltLWNvcmUtc2NoZW1hLTAxLnR4 dCkgPj4vU3RydWN0UGFyZW50IDk0Pj4NCmVuZG9iag0KMjAyIDAgb2JqDQo8PC9TdWJ0eXBlL0xp bmsvUmVjdFsgMTAxLjc4IDI5MC4yMSAxNjQuMTggMzE0LjcxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8 L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vc2NpbS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1 bmsvc3BlY3MvZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMS50eHQpID4+L1N0cnVjdFBhcmVudCA5 NT4+DQplbmRvYmoNCjIwMyAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDE2NC4xOCAyOTAu MjEgMTcwLjMgMzE0LjcxXSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VS SShodHRwOi8vc2NpbS5nb29nbGVjb2RlLmNvbS9zdm4vdHJ1bmsvc3BlY3MvZHJhZnQtc2NpbS1j b3JlLXNjaGVtYS0wMS50eHQpID4+L1N0cnVjdFBhcmVudCA5Nj4+DQplbmRvYmoNCjIwNCAwIG9i ag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDE3MC4zIDI5MC4yMSAyMTcuMzQgMzE0LjcxXSAvQlM8 PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSShodHRwOi8vc2NpbS5nb29nbGVj b2RlLmNvbS9zdm4vdHJ1bmsvc3BlY3MvZHJhZnQtc2NpbS1jb3JlLXNjaGVtYS0wMS50eHQpID4+ L1N0cnVjdFBhcmVudCA5Nz4+DQplbmRvYmoNCjIwNSAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1Jl Y3RbIDcwLjIgMjQ0LjAxIDQ0Ny43OSAyODMuMTNdIC9CUzw8L1cgMD4+L0YgNC9BPDwvVHlwZS9B Y3Rpb24vUy9VUkkvVVJJKGh0dHA6Ly93d3cuc2ltcGxlY2xvdWQuaW5mby8pID4+L1N0cnVjdFBh cmVudCA5OD4+DQplbmRvYmoNCjIwNiAwIG9iag0KPDwvU3VidHlwZS9MaW5rL1JlY3RbIDQ0Ny43 OSAyNDQuMDEgNDYwLjE1IDI4My4xM10gL0JTPDwvVyAwPj4vRiA0L0E8PC9UeXBlL0FjdGlvbi9T L1VSSS9VUkkoaHR0cDovL3d3dy5zaW1wbGVjbG91ZC5pbmZvLykgPj4vU3RydWN0UGFyZW50IDk5 Pj4NCmVuZG9iag0KMjA3IDAgb2JqDQo8PC9TdWJ0eXBlL0xpbmsvUmVjdFsgNzAuMiAxNTcuNTgg NTM4LjE1IDE5Ni43XSAvQlM8PC9XIDA+Pi9GIDQvQTw8L1R5cGUvQWN0aW9uL1MvVVJJL1VSSSho dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2NpbS8pID4+L1N0cnVjdFBhcmVudCAxMDA+ Pg0KZW5kb2JqDQoyMDggMCBvYmoNCjw8L1RpdGxlKElFVEYgODQgU0NJTSBTeXN0ZW0gZm9yIENy b3NzLWRvbWFpbiBJZGVudGl0eSBNYW5hZ2VtZW50KS9BdXRob3IoS2VsbHkgR3JpenpsZSkvQ3Jl YXRpb25EYXRlKEQ6MjAxMjA4MDMwODA5MjMtMDcnMDAnKSAvTW9kRGF0ZShEOjIwMTIwODAzMDgw OTIzLTA3JzAwJykgL1Byb2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABPAGYAZgBpAGMA ZQAgAFAAbwB3AGUAcgBQAG8AaQBuAHQArgAgADIAMAAwADcpL0NyZWF0b3Io/v8ATQBpAGMAcgBv AHMAbwBmAHQArgAgAE8AZgBmAGkAYwBlACAAUABvAHcAZQByAFAAbwBpAG4AdACuACAAMgAwADAA Nyk+Pg0KZW5kb2JqDQoyMTUgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAwL0ZpcnN0IDQ4MTUv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2MTE5Pj4NCnN0cmVhbQ0KeJytXU2vJbdx3QfIf+il vbCm+VFFMjAM2EiCJDZgQdLCQJLFSJrIikcfEEaI/e9zDrv6Tr97m2RfPi8GzenLqiKrThWr2Ox+ 3oVlXbxLi3hcdHGr4FoWp2XxHj95t/1LAffzEjx/90tkPx+WmHHf6yKB/5dFcl58WBclP1+WtPL/ YUmacPVLBo1H35zxe4hLCfw9LaXw9yqfHdzinGMPjMRlRSMvzkfcwT8XVgwook8QUMW4uIih+xjQ SOwDPhLYR9DI7ANyjeyTFpdWiIgrGorOgkYGDx8hq5CzR+einDsoV2GDynHoU7VUSMXpgr2XyHlC WVI4AfbJHCX4kHvMbOCfcKL158IGRqDkoRhTcmzgX+LgKTgHNtCvrBgCVVdImtwSVs/GikberBIw eTQ8GpVzoY3QgGpCtZboEiLNkAQN2jHFJQiM5gUMpZAcnTWhTwbnRNUl8EkZ5DBUyFQC5IVC1cHk oXB0SYEDDhX9ogNqPKwfHWcBpUfiAjNAgyJyWWKgnvGfGFd0LoBPHU+JS6zjKeAjiT+BXMkZmo0K 9mEFnwQ70PYxYSoes4V22QfDyIUqAcPCeQOcsjreATLXyDtAuFupv4gGbAFFAvOATcBQpM7JOcAY WAxgKoFKgndIBBwCeElUDiMvIrFqfRGlCBhPVNkZshJdhN6UqkHQOWNesAwdA53hUVIA+wB8AAj0 p7DoClDTVLpiKgEE6uAyAZZWB0UG4FCrPTEU5TADFKGB44GLaYxECu7ISs2DSkkFK8Kk4Ax5muFz AUw1ww4B/9EC5HK2acUsQ6CrakXKkhxngTElmjIAXomuTeMlmjpg/ilQh/CoFAob4BOJJrhEgsYX /pyE5IBOqvqBfyVwRAM/JSIOrp4yFQ63SrkQjJBVKip1yStnimnnlTOFt2RiLGDcuaoFnpLp0IDw komLANznAG8LcL1MH6RD5gicBnhcFgSmgElmIVrANEN3Cwly4pjhOznRTAB3zjQTPA4KYwOyCgYO 51jKurLh0YAc+M1SHJGJ8FXog4ROIQoCBJfAmQKvJQp9Ky+YH6aDu4XBMkBeUWgiAPclES2wWUnU BjyuZKoONi0Fpg6AqVvXlS7JWLlCNpwTLQe7BbBzKyIWWoktCIPHokWLBRjerQyUAVhBq/qzY8St SGA/pX4xXbemzH7kkgPvUVqmw66kwMjRAgUEC2MAW4ktz8AduD4oW2VbKRDLYX0GIfy4spXYgimi I5foGUkY67meRNjCOXpZdOQHJ2B4YYsyHPmlwBb7Jcpw5JeFLcotlOE4qqJsgbNfA6VxGVkZbwAO 5yEELYzAc00Lhf1qKC3sR4sEzBmDj+zHlnDNw2jRYvSDWzgEc8Y4UigDmCeXBKxE6hQRFQGLCxpc B1ygG1fDegzkx3UGYbGuaeCMWaFFvXAtDMR7hIOglfgrZASuSpHrYmBEjlzHAh061gWRVo51jYzU nydtLDUYo6VAJufiAMgafNGCd6FFaZljEXIpnoGYnAvAGIULK4MUojRbDMpwRyw8whbXX0ZShG62 qBe4r4uMNxE90CJygBkXyTXC4RwEsbWypTXao6Wcm1KGAvIMuFjQqXuljKpJrtIxK1vkVyiNCz+C Du6BkxNYGEvEyha1BgQ4qVrD7NEiXhIpGJEYG4AC4iUxWYjUPfzGCRckLDRsEZOZ/JQ6TeSXuB5B N2hRa7AEEg1HGb6mHGzxHtdJ8nS6UhuYFeDM/Ikeqg4zjPRkZc4V6Y3KAB7ptcrIG4k/pddFeq1S i1jj0BJ6BX1VhV5BxKoSB/RaVfQWeihcBtKIbM2cJT1ZM3Qi9FotgSsk+ZXMe8r0iPncWhOlxHvg jCWB9wpbQANthxZGKfTLRO0KfTUxxRF6XmJAFnpo4uLCNQGtxH6Qlkgn9NUkpGDcSPRzYXxJaaVe KC1VDXEEWbRmm3R40uJeRijkIs4WUCj05Ozqeu7Zgl6EkSEz+RAspy4zxgu9ItOfaWO0YG+miwgg wBoXCaScTA/olxlKZVqAVqJc+mXmssqM1+UM/xP6dGbqyCQPLcqg15aVeqFflhVzEPpqAbYXxjbE RiYl9NXC7E/o04Wrv/jaKpwRU9E6PkafUsfHpLaoZ6smqvyVnlygaCQnlJFgb6Enl0xr0WsLY47Q k0uB9zDm+5XRW5iGYiUhBVKw1VEvzKtXR2sxlVyZkAsT3NUDrcIUdSU6hZntytVBmOyujB7C3HYl kmhZtCiN2S1WF96jDE28Rxlc8IS5JFYc3qOMTEwmymBOgJxqYcjmPWbfK/UMz0VLeI91CXNBgXd7 xwWfkdk7Rl96BlpYIZGQoUWdCNNcuB6TNHJBaoTkzLEIikzTWA5lZomsUGBqcMnkXKiDXKsj6qDW PYw5tAmWD2qSlYZnus78AtUR8ZJZRzEREJYNnrEZGSBb1FohLW0mhQWFUi7uowW9C2siJP2kyGwp KcgvA+m6UkbGrLUWLcwPiFq0mAIyUUdCzHuRrcJ7wtIq8h5LKgwfrVqXCe/VSs3xHkuZ6ilM3JEJ MhFdWd7U3JT3GF+QpbJ2A6a01moZHJRVUuCopJZtBZjXWpytQorCwm0lF1ZJMAMyWxZqvua4tb7L vMcKraapLHciVzVlLRMZ6zkKtAopWNvRqgibrPtWUlCGckZAAPJDzqgWg0l5rxZlnFGgjJx4r1Z/ TJNZxUZGQmTXLA0j7yW2CkewsmQS3mOBxURWA0s/ZiLKMky4imisBSKr4EgKooYrByoxjorVHqDM e2wxAVZm8EK0a6Q0op05IQDh/FZLw1CsqlkpOmb29F8oEfyklprCX1kssupQerISdZSImEwZUgtQ 4EzptUpvV3qy0mbM0NHi6OmhmogmrcUnvFPpoZpZddBDleuv0kMVufBCb0aLWKsFbIGHaa0zEUJA wcqWvsrsA3CmDPpl4v6A0lfTVrSQgmuFMpYk5kLKujPRU5Qen5gwM2WHK9AK9OSUanlTa1j+Sv9N mSgh/hIzQeWeRCrKe6xRmT+zQkKLoyq1tiX+apnqiL+t8OUI6Pu5VmmltjhSemhmNqb00MwsgZkf Ejxahr5a1w+lr2atMlg2J/gQ/QYt9Em1WEMpsrD2wAoFK3DdQ4t1Ef23FhpprVV0Yj9uBCCfY83G Vua9lbUfRkDuKKlZd9WimDlXcrW6DizlSMGsg/6AQlvYj1U0vTjVcpxWrvs1BYvywlIWoQQWTMR9 wfK3cAVESQ5eiZ6MlUSXrShfWUlCS2iVWjiyUGdVWCtsapKIR6uQIrJWF2qXFMzZa+GzMiNILNJW Rv0UyJnezpWNaTG4BNbwHBERilZhdcpyPsO+v/71m0/r9tS6fPbm8zef//j2+zdf/O3Hd28+//DT z199+Jf377578+k3S6i//35Zf/Obf/wHo1Gj+Tf3QPH7/1zcfy83wgPRLuiLd3/98OUPfz2j5N4a Op3TZ6P/9JRygiZM0MRXzK2wU90o3K6uOde17EZ5/+3X7865hY3LZot92Kfc/MjE6dHEwN8FE6eG oJ4avH4c6D39Pu0//O6Hr//WMfM93W6yP/z7KVFYmyKDH4kM53RuIDK0RcaRyDgnUtoidSRS5kSm ti1vNjmn9BtsN2XsIzwfRB4NXudQUZoioxuJTOd0a19k9G2RYSQyz4mMbZEyElnmRLZtGdNIpFvn ZOZZJG623g2wa2Uf6vlghnHKNQLkAJLSDlQ+dWfhbXEJNpvNaXa97UN+RdRu6/fCYuVNt95069u6 ld31WovVtoy+XK1kD6nd1WqjPBHVm7gcouoDg2Fk8g3CNMBBaQvVYWwKDcKBC6nvCB1GpzgpNHaE DuOTTArVjk37fqbmX2qI1g48dBjsdA4emttC0zoSmhqjLX2hyXWEDrOoPCk0TFsqWeRLHViLdlmI BVE1VptB91G/Jqikji73WHZaf5RXSE0drF4I4mIpm1jKJlZ5pI4Lp13BrWi+FUEvo3nax9KN5hvl iaieCvJhgb1nkF1P8f41Un1b6o3Bv377zc8/vXvz2/cffvHLTlS/p79guGSwTZYjZIthOXSUEQeG s+TxheFyumK4jfJEVFeFh5D3wKBcMNyU1LJ2pMbnDHdPX3xv1HGGSGaItEE08twbAJIR1T5//N1/ fPbmj1/+7yJbxnDGOV/lnM85xybnWzj/9vu/nBt0cwEekNmurm3gvtp46qZ6UWkjk8dmLk61nE9V GlPlyZyLnN16zlqbrP1AizwxtGlP7ZpmtchTSBuL2NHiZcA4dz7X1JqrWy+z9uesc1ONeaRGt8Xh sO0e1gNU02o0XLtOwOqzcFNhyk3FKTcVqFwrUvWp0hRVnqIqU5FkPYf9cNv2hk3fgH1pYdNfjh7e nwyoiWir78Nxj/cV0wpTVPGy19i2hKmjHh3crp1kY2DLBrKvZRtWUxZLsIvtlpQ9zFqc2CJLPVW5 XU3r9iggOJuG2/tZcLAHD8Fb3PHGz5f2dC+kl9mGmW1BzJZmFkszi2+yD2EUf62UP6aZIeybEd00 c6M8EdUxQQiHZWiGgW+QjpKp2zQPkL/te3/xzyeiGoK6NHtWeU8Vu5WPTIkKx73uB4GhJ1AnBXZs d9vqPhWYZojy5CjNSY/by024fPHZOUrNoW1z1+y3q3UfeGNS3WKpNIgGkzruWz87mePO9D2t9Jfb tUHlBqMN86OVDqqlixfXiEsDqkZEue14t+ZoMJNXwEw6MJIujPZk8oFqgCN9BY6kgyPtI8I14qJ2 w5RrBMaBsKCdOKV9MDQi41CizqtVLUmwDe+gHVBo9+iEa4TZ2zZ5a/Qdw952u7tZ/LMSj1vdDxIv VQBPS3xFSFJL82zDO6ROiPqYw7z98v1pOheCZY/2BNFi/x5V98iz+/IOvn2Kr0idGtE87S5xmjv9 9qsPP799T7a/+NN//fTL7WjMKxLA1HGVlJ4dSSsdvDSS3BlJeXYkjYB8aSS5E5Vz93Ht2Ugasfba SDrQzuHZkbQS20sj6QTx/DRiWxnvpZF0EJufRmwjRl8bSQex+WnEtvLrKyMpHcSWpxHbiOnXRtJG 7IXaOthxDit567uI29XSu2TBONl9e9RjAWJ3z905dmjuwNjNsiulobCuY4HAnli+qNFvW/H984Ox Iaqr0uPhkZcM+JrdxmB4gvBecv9BdDw+KHgQevkM4bNCQ0fo8HBEbBDGgVDtCB2eaJBJobkjdHja SueEHjfL26Y5H+/mR6aQfYznw3CXDxM+CQ/nO0KHh0xzgzAMhEpH6PCYaZkU2nb5kaVsk9TG1hA/ PMd1O5X4rIk6uPDDWOVaYXIg1beDVSjd05AWQPeYtvvQDuLdUrvK9km8Jpq3NXRlgbS98rDvkZdO IBmfg9eHhSxePAivDVGdqccXJ+HvGeyRtnem4TmiMEMUZ4hkhkhniNIMUZ4hKjNEt7DxHFULVH2q KVC4KVS4KVi4KVy4FjAuudgeprY8NwYLb5ZXR3sNIVp+He11hGh5drQ8O9qmSLRNkWg78NF24KPt wMcXB/xfDvhCNIv2QNKCzq6Z8/nHUVqeHx+dxXgpLc9rQ1RP1ccHGvcM5Gpa/iB5sNKJ6wi9mpY/ LTR0hF59uedpodIRevX1nqeF9mx69bWcp4WWtlAdAinNCdUOkPTq6eanhXaApEMglUmhHSDFfnIo Fu3sJLCBfcffDondSrvi9rm8Jra0IXElrEYbpz17jceXhR70PnpUnx/fP4m3Y+z9sFoaonpTT4cE +55BGr6V4RuEvo+R45HuB9rhxkOYFKodocONhzgpNHeEDjceZE5o7tg0D3cLdFKo78z0JvRcSZaW 2C6jWWNX0D7m14C8PbYr/m3vZZgb7tNp6HeUNpXHNxJivpQ2FdcQ1Zt6Piyx9wzK1bTpQfJgDThu 9z4IvZo2PS00dIReTZueFiodoVd3Mx8IdSA0d4Re3c18Uii/X9UU+lFL5+M1/znuxdyxkOFR9pvf nL8PUG7vAzxwHh1GvXE+fx+gxFPOd53kSie90ild6ZSvdCoXOrnNrsNerqne0aldsc1sseP8Ypva YudMxQ6Xy7ZfXr9itl29XYNdD1nDPHzKDJFbD1TDFVTsrQODXv3K2nbV5gxGkcYG26Dt59XF8uVi +bJtaprL7zN6zSLTduwr62u28WTLn3M7vonrPnIGgTOrHhdYue2F91/g3khPhHUmL8fd8DaHw1tc f/7w4cd/evPm/97+9N2v3r97+z+/ck71kz+/++mHv/z89scfP/nqh+/efPvdN2++++Hrd+8/+fH7 b05f+/LnEi/oW2xz3bRSP9DXnoEfJTRufXxVT/yljMZIT4R1FX58u/WeQ7ia0zzKHjhgcD2xw1Ip tCj7ebUcj4w/El99Svu8WO2I9d313pSxj641gKvZ0fOGyh2xcYgPbQ14IDb28BGHWW+aFRvmDWXb yxJ9j0d3cTGH2wG123Uf96v8vMPhSpiz124sFu0TaRlolCW69fEzVnL73swgzKWGsN7044vh3nO4 8k7yk1RhiipOUckUlU5RpSmqPEVVpqj253jPkjXx1Sebg4ebw4ebA4ibQ4ibg4ibw4ibA4mbQ4mf Q4mfQ4mfQ4mfQ4lvouRKqLQHB2JnyMUeIIhYImIPEkSsDrMHCiK2VtmDBRGrRO0Bg9jZc7EHDWIv KYgaPzV+avxso1DsyLzYhqHY0XlJxu/FN2OaMx59+ME3XeQyh5a33Dbhz43V9JYrxkr6d5l80/Uu c2h64eUvb7QcMndfGwmvSguyu6K+3pGolmPfSv3zUbcce0D2Kse2nQHJ0p70lVTQPrpn+doejOoH y7erybEnEGJPICSZI9uTCDNs/Rz5dg0dY+TRoz63Pj7rk9s+0CClLA1hPXUez60/cLgdXO+nlE9R hSmqOEUlU1Q6RZWmqPIUVZmi+phSPkfWwteAbA4ebg4fbg4gbg4hbg4ibg4jbg4kroWSa3HBwpl9 IUJsg1jsCxGybxTbgxwpFhbtc0f86wfb1dnV2zXYNdpV7Kp2TXbNdn1R8bdmMlzYW9C/ogvfcAC9 fYN7kC1PyFQX/i7zbnjTlQXSXtix1WdHW/1LE9t1/79Z1sX2iNV1X1AjhXs8Ca23U/L9hc9pQ1hX wUdg3XPw3WzNT1GFKao4RSVTVDpFlaao8hRVmaK6LXxPkrXwNSCbg4ebw4ebA4ibQ4ibg4ibw4hr geSSg9s3h9S+OaR20lltD1jtxLPaXrDap5jUDnCrHeBW281WO8Cttqut9khD7QC32gFutQPcevxS fXsGowjuWpC/ogPfAn7sx7cW8AdkLeBfMpedZ9cXDx6m1eYb3nRh4VP7qJWtPjtI6x8V2q4GDHtU oi8etzyobPgQwRa5FwvfxYcIG+mJsK6ijw8R7jmMT7D7FmX/DzeohJ7Y4WGsMCtWemJvT/7Oac3T JfZ4DE/Cx6H0xtBTT+zwLLzMii0dsePT8Dop9ngc/lHs8MTBzYvOz4I5fzvT9Mh8nJvuzM+Pgznv zpnfd/PXuoVr3eK1bnKtm7b1czvI0DjOpbbZrbbZrbbZrbbZrbbZrbbZrckcK/ViwhM2L1NUhxNc T5G5A9kwXKo9GDCU1T+ytl33/2tHB0On6Snw42sZ535uxrAnHxZRdhff5/aaleb4jbZ7DlcWYtui tdVwn1BjRP1P5ZDCPz6t19u2fH+h9akhrDf9F9vy9xz6X2x5MVzf8NjbWc5H5td1EU6G1PTzbBA5 Hu57zcziFJUcqIZ5g9oJQtNJ/XOC27Vrnf7XAfTFw4d74uHXSz5ORc9NG9amact1PaWTITVNa/t5 evzUyWtmlqeoDoF8/FKA2p6k6aT+Zcft2oXnwLTHdwbuidPtoO94Ko2PoLvgWrZN63VFHRahj4Nq GTfZZmtaO7B9am5+jiwcyMavVdqWsaml/qHN7dqD6MC8ae24ffq4Jo3nEhvm9U3zuic0JSeDaprX dmCT60L3ibnpHFk6kA3Lk2T7yKaW+ndPt2svtg7N23H9ND4o/nEujUw/hLZ5n9BUORlU07y2/5B8 D7pPzM2vc2SHkDP+7E6y3RNTS/0ztNu1A9KheV3H9ZMfJgO3Hapn5fouJm8r1XmusK9Sezgzc667 giys+XhFRv+E1YNKrmPStwLaxzLznnu4HtC8nAyqiXjbYk2hF9D8OMTY1m0KPc/5+GcOG7Y/Dyn/ D16Rt0YNCmVuZHN0cmVhbQ0KZW5kb2JqDQo3MzQgMCBvYmoNCjw8L1R5cGUvT2JqU3RtL04gNTAw L0ZpcnN0IDUwNTYvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2MDA3Pj4NCnN0cmVhbQ0KeJyt XV2vLTlxfY+U/9CP5Om2v10SQgIpURKQGDG8RXkIYYQmmQBCgwT/PmtVl/ucPnvb7ut9kIau6931 4fKqctnu7lN82fYtV79lXErZXPRbCXnznlfZfMm41i0Et5UYtiAFV7/FlHDNW3L4PaYtlYhr3HJg e92y8Ip7U8B/bqsOv6d9qwVyU9wkBP1NBHKT39ye+EPenHMkEoiyg5DNeepOFUQVEDAyQFLJDtY6 EjuIXEHEzSWPe3IAUdkCyTmiBf9BHglwVSXAVQVWwGIniVzo9h5IoN87f4JQ79CbUhw8wi7AfO+p q4TNBzoJHfeBXipp8zHAHvzDx8qby+ZT4M2Qk4Q3Q3KG20rd4dod/aqQzH4XjIGvji2QXDMF4h7x bIlb2NFcat6CY3dq2oLfoaIWEHQUXBNCoBwOFr0q+xYivFXwj5A82GFBSDRMIDDTh+hkKDuGCsMV 2MuC8Q01kAu6Km3O+Eng/iKyRefqVneMv4MnKjoQPSBUYUr0EFb3vMUQ2VJAwN4K6THC2XWvQA06 SO/HBKkVgxezk43djhkerRj7WCjQBRD1wE2sgTdDTkWfKhAXJbKlbGnf2VJBJLYIAAmp1e9EJlrg vuQ9WzyIwpawpRDYEkFUtgC+aqEHnqOwBZIT0eohOe9sgeQMoFVwpgJbKkCZOEQ1QDJlVEAaoGML JAttxn9JaDMGJu+0GZ7NjjYDFtnRZgAue9oMC7KnzYBoDrQZcZYDbUbgZUKrMsIibYasnGgzwJQT bYbTM8e0Mvo4phVAyQyOmhjitBmBmCttRrBloc0IwSy0GTFZdtrMwN5pM0HpaDMx5GkzQeBpM6Ml 0GZIR7ZAS2Z6oM2IOMQ9WzTA2cLIp824DyHKlswYY0th2LClMiTYQnDTZmJaaPMByiNzAHlsIc5o M0IPQGGLjj1bMseVLYVDxZbKYWCL0LNoqeo1tBBeiTYj9NBJtgTazZZIm9hCTtpMKDNKKiKu0qMV gQY8sgWShTbDAtlpMyJOdtqM+BFHmxEb4qgZoSeeNkOWeNqMQJNAmxF6EmmzVBC0eQdXos0IPbcH RAfkk0KvBHe6PQJ0sjN/RtwjiENkUnROwOr27GlRIgX7BcHpdmZbGAeKsSU7JdMVgvh0yHoMfVAA KU12TMiAluBeZGZoF4QmKKBDHNM1k6AgFEEVtpGXWOXggYInBWHpHMIHHYbNLiN0mNdA0VGe8pgC BZKQX9Bf8dTG0RRPHRJ5H+UJvYXwhClAGhwICvMCKM4PrtJm6PAe4BfoweRB1yMinY/sB/wF4+Ex Bii7AV5Ep/OZUgKlZOWgjqIc1MGERCtA0fecPJDvIAUxCkpHDDrCnnkfdAT0iaNIilYhTuGqSB3g RQKCffiXw8jrIOukBo7EXxP7lihFrUqUzElaOC8Gzs/CqTIwx4tOiMwMTNKgaAunTSRtcOjkuGPk RefLPZPDc+bE+Ajnx8iAEU6ZEUaDiqQKeaEjIouDSqTol8waIUG+IFQx7XryVp2AIblQG+sCKZTM fC6FehnqUqiDIyCFOoSIRdi5pFax+kjwPqhMipiMbPMcBYSvSxFYEfgBFO4W3IEUylGonPkTe14p L7PnlVIKe14phZlQELMoDIj7SnnMO8zPLhF7rEVAEXXCumEnitFnUJAqiFyX4UFQiRQDGGh0cAHb oAOpg22VFLUxanOknyulRHqHE5ZDomYoMm5zIep3hnVmnaBx5zITPEiq1CDcGcVZvbozeJGr9d6s ZQ36Q9bist7KWsfTyB3+d4XVEkj8hExGvYxbQJu5gkGKNM1kwShFvaU3UFgm2HbGKQoDKmPwFhY1 uIEmcMZCK3jLYSN7orkaZGaZpXIZt5jzaTmDtLpDLiRUllQgI0mVy9jA9KnaYA40qDbecHiPyacy aNFNCsuM3R0QQLZwmiSprWjfGPSVE7ZjVQeSI6N+qxo0O+NUtFucm0ESjDsjFf2hBIY0shzlEolI S+wQzUPmoTBGPxKJtsIDyAE0h35BIJMtKckQ2FmCSlZzyCBMM1r2OrEKmDZwngZJxVV7wdQgmo6Q 9lGXar93lugYaG1FBbmz2MG9vMGr+4A/FLM6CySWs4EpYUdso2yk75moQDJI9ky2FPUGys2qguUn fqLpWhAXNZ0F8F7UdBbFe1XTWQTvmvF3Fsa7Bviu5fOuprMmdkyJnIBIFlVM0gdVDLlIlUo6kqKO IltMag6FJXp5Z83sDqSyjnZZbagUVnQ0kQ5AFp3a0DfHSgokhR0TKKIfJDMd5j5U9IpiYhSkukSO gp8dgiGezbw3kFQgslz3h1NZ5vvDqYhE7zljO44NSB0W4Xoq64y3O10/iE6wILlWAkm5VSfbnXJZ /YBEh7xOWAAPScYQ1GG9oViBp0AeSEWqAakxBGBiZZK1F1ykBMYBaJBR52kkBZBMJfgfyMSwpBj2 R1dgUIyqTud+qmAS1cHjQkdbqaLq9O8ol0UaqwOQx4TtKVfzM6ZirIaIV5CBpPYCMe+j0857rpu4 mHFM/iA5ZWHu5WpKVcA8rxMSSGiLUe0FGkEy8TtGQGQ1zGqEpPYiUJtCA5MsyLIrG7XpStEFXadp ScLIiqw3QFIbp3aQ1KZzBmis4DQfcAbAqo6o5mLZQ6+2OpJqeuS9h1PBAFK0EoJi1ECUG7kuLExw mDZJVh1NLhJZkDsu8bwuHDAUUKFLB5BQkYkgFlMks9ZVkJu9akOcgBS9ASqyJn7HTIBZiHKTLj/V k8gwWGwElQt7c7ZyjSRnK8eAzFwTO+YWYPao2MjG6prFG0itcBwDvehs5ZgUCjOKrt99cYoHxjwm EdrLaClePcmQLl61MT+UwNzsuEbGMl1rQUqIh7DIdbJWiMww5bCX2ahkzn2OAVl0Ve90Tc3lKkgq rup1ZoJyVKqM+aIlFG3yVedJLiBAKuwZ/nXXARBdl+tgMZwqO8uKFKTn7MQ6AGTUOjWT1NFkssHS kN1kJjimL8fYRMZUxZSQqlqmK/6inuS9Rf3AVFyrBg4zYtXinuswkFUrYLCJTkGeWUMY+Y42AQIc N8/8gMKGdS7DHzWy3gAbhGt0Vs4goxbMzAQoUrWe5r4DyyrH+RkkKx/PCEAdyPKZSQFlHVUwVQi3 PiCXZNUKmulKtKzG1LVhHaamI2uAVNOBpbA7NR3xB1JNh6Vh18yFfAoyqOmeEoKaHsgWOQkjw5Gk +5ANQSYt2BHzKMGd1v2UkA9hVFyIX25WBF34gMwki7KRPAr9QBu0hvPc9tLZCCTYNMEhce0kq9oA y9BAG/B/wbH8A+lIZiV1v0aXJpHCNF1xaRIcN2QcK1uQnKhYRCLdqX8TJXC3CiTlFhWGn4LTKGTB HljlbD/96ZdvdPtu337z5dsvv/ry27//+bsv3/74l7/+94///MN3//fll/+BJXvlz/+5ffnmD1zT 8B8/+9k//sPBW4rx/va7v/34uz/97ZkEJgTcBEnZrqUvkVA7JH77w/e//+6pvKIWbVwyHFffl8f9 OZP35//644M4ctgdv9z2d1zVuP7VPTPBmbKD9YmygTu4L/pm7kcJ8RyMX/zp939/xu97nK5x/ttT tTGM1KaZ2tDjjBO1eaTWDaF3WNXjLTOT46qn6kBt2mdqU0+tjNUmN1IbZmpzj9NP1MaRk2U4QGmE qTTFVFn11AhTqc7U1h5nmagdBu7EUyNM5SmmZNFTeYSpPMWU23usE1DlF0CVh4lqnDGO6Gygbxhs Q9s83ezv6diHOqLJPjJfS0StW6/MDHEwWjcmRu7sqSXH7NU60hvC+cRYHifGfHNiLB1lo+7niwM/ SChtUL4ZTopfxRWWuOISV1riyktcZYmrLnHJEtdbYvk6th6+Jmxr8HBr+HA9gNwKguKO2C2WZYoV z8WyTbGMVizWi2UfK4q5baVXK455CnpcTV69ZNeehf/y/R/++pfvvvz8hx9/8k9P+9iDc01D1/Tw fMs1NX+K6b3oqHVoei887pk+Sm33Te8F2x0bfC/kbqv3veiTMPKc70XfLc9J/AzP+V4oSx6a/lIo S+mbfmc6zxbiuYV2C2lLBdVSQbUUUO0+sfvEQl8s9MVSiRifjOJJWjT0ywN5KA/4SMet8kA6ygbu 5HMj78y9SuBZ911zvXHpTb/+xb//5suvf/c/PNLU358Kn5dKTXh4YtKvvv/j/z7v0THAfNrlU3oW l7jSElde4ipLXHWJS5a43L7G5tbY/BrbM5jdYFsDiFtDiFuDiFvDiFsDiVtDiV9DiV9DiV9DiV9D iV9DiV9DiV9DiV9DiV9DiV9DSVhDSVhDSVhDSVhDSVhDSVhDSVhDSVhDSVhDSVhDSVxDSVxDSVxD SVxDSVxDSVxDSVxDSVxDSVxDSVxDSVpDSVpDSVpDSVpDSVosXNdQktZQktZQktZQktZQktdQktdQ ktdQktdQktdQkhfXN2soyWsoyWsoyWsoKWsoKWsoKWsoKWsoKWsoKWsoKYvL4DWUlDWUlDWU1DWU 1DWU1DWU1DWU1DWU1DWU1DWU1MXdkjWU1DWUyBpKZA0lsoYSWUOJvKHk5hblsTNrG4b60tpxPQ5l +HLKcXV29XYNdjV+Z/zONghdsavJcybPmzxv8rzJ8ybPmzxv8uwJrOpNnjd53uQFkxdMXjB5weQF kxdMnh0412Dy7OC5BpMXTV40eXZ0XqPJsyP0Gk1eNHl2pF6jyYsmz473azJ5dsxfk8lLJs+O/Wsy eXb8X5PJSybPHgeo2eRlk5dNXjZ52eTZjjxfRzmuJi+bPNuhr3aIV+0Qr9ohXrVDvGqHeNUO8aod 4lU7xKt2iFftEK/aIV61Q7xqT9RVOwmodhJQq8mzE4FqJwK1mjw7Gah2MlDtZKDayUAVk2cnBFVM npg8uTzF0tvEnx3GSHouge+kHRKenzTnF04PZHefYnrpmT48ApP6kunxU0yXF2xw+/6qfrd3Tn9k Hx+87v4l50nfeXcO4cRCZ7eQ2VuoHO2GWX2L8rgGuya7ZrsWuw5CSFwLgO7cZM+Hvj90E9ewNz50 O1ifKBu5z73H3oOE4WG/X+IKS1zxpT7aENksK66O+twkzvCeXjApv6q8dAR4P/JifcWLPnyG16Rn +Pi5kv0ly/NnWO56cebH6a0bJrdMl77pN7KbWCFqKaRFmb5zrVcrMMUKTMOPvmF9XO1+KyjFj0In zLNbfMxu4WZ2ix1lI/eFS3ZbkOBnvDPUhJ6AMgJNfKnT9U6nb6e3DwLisIbLrxh+eTx22fDSM3xY wdWXDL8Fs9upccGEtwR5Zb6TI2wxaIGoXz44rjZt2uJPbNFnCNBvGxxX47NFnlzeCHkYhYb7fo7I jznifCljkiNyR9lo8C6vZXyUkIbzqV/iCktccYkrLXHlJa6yxFWXuGSJ6y1KloBiOLdNCLFNCLFN CLFNCLFNCLFNCLFNCMkjoJ0W3C9DFvrgeoi9r76H3jwu4HrwveX5nD/Fc71gyOMCrhcN90yXTzG9 F1vFDU3vBdct04v/FNN7oXrHBj8N2NvPND94bvxg8DRQhp4rfc/dmZFjyyCWOWwbVHK7Wiay7UuL Pf36znE1ftuuNJToF3aOq/HZNqX5oueo6YPCh7nXGbvee1D4YH2ibOTey/vAHyXU8bPqS1xhiSsu caUlrrzEVZa46hKXLHG9zdhfx9bD14RtDR5uDR9uDSBuDSFuDSKuh5F7kWqJxs4vxM4vxM4vxM4v xM4vxM4vxM4vxM4vxM4vxM4vxM4vxM4vxM4vREyeXGbdnuXTqauDdP0e18hnPazf8Zl+9+sTjPe9 yLljhJ/m56n6TijpR8lGCboXSzd9V/q+uzPz2sGcTV8tOI7vshnhGnH+FBuRGpH7VuiXySYTqi13 30+o+oW2OzPqwftM3dBx7j3oHmScm/PTr1Y8so6/H6Gfmxtpnr7tH7qs49f99ZN2A81++tJ+XNbs 3bDPp8s6dlfDmd+HHZh+aiQtD9rlMOBR8xQuucs61TyEi59+NKSsa66vDJpvyeHydZxHK2TWgbo8 aGEIl/OUsYe61gE7RmsAO113Wv9iJop9GTdSuH7g0gxtqdoN0RpaYu3n48dDWf1+5K187Hvqhl4I 7z+N8yhjmhV9l3WWmy6fL3pgP79fNHdWeyZLb3p7D/PYPutIj7elx2dG9d7E1C94Hli47E6/0r20 xpbfs7nZMOpXSM3wFmSxxd/lO0aPXdknAx39EGInTjrcbqh8msbKMkDTPtKcprNe7bKOvxulH2Yd aY4zzbKueZwOJmOVWqK+fAvqUUweiwmt7oitGI4t1aYhGm6mvNKXcSvxh9bN0EIlDIM9tf72o/bx 03H6wdxbiT/11A29kC/o/ihj/kkn32Udf9JJv/470pxnmkOXNc00l6HmaS6JXdY60VyG3i7T/JzW Nfuh5uk453XN43E+B6szVi3kS6uuShj25PZX4r4eN5d96wHgOz3J1oHc8lpJQ3nDT5O12DztfjEN DOBxKxmmViWkNmCX88fHcZoezKfHz4XpF7ZvJcPSUzf0Qr2Y/FFGnU64vssaJtCqaaj5fjL8es1l qHla+cd1zTLSLPeT4QPrrBQVP+zzZGUqY5RM0kBtxUJt+aC2fCD7SPBNCIe+jFuBXJo1tVVddeit 82NN/UBu77+8D+TzQ0mTQJaeuqEXLp9K+iiD37q/G8gP6mUMLXd5L+BR83S1ENY1h6HmafKK65rT UPM0eaV1zaNx3s8H+p+HouHgHJbTS6fRL4JQ+jJuhaK0VCEtVVxemHn09HSn32qKSyi6mzv9B+8z dSMvuMtO/4MMNzwN9GtsYY0trrGlNba8xlbW2Ooam6yxncfoX8vXxdqEbxEobhEpbhEqbhErbhEs bhEtbhEubhEvfhEvfhEvfhEvfhEvfhEvfhEvfhEvvouXm7m+TZ/t8MbZu1D693qMqI2whaLzbRq2 t0L0r/QYERrRJLdzLeebZN8k+ybZN8mhSQ5Nctuzc6FJbpt39kHrTf8SjxFNctuJdJfDir6Tpk8r dOPr3KJ/Pj7d+Lo3PnE4F982P3TD9b6IeVUxFdEN4jh85CN0g/imE0vfiXfKOtcODF07MLSo3PSv ORnRfornTw2n7WjJXY6WHp0wLwbDk2LwPBqYFIOhp27ou3QB4EcZ87/w4Lusk8Nod/kbD4/s03P8 sK65DjXf3m3+es2Xvf1H9vE2h43G6ZzT1hcREPsybkVPOwMypJ4d6Zl1bqP24+DJqYvL947bc+qp G3rhsmX7KOP2cfsj6+Q0011eEHhgL9OdkbCsubih5ulR/DlM7Sj+w0G/GfBc+vTo7ZSenhnVPeh3 pQVHqZ/UvbzGVt6zTY9z9I/gmeGt3Cktsuo+7MrkYM9dDnwGOOlwhxH3+Zz/9Lj96wF62ed81Hx/ KKQD0NoHaL0P0POL0h/Fy3PxH26zEJ/e5u7d5u/dFu7dFu/dlu7dlgf+nkd2bZHd9uddbQEirUyT NgdJW1dIq9fa5p2TFmiX7+O/gq93Hwf/Oj7/nu9GjqjN9HZW4aQ5RYbpbh5r4xwxfjLEtRNUA/OZ lM4EcfbvxWm69GXcKlZyMys3NOQhCM4N7+5glienov48VhgXK6X01A3f4bwcLHyU4efb+77LOjlw 95ft/Uf2289qL2iWkWY3nYVil3VyNukv++UDwzvcbmj3NObTsscuz9E+ar79iPaC5jz02PhBacPv CadziE53nda/GEUDGXdyCf/WrhnqGzF2+fQJi/LkYNb7e09YFOmpG3rh8ibCgwx/+wmLR9bJ0wbe p6Hm6W7J6azOc8b1rWB6kD7/Us0pPT4zqluk+Lax6YP/pO6lNbb8nm26m6J/R9kMb7BuO7L+8hWd x67k2UDXIft418NfXpd4HMjbT5d9PUAvD48+ap76tK5rHnosTHeoZFnz5S9KPrDfeV59XfUwYM4/ YDxH/lmNf0wIb0ujR/H3c/P7ov3NrH5GiG0au/z90Jc6GBb54iJfWuR7n4PidCrRP4hurrJVjU8t GbXNRd+eZfeXXcY3d/4/ukDhVQ0KZW5kc3RyZWFtDQplbmRvYmoNCjEyNTQgMCBvYmoNCjw8L1R5 cGUvT2JqU3RtL04gMTQyL0ZpcnN0IDEzOTUvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzODYz Pj4NCnN0cmVhbQ0KeJylW12PZDUOfUfiP+QfdL5jSyukZQHB8qkZpH1APDRMLcwydKOmkeDfr517 zq07Q99bxfBA46pKHMc+dhw7k3KtIYaUWw+9+P+b/XGi2h/pRtin3IYTOZThP6URak0+WELL1Yie QhvqRDQ2zqK3MKIP7jWMnp2QIHn+NILInNWDVufsK8c459ufKC7QsDlpshq2VFKfMPzPlMXlKMnF G/axzLWHfaxFnLJpLbqE/kObGxv2Q88uiNifLs5ZbMioztSXlOicXTJxMbLYNM2Ts/2qOjeRQ46q ixg5LVx6yL47ozTkMrUnYtSUSk19de7SGOQWXWa1uW2uYayMpy1ZYjRqSqo2dyTx72zG8HWLqdLk SU5Vo9wwJbZgPJtTJoH2yWUE4+TKiWJUnXPVKJlzUygpR1ddDCVXXyPZd2VaSrtRzfehLZTa57ga SstQdmljzrA1enK1JxvX3VAl2RqjulTGvgzXS8nGWRwnxZEjrmJXTlEbbJRxVl+t2BaKqvPLPdRY JheDWByTi4Saku8tOdVcFjNKddUlkzzU4pgtqTgofbWUQ21p7qga5bAoxX7tbgXbYagTmcUWqmNq qNi4oS6LwafK3FGxNXTyKyaLdp9bY2hx7sj+tDhlLjm0RSozT5v+UwxSrUwLmhe1MrVmC7W6zB2h tSlBVaOa76MZ5zYlMKO03ny/zZ0q+3fN5g6Z3xk/qa5JU3YT9b3VFprqtFsKPXbHvZofpjZR3ILB fjhszTXN7tn+68MhY7vranJlU68kB1Z2wqTKto45qw022cV15iiXYprxDUsTt1kzP3YD+Cy13VeT RKONqeYNmsxDqo1TcxNTkQZ1rJmGjHBFVvd+E6qZr6jJERxTKr4HB1KM9n13F4rJ/GqYFUxE84jR J+Wrm8+kOOyvJo8WLfsiTnWzo9o+Uhomlzr0zJV9dPLYMiNcLA4RV0uKE/XuWsbOlVbcXaK6d1fX dprTqkPOAsuMHHEuM93fv5jRRj205AnvOIdN23q8tGELWFL4xz9uvlriawzPbp7ffPbJzdd//HK6 ef748Nv3jx++Ov188+k3PqD5gG/DzVc/WJRS//Dee+++g+mtcfr79y/+eJLD2Jt7cWk7DA6Wzuv0 HcH9RHm2yrjLJh+zyWSTO4jSSAwSCsIcC0Q5WjMNrPn16ffH7+5/31n5gIfjZWHx/NXLF6enGRjg IXokkQ+NSbGe/3J79yeWPkUWnX8a4mZaj5j2cXpSDiy3zH1quUMt9LQR+U88er2Ev7w79RL8ejtc eVxauexO7ZdWlsOVLwB/kWx39gW8d+K996vYfPUUm7o3baRLWmu7U+MFrY18JPAol1bub79yPVy5 X1p57E5tl1Y+tPVZ8J3ZhyYecklueXuN6dHKchElujv10spyjJILGpPDaCQXMZbiW6tMDkF2ya0H T6bFD1ZsrXZedbfu42/Gba7TeTguO3ya61XnWaOgnYL2Q2MKvWf/PGtPnGdC3F84z9recod6kdeQ /yYPzZcQlHenpgsA0nK4cr9aWQXT5qAv3//3s5svv/uf/b7g4mnucjX3+pRQn728+2lnV4CX31x3 tvemnLIrp19Nr5Wz7XDXp7m/MUzjdcPSdcPydcPKdcPqgSEvWsTLBbBIIVFJNBKdxCAhJI4d5HqY 9rebNrbTLl9vvIqyBCNdd4BY69dcEOlwT2sSu+e5/WC6lxyu3ZvsGLzte0S6PojqU0Lt4yQRA2ns be9NOfuBnNdHmBR32O8EsDeH7cSPN4ddFQhyvCoQ5HhVIMjxqkCQ41WBIMf9QHCVgRmaef/0ugMI xojMGMF7ttfhQBAfmTEiv3Yv+ht+kNJbzsvbeRfP6lm4BMa5K17KvXq4EGX34LomOED8y1nBTmhZ 5cpHui35eh09nR7keBBkSr2efX1KrH0QslrjddarokyOB1GmXC6RrIK2vygogVGODsC/ZIn+lvPG dt7Fu9gsa0N0wp2lMS+xgjg+Ai8krxB/Tyn18sVLdufmC0vXep3kO7OP3NPL51dbRXfgup92exX/ WvY5PiXWPlwrw1c7Cl9/ZYM5veW8/Jbzynbe5UzPOybAMl218TxrPM/aldF4D2tHmV7WC9UJhRQ4 NFbvXVG+bvTv3WH1wJevuskLa+nCK70e394WBl8/nE7P7u8fb57dvzp9fvvLbCJN8N8+nO7mz7Od NO1rV+XlTAsoe4cMc6HuFVBSCTiBQ1nuR6FifK34vJRCQ10qDKEtCWtoSF4aWg0N2+o47Du+70uV LgycRaPj/7gxKO4JCjkUQFNWZiIvR5H2jA0ajOCdIoRPiYMTYZo6ZiVeltGBWIs5q+XdAKsuvzAM fHr6w9tVsMVHpvy7+8fTzRf+58O7F+cPBMzz0/ePNx+fbl+cHhba55D+5O7Vy7vT8x9v3aT+xT/v jMPt48v7O3x+eHz531sj5qf/3D/89N39/U83H9x//9vPJtX85tcfT6dHF/Px5vPb7x/uN5//9aP9 3Xz+4OXtq/sfNl8smDyPXdaxYT883P5889HLH357OGGvX/z286/fhDjbklNFgb2gPBuTEzGB1bMa CGpvhy/f9ZXydvgyV1ZKw3o/jGcyhTUTXpqci9fONuck62x0TrLNVuck+2x2TnJpd05SvE+8kLqS OZ7JdCbzmSxnsp7Jdib7mRyzp7p40+yqTlJnX3VqKM7O6iTT7K1OMs/u6uJ8ocMfLHtYyXYm+5kc Z1LOpK5kjbNXO0lbbalImcJCh/rMowfKEuacY4kVwbQ4sAuTasDJzAsH8hjzpNFB6mz4TktHIxtC wmz+LlFhdn8nWWb7d4kRs/87ybY0gCfdlw7wpGdDmaFkaQdPWpd+8IRUXBrCS5hZOsKTzktLeNJl 6QkvIcibzwhLtm5iiOobemxo2dB6pv3pyUqnDZ03dNnQdWlGT7ot3egl9M0O90J7Pxqhzt8meJt6 CYtLn3q6SzwXVvh2ZNJ5Q5cNXTd029B9Q48NLee7mej5eqZxQ6cNnTd02dB1Q7cN3Tf02NByzpaX FyQM43HNL74NHon8GCvw1oH/w+Fwrc4Zx/EcjDOJ7WoqOwNk7F6zec3edUaCwLZ5hntmHCKZad5c pPFABTNYDvX4wCYieogBDc3ALgSbEOhBgClOMrYh0KkJazdiDkJoY+KAvCEgJQkocgdmQLzfskqH KnFgbZKFSFQdA67BgRd3YoPFqsIAlhjTMA+2YIWDdQ0WMVjDQAkj4Pa/bIpZGgHBOytBwUsUkzjc SEJhCIUTIRUPhacTkoSCQ76gb1JgpgIzFZipoFVTYKYCM5WBcQgkBWdegaUKLFWYTyEIFAZ+ZX6V N5uGhQosU+GRleEZlqlIZyoiXYWFKixTYZHKAL71hpqZ0YEZ1F9RfKnwjsqQX8Ac3lJhkVp4fIAP zwVc2iu8qMJSFQ9Bat3suMJsFeaqjacPFoM31cbfeSRhXGc6uvGaymNpYGXYqsJWlfkJbFVlKxEM VnlQwosqE2GemojALfLgw4kFG7XEU7CfmTe4SINLtLxZuSGHafCLBgM0KLxB0Q0KblBoq5tg0JD9 NMSo1njAYjDCVIOCWwNzKLrBPxoU3njgQvGt85AGP/hNgyEa/Kch+2jwowabNIS9Br9qsFGDf7UB foMJAPjBdg0RscGGDUlAE8yH3zVh0rABRoNNG5yv4XLYYNsG/2uwcVMsqpzH7IOZB7IL+GlHm6cD Cx0ZYUdG1IGNjg5Phx93RNrOzAU5WMcp11M9b6In3qgwCVjquKF1+HcHnDoS0A5/74BXh993+H0v TJXAD37f4fcdMOzw+w44dvh9Byw7/L4Dnh0Rum9h2iuvg5gEOHbAsAN+HbDrgFsHvDrg1Aevk5g3 Nt7WgZEObPQ1oQNTwKDDxTvM32HuzjsLzD1g3gFzjshEEAkbzDdgtoEDcyAUDHj/gMUGLDZgsQFL jczkEfzKRnOj8EcIhQv5qMwysUhjpgkh4NiDGSU0OvoGWwPeOuCdA1454JUDXjmg9gG1D3jn4K0e mh/wzoFIO2CJAS8dqB4MeOtgqixMgZn+Yj4sNeC4AxYbyurB2GwGZhOYTXjdjMyjkUPD+wTmE3if 4FQVmFNgTmFuDEcUnLaSmJODH/IfyczPwQ/mFjiowOwCswscVOCgAgcVwEEKc3zwg4MKHFTgoAKk CBxU4KAC5AgOZqm8J4AfECU4mwW+KkCY4KwWIE1wnRMcNdJ41wA/+LYAiQIfFyBS4OuCo0aAUMFR I533FfDDUSOIBYKjRgBeQWwQHDUCMAuOGhm884AfQC0AtQDUAlALQC0AtQDUAlCL8N4EfgC1ANSC /FwAbuE9DqmgAOQCkAtALgC54HQSgF2UdzPwQ7gS3gmBe8WppMC/ssiC8KUIXwp/UL4ycOdROIEC 9AqwK8Cu60UQiwHsCrArQK4AuQLcCnDrNtlXIFp5+wOCFQjWwtslFgNiFYhVIFWBVK2bU0Arr6CY BDgq4KiAowKOCjhq4zwsCjgq4KiAowKOCjgqYKiAoQJ+CvgpYKeAnQJ2Ctjp2MQwBdYU2FJgSoEp BaYUmFLhXRrzgCkFphSYUmBKlfdt8AOmFJhSlmNZJY2R9Tk+aYl80hJZV4t80hLjZivznxEtXydO 5XOHyLZ4ZDc8sgke2fKOeS34xi3XQmbsakY+PY+VPCp5sF0RWQeOjftpHNzalj2LwZEP7CJfA8fO nwZ/GpRlcMw2H7FPXFW4TZYlo5CZUPrtzdA+kSPf1iQ+qUk0QKLe02t6T9R7ot4Ty7eJLfhESyRW wROb8om2SXyykGikxCcLidZKrMMmPllItF/ik4VEQya2+1MhZ9byE62a2EdN7KMm2jkVcmahKLFf nAiBxF5rYrMnERSJ/xgisWCc6mtqYzcvsZGV2GBIfHWZ+haKqXNgJ0c+9Ex8a5r4xDQRC/g3B14n pKxCPkRHYk8ordZX2ayc6ZWZWMh8RJZpfXZ+0lq8z9ur6fafRvBdLG2YaahMs7B0ZgSZ0RqZRsjU PetoiQU0//c6IOh+7EMl1tES+wnnf/OyiHl+8coZ1DZLatv3tWRGh2RFjc+t19fPm9fEyzrnfhwH spu0Pm9j5WzzrO+N522vPXdZn+ysT39ef+7y2qsBPvQhkt98NbA24bdNWGrzoAn77jv/ByY2t5MN CmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzU0IDAgb2JqDQpbIDIyNiAzMjYgMCAwIDAgNzE1IDY4MiAw IDMwMyAzMDMgNDk4IDQ5OCAyNTAgMzA2IDI1MiAzODYgNTA3IDUwNyA1MDcgNTA3IDUwNyA1MDcg NTA3IDUwNyA1MDcgNTA3IDI2OCAwIDAgNDk4IDAgNDYzIDg5NCA1NzkgNTQ0IDUzMyA2MTUgNDg4 IDQ1OSA2MzEgNjIzIDI1MiAzMTkgNTIwIDQyMCA4NTUgNjQ2IDY2MiA1MTcgMCA1NDMgNDU5IDQ4 NyA2NDIgNTY3IDg5MCA1MTkgMCA0NjggMCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAz MDUgNDcxIDUyNSAyMzAgMjM5IDQ1NSAyMzAgNzk5IDUyNSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMz NSA1MjUgNDUyIDcxNSA0MzMgNDUzIDM5NSAzMTQgNDYwIDMxNF0gDQplbmRvYmoNCjEzNTUgMCBv YmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggODQ3NDYvTGVuZ3RoMSAxNTQ2NTY+Pg0K c3RyZWFtDQp4nOx8B1xUV/r2e+4dmGEKMwMMbYAZGAEVFLtYIiPNQiyUMYANBFusQTF2TUwlMWXT e6+aOIwaMaZo1vSemLLJJjF1s1lNTN2sCfA9975zVNRk/f/3+3377e+3F577POc99X3vOeeeQZAE EblwM9DE4soxo/KW75hCiv85Ind1SWFxVW7B5B4kps0nSh1UUnh6UdKmJdEkAilEURNHFZeUUpZh Fsrfj1bSRk2cUDlyr6+KxKq7iTZ/MqoyUPjda5ZWUrpfRJTonVCZ12/+nKY2IvEuytc1LKhfXNir /0Gi2PVE6sqGZUu9W67a8Q+i4m5EEeZZi2cv+OmncVai+F/RX/Ls+iWLKYV86B82csyev2KW8fum iURj+hDtz5ozs77xk9Itn6H9KcgfNAcG28OWNKSvRrrbnAVLl7+ZW/UIkZJP5Bw9b2bTwpkd8y4j 0Q/+xLXNX9RQf0Pevr4kelQTmfYuqF++OPvXzAbUx5jJu7B+wcysORMOkSjdRxQdv3jRkqWdbrqA RNUBLX9x08zFnV99sR8yEd1ZSIttBNHTl9TePN0+/EdKMpF27frb6pc03lP4ZdSvfTuWRD1ivBXJ KFKIL9SLpA4Se83jkX9p1CN6S8dchiLNYqinO9D++YBCDsqjmUS+RPSrIlc1GMUVyDFF3BDRH02m Mauv0QUKmUixRyiKYlAVw+2kfOMn7yrZ9rhKr5dg+MXAYzDeqmR5iW7T8tQdEdGap2g9+uhoxKsY yx14Lv/Dy1BLmw3FVH/SvAO0+di0+mXX9G9d6kO0OcJKk09o79ej9RXDqbWll91IRr1+d66jTj15 3ch30G/Pk+dFnE4Np9qf3lfG0XYM1cfF4SEadbI66hdk79JnBj14yv21UIYxjU47wZ5NfU7a15M0 rEv6B8y+/+FlMNAd6ou04KR5MzGvj21/fdf0b13qRLrDcC7NP6G95UfriwO/3xbynVIrI8LtPs91 lP0nrxsZiX6vPHme4UGadSpjl5f6NLdjaKVZ6sHj4jCBxpy0Tg12xWP73Mir9ZT6a6f0yBE0+AT7 SzRI3XDic1XnUnGX9Fs05VT7OjK+AXSDOoNqT5ZnXES1kR8AgvNRtq5Lf7/Q1FPpQzmLMiNvpEzT W5Rp2AR9U1gPp8xTqR+57NTKyfa08pFR6KPoxD60PMPBrjZ1Lw08oa3jfA3bbpBavI29/hQvQxpd JL7qfOtIf3d1aeeGk9WJbKQbju3vhDbzT/7MfrN8uC3NL+WFru2q6VR+sjoRD3e1Kw9Tepc2v6B0 Q3NX20n7RpmIWEo3lmF+/+mfl9fKYJxX/7Ny8lJvoYyIthOfoXo29VBvo4wT7D2o5rfaUjZTsfI5 zVfG6zxaaaNRYg91U66jnspfab5ooHqxoPNdpOeLaTTfMAllv9BRotdDHfETuA8Vik/Jp9VRzieP +g3lKmupu3IBeZTBVHiqvv2nXpjXJF75d4/iv9d/r/9e/734Um4SZqnV7V3f30odHdTtjbRSY9FJ PXV7N9qlRNB1/zfHoSaQUD7CO2GLaOkyhiV4hwCn2o6ygM4HVh5Jn0eTgGbFT+cBK/9ZOfVXuvVU +oloBibhPPh3IBsYzvz/+jJcTdOVF8mnHqAZQLkhQBnqO+BBtFYN0UBwAzAFn4dHAw8DTcBswAvM BOYBDUCFjiKajc+USeo5NEVdQjXqZspS51C9uoMWqmMoD3OkTH2MKv7X4+t+yuPrc7Lx4Vw2WvyM M0SQypSHaKTyPmUq92KOfESTlSupn/Ix7B/hnPIVn9OU1+gM8RjVAdX/Sl3lFsoXP1JfpYKGK2Oo lzKW4pRS1CmnPko+ZShnoK1xaPtUy7V2lv2rzx7nu9E6r+HPOJi7pcfmIz3tX+1DayaMFP4pj7hM //mNljaIJnB38pKBTDjDZtFQfEqfSNU4h6+h2+kh2ko7vQ5vsXexd6W3xXvZL4bOTtJ+PpOJWqdR AeZRLdXrJUNHSi71rvZe+gvpJUn/JK5d+HTS2aA8rZaqIz6d8elnn17w6QVEn2r7lUBbPSkXajwt xn3l8Q7QncBjmhfqWMMQ9Xp1rbpOvcxwmhpQm9Rqdb56QD2ofq1+ox5Sv1W/U79Xf1B/VM9Qx6k3 wS8nxVAifM2ibPSRBw+H0wh8xiyhMjoDo59GjTSHltBSWiEUYRcOkSzSRHcxUdSKqWKumC8WiWax TKwRF4tLxKXiCnGj2C52iz3iGfGseEk9V12objAoBtVgEPsNEYZIg9FgMkQZzAaLwWqwGaINdpEj eotRIl+UUaQ4oHv07fE/cUNaCf98TqHfv7gmYhGOLyKC5CnFRC8/EqVPJTbUNTpIr+syjP91tP6J f/++S/39bOx9+qU9zVNpzj+qcfq0qVMm19ZUB6oqK8onThg/7vSysWNGjyotKS4qHOkvGHHa8GFD h+QPHjQwr3ev3O5Zmd18GZ7EOKfDbrOYo0zGyAiDqgjKLfGV1nmDWXVBQ5Zv9OheWtpXD0P9MYa6 oBem0q5lgt46vZi3a0k/Ss46rqSfS/qPlBQO73Aa3ivXW+LzBl8u9nnbRG15NfTGYl+NN3hQ1+N0 bcjSEzYk0tNRw1uSOKfYGxR13pJg6bI5LSV1xWiv1WIu8hXNNPfKpVazBdICFezuW9wquo8QulC6 lwxtVchk07oNqpkl9Y3BieXVJcXu9PQa3UZFelvByKKgUW/LO1cbM13ibc3d3XJpm4Nm1OVYG32N 9VOqg2o9KrWoJS0tFwadOcEevuJgj5WfJcLlmcFcX3FJMMeHxsoqjnQgghGZDp+35UfC4H0HD3S1 1IctkZmOH0mTmotHwoR8qQljwwjhX3q6NpZL2vw0A4ng+vJqTntphjtE/rycmqBSp+XsljmugJaz XuYcqV7nS9ceVUld+HvZnMTg+hneXrmIvv6diW/ke4NqVt2Mhjka189s8RUXc9yqqoP+Ygh/fdjX ktY+eShfXwcn5mphKK8O5vkWB+N8hVwABq/2DOZWVutVwtWCcUVBqmsI1wrmlRRr4/KWtNQV8wC1 tnzl1Tupf+f+1gFe99b+NIBqtHEE44vwULJKWqobZwU9de5GzM9Z3mp3etBfg/DV+Kpn1mhPyecI 9tiP7tL1HvVa8O240rKw5rkx0+StVtxqjfa0YPCW4uYrHI4MBx6XntSeaOFwb7VwkyyGXsIlNNWl HSTUzKLRWpaqVS0a7U6vSefrd4bkDo8pIjNoOqYtBwxHxsT9/ObQuLQ2oB7ekpnFxwywS6MR4QGG Wzv5OBUtFuGOUcOkPc7RMkvNxMqFTUEzukl7ioneIE30Vvtm+mp8mEP+idWab1qs9edbVukrK6+t 1p92eJZUdUlxfj6ngpSObJlQijAHS3Pc8rHq6VF6+khy9HHZY2S2t8XkK6ts0Rr3hRskL1YQnI7M GlN/SX7MACzNUuxuvtJ6H44ipS31bZ3rZ7S0+v0ti0vq5gzV2vCNaWzxVVYPd+tjrahe416pdRVD ZaKsqrBXLvaewlafuKi81S8uqqyt3unAaeeiquqQIpSiusKa1m7Iq97pxeauWxXNqhm1hFdLaC1V IGHSy7t3+onW67kG3aCnG9oE6TaTtAlqaFPY5pA2BTYD2/y6TbvwkBLnIMTYbku8jdrjWV0zp6Wu RltcFI9HiW8RFL4RFFR8I1qFEmkNmn0zC4MWX6FmL9DsBWyP1OxGTAwRLxAcbU9qqfNhn8KEqia3 4Kmoak162zo7q6rTX3YfrEnHVJsC1FYHo3Kw90dkjkW5URrqYB4VXN9Qr42DAtVaXWPmmIYaTFvZ IIqMCUahhahwCyhRqtfRpiMqNeDZ4AHq9dcjEVxfE6zJ0TqtnlujT2dHkEb7huKxc5sRWVpHeTUt Mb5++trEUjBnXqhRFMZGldVscSOJzmo4SEYrRt7gQ1ZDnRfRNlBDJaY676VmN1tmYks0ZM3UYXaH M0lzS8202MzBqN5oEN+atvTWlmREprGmhgevpy4MF0DfjqAFI8o6JpThCogOssZoY8H3hRiqVnSP 1kx5G1X4lmNn0Qatt2REdtCWOaYemz/Xt8Diy5eVTdoeYQm3sZetRs1zK+KuZla1dd7nW5F+zNUr 16e9HLSJSe6dmNhU03K8ITg5p1eu6XirTTe3tJhsJ6/A8TLZjrBm9JbgrUEUilK9bcp526ISxViI DVKcK8U5UqyXYp0Ua6VYI8VqKVZJsVKKFVIsl+JsKZZJ0SzFUimWSHGWFIulWCTFQikWSDFfinlS nCnFXCnmSDFbillSzJSiUYoGKWZIUS9FnRTTpZgmxVQppkgxWYpaKWqkqJbiDCkmSRGQokqKSikq pCiXYqIUE6QYL8U4KU6XokyKsVKMkWK0FKOkKJWiRIpiKYqkKJRipBR+KQqkGCHFaVIMl2KYFEOl GCJFvhSDpRgkxUApBkjRX4p+UvSVoo8UeVL0lqKXFLlS5EjRU4oeUnSXIluKLCkypegmhU+KDCnS pfBK4ZEiTYpUKVKkcEuRLEWSFIlSJEgRL4VLijgpYqWIkcIphUMKuxTRUtiksEphkcIsRZQUJimM UkRKESGFQQpVCkUKIQWFheiUokOKdil+leIXKQ5L8Q8pfpbi71L8JMWPUvwgxfdSfCfFt1IckuIb Kb6W4qAUB6T4mxRfSfFXKb6U4i9SfCHF51J8JsWnUnwixcdS7JfiIyk+lOIDKf4sxftSvCfFn6R4 V4p3pHhbirek2CfFm1K8IcXrUrwmxatSvCLFy1K8JMWLUrwgxfNSPCfFs1I8I8XTUuyV4o9SPCXF Hil2S/GkFE9I8bgUj0mxS4pHpdgpRZsUO6R4RIrtUmyTYqsUISlapQhKsUWKh6V4SIrNUmyS4kEp HpDifinuk+JeKe6R4m4p7pLiTinukOJ2KW6T4lYpbpHiZilukuJGKW6Q4noprpPiWimukeJqKa6S 4g9SXCnFFVJcLsVlUmyU4lIpLpGiRYqLpbhIiguluECK86WQxx4hjz1CHnuEPPYIeewR8tgj5LFH yGOPkMceIY89Qh57hDz2CHnsEfLYI+SxR8hjj5DHHiGPPaJJCnn+EfL8I+T5R8jzj5DnHyHPP0Ke f4Q8/wh5/hHy/CPk+UfI84+Q5x8hzz9Cnn+EPP8Ief4R8vwj5PlHyPOPkOcfIc8/Qp5/hDz/CHn+ EfL8I+T5R8jzj5DnHyHPP0Kef4Q8/wh57BHy2CPksUfI046Qpx0hTztCnnaEPO0IedoR8rQj5GlH yNOOKNqqCZyaQ2kjPDgzh9JcoHM5dU4obShoPafWMa0NpVlBazi1mmkV00qmFaHUkaDlodQi0NlM y5iaOW8pp5YwNbHxrFBqIWgx0yKmhVxkAdN8pnmhlBLQmUxzmeYwzWaaFUopBs3kVCNTA9MMpnqm OqbpTNO43lROTWGazFTLVMNUzXQG0ySmAFMVUyVTBVM500SmCUzjmcYxnc5UxjQ25B4DGsM0OuQe CxrFVBpyl4FKQu7TQcVMRUyFnDeS6/mZCrjeCKbTmIZzyWFMQ7n6EKZ8psFMg5gGcmMDmPpzK/2Y +jL14cbymHpzvV5MuUw5TD2ZejB1Z8rmprOYMrnNbkw+pgxuOp3Jy/U8TGlMqUwpTG6m5FDyeFAS U2IoeQIogSmejS6mODbGMsUwOTnPwWRnYzSTjcnKeRYmM1MU55mYjEyRoaSJoIhQUjnIwKSyUeGU YCKdRCdTh15EtHPqV6ZfmA5z3j849TPT35l+YvoxlFgF+iGUWAn6nlPfMX3LdIjzvuHU10wHmQ5w 3t+YvmLjX5m+ZPoL0xdc5HNOfcapTzn1CdPHTPs57yOmD9n4AdOfmd5neo+L/IlT7zK9E0o4A/R2 KGES6C2mfWx8k+kNpteZXuMirzK9wsaXmV5iepHpBS7yPNNzbHyW6Rmmp5n2Mv2RSz7FqT1Mu5me 5LwnmB5n42NMu5geZdrJ1MYld3DqEabtTNuYtobiC0ChUPxkUCtTkGkL08NMDzFtZtrE9GAoHvu1 eIBbuZ/pPs67l+kepruZ7mK6k+kOptuZbuPGbuVWbmG6mfNuYrqR6Qam67nCdZy6lukapqs57ypu 5Q9MV3LeFUyXM13GtJHpUi55CadamC5muojpQqYLQq560Pkh1wzQeUwbQq5ZoHOZzgm5AqD1IRc2 Y7Eu5BoEWsu0hquv5nqrmFaGXI2gFVx9OdPZTMuYmpmWMi3hppu4+llMi0OuBtAibmwhl1zANJ9p HtOZTHO53hym2TyyWVx9JlMjl2xgmsFUz1THNJ1pGjs9lUc2hWkyO13LTddwR9VMZ/BwJ3FHAW6l iqmSqYKpPBTnB00MxWk9TAjFadN7fChuA2hcKK4X6HQuUsY0NhSHc4EYw6nRTKPYWBqKWwsqCcVd CCoOxa0DFYXi1oMKQzGloJFMfqYCphGhGLzfxWmcGh5y1oCGMQ0NObWpMYQpP+QcBRocclaDBoWc taCBnDeAqX/ImQvqxyX7hpyaY31CTm1t5jH15uq9uIdcphxurCdTD26sO1M2UxZTZsipRakbk4/b zOA207kxL7fiYUrjeqlMKUxupmSmpJBjKigx5JgGSgg5poPimVxMcUyxTDFcwckVHGy0M0Uz2Zis XNLCJc1sjGIyMRmZIrlkBJc0sFFlUpgEE/k77TM8GjrsDZ52e6PnV+hfgMPAP2D7Gba/Az8BPwI/ wP498B3yvkX6EPAN8DVwEPYDwN+Q9xXSfwW+BP4CfBE92/N59BzPZ8CnwCfAx7DtB38EfAh8gPSf we8D7wF/At61zfO8Y+vreRv8lm2+Z58ty/Mm8Ab067Ycz2vAq8AryH8ZtpdsCzwvQr8A/Tz0c7Yz Pc/a5nqesc3xPG2b7dmLun9Ee08BewB/527cnwSeAB63nuV5zNrk2WVd4nnUutSzE2gDdsD+CLAd eduQtxW2ENAKBIEtlhWehy0rPQ9ZVns2W9Z4NlnWeh4EHgDuB+4D7gXusfTy3A2+C7gTde4A326Z 57kN+lboW4CboW9CWzeirRvQ1vWwXQdcC1wDXA1cBfwB9a5Ee1eYx3suN0/wXGae7dlovsdzqfk+ z/lqpuc8Nd+zQeR7zg2sD5yzaX1gXWBNYO2mNQHLGmFZ415TtmbVmk1r3l/jHxdpXh1YGVi1aWVg ReDswPJNZweWbWoOGJrjmpc2qz80i03NorhZ9GkWCjU7mr3NqnVpoCmwZFNTgJomNq1vCjYZhgWb 9jcp1CTMbZ27tza500rB/tVNNkfpWYFFgcWbFgUWzloQOBPDmps/OzBn0+zArPzGwMxNjYGG/BmB +vy6wPT8qYFpm6YGpuTXBiZvqg3U5FcHzkD5SflVgcCmqkBlfnmgYlN5YEL++MB42MfllwVO31QW GJs/OjBm0+jAqPzSQAlcphRHijdFdWgDGJ+CkZBbFPZx+9373YfcBnIH3bvdaow92ZOs9LAniaIJ SWJR0rqky5NUe+KriYo/sUduqT3h1YSPEr5JMMT6E3r0LqV4R7w3XnVpvsWPqyrVuaCYue9A3ddx 8b6sUrtL2F0el1LicQly7ncecqquJx2vOhS7XdjtnXbFb0dxe7QnWtFundGqP7rv4FK7zWNTtFun TY3322DRWsy2TqwqtVs8FiVQYJlgUfyWgqJSv6VXn1JShVcIEg6QakLZbcLlKVUfE9ovG0WQEFe0 VlXm5JS1maiiLGiaODkoLgpmVmp3f3ltMPKiIAVqJ1e3CnFZTatQiqqCcdo/1Orp8zdupNTCsmBq ZXVIvf321MKasuB6Tfv9uu7UNKFITc60Jc1LcnKWTsNt2pKlOfo3UqJZS+VoRu17yVKkta9mPU05 v3txMdD0JbiWhm1Lf7/S/++X+HcP4D//aiXt9wtGdirnUaOyATgXOAdYD6wD1gJrgNXAKmAlsAJY DpwNLAOagaXAEuAsYDGwCFgILADmA/OAM4G5wBxgNjALmAk0Ag3ADKAeqAOmA9OAqcAUYDJQC9QA 1cAZwCQgAFQBlUAFUA5MBCYA44FxwOlAGTAWGAOMBkYBpUAJUAwUAYXASMAPFAAjgNOA4cAwYCgw BMgHBgODgIHAAKA/0A/oC/QB8oDeQC8gF8gBegI9gO5ANpAFZALdAB+QAaQDXsADpAGpQArgBpKB JCARSADiARcQB8QCMYATcAB2IBqwAVbAApiBKMAEGIFIIAIwjOzEXQUUQABEjQI20QG0A78CvwCH gX8APwN/B34CfgR+AL4HvgO+BQ4B3wBfAweBA8DfgK+AvwJfAn8BvgA+Bz4DPgU+AT4G9gMfAR8C HwB/Bt4H3gP+BLwLvAO8DbwF7APeBN4AXgdeA14FXgFeBl4CXgReAJ4HngOeBZ4Bngb2An8EngL2 ALuBJ4EngMeBx4BdwKPATqAN2AE8AmwHtgFbgRDQCgSBLcDDwEPAZmAT8CDwAHA/cB9wL3APcDdw F3AncAdwO3AbcCtwC3AzcBNwI3ADcD1wHXAtcA1wNXAV8AfgSuAK4HLgMmAjcClwCdACXAxcBFwI XACcT40j1wusf4H1L7D+Bda/wPoXWP8C619g/Qusf4H1L7D+Bda/wPoXWP8C619g/Qusf4H1L5oA 7AECe4DAHiCwBwjsAQJ7gMAeILAHCOwBAnuAwB4gsAcI7AECe4DAHiCwBwjsAQJ7gMAeILAHCOwB AnuAwB4gsAcI7AECe4DAHiCwBwjsAQJ7gMAeILAHCKx/gfUvsP4F1r7A2hdY+wJrX2DtC6x9gbUv sPYF1r7A2v9378P/4VfNv3sA/+FX4nTtTxy0/5+i46ouvzw9kc6kJbQeXxfQRrqKnqT3aQZtgLqB bqd76QEK0h56nt45ld/EPtWrY0XEArKqOyiSYok6D3ce7LgXaIuIPsZyFVKxBu9RS6ej8+vjbF93 XNXp6GiLjCGzXtemvAHr96K98zBesEh3DtLSyoXQdr3Gt8ZbO7Z03HdcDMqplibTFJpKdVQP/7Xf xp+LyMyj+bSAFuqphcibjfsspKajFDYTXR8ttYgWA020lJppGb4WQy8Jp7S8s/R0M52Nr+W0glbS KlpNa8L3s3XLauSs1NPLgbW0Dk/mHDpXV5LZsoHOo/Px1C6ki+ji301dfES10CV0KZ7zZXT5b+qN XVJX4OtK+gPmw9V0DV1L12Ne3EQ3H2e9TrffSLfSbZgzWt41sNymKy33MXqGttPDtIUe0WPZgKhx RGRcZukxXIwYrIaHG44ZMcfv7CPRWgvfNd9awp4uh/3cY2osC8dRK7kBJbkVfg5aK2uOi8QV8IH1 UY84dY3u/1HrsVH5PauMx83HROYmPaWp462/pa+lW7AC78Bdi6qm7oRmdZuuj7XfeqTs7Xr6Lrqb 7sGzuE9XktlyL/R9dD/W9oO0iTbj66g+VjE/TA/pTy5IrRSirbQNT/IR2kFtuv338k5m3xq2h45Y dtKjtAsz5AnajZ3mKXxJy+OwPRm27tVtnH6K/oi0VopTz9Cz2KFeoBfpJXqVnkbqFf3+HFKv0Rv0 Jr0jbFCv019xbwf0/8+nY4n6BnYNlYw0hMbReJr8GNnwfo+noWL7dldxsamX8Qm8uxXy4u1vwsfz Ir/doNh2JCcX+HYMjNyoOse0iV7bCowbca4taP+w/ZW89g8PxgzJOyjyPvj4w48d377iHJLX/+N9 H/ftI5zpTh1x0YrRGBfpy+itDMzOGtS/f78RysABWb6MaEW3DRg0eITav1+aosZJywhFSwv1jV9r 1QntkcpaX8Gk/hFpyfY4W2SEkpIY02t4pqNycubw3qlG1RipRpiM3QcXZpTNL8l4z+hMdcWnxphM ManxrlSnsf39iOjD30VE/1JkmP/L1WrksCkF3dTrzSbFEBnZlpaY1HNY+phJ9liHwRLrcMabjDFO a/fiKe0XuFK0NlJcLm6rfRzC4us8bFgbEUcZlEW37KRunV9uszrE6b62sMhq6zy0zQJhkcIM4U/W VKZDu9v0u1W/+7uLTC071yLGdfNlZf5gtVgTM1J9ZpuIN1jJ6rAqW3xP+l71qT6rzxqTWhETiAhQ QUFBzJAheXlTpzoThjghnf0dB/s5+yPiOVP53Uc5OZnx8ZF6yLPVdDVa9WVkZQ0aLDjOCUafmm5o NglHpseTGRtlWNT+xZmqOdaXkpppFyYRMtiSstO8PZOjDavER+Kp0+Ld0QbVaI0Swzqej7JFGSKi 3fGGkCXapKomu2Vj+yrtL5w2ExkEZlca5VA+PedP9iQ6xDiPw67dbLglWnHzwlft34P93ZNdfuS7 /Mh3uSy5WuFcrXCuVjhXK5yrFc59FB8CqXP3dmjK6o9Ib0VJ8KGt9jDbdP5pq1XnL7daNFYcftvt lt0WxZKc/UPfvsZu+k+gywe0CUursYoKDhbo83aIyJv6sR60fvtyWMCckzOENYIaF23wpWdkDXQO GNQ/HdFzafM5TRUDeis+n1ObzLFHpUF48ic0nDWm4+GEHj0SRNbSqxv6xeeM7DlwSkn3jvbk/Nqx ob1FFYOSxmeOmlf+yuFh1UVZYslpsytG9HR5sg3nZntyq1aO6101Kj/GPLBioSLyTh+Y0jHVN2xC +wdDq4d7OvJTBleQoPrOQwZrRBpW8YytKTQsJxyVnHBUwAe0qIC/1qKSE45KzhP4UB1NiSJP+5tM kRuKrTTsEj1pIPURvVujJmFJ7zuoQeSx+4639/btkxkXHXnMsox0hZeptoBdcWmK5rc2rQxWJcIU 55++aszaFy8fV3nt6+vyz6wtdZsiVIPJYoruN+GsCZM2Ng4e2HDF5HFLygfYjeZIdYcjMSY6rke2 u+rub2+549ctU1zenu7o2OSYuJTYqOy87JIL9qxe9fi6kVl5WZHONKxAbZZdjlkWQx46259akC5i tZkTq82c2Dj4HBsDh2MT4W3sLm3mUDLHJjkcm+TwjEkOz5jkcGySd+GDfhRiYw1Fl7vbRFZrBM8S GYt9ckZM1Xa0LlPCeMwEuHzSPYfu7fhaf/yZ9395S/n2AYsevGBL6+oHm4YoN97/yz0V/KDPuOvL G+ZuP2/sr84R6/dof3sJz9TV8CyXlrUmZ4efaHZ41NnhUWeHR50dHnV2m+L0R0XFemO9GHxymzD5 beuzxO4s8VqWyMqKTNL+McZWng1qjTwy66ee1QS38vRtxBGe/fpzVk6Y6b5053FSXW0w20ztV2ke KrNMNlNEBG4dkSJkwtZgiIIerwiTzWwYFeOOMbG3phh3XIzbaeo4M8qREhuT7DB29DU53brfnYfV KvidTVNajbFhv2PDfseG/Y4N+x0b9jsWfm+3pVJaqhGubY2NTYpsE923ZpQnaRtk+I2Ut9c55Ih3 4gRn5NtGuqtWwTFjB6JnxOB17TfFeZMTM+JMcLVUt+6NTYEXo40OtyvW7Yxq/9xoM0ZE4GZ4WPMy VfNocufXhuURXiqgO/2pKSn2RG2GJmozNFHb2xLNVk3Bi0Tt6dnoyWzhzfZn12Wr2faw//aw//bw SraHV7I97L9d+03wvAFiQGKbMG/LyBiSN2KXMOMdbxY9QkMq49pEbmveJO15YzU7ORzhfW7f1Kl7 j2x04bh0Wc2DBju1WaCtdj1aTm0HPLr+DYblBpPVaM2ftqF23oPLCkpWPjBz+KqBHfucTkMU3hE3 WeJjzDFDp8xo7HvtgbsmTX3g4BVjz51Zkmw2TItNjTVl9c4a3/LEotW7zytOTRUrMrohjCaTIyWm IzY5KzUj0Tp186GrbzwcrE/29UjO4PlhmIh3bh61bSvoK3zWcIis4RBZw1PEGp4i1nCIrFpwUxK6 WbToW7ToW7ToW7ToW7T9waK9IxLI78KLxR+r3RxOcTr5kU8J2j+YIEPjR5CX0LMCL5Bcv323Vbxm Fdaub2MsqIMFAm+NfVpYw1Pu6MKamnlkqh0763jXdMEmpWGiKS49MdkbZ2rfCpWkzTxTXEZiUnqc SRmnz0WoZEQfU85qUka0PyW14T2p2g8rkVKH15eoRvxcNHFHQcKEhC0JKoVDSOEQUjiEFA4hhUNI j2JPNHfu3oFImB0Vurtw88hGmHmCM6JajjvKlZ6QdOxoj45QG5Wx82vxGUbVnap34vV+6sNJxXCc YlxqtK8iapfoh4/FiXh3RYTfXVj0Oce8ubXRRcrjpH7uPDrSz1KKF1WkDO6dYTFGKCreUKYkX29P Rh+vg12IjRKl49bX9o2yO61WZ1JMPM6S9hi7s3f5SPVWzR9tFYT3r5/hSX+a4Xf21ZZ1H2125Wkq 3RyOtDnsmjnsmjnsmjnsmlmbrFZXdkW62eGucBw95xXI1w/mEe4c8aysbHGSiRQ+3rniIo1CxMer PxvjMty+3HhjR7fjZ5N4IdKRkJ6c7I012mI6KsUrTmOKtpVHOszKhe0rjmxqR2fVHqUgymo0RMBg S05o72y/MTk2/NYqg/fJNHonudhZV9hZV9hZV9hZV9hZl/bXGRRlr3C1iZzwa0nkvSyf2zHvoSNL RNuey/BuiWrfm9DjiBOvaYfRsrj/w9qXwLdR3evOJs1on9Ey0mjfF8u2ZMmbvI5XKbZsx3ZiZ3Oc xHYWkhCHkCaBNIQAaVnKUgJtWm5L3+PSe9s+2hAnOIQLvN8LtLSlj3df2j5uC5d0AW5bUei97SVg K++cmZGsOE7YbpSf5nhsR3O+//b9v3NmYjMoQJV5onCpH35Lwdglz5dHQWVpQr7H0xtaplswTTxu jsWUlRaLdfZj0gJoGKe/Sq1WwjyihHlECfOIEuYRJbS0ErolYKg8B33UXzuospg1MUtVpdwVHnSt LKSJVj2g60kw0QLPBJydLo6YVHMsmYQsviSqfChk7oDDo77LqpVA4tEktLeAjzxKGV2c2WOgsHwS V5kcRpPTqMLyaRTkDM4CjFxu2+qO+y0KdJ8MPaqyuoLcTp3NoF4Izi0fHiOVJE4AUgbapOPF84+X +dXWsG1uFH/cWcapFAaHScrJh2QM0ozccTKk0xklMIWjTjpqhOO7EEyjBKZRANOprKxMQDATFh18 Az+YoNVwBH4kAX+ERpz1Q8pKXYjgYEWHHiLAB8G7ArtYUnIZESkQGz6WNS2BlxM3J4MlXkUc0pis mjpryOcz5be62+wYhlEGl8Xi0lPl1iFHyOVg0AZHbaLKggJCY3BxrFtPpY2gL1Q5EiHsjdTnGzMP 98z9ezFavhP2Ks0R1/yPqic2jMUGvjuAPQu6JsCJQKKAd91eyhFvyzwgZYWQg7zVCDEwQocyQuJq hMTVaBFhSvIKNxJHDoO+yimB65Q81SlRAqdECZwSuM6zgNwrEQ4QAN2wD0aWbORyAju2KDMWG22B v5aweeLtngdfP/bln9/d2XPs9WP3nf9S16nQ2q9OT391PBJc85Ubdn9tfRh7+O/mToyPPv63R49/ 8P3xkb//93+8/p/u7l9xz9ktNzx/d9+K+56BXB1kxh+C+LMjEWT/Cb9cmohcmohcCjm5FHJyaSJy 6AJmxgHhcUB4HLRag2YdsBt0wG3GCBMArOekXK4G01SdNA2qS0if6CD05bzPt5jsESWUHf8hv+9/ 7H9QYfBwMKuUWVFTWd+2ndnIqcbRsfJvfr1/S7cff3DjI9c35SuLcQFMTZpb1x0YHbiuWjt/MZye QMQZEyow41qkE3mAd9KVTB0FrroOzqJOmEUdnFUdtHIdsPJTEdgDR1oZCAUYMRI0jAQNI0HDSNAw cPuxvZIGPP/0NI/yvLkZIHDKM2iWkozA7mFTe0VPm5KiRJAEKvErIGHNTlxqbc0GlkWrg6FgsNDU qORGv9PqMaqIfaaKlhWNewpggSbHUNVm7d3TH/K1r0u5qyvCxhu1VH6+cznXmnzgHzon2l0gyYBi qQAhXlU92uqbf7UIIqDMMlxTP7Kro23LQINRG23qr8r/1u/A78huM5PyfNbTuBxkm/SlHD4B4mYZ 8tYZpO3S2zM6Gs22SRC1SdC1SbmmTYKqbRYr56MJ3mBEswkeMAZ/wp9Q2yzwd20wgdtoGr6BX7FB c9iexqpgFj9pEwjH8yc56WgUj6d1kByqK8+iIaQO0Owgr2LcdWgdr1KjWQbuglHCUR1Tx7BNoCc5 1WaTRYbZWTQixSEwQY6BHVc0OkbnaOiqC2xRL35jUYASl1GX6iKVWdyCy/GJjn3fGmvbNdpoVgFa QmmTy3f31I91+BND267fOpRs3PbAiuhoX5NBTmC4XEWqYp1jDbXLq62J4euuv244iW5fe+9EgnV7 LQEX69CT3rDPWbc8WdffWJVsWbF7YPCWkQod5zKoGItBDzpzu8/hiLcHavubEsnm4d3ARjoQ678E nu9Fpp6y8LDLYSBqM5DGfezAh4WUufT8Kej5cj1s6BxSbCcA7XxPAOeFKH0uWmznFoh1IZ0JVOGX Qht6rMB6wEhqU/HbhSZV6OI+/EbRETdRjN1gEIU+yBy+AzL1AcBqoshx3rGhAnXDqHXDKHZD13HD 2u+GXgPvL+WZ0h4CeBrCShNmpQmz0oRZacKsNGH2aYyG/Bp2GnA7Gq8A/4QyOEQP2Rb8RmgspAwe XXCRMfRKAmhcTHKJA12HZ/du/8GhTrGRNVDlw3uX9e4djArQeADHff1zZw63txw4vQ/3FeCY+8ua o6srylcdGcXNpZzdC7LbVoCKH7med/hhYgv7USs8Bq1o2IwGNWg5h5ZbUG5WClJhANOepXAGDng9 PMVZOEsw4BqyyPRiZ6FPtTJ6VAwEOENkbAwdGxuLjkUDAg0iYHGvrS0hPwmWlZPYU4SWCzlYj4VR k3h+NYXqw167R68g0D0oug2nQOpy+TU45YSCJQoYrIoinhQkTUqj/PA5ohWeh5ImnGMz4IxvgDk2 IVtOBpvQxOyl9/kOGNgB4IIUHIRjaIAWzgRQrwUOIl7U4oaDiiq0Io5W+NEKH1o3VDbki6vw0kYR MJhWYDnwB0q10itQ5Hh4YbR4mpdPWHYbQdsjTlfUriXy72Ef4FprxO0pt+vw/HfkKBN0u/wGEkN9 KGrEFcaA0+4xKnA0gqEOXG7wOZw+GpUFtQzkJYwW/z9zscKY+K7ZClHRqj48RzSodLDF0ak+fJFo VIKxTGs1Q4TiINL/JvTjcd4RiaGRSjRoQYNmNMSiYQSNDPlUjGOIKWlhQLSOCX8WRGkULWrSJbMt ThHFf6eR6SNet9+kIvJv5F+TqU1+pyeok2nQjfnvq0kaJKggq5SjLGqUKQ1ehyvEEOr8D1pYq04G mjkFhs/PA9qFy3RWFhvGWlmbjsBJkBTs6O8oDSnYe/4FOJ9G0MEcA5krglhPeJlZNHjSNqgOzaIh UQBMgL8lPQnMMXVoSbZhTULVRMEIPyZ0KITVjSv1Gmzl/JNKLURWq8ResbkIJaOdfwLbz+gzBpue cvsCGpZzmfDHKcamh6TS5Q7RnNVpnFvvhVyCBjj/jgiCaAsjvacs5pA6qJnFUF5hDrrBOVUQ9IyN gCoHA46y0PtQkZjSb5VtlRQJKPqgXMxy/gKoOfqUlX5NHICpFI0Q8pCXrwwQwsoA/i8kTgc9noCR wkfz/BChNPjtDp8Wo9BthNoScnI+i15F4Z/Hvo9uaWKhy8jVitwfFWoYRnYT/oJKS+IoDlpF6nBe CdcGvgWf4024pbWB5hPB5FkMR1SIC2NPQvF/FmsGM1FZQ7+pqiIDb9KTyb+SW0o1+vMXwOACfSFx dUEeX1KQx/+7Pdm1cqIt/7+Mfr8RDY8fGik3+Gt90b6U98+miq6mfzyVagubGm11w53Pvl7TmXSg yeqRroSXdnjwxzwOb+dEW6izoUJLlXWsQr/mawiz+edsFU353mh7pSX/GBttAT6089K7+G1EHKlB Gp+0IKFZrIVXqtkPY45WB+bwzqJ6QBY2Y++7q+JVWFX5LFpzgtwGBYuxnPAG6Np5UWi/TGi7mtCO 30ZZq5eN1e148pbu9OGTO2KjPY1WBWjdSFWwdYzv3jNYHhvZt6x5tDmskVMy/KsOj9VjN6TvfOnI rT+9t4e2e6w+j97KUC6/s27Lw2ObHp5MOn1OOeyaMcFWc8BWUGH3PoMYsBQU0TEjr1BYLmonbRdl WwpthbDMJ7ZeS4rh+Nyyu370pQ8F5Jm7/udtnT8Ir/zCjgfu33x0dTnmuuenR9tEkLtuf+7Q0D1b GubeqZr6CoxJeA1acA3lSBXUwsGHGxVug9uAKKz/CVXt9zWTofflCx6Cxl4WtexPIGNrCVIln38L XhymJ1UkAb4m8xvQLaQKrmuB8XH024ArEZ0AKlK8UJK26fWcjsr/lKStBoajyfzfkzQHr/jSB9i7 4Ip9SOUJGQOvWG9XqWyI3Sa7yDBm4kP3pHnr5dJ0THJn+bVkaRZ7V6fLH0Cn5Wp4hWp5/n7KAEu3 kQKgXtTp8F/53fkZiuYMeiu4sBWUOBMK/7HH4YFY7rj0Dv4OkUB4pPWk06mzwPsZkbBuFqvnlTW+ v3Iy8Ior4Q0dDZuNwFVPxLdJuEJERd8EueNqUrGvNBUyRjkpFrGCD+PvyEgFoavK7syO3LWxum7i zsHKjaE/FfBGx1k3zXiWrxiJ3PLSPcsG7n/p5o4bVtYZlfg9BhtNOQKOpuseWr3p4S01rAl1Aqgh /KTDlZ8wOki91aDK3vPiTbf87P4Bk8tlcIl2AOwvCKpT9QmfGt7Cafar4INCEHPZlB9GouKKVCnI CokF5/kYSi3+S8oErOA2knmnoLF4oLbmsXBuI4X+hjS6LZzHRJmL03wx31AY438pOtsE+neFMSJe O9oLrt2EGM6ASDTOKOkp4SqBDUovrShh9hY+WgE/EHx08QPxf5eLI/mlS4BSf4Cuk92BBZEnQCjL sSAjPOvz0rvoN8GnhYVHK4FPc2h9UxaYm2TbREUuduEjRdRvWuvH09Z4xAE+EnQWCpIy2vxWZ9is BBhAeZFCK0eu7y8nVVqVmjbrWCdDqnUaxt/IY68WLlGaO/4lcDX1CH8G8WEbZioq2Prks1gz6ChU mBFhESU2wWsQNjzlVTH2KaZoP1EVot9LXIjBGlHS5l5TI4U1GwVV40uUwcfZ/WaNLH/oCkvukutY t8XqNShA16TIfxvdJ6fkuIUEsYhDAZ6Z/zN1BeL5GvTH4CwOz8pVWkaV35NXUFqNUsps2KtgnhaI ugH6JamZAmGnPUFsKeigcAryJRRQ7FVal3cZ/QuXB3uXLj8IdPynhU+fu5UU19UAorIpkJHqkfRM uakiBEx7iVd4NTFlRYW3Wgm/YhBvzWQFq8IdwUnHVlqCtKi0JfSpZrhICCKDKdUPoDBZ4HHXECZZ k2yKNLjNnFtPYvm7CV/YZNcr8PxxjNS7Oc6lJ4OWHa5yj0WBRgg0oeY8Eftmzr/gw/vmblergVPJ 8YNzdxbP/tDrhorkfDX2I2eZVeX2St7zLkC1EWRfjx7ewGsn4rPoT4DD2GunVGVmmH3xLaUOU4h3 OSxeomxoFBe7Fk3HwLLmZCW+YAv8Xa91jytI598ODwAii6EkY2ctDjidg4zNyFD56ErAtsEfud5u tjgYebvX7fJgqt6vZb09vT3e+WdLJ0PpLHTeP/itofDKlSNh9K+UuLRAwVq8+dI7RCeREBTD0HOI EYP/fZETvEOdT/ekbrNvFtVJ8XpZQb6WuNfZdsszN9301M1N7YefuWnvqYP8k56e/atWHej1uXvB 8aasB3Me+d8P9Hd+4cdHD718f3/n0RfvW/XgjiZ+14ODax/e2dg+/ZDAEwDm1wH/cgBOV34iKD8L opQBF9cEQGdCf5XJ1IG/mSbVW0uluQKBu1KRg/ITWao54ddVT9w3dawQkqDF0Pg63Q1ree/J9hZT jP3yNxqXVXHY74ePrI3lHygFVE6qk/1TPZlNjEyW3+mq6xWRXEc8B5AMICmk7qTCzQTh8w4QWxw+ o4txK9RReC8ju7kGHgg1QPScWAPF+ifoZzKj5PXy0v0QYi4BTgJFs0VQPyfXqpgDEwPeyOG+m546 UERcH6j11uxv02rz/7eI/TJwvDnrXWdymiqbW31mf+cXf3L00E8A/l/44e0dN29f469sM8kDWO+q YzuBLb68fN1XdjS1Tz9YsMUjwBZJUOWbz4BUaZqpoqNMNXy0Q7BRoCM6e5R5s7HRnPobjAUx0gvs +kIC8uvUL0qTZ2gJjbDItc1gsiV8G3+EMgXsNo9JiY/o/PG26i0FswGOYt1wx9q4oyZbZasIeOjV SvJPpngv/9C9Lf0JzkCC4MYVWtVfyjpj1vxA0Yw/8TiC3VvaIBOnVZ44H/43K4e97muKcvknuBgP 89uyS+9gc8CivUjvGaQd058KVgertQ74jApEC4JfwytSLRcdHbLoZpDsmNNuQ9yAGUAW1AgBI5Bv MGlht4sw/avXu2sob9hc4+Z7h5Pj2RqalGEYIF6qiu6NTRXZOle0e83YmnRZ9bqDmbKhjiqt8H0F qYg0DyVDfLmlPL1m/Zp0ORrquXGgXG+z0yraRBsdRoXD52AjjcFIcyxQluza2MZv64nQLKdTMRba AGi71WE1BZKOaEtlKJzoXA+wsAP7twD7uxHXCYQA5j7J6ggaVJWTtknlVklAO/feCwW6eRXZrEWn zV9Q6D2c1WWk8hcKRBh7G9oF/1XAM3ekaKFDsG3V2xgSlhsU+abAMoMgF/ifQdyYAeQpFjOeUgan 6CnbQpJqXZykriFe4e80X/+NTeOP7GoA3mSxegyUr2s8lVrf6aEMbovDZSDRr934lW31yamHbsGm C/Vv/pGNU51e0LatwnYVCQaKeABCvwbX50WSTyJm4AV/PuU1u5VmE6DDvFJldkyxMolt6UGBEDpn sW0WeuarKTOCAHU9oTQHXd4yi5rIf11O6Pxul88IOuAEBgqbwuh1ODwagnSK++W0avwF1qYR9tPN fQtfp9RI4hOK1F36QE6Ca2xCRnhFTKlGmuJxdWIWfZdXNqnNFk3A51N7ZzGWZyzquqmyqbgPyksL VBbKS4Ur52Kw27fQ4lifEhcApGngS0hNhqRBkpqkEZwa8SahsYad3qhFhb+Bnwfdf9jljlrBPP8f ieqDbqfHQOL/gf0Jp/Qeh92rJ/H30d/ilAFOWYvJpSnTauyDeZlat2j6yrnv4MMqDTyrUcx9VxwT WpugMtUCez0IsEgio88gfqwesSJhDOGVCS6ZsIIXooUPZLGoBRGEQdTuYFBdMRVUG1xThlJqyMWS MasFmFGwZCom8hn6QqkOgodIfAk5ymCuMywIUrfqcH3E5QqyStnvVarfEyqjz+oK63EtWp7/rVqm D/scXpNS9qpOfZ5QGgAlC+rkqvxvW6wWjQwH5Rz9vNmcv42CGonGYkFfQ38iKCeAweUftVrR9VA9 kWutxnwKzB5qP3sE7Sd2BjGDhk2jtsInwfgtCMzlCrVryiLXT8kL7hp7L/VzOEO467YYWVfYVnBW TmHwmjkQTPkZNakLep0Bk4KYw/4DOKrP7g1oZSr0oXwxzNFD2ICo8AD6G0dfoVRygtBx0Fs7QY8e ADkngtScQWhs42m3EbyQIHzoktItJB9uUhkUYn+LJKSB6Jca9SUktZItRwuSWgBexfwei4ugaA36 m7yHpiE5wnaoDWo5TunUeQ+GaHVdetAtupweHWu2GbCXPXBXEUnqjJqIzmTiDPNVXlAl113K4a34 j4Uq+QPerWt3tcfacZXCXK1Wo33VUNmvhqJ+NQ2V6upZ9D95LRIK6RBUjUDtH2mQ1pgapPXtBknH byio2w2zGMUbGfMLSDVdjTU+X40i1Wh1dWVb2Sxq43WveFGvl3D8obKn+dfqPgKJFfbjCVu0xnav Hyss1p6Lrh9LSXvzEiBy148FBPIRBHCVsI9kjcQ4pDOEkDhJsTixsD/HW2m7zerSNj4wmN4zWNFy 4z9sO8hW9aeaNy6rUlNqBUHa2kc2V2/84orgY1/qnGx3rV7etqvZolbL5Wr1mtbuQPfmtux0T6C7 enmNDRQmiuZ0nMPqcxjKVx5acc5c0RrpHm7vBOgeB+j+XLYbKYO7Ak6BTKT01ErrHbXS+kethBf8 WsCrdhZ9n7eZonDpO+qGO1Yh/lG42hKlhY2smJJXICZlbY2HkIGiLjsd7LF109kUGJ6Q9QklBUBo ThV3BixgVlwhCZmurDZiritwY5JhWYHI/Dw5cf9YdFl3d4jS20xGu14OOhjQbOmpcG8mE95092j4 CVP1CO9u4btCnQc7WlbVcehbe8/e3s0EGyLXU6JIQ8nqCyx+/veReh/df9sP9nYdmWzWl7Un8seH R5smbgYRtAYg5sZfQmqQO0/YhbVGcRPUG9Lmp7dn4IaSJbaCvnP5FtBLfxC3hmIqXhPTolruLRev 1GRc/lkUmzH04H+sgitxCk0GSo/yE4o+yH6iOeGtuC3wXHET6KLNvnKR7sgvUyDdmIzkmnpXxTY+ PFXTtvv46uhgZ41FIcf0Gl2oaWXDvls8/FhTaqQ1qobbSv4bwzEaLuDQ8zef3HvHczc10lavRWuw 6EMuT9jz1BOjt62K+qM+yiCsvgFc5L+S7Uf2IgdObhkfvA4+2TReN4jYZ9GLJ0OhceNZ9CJCAc6n 4q3j0dyudGvDQAMWz/JZrCHbkE23vp2YzKTBVHnlmj7Ejnuz2iwHZ473CA4DC0OuNSmuxo6NSZ0T FA8Sr58/f4GBFR8VU2dpPyigQC6cCAYlEkgsDZLpMihZczAogYqbiP3p+3rX3NzrVYBO2OIykuZ4 uqrl5i5KaJcNlMqnax6tt/krBEQ1gdRgSkJ0ZWuZgCjEv7F3VMCf33Fvv6ncYDZWbf7atkhXrVeD 1/Yua95858b5X8PFLrj9GtP1re/0r1o5f3fhDPHPGOaqzURa++JaxsqEXE6/S7SET7CEieb0ai5g F2x2+z/tT5GkvaO8/YYVVTJSpdVIdjoF7LQP+eLJkX5+NbSTK8izNz6LhZApRA2sxCKbsR2np1nw 6leexeD/nlQFzObqn1LJti+z5tanWyMDESzeyDdikcZIY23l257hDEgL8lPL+pisLCu0KaW2apV6 sgvS7mX6vcQbdNFsS2k/n8FOi7fUyU+RRo/N5rNo5fnbFxnLG1sw1t5bP4Gx0JWknvNaOEAftLr8 0+gutVLYMoGTGgX6l7xmscHqV8Y+jcHmXkM/p9QocJxUKdQWOv90PsCYRCvKnpPtQg4hh2eQfdsG cGjGTN2AFpDki7wq2ZwcAK99xuAamGDYfa1DA0NYfJKfxIYmhybHR9/qOZgZh8GmuKEvaclpmzMg TolTFX0dOapbECaA+RKlRhRaasF8cBdXgn7x/AX6HAODrgg9oAAS7rAJZUtMRUgKlEQXihXwY9sX q2ONlWuPDA9/fij6JqyADP1mXbfZbzdRMkqOk1p7KGFLT/DOfTo9odCQ+7iK9ki4vZJzxhUyTK/W BOqL0VjIb6XZEBh4wBTFZ2yd0fZdQ5WVI7euXE8yVoPfnXfuHlcoFTKtRe/0ajQqMtC7ZxP6gdsP mjqyp2m0zmZPdJfVDya0eq7UvGJmNJbmUGDeejns/DeAGvKIbCcSRFLI3byrtRFV2VKQyaTgHoUU 3OOSgpU0BQtrCiZOBImJFSYmFZaYVFhiEruJSYUlBosvoLLdqlTIRmjL4GOaLD2AFhEntX1CZOaE 0tu66A4JofYWtcJSugKCa6G7K4alYKg6/BGSsRvhTVfp42sn7hkNJzY9MD5wG08aXbD+Kh7v+Hxn K6i2oPq2eZr57hBXKLb7+kb6bjux6cazt6e7OjBVYTfefBeos5sO8p1HpkDd7aiCaI0BtI4DBhhF qpEn+LJYbWvtrlrcAJmHwQ1vNzB4yuGOoHKIlngjksAFQd28eKoz+lgUg7fYnILMpJqQCjUh1WPh a5VwFMkgAfHzeMp/eJi4n8CeJ9BXCJQg7LFfB3ssf9igndZiWsUf7H2SFLFwX4ZIYF6LioVZuBtJ IDOgcb+qV4OvQ7UCoCR+PMTNP+nsnh7kJ5fF1KD9xTEQ87Uju/ld376hoWn3oxPXPbSh4nH8wL7m dS1eDMNCnt79I5Umq4nUcnqNQadWcRZDy02zN9145tauzj1fX2U4cqwyO1UHa3Pg0gfYUZDzm5DJ J1kakhWBpNgkhmcrMDubRP1skjPZ4AMp42WB2Uuv8Hq4zz6gzNWmrcFcPOPO0hkhzSdgJY6eS74n 8pHkuUVLTqUpoahEL+QBccEJO0qAMCZNzogtUO3WvkSpFDK97iUoGVhAsr5F7B9u8WV29vja/bAd 0xnMWplCpbAkBxs2iZE698dC0sVNYniOrf/CSESjUxts0I8CoPI1ABSmkP3IjpmyMpM/BrlJSrlu Gj6hfdBkSm2G2VKFdLaklLun1xGy7SB8eOPGnpFuZ64nXdmQ68xUZ/0ZOntjKZUVQCgw2nNJgZUk LyRECb5kCa6E0srlnwwgs1TSrkKB5Q0g8CAF7gpTehiQDEko5IpkvMrcsrySOSNmzDOL8SwbPTpm rU9GzFocJRm3FX4v0pNZFtp012j4eyykzM1tXaGOg50tq+qXoszECzgOMOeqh+quaoQNY0dXRgiS JJWUUq38CH4tWInaKzuA6JFHkYdnjh3b9Si0zqmD4+M9qyfgaJdhV2tUBcucosfdswu8DoL+2s67 ao4ePvho5pHcPd3TEwdzRzOfy27Lrs50ZVtVyigR18JM2NAnA4en4qA1Gs5xacF8Uj4U7ZgQV3OS ElMRSl1KeBeXfkV7LkIfLVppUadi+sSG91zVB8StnsVSaSJ/VLBPsENoaawf1kJ72oA9WS0hrNYA c4YFc4IOKCk4SFc6RBpgjyQ4iBI4CAscRP80CDiC0T1dcJD8jsWu4s9sT5e3m5Qg9pQayuQOW3ua 0POLzId5N47dMSIaW3GFsTcV3UchChUK4kXRfWoG6yaudJ8rXWkl/Nd1CgIEtMHtANG/eXpUym/E 88BnNiJDM+m0d9gP81almoVO4lrh1Xv1SCpZSeXWpIczA7nWbh8by6Uykaw9qxaSmGR4mMnOJc9B wyeFpSYpehdA/0wW8yycJp6HILoAiM0vibH50ieE/lgAnI12mBRwWxTttlMQjE8N4saFcxKecjnI lDuR9TPJZB1c6rw4s8bp7IBh9+TOijpwON2X7pgycDQkkaatPePdodxwuq4j15dpzlZkOKkLWMiN sAF4OSkuWkB4hfvYAldv1D51hpR6QLlcxNFIssU2TYD10yZG0Pytvjnr4a7RnH3abCj2fRLyFA88 +SHkCzNf/OLEsUmY8aaHh1v6RmGtmnhoolrIfC3qlgnwmo5CLcbhuunG6WOZ+3OHuydHp3M3Za7L jmX7MmZrKhvIxoGBnrL2MN3pnKyQ8KD8eLV0d2WyW5zbPrrJ/i9Lch4sv0ROS9/Xs/pgr4fSiyKP pXJZvOXmTmBDeDeNUPgq6j5TXjtGWJbKYx+jPQcJTan4jAkN1sAP8NPACwzISqTjRBdyFrseUSIu EHsrB93Q/qbaePlgpi/XlHaX52p1stpMMMsJAXf+ZTpXsOqFxGvvnb/wsytXl/GPYYrLVCQT3CeE n1awIacjZFYqzSGHM8Qq9NfANb2tky3325RyAgPgMtaAvasBI60c8VN7EP4LQbs9wCkUXODDqmsh JBYUSqFU0RbGbScpEqQ5m0Xkcx/I3hNQOojsnlm+vGI/xGamfKx8ByAEu04ry8Er5YIp6+C6CqEW dDSn9md0MlnHjbmJ9LrMqtyy7gp3KteRSWYLABZrAUhQLxdgLOgWPxOi47JbcK+J6TXgJZYoDVdi LntPYS7F3CxgLvh5fvtHebWr4NQRTqgY3cAkFT5gEhmm1JB6LmjragQmsX5sk1zNgTVX1JKrWCz/ oOTXW5DRE6OSX1eBFLfF690ykYA2smTaW+LGbRPQTJnxXH860ZLLZOqzINMRJ7gBMYMlJPMwyaRo oZdBwgK+/uJV7SKtBYuE7TP7PdeydcAY8dtVMhwj5Eq5gou4HBUO3WeJgw/m1t04XAl+SaGiaVpv o0mF0lCxbBne9MmiIv+gFBX3IQdmjhxZf+84jIDtXoD2LoD2IPgiUTkEoXbft75tfVti767ty5MP 3Ju5K3dz9/jQ9txenWxvZiq7KtsLIH+qfqAyU7bAlaUMA0NEAv/lAl+C+C9ueQpWkF0FW2bJnWqf JoKujJR5DfR4S7mfE8DXkAwHwBc8HtqPDYv2w0lgP53ZY3VUOHWfIKikSrHYjK8sbZq5bKZgXZ1e B60rJ+XAvDX48k8cYSJPkF0ADG0XMj3T2RlryTyLXkRWICYsiMgRP2AKse0xchbbcZqJgdcK3yw2 xNu59atW1Ocm05kVufWZ/mxLpiwr96udWfUypLuw9lps6YukQKAE7yUuFE271G3LxU4H/UwMDh+E gENt1eLlLF4Waqtn0Gm1kjIICq5Onr+jYBaMIlXxmjj70TyuJiTxONlueHbun5fQVBVLirefnNBJ HM4OIvBh5MEzyB3YjlP3jY83bm+CTC4TjbIBQXVo3NH44FlgrdsRFeRz7AG2EbwySmioADKUzdyu kt217FC3K3dDentmS25Vd1MskxvKtGdrsoEMU6TXxXLV2ipR7AUuB4x2OZu72kbLT83Xlq5iJVxx kZtQdsrgtS4YUihkwJDqmGjIj03YFkWhSBJrQqwOL5BEdAUU6IETmZRaLXCiXWrV0gL9p+pBL4tH 4AKLyeKSPib6Bv4YiNvlSMuMy+XrVsLcvJzzwXRsTCVjvd2GXGvaJ7anXEZWoCRFRndeisLAZ26U 8Mc+QyQJHRH3GeJE2Cwp5rF/BbGyD5niFcPD8ZjLpRLQOLUhFmvaKfSb+8bjEB5HN990A4Bnc3o8 szaX7Y77mnLdmdpsCU4LwVAES2w2AWSM/hPB9ul9XvavBcfGRcc2fUbHBrCHS7of7r/Qc5eQa8Qu 9M/E9wSldPUJvge2mOopnw+pnppSd69KIjB/sbS6H9AD3jTex2eSmYYGtiJnT/cg6hybkQvLDAmR pLW2itUEWOMcNIa+cAvFNQEuFZALEH/k8hJ63RWCcXpnT6DbqSZxXE7JKCPUl5NuHfowBZdwQe/4 JrzHVK97qzbDBuwmEvwQoaCdkRibnuQdeOVVJGURxFIF+heFRwb8Qlo1Uo4VVo0cXlqrkAd69/Rj 8Cl+NYAD34n/CGlB+pFx5BXepK9Iw7WeNKUGb27agGbTydbZS+9DIb5VWuUBxzdOw2+1kgNgyGt0 ejQ7YCN0cTxJknANgxZU++d5DRhUJEmbjUxWEFDp56uh1L8KfsQqNw1+bVVZgFeBY0AXJ/H6nn9R D79tMm2ox/+tKVPmbn+1vmftq+4B6WaSVvExRL8Qpe1o8mUo8ZtBIYG3ezLgJP1yFPyNFt5EtcxX 4APBkBwwPtYs3aVeIIR1cMWwtq6wbsiaARNEq4PFDTDwXrBgKKTFpa/wOw26W332xNjh/roJm97c VvvHjumhyurtj+/eeXxTOe2pclfFEgGXv3rdrdlI2oXSDJPPT43F0zHz1NqqTMw8PD74/yn7EvA4 qivdurV2VXV3VfVSve97t7pbaq0tWVJr79Zi2fKOLS9gAzHYlrANGQyEPRBCJhAIA2RjkhmYSTLG ssBmC8n3nHkhjPkgA4YMy4MvM0NCRpMwyQQSQuvdW1Xdam2GSEilKpnSPes959xz//srf8LO3nzl yL4uF3Ek5Atvya797IY6j2zKeEMZnMMDnds6uqY2NUQK25oCXW2NDsdoXefuaGSyd+zqjWlWFyi/ v+MSf1spvu1iX2vx453t3bjOkU7ErT19nvouZVUPSvZrxE+xTujdh2dy3nUoG8WMRmwQrSkZ4h5s oq2U61rnJUM96LyU9DAMsInHQqP2X1Mqw9VKtBJXv3NGsZOF1fHFIXLzog07uK1qIstX6Fovf+jy hos2tFh0KFdBxZHSZ/oLe3r9ieGhoVhl0S4xNDCUqKwdLFu2ixy4f3cdb7IaBNGiR8Vjs8Ps7Nw3 ui+RDwtjNx2/8PCTNw1JkY7EAVZtP2XLHygLed0DN+5dY0r0NUCvcj+c+75FTWM5mJd0N4HkAiyY tvxUgxem4YdBz2PzquBPCgyUggClLO7x6HecivvkTSplyFPp4fBgtfAItbeKK6S2F+UXgx8tLVot rW8R31pUYLqmX/UZZqbSXDT05dIF5y8I1nYUVWp8OHbL/J/AeiqLWbEA9sVT3aHx0KEQIWvdaYt2 m5uV69tLdqWru9CfwqcxN2ZdDaxHY6kVsulxzofwGtEBSrMOsaTw59xcSluz1NZ/V0aGMqOZDhkr tFLQtZQB5rqO9hT6qrKAuLmCsQTq25OJPPxCO0lvg5ZxH6S4hG3C9mCTT2DD+NTMuvgOdGDkZm8X OhYZ2YlS2uShnVzU5Q31l3ZtQCPeNpYp5ZfaybkcDIkUFM0FU3n5HfHldz7BXJY1Lrcu7IqqIZWq +Zm4o+nSb1zasHO8wcbgOEnBZDExsLe/e0enNzgwOBzddtWQF20dQ9OOJdWbdeU7+2OV6eXjn0D2 JFMdHUm8H31Hd6otSRZJMFqMkgvakk2xpQsjLWGp4+LbxvBGaD8EAS3p41+07+oLS4nuevxI5VmV sZUvDJ9/pfwVsBfyN4zVY7eeHM8hhFKlvQxe/wfpRaSyvI2gS5GCRBDrU3pM+3c1oF2q3lTRu5BI OIcDy2WQDmWgRE7GfSULKsaowoCapEpBWf9VtQnqErUIDENe3CS+SK3Wewt7h/xpO0sCgmEZOmQL ZL3GykxurjBQ2HtsY0rHGSSTASERUpZ0sUR8d7m6qX7mGuhnmrB7C/ruFpBoAA0FExhrOD3/okJc g9YE0ICo1ytXpQmg4Sk8hgUxvcaD1THqoOtxyuk0hliiuiA5yFPxknuwmpgpydgZ6HSyorIynnu7 YmWTK2Vgq8KBXbOQMN281P7ARp3Wg8QaUA/SQcPKKc6CG1o5LVF5Brogz6xYQcGbO6Tgza0M6Lag I9BuOXFQoVhTgJXx5ZZ5DsfyoWmjoF6EM+g67L2Cy4Sw2BRM0KiC3BBTYBumJsDgclxJFU2mBn/y ver84fXKCHfJm1OxvxQUMAUATJlGUP51ah3C/1jXtRymU33tMjjPp8CHcBITAT0zMhxG61+GnuGu wXRbKT3qqJF/LYxTXsP0gYmIBgaCZiPlsKLzTUmrzVFWrUdcUxbqRXWqgh6orj+TP6ysdaEMRK7r y+SPVGcutLVN9ojM6F+X2rb114vp9SND4S1XlnwLc1gov2QOW/6EuLnii67aNO7M9sQb+pNmOLmN VuZ4KMEcdk9BUCWIvmnT/VIprYISitqLvbwoVmZ9BQayBgESfHhKm/iV1UcuPZx0hEsV1qOodQFR UFzE7U8x/Vs/afqvMvG+sU+Y/hcxCjJoN5r9Uf/wW5BDaHfgIwV3dwLETSAhIRyWqB5EdSDKgKSC /LEChtjbK2KIofDSm+UAVwNO5l8MTvYkziGcpFMCNjYFxeRAJ/QJwzDRxrUuFtRTrLEsW4Ucm6x8 fNL2ROKt9sPfv+LQ3x1syR/+3mF4bf0nV9f+cRhoBlzd+8eL+/v94D8OPnHrSO91s1fA6zC8XlO6 8cJ8064bx4Zv3JNv2nkj6kYv30O8AnmDutGvR93ogZYVsBdV77MAwoiCRKvaiK60pCtoUWpP+oqd 6CVxfNVO9JUa0VfQkdUb0e/eGe/vKYRrlMVidZmYxOjY+jTqqvkna6PSiD4Y67+6r2tbqxP86sqn bxoSg02hclfFF5K/qoTRf5XsSlhHbz5+dOCGvWvMMI4uP7Bh65q916j5xj1KvoG4dWvBBdnl41PI YFKcvtKUrzi5FOogTGKNqtrUoHC/p6FwV9C5KyjcXIGzRkp8Z8pHihnUN+McbkMdhOIYmvNX7iBc xLNm6dPnJywyM5+FqTYe5S66a1d8cGAoiYDcLSulI+XZCqfA2UQ+JFQ6CRdnIP+rthKqPSqVDAR/ WNlLctHsVDOICppSLQD0asolaFonIOUy1YBEIS3DnFDnIgU2NRwVrP6SdRTT3L0y4aequUZtG9xK jkZRIhp/GKdZnc7mCVsd9c3toaVuJtLTnvcYAmGPniQAcaHslViW1Vkyo60fP7rc0dzU0h8TCB3H sUalk2P9/Bz+AqS4hL1Q0GdHukfGRz43cnyEqgFi+4MGwKYoRQ/a0GBeAtCmALOBNwo+FY1NwWFD KqaBsaFGQeRzXE+CPyiQmhwKi/QFJVSCt1H4vm79cT2uz7zZyv1aWiftlqYkQgVdex0hrg3Lv1SN sQq3poGtTSL4rBqwtYVc5S8FW8NfaNx549r6LQP1MkciMLVU9+a2ZH/OFSus27S+EEtMHJsIF9sT VoYglBWhYEspmywkrPHCxKYNhRgwDlwO5W1zWMI+M4w/XX6XKdQSiTbFfcFU1+Y1zXtKdXqTVdQL soggRmSHbA7Vu2PNcX8wuWajJgvqAHUIuxu7+1msDbyB7cN2QI71YFPg7dlwwnzsFhRstwsO4UDP vh6zIJh79pFjN2Bjx4q+uaODbTv2D478emLdxO6JqQkiM5GZ2NL4XHT/8JZfDo7dIsw5irejoJxV vXlt67aIijh5pSj68hmTWr0xqU1t4ltoe7e2sYtevUkbX8pO63nZX9OOv0rRjjqAk4zeF1cKbd5j ggnhvF3tyPQm4n31zpBHh1IBNtg8XCuD80swve6yLkfKJNvqd9y0ceKajcn/RKhxldqehaF1NLld kiWeFyrluNom7obBRGHY7feuILz284u+fc9AlKbtxWjvofWLOserNUBM2cv6G/wA+X2sHdsxm8Ck UFqzuLRmiWnNEtOaO05rPimtlF9thvRcqOgxzNmKDUjMjCrms8jpNGod3GfP5GrgiJZVVVeRBH5A J/oTGdvg3oLnOlUO11bC9HfRYgDkYOuQLey26CiWIrfXljNV/q1e+9ToJj+iPovtxbY9NtHTk9vb iAhyrHVHc1guCD8NW9fuLe7cSTdG185tLbaiojJXHKsbdRflOXpIm6JRORkVkyG1Z7TVrbNahx5a klxcONammFXK+uffl1BhFdEeKh4oBftQs7FSO07Vo9Zk4Tm1YPzTipsup2qYszoniVMLvchK4djE r9K5XFs5Dkirsnp+HnGW+A2VxaPgEXRoFh7Bv4FpHCfegJrWg3XOZHtElKWlvN6UgLyLnmhO9RTF 1FxHcxEl8ScjY6y6KeAs9Bkgq7S6oGqKstBbi8j76Tn3iFeu7LIpZz8ld1zOP9/3F/NA066XyNeg K90NaTVCWmdSa7cqvT6GXoMbfmLNqY3Y2mJPsaPDX6wv4sWtxtRcc9GEDq6OjO2oMSakY2cm0YoF nMjRQkV1r4vCjgXLWsKK5X6zwooF6CFpJdMjX9JJ6lpDt7fcU8MpnGAEb3xlXoFnK6URZR+Myfhu y1B17WK7JyAaOY1dNVyULJLBYFiNjwBUACPL88tMWOExsxta8Jew62cuPNKHeLzzhhgqbvce7RWd iNnR6I3R9b3NUVmONveup7BLdx47eOzgpdzcbUM3FI8U+2LOnXOXot195MzWMdTJ89iaseoOApXz ObVmC3mObFydpVT218jgE3cWrKyln1p3awRWXdhjdpMUSzNWD9qb4BOqexNMAXUhr66G/4wUiK0g T50Y+ERpgpfR7oZIT9DwybsbVrGPT2k2teJWvJLRiPp+VY9Cb1A8yqzqUSi84lHoHmhl+7H9M76u ccWR7M/tN+6fnNxvJFxr0SptbwOqB81EXBuQB7ftHSuOdhUbiqmUv62+DW8bx1xzkSKJzM2qhSia sXWrcxjyPIrUFXFnlQXCv1xon8JlgX21kpF8q/ikBcngfR6bsqSLgMOyNdJesF4is8qC3/l4v7rP q10xBNg9aLcY8TSWw+4u+LqbAB9DEXgMReAxhOMaU5K8mKiUrMAfH1czFZ8WV/i0uAJeP1RyG/TD SeVAJy3Z8Wkxvk/pLDanSzGecpTCMO9b2DJWe6hBNSRfccvYkhJ7y0KFnfgaY/JYbR6JHvuqUjqp lM1t2WJ917EBxuJDRXO2WlG5atPaNZfcfiEerNbDfz++qy+ydRN+tPJEQ7gljkH+1GG/eAILzX9Y sKFCoU/BfY34gFf9wQtkjU6rdrUslA+Vq6mK1z3/20IrAvuWQFQCMRHEKRCMwwedQRAOggD6sTsA wgHgV576QdgPYgK4MgACaKsUK1mLAT/MegIIN5eFwVwA7VNDd0gSAfR+PTpoIl4K8M4SP1oBhFC4 iqUmlcpLSv1PQWFV+Y6QZ1PKyWzVIwZqUuwK8oUXJ44BnMDLZxUYEG/cYSTLL5AUAsO3eUJmliyT xEc4Zw64bF6JIb5Jspye+fM/INgPUmfkiC16E0tANcXhN/Zjp16P/yfCucB1POJ28/yfqJshtwew t57AhmB61wlJa0OL14k20IqukQyIBkDUD6I+EPWCqAfE3CBOggQB2jtARzvoSIM1dUD0W8GYqC1v oWuBg+oq+uEbREF7jK4FPUrE0WOhp6T8O8TMbnFcPCR+TiTFgkkuio2lSKn9y3WgDv2uDmWdolku XlJ3VR0+AJ/aRpUo5xXEyckz3d1nISdVfi/AFqvAxeqHymi6yucK2IgKvrICy2t+pG4mqfIHhMEW 9/qSDj3xDI4fJwzOhNcXg3flP0K/AaMjdxCGPT/H8f+Lsyao9j6TDn8VB+dw1hxw2j1ILIxFWBAK fifLfnx4QUSChWF5KCHGACXEslBCBpi4oiM/7JU7XKdg1yWgdYxAeWWxGwqSvwHhIYOxDHIWHRlg h6r4OALPsAOb5hbkyiMZsEhRk6jkj/6fNRhoC4EWHvB+VJlFAuH5hvpECUEHl6Rq9VUFhM5WwaCR 3qqqOxmRK2BcxIrYLTXILX06c8znDVl58rVXSd4adHsiEmCBvfyBDphjfk/IwpFnXyQ5yefyREw4 W/5jndGspwgEf7Kv/CACO6L0ZiM4BR42mg0kQXNM+QQYp9FxGbxFKO9UPEf5HuIayJswNvEE5oLE NiOrd4GEC9iVhQc7iBpbjHiMBU5Uzmh3Akcb4pwD+EoOzlziRshxbEQr+COU6JRqsMhwA4RKa6sZ nfwSbapiEJnVRmQLgzd+lm7IOf0STl/DikT5WZ0Y9nqDFpYCgPiQloJ+d1iiy4+JEqW3GEGeNHHE DqvdSBE6wfBxBj9n5ik0X0BKtmEY/ipxCkthHU9gIqRERmjdUeX0giz8fRPbz+JsRDoN8JOOohBT Cr8jVYCXybOT6KSaT4PuAjPGV2mdUffxOasL6SK4s/w50YwwlHGSl/QMelY+Cv4eJt/0IAJ0cQeC Rll2iPj+QARBT9FGWfIb7Tan+PFXGVHZmdmP/xgvUC4sDbPjkRnG2n4abJ7FUMfRabCt4BEi9/r9 Lutd/gyozxQyeCbDue6NT7d+hTtCHNbqkcpxTpKCWLfQOqGt6a4CvrJQoqjFXsELLm/AGZlsrxtp 8cVHLu/baPA1RiNr0l6dwWTs2NvZP5l33joR74iacnV13WH8F3o9b6iPJOS67mRmIC2HXEm3wWSV Qm6zxWv3tIxlr9fLfjkWC8cQrZdDWr9Om7Eo1oo1zXC++qfAFrQYAL5QkDCzjzPWPRqcdhwwHm48 QR2pFKjzeQ2IL79oN+nSGVdVMUZb27CqVWn862jXuzuXSdtdQVE2UrTotFicIpXb1li4oM35JYMv F44MZuNDiVDOJxIfDE6vS3FyyL5Gb0D9IoSbQiBo8Fv5uXQku25/f6S/2Z9oeSaT9jX1IUwhSJGd cmD1WHzGjkVOQ0oEznqfJ/g3wjRxf138a8yR2jMKXz6jwUFXBVBTrKNVKSh04HacZIIXdNz6hdTI pV2WVDxq42kCWTLDxbsDQ6Mjw6meKM8wMF9qMpgMnD3w1TvHD4+EaV6SOKPJyFtMHBmw7d6ze7sn xEp2yP0iHOvVtAQtvhnLzbCO5qfAVhjipsHtBVHyHXCwRPxReTr3oL5Gs/Iq/llVoT7t/nioS1c7 ApIs0Nk9a3q3553+nl3dDRNxRlD4T98WH4qHYUah9+ai4VIG/3eV3z3Zhuz4Z9YMHh5PRaMgQ+lI Ajp9qrwhk/E39YXCg82BVDPSpCFIy0FoNREsg/WeyMDY+vOzLklyRU+DLQUb5jLfYzSymbv8aAO7 PXG3f5q9136kgr48XT0A1lSLaVzdqy5bF4loYac6ftBpLt9lSvQ2RLtzAY7TGYOphlb/vffGhi/r H4Sx8OfJgf5QU9iMk5jTEetMyrygNzvdDqOepe6+d3B6bTI+uLNFGhyxxZu8yAuH8efBk7Qba8Gy syYTZpRPg60FKRkN6r5afzB4n3xf8pD7sPGQkivOqc2E7+fOLOwyqFZ75JVaX1sW2grBkzhJE3TK hiL5o3qjgb+KNrosViiLtTy04rW2huGcrcHKUjj1r0YThxv0rqSnze722MvdUDIkEg/4kd3jtre0 TjQ7dazOYEH9LUnwAb4PWsAabBTbjt3+LLYe9GNxzAQmoEMeABtONaTgZ8TVeRpsmGGwMWTyLmwj 2FyIR8h78ofi6+8pWNdZcWvxLiHDEC1+dFidv3BXy7R/C9hyV8EP/AgMSMcX/Vdi3anJuWlVhjBh mjs3OZfXwHBefgPhqagAK+8ouGKf2IzXsqwXD34xy3vxaFq7w/cZ2BGTMdC1udnXZuIMUf9XMqNN 7lDp0Ejx4h5vXcztDzllR7BrS6M7a32c559pb3UlXIb2JnfKZcg0Zz8fso/0p9pDAvm6Qzan7Jli zmnQczbRZMdp3BptC8b7mjxytNkf7/Eass5Qh03Op7LFRhdN2b9Z3yp5Ypb6JtETLu/3enHSFZND fsHuR5jZ+PP4ddCz1mPZE3ET4rEb46EqCZhbituMJ1LTwQO2w9ThSntYfjG4qepKo+dvCsOvg1OW xQy9Z2tbqJigVFdKV1xq5oL69vU5Gf/3qra0FYey6fK9lftaZ5qMh7s25JEl74EWgFMfKR1hoWcx Gfwbhs5C26Js+nPOOsQpZdRvVdBizcvG11rTUfO/lOC0VkZldQqUIVifCQQz9YGFceF2WkfjOPx2 Kun1JpI+aIn4/GvgA6CH4whCjxKHuRT4t5mEHkMu0obVAefjUc+U5X7qSuRDlLGcqUGFJJU/rvi9 lYcFMFO62CJnZPjXeR3NClYpEmYElxkNVR/MZgOhTDaAP1e/tsVLM4zeLLptBEWk83jT8rGq0t4D pd2EdfTwWAO4A2FOQ5bJcNiPwUiCA6cR8jTqy5lyH5AqctfErmJP10ymxAoyb13oxWHMsozvYUxu WXZLLPWzpYKfJTmTU1npZY3feZ7X1WhAuvyvK0g/+HOaowlElM5ierT8a5Og0oT9DtKkYomDLbOc eEAZt4Ilvlzqv1s6jIU/u/Cn1PcS78GZYhArnGgJwelhJrNGQmJ1Y4NwrrBwxhM90/4T+ek1LYnc VOKwrYZbWhdL9p08/O+8prL0HgldbaeQq3sO3oMjVQTe1Ozvi9OC02x1CUyuOdhbtSVHKGTL7Wwo bbK7GrNZe/vaBsvq9rT0Hrfr4UdvY6Y16446+HDnRJumK8cg/XVY+kRYWvAMRsxtfDQ2Hbb5pyok q90jyC+cn9gF4pBXOIYEYIaUtLSFhuIVGh2hgCO3u7FjomGRRyihEd+zbMTKWHFsAM7qD8GxmuG8 Hnwas4DbEXo0jE9YzvFVYTr0N2pU+OmAo1vwhxLjVxTHp0rB2OjRtcMHS5E7hUhnJtkZt6Dr2k3E B31TE+nY6IGhvkPr6xIjB0rxoWavu2moLjnY5NmpRKzgQ/zrcEQoYm2d8dVziIFWJWK1YFYUrnL1 WR9JuabEo9WgFTUIzK0QtC4xsyoPlwet3Ts7nXXJuK2iF5RRFoPOxj1rFoLWYjo+GA83oqB1aHo8 xZo9lvLHFEInpuEcPofMALK2oT47fpkStKaanklnUNCKIkFI1dUaVc0zHr5VjQSz4LaC2cy3xjyk MTSVfNQ+3fSg8Qh1VA0Gu5VWkWowuHgvyZJmB9nKLI0GVTOF+r61ubCtzRno2d3lSNdl3LQgSwGH Gg8GjDzMN1A8KFQoAToYd2shoRKYq4R9b1FAqGg5eEnJoqIng05MQGGg3smdiU0HBat3ynp4oU/h /TOm/OJq+nLdVg+XAS/BIJzS8dBbC3Bql2ut1J6MhszGgMzACPNnkt3IUDTF2+Oe8iOLlXvIF7fp SB1ttMFR9uI/BnNwlN3o7NE82PiYv85fp3ecBpsKHkyfvOvtht824A0tdzvyVGSau+uH0osSLsl3 U0dq0Z8nV4J/rlmMboFZHrl4UVDLLiBFc+Hubc3+joxPTxMUQ3KeeEsk3ZXsKnUn/Pn1OW9jzMlT 8DcULYezvlwq1T3cnSSuSvWm7bwg6G1Wg1lPiSYhGHMHbLZ4oTm2JiWzegMHfyPpKYNoSDi9Ibsc 6ULzVAjSe5x6CMthdSexkC+GpCKaBd53KHafg7/PfCh1P6Na9Fll29KZ93/8Sk2GtDSIXRToolQJ PQPHaU72BoTdG9fyPK8fo7UM4w54x9/hTzqjNElTOCHKdjjzkjt2gigKYq+ldBRJwm/XKiHufzfk BJI3KZr0Y/w6ygKjgPQJNqQahgf5SynEEokp25T/0WqCVIX2WyE9qqkFy4tKwfh1jpDJZqDq9zV2 rG+QaRhTWRwi3ZoPFBMVV1rNh3KKawSjtGoOdPknQ6VsGlxeuUdc9uH/AiNwCxbDGmdMAd9pcNus OaALwLnuggLP+AMBg3PKcBibUl08cGSddpT5aEjRaEsrnOQrJT6YxS2u8OE+i0vQEeSTBGcJut0h K0c8RVGs6LbIbhNN3I0Tt+E60UVZ0CHOgqFs1KEdRzpeB/5HL+l1FK4Me5fZDB5idDQBx1uH/wvx f+B4+7BNp/yBBjmbtaThoAt8wGLqsOiYzk5LN6p9SIylZSrbaSFc8SnX4QoF6mEPVdBoBSi6ghqt nhe1lKLY6sTV/EhcB7WGIcjvEDpzwOkKWFn8IMD3EawF3Vk44m9JgpGcFptbYvC/wvErASM6rFaH kSaux/ErgE5SecALxhoe7NPryw8ucMQo8lWO6PXgIVWMOro8yWt3kD9xOGNvUs4r2/Q0FgSzmB0L w/mGzdjhJ2bj9afBF2dlPstzp8EpGOH7Q3xiKsRTnimpOpErLPpxjaCruRHkj6zNRzHtNK2mVnMs qvHFpgV+DIOvo4Dod9q9Zh3+2WsJFsZ/Tr9If//bNBD8TodH0hFHDhM6wWV1+gSc/ib+a3TcMg5N 6vnnoQNR+tCAvqwzwIc0Qz3zAxJl84yB/QjpLMwaL4Y0BrAuFO09flKn42ynwe2PBWQ/K1tOgzsK ek52T1lZYYq9grhSC08Ww5wr/k8rNLYSC6XUGhTstUQqafMIgBx7gwFGr9MOI1jyHvxWnJY8drtX ABQuGHhSZ+BO4LJg0ZM4o+fLR3FwJ8NBpefNIqb47ZfA7ykjtLD6JzARvPa41wI/seBp8PMCzwak +x2HhNAD1BXQTf8Q/lcLGg0WlRXNoWpZER3DBpVUcWG/RwfRlL8gQP3hmLlf8EYlWNolSpzw3h+V Ewd0gsXAyFY7JwgiD0adLiO8N9kcZrelPEuhTByHyfgpZW8Nj+kxCzohZ3qWZgmE8vTWWZB9p1oS VDMSsL6yg6V8nDyr7SAon0DvIf1ghLpl4T1XKe/Zu8p7RurybclUvi1VfoyKtKYSrW3wPWcwHHDz fwBvUDthuJTAjPB3rjERbbV/sxaUhYhWt0UsjuXAMzDhsFrdJkYCOmvI7QpZdUbWEff5EnaWtSd8 vriDBUcrvZDEk3qTnqKhx/koH0i5eN6VCgTSDp53pJVdR38gtsCRNGFFLFowhsM+1nKSourZ/na0 8gdO1Cu4n2++IKnn0GnlFYbRfLoySq3NC1+KXr0MdGNL7oLrxphQzOo16WgA7cYk9+zIO/2FPb3t WwoJjuF1JG3Jr9/TdNkDe+vLZyA1Xn8cASjE/V5IHfH/tt62u4V6XxDQogaw2jxmJtG/I5ffNRB1 eO1Qc2W7w+xzmjov/eKfO5ZTOzc/B46TuxS++5/GZHwv5seseP5xXkxCKXwGg4SKZ5bE0DGiaTVJ 3AsTVavsEmkg0eaw2xU0Mywrhz3uqI1lbVG3JyyzoBmhihLwGz6vFzmK4gX9n/2emJ3n7TGPJ+7g OEccju3q+TkCJ/dibdgoVnoay+P74DRAgRcfl/rgZ8p9GjcVzFgqGuUD/9Ekfxu+p2mML3ZpY0bi EVGluxoBaR5NEZbWdhtbRVj0isLC02svK1DQl7vMshcGs/Anm6hrn2iUnU3rWpom1kR1kCgSJyix sbSlfvtt29Plj1g54vFEZciFqMcTkVkiMjS9Lks/ppgqxepetrhFJtRWiqeHmz12j52B0zov6lnB 6zQ1bD765/9ayhjoY5Llt8Bh7G3MhXEzvM2NiS+fVTd0VQhrNVclchiGk9LtlMHsMEs2DpC38Paw 0xG28X/ta8qkHS8g36Xojvl6lx9lyH7kH56a/wDcSdyrdN+7TmCW0/ixU5w35BilBOgjznafVVoR lqdV0lKFuBPZoT+O7DDu96mau+ie8PvrkFbW+YNpdE1/HA+oD6CaOvV6ZxpRfB8cz0FIMY/ZTqAj d3/4ODpalyVGMTSU1I/Uw46qjuZgtmtNBn0dGMpmBuAXegcov0tw1A+grutOiBSGGuJsGru03UTM I6TB4rE6AiaSxidJg9lrdfhNJPW+QdCRjMFsoI8ZBBZyy4IQon3zTfhJ8pXzve+HBA/fZ/dLJAF+ C2cIN3y3RFD/iM7FoFEQPK6ckAH9EQbAF8pfwSPUA/B97IyIGsizizLrSkgYYUxem+w1MfAq2+C1 fLLi2eifVPZ5IXoHwCyewTsxATPOYgw/R2LKWYJaBVvllbJOlTFJ5Z0m+AH+VmeAadQfY15fNOql Jef8PMyz++FbzuIMcQWMbr8M33tL+WHwO+oOLIQFC1YCrZASqK2ZUBbRCKuPvwUOHeqHetgzDfM6 k616HEWGUCY3lT/gN7smd22ngNHjMDnNeqJlos3ty080Ahgyyja3iFMXPlfedu7V8gXP6yWeghET dfFLr705Pf3Gz392CUnTBM0pc+7VcETvwhEFsMYnMJPatWDS+kbR9TE0MpNy0DWv9KWrI0zlqudR V88KbTE1N+HVCEc2gXfdbetbCL3ZaXJ6DIDasXPnThIX3TarW9LhlxzFHdNvvvbSxZSOxile0v8U PPzqOfDwc6zIwdHR5NnyOBzf5vIP8H7qemwc8xQM3d2en5jNuqbXo8Ov66BIsupBRZ0VaWs5AfJI FW61tDRXys45rceYUWr5FuXAIquSOaNf4f0kq6dNLnPf5pxJCrXGWPUwN3a4ZG7c1Gt2mBh0QjRr 0CXsQSsvJvqbmvoTImcN2JKskSXL86LNoCNBatP1+1/o39gdgzGO0SaIskDjus9d89Bnrt+cAiR8 JEo25OMbNm+7u3TJRAfPdWy4ePgHWzc3mAAtKGecHIU074M0r0c0JxJj/0xRYtPrvd7XxeU0Q+5b K8X3ivNoVfajIuohExT3XP2VVk1CVCtE70P+K9kWMlpym3vMTgu8o2lIeQoh40jxgcbGgbiEaIzz AkdSrIGVnObezTkz4hAKCPBWUTYygGxcd1FRoREndAaNRlM9pHH4yN4iz9X1bR3+wbZNKo0m0WZk KpwayDgonaDsELx5XgD/TM5C6wg8C+O/b2E05oTfYcSFEzPQODDUuPf+uXfOvbNgHJYVjeNHo8Oj JdLgtZscZp6o603L9kxvEoeJBZzmBZL80rfLjxw/Uf7u33ESR6GweeP3jp/cMTn76Hc3wnSdoDij YhtwPE8q4wk9AUPpa2esAvYUbsJMcCq9dkZwcsqA4HDEc++c1xa8BHjSVtdbh/MmaK1eAyCHS8VR khA8NpgN6fBkb8YO3tlx8vj34J+H1gBH9R2w+cRxsPXbrJGjCBIO8LuPzqL+uVvmSehBfonTxHXY JLy/Gt6/q9x/TrnfPO+C9vImvL9RuT8K7/cp9zdhk5Cmb+BfgzHabTDrsReM3rgvlrUxgkhzfAix FyZ9KHGhGZqOxcwymhZazQyNjl9rbY0hulpsNiKKJgqGaG1BZ5sxDFEywoTGo3/FTfgzGT/hflnv tdmA8f33jcBm8+pfrjx/Re+x2XDj+8TDdCgWN7EPlv8kiND/0Q+ypngsRF+2H4ZzMRP7AKBE+FH+ 6AH4PBpi9mMkhs3/N+WjhrGN2KXYNdi1WLbAlQ43eT/ruIARDqK922vHEgkhjw4I6B/b+1/CYGUV UtlI1FBv1syhMheo5m/rIpoXqh7qs8Zci7Kepeay6gnjwKLshKyEOkRla1GGgP8AXO4tXFKK5yNi cvLuS7fesCkV3XjTZHDdlu11Fr9dz4g+h+yzsOZAgzfdl/VxnImHMtb7nZb6wqZ8cvIzh/u6p3eP NntATPClfaWL1rismcGG5lJWPhLqv7gvsXao4Gq6ZPe2SK4vYSq/Aza1XjS5pa5l6+hAqGt6S2N0 8KLOjgt3bM8ltl2wJe4aGFuXCHPQV+GMYHC0XX7Jzni43qvHdXaHwytwOmNoTSbYnrDJia7xCwnc 1dY5mEoMFAphT3Pi//N2JvBtVPe+nzPSaBltM9ola99lWbIka7EsyxrL+xZv8W7HS1Y7i7MvBLJA wppCCEuBlgKFQqFsSQgIAi20tNzXQm8XSnt5vNfS3tvXRwvth8LlFrD9zhmNbCchKfTe+2LIKCca ZXT+Z/me/++c/19fEqye88X6s07a7NcFJ6cmQ7ZsluEdLViAv8A/jLVh49g2bDu2j1HkNmwm+GQm 020whfiJ9m/jSYzE1LgW68dKwbsMaSP7bbZ+kpeYyONVjBpzuzO5DSHTZgPRLWoa+XfF9jVr80B2 qmk6gtKLZgrpCrOvI4spEX2+XdikS7EHSGhdqoK+qC21Wt3iUM/aUiBEbt6CKflLpsQ/05QJzpKX 6ZJDOVPAoigfubK3Z1ery9K4vS93x6jFRcCFrM6qFiWCvZMqOFsJAM6XunQqf2ao3jM+s71y8pap KHCiNVT9QESpcKRK/TWlmu3W9FC6/UhFbLyv0x1M22TzvwCBYE9nu8eRyyQNuU0dpa7awXigs73D 33K00TuddEKsIXCRXGrpPZbNRIBYr1cZKLFYIrYky20xtzrStxM/LHMGKx32ynBQayx3qLW+xNwz Zc0JS9Tn62jr8JVEIxH8nwo2E+YFC9BaR7DbsS9jX2Ok6w7tH+CvnF7ZtkexI4+XPzN5giBr+G03 ncUD2DTk18Dpo8OTsB99wkgVk9NHFYqj05P8tpKz4B0siMWAiNGrtxDrTvC27K8hD/EHvPBn+Pr3 t3y5e8/zQIwNY7VACjspmqeQIdnMWtCauhRVkPMKu66hNVOcTdFLmjMsWOqVMZz1bPO5k0HIgrzC UpCvVXIWP3eDvKeQfpG/GP6Fw+hzDLwoXSC9CBDq6sn92bJ1s7vSyZGsa+Sxj++57Pt3bWtxakq0 MrVerxZIVE67ITJx/Lvv3/wdEH59m691XWbwXqbEW6ISIeczgERgDsTN3T/dOfPHPXX7p1dW20sb V1Uwrb6Rm9cPH+xxz231d+5o7bq7KbN3x0zIVRM0gt+qSusi8eaguqqiYqwp8MldfHvT7GCrM7pm csgTv/Yb35v9BgBPjFQM7r7mxoa2dbVOsZBW0nKROjW0q2Hy7Ddv2lA1+5P517998K2zX60JVwoE BF+qU6qMtBgdd++oa2nW+jOdU5W10wMt1r6v1dbsGqkMdqyZk6OOHSjzj63ZENdH0/X4VbZUqdFa wdii+xvNqZpm4MN4sM3IBHuJELYVuwq2mpnT267Su/NgMxMJSfXBSmy/vk/fhzWu3vm21WeNHHiP Hn6vq6tNKL0qtA12Eiv8WZV5b9OR7rY/r8LOaQPRwrIS7bWHLeEl9ozNS9RP36BTqbfZNLLgnI7K Ly78dUlOvuEJkMX5XM/9jFQeLtbq7AKUKLYetpEkgWAv7akZ3tPhb0y4hb625gZ7IFfh0pNyW2Xv 9nZbOhE10nyTR2mQE/gQFa7z56IQgMq3f+f47vyxNQ2lWmHFgdfva9k9kCCR7gNBTpqavHLF2fm5 +5sl1sqhg4/9+ksP/Pmr7XPPe7oqSuujTq04ntVHK7OeTz7lgfobr94zXKFypdy+lIui7eHq5tLA 7O5tQ0mFLWwflMtRjvb52ECvv3Fs/abowN17mmJDO6+67uBW72z+6lZaRQsVOlquVEhJtVo++MDv b4xdc+c9d1yztqrz+D+/yNT7a3v6u62tXbQz5eX1IBvOzwluJpzYKmwKW40dPDPV1LhqAsuDyxlZ 42Rzy8qJid5qhyNM5ME/n6oOt5wFP8Z6MRq8xljDUz8fb2rSU0NgaI33Q7NZvwL7sHaN/qPAGvLD 5OopDBqUYv9DkbbepV4eg1ZNIbnnf7/NeodREDRDOestLodmZdMLgiUvAerP/M+y2lLHLvhM7Yso xS0IdUInzw6IUKI9rGWO/uTma/7HzWNJra6i97IHNjbsGkohu6BU01TN5BV1357/2wMt5sY9Zz55 6AEATq7yj9w84/RpRfzs/NVZnoC2Gy12GU4AL0+m99tcAaOUdzl+HPg++R6Q1kztr7nq57d11e28 89Fn+luv2zPZ4KZUlFCup2VKuUyiVsmnHv/Ljev+5dUz13UOPT4/983Bx28YgGtc8r6HBaSAL5Cq FPi7cBSHQ4NcPD5/Ga8Vchi2sBf2qjshh30F24jh2PjCu/w4v2Ipg28jm8G3kc3gqz2lGHXmgfYk Mf6FMvjGq/efPXDlM7uT6Ho4vzt5ytW+t7djR6fP1b6nt2Nnpw9XbX7ljuGeW17ZtQldT7xycODL W5nqjScGBm7fBq+3sHrSwse4gO+Da0LrSZ0kjxtPY7RUkge506YRYhWWzc69xmZKXh7rDhJjYcxN ujkhHheQGptOa9NIPkZHTVCmQFDKl9KQya1KoUGMvPVCCckbulWCSJ02wEn1OzjsW8i9BZ9iCnL/ dbCGarDcs5gWn366wg1/sFQeP/KUxGZLleRBihFX0lqeIDRKwRmr6qRgjN1uivYssd6rC5IKcsHB 3Evz/3KvFTutCNmMp9cRpEI8l5Jp5SK+WCEDmibYf/WRtoqaNa1hiUAigosEEZ0e2J7rOzJSbqzf MfhHPCJSkESzskQJh2uLXmMzqMTvVE90Ndi9TMho89oEcGUu11IyyuXQe9tnG2NT07sbvyMuxMPv np/n7YPfdhjrfxarwFsYWVefryvn6+ry5Xgoe+30M5hclVFl9JV5oGfItr7QgsNBtI3q88Bwkpgs HG2GC0OqcCSXdd0VDrsoU9TFghaxqXoX961exJnHVovGwuPtS29/ZLZhx0ClVAjXJHD6k8R6Zhty q+sdZb372i+TKsR8uJSTbM1Nt3iN8a54eqo1CrulkI/zRZp03+bs8LXDQVvNSFV2S2/5ge4bNlRr rVaJTGPRqgwKgd1jc9T0VyQGsw4hZdRA6BE4s0MJf0vC6vQ7CapEq9DScrXbqQut3NWYme6plOJE tGcL8rk5Fkh+lO/BSrEQljoVslN5XPCUl8/HgnmceEYboOwjoRJvHujOUGPkBH8M4wI5ogBesJEg h1wx6ffixrX4YnMpBsyhkX/MCez8qEr5Kso9q7erhHN5iVImQFF3wX8QanvQ6oxY5K8qtPMb8Pkg +EWTw/0GSvxHiKTCN2AL0KmtJhPFqxUj55VIIf70mJPn/nSePbuNsXmza1Cm5iT45Rlf1BeVluTx plOY1JYH2OmqKiKRB+lTZcPaJaMv5tAuStXuzz43vbgjeSllM8r4W5hbeTMNVzy2PrWuO64mCXTw 2Z1b25rd2Bl0tO3tt5Z7XSqT3mrGLWK5hFCr5qvtza7Zr09XnNl4/2ylQqNXe+0UZFS9SWern27J jtVYeATf6MYpm02kMqlcvvnb+LzE5LXQUgcW3uW9SdiwKNaIVZ30Z/J4/VNSo1FakccbnsGkoYXK SsIFv+wp1VAuDzTFEXDpS5Yv305XhIRzwjkKzwudUQwg8mZ8y0Pbei4fy3poVXnnvge3eNtry2kR EEjFpCe1omLV1f0BnjG3YjA8c2LE+6S+cjjnbm/KGu3MOFM7UWMB9/bdvbfF17rp+gdW9T7ytRvW V4vlStpsVMIlvJySdxz65qjColek1t4wkRnPOWU6q/LQ4zPBSNda9kwLyTsArWvF/Cgr6obTAoGO zuOtpzEdQedB9WnjsGSCS8i8KLotnsNh58FCeywYj3eAR4gF8xGBXO8ssXsoIAB/mLtNrBATaiX+ Z7lGIuC9oTQbjfJPXkPdUogOKLSSKpPS6xYoTZAQVkM7/Iyww9knjjUgjSCEGzA15sMNDGlROFnl jUycxevhtMTg9YyUrEgTgTnDUN3cokmW5dtbzJ67fI66cL3NYzc5sd6nREIVY1mvsB2b97PM9gdn Vt+zLePv2NxYPcbYI2vvXDd101jIXrsq3bS1zffmjpmNO0pSA5m1WwLOhvUN2Yms9ZqjB68G7X1X DQf93Xs7M+v62xzWhq7RRB3ErfLuzTWJ8ZXNVmdr3zg+uXJyqs9bl0lZKg7N3RdqY2rstkyupWxy ZobNAIvx8nD0DWM5rPKkOYJaJQoXl4at8mkvM+9wCBOoUZah4VZzUri853FnARb59ZyOlzw3SMl5 W6d4eXWkd/8jW/1d9REVCclBJPbV9MYnjw0HcWNte394863D3timB3fsu3fK94SjbpKpXVVtMlSN 5Nq/BF7tffSeY+uqSUqlMpegLW4QUtoOPDiqMGtlVeuOdfd/dU/j8Nd/t/PQE5vKw51rY+nJOjfS rZqh5V9ZTh4NLHk0sOShK5CH7guSB++VyKbHDhx+eI0/vPmxA4ceXut/Up+Z7m7dUGvWV7NXC67c xJHH5h8g8vinA4Nfns1WzdwyyF3RLPg4nPPv4fvhKB5+FvPjRkZBW2gJ/MH0KqVzxA97iro4y/8v CCHFg/rnz/AV9s8AEvaANO8eASkTzo0KpRKBAA7CQH4OnSj1Sr1NKXhHJBcT9SgSA5yKVEq4ssL/ yGKKjtbTEsGLRUz59HIxbYTPvR0+91dhnVZhKcQqG58ud8IfLJ7H9z0l0ZYLDJBVTpeOUvFllMJ1 oEshiueCFL5LhPJVAvb2ubhcoxDySIUU6FuHI9Tk6szqtqiMkIgJUpsd3pEdOjpUZqjfOfwuHoMz 8/l0kp3sanR1DNt8dhFtUhntWpfT4GvblEuunVkik/WQTE7A7zaIyCSCtzKyFb2eFYxnxQoPw5PD +WkGkkmaTtPaBEsmLb1lCzYb0TKq/cJkkvgHweREzc5HNtZuG6xSiAQ8uUwc752tz62pdwR693Xs h99bKJDIxdtYLIl1x6sm26MkOr3FI4TyqpU76oavHYFYMpyum+0KHhk8vj6psVgUcrVZ4yqxeqyO mr6KxNASlDiYoaS/OWF1QChRlGhpnVIqd7lKlqBEGOtGhG+DI/5vOSapLDCJjmMS8CFkEtI+4i0J wb72FB9BCRz7K/5xJOH9Vq08IVLZ2ZSIc68iBxUKbwLe5attQas9bFWcoLTz94L5avD985DEolNb jHoZrx2WoaN/ok+vKyAJtP1aOC7ezjJJwxKTIBptPgNpVKVPnAVprAyrAtgZCKNlw+fB6Lki8qUg 1CG4KJrc3njo5KbqTSvjFNpfJpIIydKm6ea6rd0hb/fl/ZlBD4smGQTfauW82dkSnn1wNnVqw32z VUqDXiajjbSyhBYZLAZrbkNrzXjWKj0XTQg8Pnk9osiNcGR8AbIJ2r9w57NY68KLjE6Bd0y0gsCu LFiXBXVZEMsCVxZk83gdo5aaTNLL4mAmDtrioCoOAnEAe3zd01sxgA4LoAOmikJQw2fgx2BhKZDm Fz5mSPgHadVCOEx4CqBTfwHoBMZeDwTGxt5mT4qyzMO+iqLjf+ehj+DzoM8LcBLZ1n35aMZNKUOd ex7c4m5nyuQQzIFQIpZ4Eh0VKHQ6z1jb0R+ZPj7keVyXgPDT2gDhJ7sqy6yqMYP7++7Zdy78KJQS mUIlZ/GHlrcfepjDn+smqsZzLoQ/hx+fDoa716KWtBr2hidgSzIv8Y8G8s/605iGUCL+0X8O/lnU XXlPsPgTIhQ6l9HhoXEBeGfuFpUKws/7F4Efn8vDog9knx5o5+dY9kliTeDKZ7EEOqZOo7Tj8AUS PON5riReLIkVS2LFEjbIGb0U7KwFaaSoubSAcPE94eIB+OUlbCDQcB6SlkHtY5VfH3u8nnttg3/r y+N6xog4DNYoCrCHfkNEVsm+pxIdAdeYQUcleyNXiG6sfA6vw7CF10+jBrfUAF88reauFHctRN18 kU3SmUOHcEn0Gbkw/NBc8aFzxYfOcQ+dQ82eJtE5VTKeIYIQBxvOwUHu1P7rhcPky6JqsRdqWfw7 1JKxAPfr70FjcWPthdT4XPW2Bzeu+dqWKl/blobqUUiNq1lqLEMHEptm27y/Mlf2xjfNQm6sXrup 1NGwvj47nrEePXLoKtC+8qrhUGnP3g6OG7tHE/V7BiE3bslWrFrZYmO5cby0PmxA5FidssYOzH09 1FabsVtrWHJEo3wPHCEfZMmxHqs9lxzrnnKjIRL2cUZcysA5UVi6HB+XDZCXRshztn7zL0CvB9Xh 7v0PQ4bMlatFkGNEZGm2OzJ5w2AZHr91YtMtQ97ozAPbu68YZbz0E47cRLZ2NG0ywMWNp7UuA15d +a0CRarVdjUEHRGlVLQe/MaoNZxef6yn/yu7GyGPX39fI6TIcHnnmlj1VJ1borXAb74e9qK3lnNk kuXIJMuR8lOKdZAj5SeJ6S/EkW+ltj8yu/n+TfGqrY9sRdfHfU1TVfVr6xzepqk0uuL6wz8+3l57 5EfHDv/4pnbmyKu37rx7wlc1c/sovPrTM7ej0caw8DF4i+9d9GCpTttZD1btadNaYgPyYP0ADTMX 8WAVD+WAt0i4yNdZNaJ/pTRSgscnRX+TqHQlSr2VFurZ7aZozpw4TOIys47W0VL+V4TiwsZT9BSj cLAJ8KNYNZZFVDi55MG6sujBij1doRWE1iH3VfykYH3BfZX6O+6r5KXdV1r4j4pkorlr5RqZgCCV sp/VD1aodcG6UMXKbECMzqfjfBGdWDEZ77+ix2+s3TnyEHhLSTfSRqVYAJFGYzHoZD+tnx1utzvS ZfoShxGlYJapaRllMWvK2takYmt2XDfwdS86FQ5bgZulwy5Eh5UX0CHDaIt4+DeIhr9DaLhO+7dC u7gkF4L/NBe6qzbdNZlc1RJRwKlOKpGU5sYyVUPVFlv9dON2hPh8UibaFBvIOlSlufKKwYYgCuGG aodKwtpZsafbb4m3B6snci5Q2ry7J0jpjCi8ltpmgDhhLM/5ShtCBoHcoEbCgTHc4Lcl/Xqjw0jI DSqFhpIpLCa1s26qJtpXFyR5RGkOHaLHPAuf8o7yXRCcwljqVNiuyIOFp7wEgZXnwcOMQustCX/E D9opirSvJTewRyrgAhvR4XI0BH8fDS04y4ZHlYq7hWqrFsWcmS+DiwUCrV3AdQK1NWBxhCyyu9G2 j/l78Pk7wAxI2x1vF3cZvk1QZr3SpNfJ8W6JnCyEf9gjpAx419xvoPUnF/7M08NZPYcx6KTFg4t8 WFXgw8o8oBhpWc2/QauXrdEvs/oFaAg+Ew09F3qtUE/gkt/y9A077uoP99cFZQI+2+1Ib6qrIjfB WI9dbfQ5rZRObTSCP4nYnTtS8fw2mc5oVo4eXx0H/QNHR8sltJqU0EYV2pBCa2lbZWdwYphH8PRW 8KypRMSu/VTi+T8BHgCBzq3QdlsW3uNtgH06Csf7zEk/HObVRf+VmlFh0sTvQyEVYbUyro9U65h/ 54Y/LjnMF3dhec7BuA3R1TeNtmzrrXJSdKBx+qZxS21VgBLhAlJE2iO50hWzTU5ck6xr9Q4e7PE+ MrnenEnHNJZkdyy2IqoHK9uPjCft2eGtV7c23Xjl1t6wUKKgDHp0LIKUklWTB+qlWpos79nZNbpe TGvlq492OxzpFdDO5Qsf8+RL9FbL0VsG0Rtck8dP69dINlyC3mLn0pschbub38WXa50Gu5cmwDfm PqJpJYUfR3vVeG8qTQad9NPHJOwGP0rCm/a4XMgDDNmtDdb/NKx/xG5t2IrnsTCOs34rfJnfqvIs roGTUQ7XQlqpzGXiYZ+ACPzCsK7pF5xBioesvrDzqjBXLecQzjbTiQ13TE2dmApbmfFayByG4OgN 48NHBgL6WG+agS3yRxNroq1hnTrcmZ4asBmSw7lcXwTyQX+mbiiuAZLamVafu2GiOtTVzFgNKaat rHJ1a8CdG60MtObSJlN1Yyd4L9uhcceslmhZmSE4Mk95KiNhozkZi5lslT6dqSzOEsl7vHZYQzGs EUuftMIVieopjKKwLGqhSr9GY6z6MJT7vcslDK0zfiQ8v0eezyKCi7uzlrFIIThxu9xbN33LmtIV NV65QIDzhSQh9qQ6wm2bW924tjLX4h461OsNTxyfaJztrXbTD1tSXdFYR8wwtdaSqY7hqew1V+0a jEspSkIqlDKNUc6X0bLkxKEmGWyYoZ6djc1XTqWs1QPbrk1MXdPjdKZXBMbWkQotVlTUINXDxoD5 n8c0eDlsAla8/BRGGvOAPKVAOZvJk0Q/ByQvv13+GUSiuVBUyx544YrLz+yuzBx4/uAV8HqqtHNn 6+DeVru/a0fbwN42O374tg8eHe9/+KP77vjoifH+Rz66V3r8h4fTHde9sI27LqpqhA4yielZzI7T jFhHS6QSUw/Rh7brv8ZmMPovkNSkYn7jrRKe1KJTspIaHM4ACmaKFTU1WEfsel6LjywRyaFnJHRl qgAlIRZKehGU+E4KVi6Hkkv6rFSfQ1ZDTqvKoqz28eB0kjbB4alqormchI9P4AIxXdW/pWbVl8ZC 2qYjm1/Dy5HfqlVpUomFlEWrtuh0MkCOntg7FQh0VDkcXruINmvkOlpOuV3G+OhlDTWXH3982xti ZUkhHi5vH/y+nO8qdgGdDC/zXUlY39VfEaD0auEfuaby38wo+1LbvrWtdutAihYRPJlcEuva0liU 1PYVfVezi5LaZGuFjGMUVXxgtnbkuiVJDcx0X78+rbbY5DK1ResssZ6vqCmEDmYwiRQ1h9+OTvDJ dEqF0u4qKV+5sykz3Z2S4ER0JaeofcznE2rWe1Vd8F7Jit6rT05rWc8VrDB+gMWUHrLvkpiyLGDe RUU1vlr5Q5Ga9WCJ5n6/KKr9kFDbQxZnxCr/oUqFRLUR8BA47LPO/xoCOJ+Ptt/bBZRZp7KaSmj8 QzjVF3S1f7Hjb8y1cW1ghpBDRqlDjPLymdJYaQwxSnSRUcoYcajmrw4HEerWn2v4z4kpF1PXOExh 1bXsTGe5HG0uhX2R9NWtbbqEvkZbbW49UtjA/Rvvn01ROp1EqjKpKQMl0pn0jrqZ1ppVGSufFdkU dptYyXqybsdxAOJT16J9opzOhgt4L2JcTDXeAVgLnP7Ux+lPcaQ/KfMgeNrYLen7r9Sf+C8rzSUG +Sc/llJowz5ywYhVJpXHI1Ca4PNx+hN8vu9iGKvA/ImXhz0VKTBuhvUtflDGvO9wCMt6oU3EJ4Xn 2uT/t9yCP9f76L3H1ldLKI3SbNSUUAJWbnlolDIhueWGHlZuuf93Ow4+WZBbqifrXEGsqLfAb6bC Atg7jOG8VAzuYiqGIIoo50b+oyBYlmQBZRZRoziMauTeUevRq7M4/GDMVgjibOPcTzYu1r6NC8YI r39AJz1cKLILHmTEpA1WLoPxUHoDRgzvKCc7SRxjowkq2GQlrMvoRdY/CRfxZLCspDBvupfNmyjw GuvPQfHWqLfHlmfAYJ06l8jnwF82r/J5r5RvfvLwZQ+tC4Q3PXloP7w+KS8JVHeE+2YyWkvt2ubK voxPL8avv+3fT04OPPzRvbd+xF4fnbxrd1/S0HXs+U03/+hQlatu1fajReUIzq4h7N8Yl8sCXGbg MgFnCXAZgcsAUJg1HfCzda9EweXCbCY7VN1hgKGqxfxcVGw/V6F+Lrqln6tQPxe9zp+Hc7fcokc3 6SXodwnNedrglfW80ZynbVn5i+gj2LCPYnjHvTSgVbDbZU87e/xUHgiL0yzaWcOFYnwt8HKggk3s E/g+5y5bih449t8sd/F+dRtZkLsohBB8PuALJYJPbkJyV1HvYjniVkbmT4CABfjNKBIjky86zRmg Ra1Yy/omtTY27B8eXASOQl2nnsMPYpJC5UhQ3EUJysPyuUEEuRg5Fim6FNkIi18US87T0j4ZmE4p TfGuWGayJSIVStjjtvr00MZ0AUuunn0Nr7g0lvgcIqVFo9BSco3LqWexZP9NT2xnsQRpanBMOIG4 BBDPYsOwykyoyoZBRAQrJYI6foSttwiqtwgcphkSgcsKvQp0MCjipwe+xYMCUS6yjIgq5khg7yxB d5ZwTRaCTvAMG2ERY7N0wf4t55qmnGvtcmQ4FTSDPI1STqUZNqxfGrBNl2vCBR/xF8AlNi4jGwPz 9UVvMEtPKE2RMrXkCf7PY9Q/KAHiApGqqm+WWS4Bgu1DN61LasxWOasBmmxuiFF90eQgswyjhpI+ tDHJx2qAaHOmCto5tHIXh1HCeBfyDofhrPtzjqI+YapQ2NIg8JYBlxe4PMBtAp4S4GQHKLceuHXA owUeDfCoAZxRoYldBHDxQaAEsKOVsjBaBbV6+EJro7jMfYWMfb95BmX0M4VCVH7hU8YM30Gh7oeO V8DfUNRTNIlQ6MgZdRan4fqZXxir+HACQN2Pz4ZHhX/N54fLL413XPDNAJcVIBClUdZOeF3qgef9 +rwQyPs5kjHVhbj3c+9IKRmBzmqDnxEqS5nFHrFQJ2jN/H0FCNxq98z/pRjIF8AJ2aJXIc8lT4kO JhGQBD/9gRP/v3NVBSXzXd7tkH9qsJcYmTcJvAk2ERKPHbGeLgxYSW5USiLdQwKbevI5WFM+WPU+ WOpD/cIn74zORg9GeVEzql4zql4z2+HMqMOZn8MrMAx+CjeXnmGzt6nyKC0Syj7JygFljLSs6gOb AyDJ9DzgHCvQTQBQb3A95uWx1wudp1C5qHYvzqB/X0VNKL6Iigru3fD12SraoJdLaaOSRjKq2Wir X78ooy7BZ0FGhWTHqaiQ7H6IFZS/j3lPsOT5y2cxGo5dJG0H7TRVmB//wA0u7FRLc+GL4fU/2La4 kw2PTOWLd1FUIZAvexfF3cX+tQRFYN5FoY4j4IIv24uWtYNl0tevWMlLw83Iy7JZsp8Jr785A+9h 3VrnQHFhSmatEOCiJReDJn+WTsnFNL2YUEmQcnFBqlziZIWY42QfXA6oxAVO5rRKWJuvspyM/vwg x8kvMCp/CJQSwM9GPi71AA8J6tFQYUNfux5OJ7LiTGK+LAJSkZbIdIQXiAA4pcA1DyaX2zDk1GSH kYJg+BRqsWk0b8Bb04hXlOj2XWmQSDem16V5rjRI5/EAIy93Azfzvs0mTHxQihBdxCE6J2Gz4jXK 5RsY4/Tr6PI2zLbiL6Z1JYpSV6C7tkwtRlKXxJfpqfgcUlfbMfy5lY/ec8OGtIRSKq1GrVFOKJQK tF3KGk6vO9Z7gdAVT0/Vu4NoJdWMv4y/SfwfXMgnIPV8BZY48R+BXcS/whIBV9KG/xRfz75HyJXU wruG2BIRV+LGf4SfIX4NS8RcSQN8z0riTVhCciUjsOQu9i4JVxKFd02w75Eu/lsv43ew75FxJfWw 5AhbIudKunly+DlNsETBlQzwDuD7+L+CJTRXMoG3gtWCrbBEyZUMwpJRtkSFSti1ix9/E29nNT42 UthpNlLYKRQp7HuKfc7vEZcvl/fcFzL/Ob40/E1vzxX9ffu7PL5udO303mIsry+LNpSqSsL1gWh9 QPn86K0zqfj628aHb5upSqy/bW3vbJ3Z27yhFl5NnuYNBU9aGOzCW5C69yxmB48/xTrS8kB12rSX 2M/tT2edacSl1L1dImUJimEkvE2uJAmcEAuf40kgsqkNMn5eiE4TCMRCfGeXECfRxmMZScwCPg7Q aUz0FG0LCXw9rJsEVvYsrJkPzgTtQTtWkcdzDCnW/cq3Txr7Hu+ywlavos+MfSTBeUreRXd5afH1 Uvl8qQT5xEUy8s5oxkEyaXc6aBPxxQKeQFmabvZlx2usstBAywxYIVXcZLbwpVqa0qpoye3hFUxC X16t1qoFCh2lLVEaNHJb5Yqgs6FvQ/1aNsJhLbTvEPwOK5B6FwQ/Y2SNLa7GSldjo6uSJzfkwV8Z IyZvLWW0xubSJ35i+Y0Ft1iI8Eu1+7Tf5UzPTlqB1N/f1ZU4n+gSy+SdRZwTIJrDhwKdOxrL25M2 5OkipQJbtM7f3qOPNIebRSTy+pDCht7B6owrG7HDpQzOI6Rl6WZPzVjGvKLD1xAzaSoHq21SmhZK FDql1qRU09VJc7mNEsghkqulglw6lFDpVHqzTCkTS3VquSnWFGheQ+E8c4RB46x7IYyfweuX7SgH 3yr6v65EGp0+9BJHR3vJ/Rdzfn2+7Vu8CvyMVLZbRLHNUTD/GAolgBNCATBDI7gMJp9Bulsin/89 /vGnOqPpzmJUqjv58MkVBo2aBM8IhLBMCKcanw18ZR6tiBugbVfiWUg8cbR363BRmwM/ZRSY3PFt tJv8l8E9+peWDPlZ+8g/F2VwEfbwlcHeHY3O2rhHyufzUGRIocGfLffWhvTqQFOFJ2ZUKlRasAMi HV8um/+fqpC+cUODI8JM1TlFcpok4QoMzoBChVKucCR8trBVLlJqQYdOLZLr5GbbUziwpvugdUbg d7sLttsQxmDZk95kHjz5FKnXk+V58ASjw0gsRsXwv8RA7PHSUsLxIr2v+jvLvuXYtuU63LJB60Id 7tzIgcVh7C5X66bmlVuYEqkl1rm1TVdeapOK0GghMrjC5srOCj2wDacbx6uNN8ltMU+ww6JyJd3e uEMRSo43+ZKrr+0Kr53sq3UTIqlUq6E1MkIkErprByJqs4sZyjjiTpVe3TCc0GnhYhnaMgpb4wS0 pRXzoshI7xf0N/AByjzJU/7SuEey/3OobxyT4BM8nog//xseCtJhsil4IDT/JZmUJyAF4M+QSwic L9colZK5L4vEAjgsykT4TqsJDowiQqbDWA3Oj98Ba9+KlWHV2NjzmAc8hlGYDTzGkEaJ2UjBH1Hw LDgJJ4skOMmYRIEoD3NSTvwvTuB8VLNPUWWtwheqQNWjPGSVsW3o/8/eT+7mYgPFEucIcuh07/LN 5OfsCsLvuOfG3MY239CgO+lRO+rX19evzlraW/rGHqnJMjUKe9S906DyZnzuuINq6WhvARs3o7jM Tav9tL+80l7WFrcYIw2l2UmXfxLUhcrCfq3TZqEq518weJ0Olcrm8upikXI2rjysiyOwLhCPZdD+ H9gSkdqWhi8YrVfBWBl8gQH/j71zj4+qOvf+XnvtmUzmkszkfs8kIckkQyYYEgwhQMItgYBGEBOD IkNmICPJJM5MArENCZdWEKrpxb6Knh493q9ULVZPbZuoJbVSq1XUWrWoRxQURKoQbtnnt549hESw 9bx9P+9fZx74Zs3a6/Ks33rWnrUzkz1Vj4mPkA9M7E76bcT4QBx9vy139P22Kd/060wXH3vfzc3m zNL69rqMi11Z2EbKJrM+uaA89+LLSlO4Na9ocvo8d2Vq7ny/CNSUfjkut2xCbllOdFRWaZ5z4V8m rVqxtHoCLoqNRnO0KTvBZDbmVl1REmmzGHKqGyZfvKKmoLx5S0V1U3lyQv7ktKzSnNhE7RsGg/IO 9gjmPvPxNOVptqkqMs6clhS304ANSvHkP5754+Tw/W3C5z7t9vjnbjGo3fkRkHfYTC+lZ2VlvGSK jjLtycjKSn/JbO1PT3nVaDIZX01JT0l/Wdwy++V0oXOD+qHczaZLFilVSqoySlER8cbHlJhHk6Ti Q2+Ib/f549n7i599nznBNu6Z3I0zTqwp2mJhhyxRY9MsIj0lJT05PX3kpEikpIp3jlaM7GTN8l5x pxZxL4r1dC+KPnEvCvbwk/GZps3SzBfG3IyCbnt99oZv4+9FsWJaRWW5wkxJ8dHx0ZFyTlmOLWZC aRYzWBJtMclmLv+y6+TGTae6xZWsrOiUGes3bJozZ/OG3pmy+INGgwneNMKbq8ibCeJOFOvpThRY dOJOFH1PRqcYNXfErSjO7sNGbzo3RbzOjr0VxVUxOWXZPDI6ISohycSnTZ06TZbNSbG2hCg9yy6b EPvcnE0b1s+AJ7K4sL7+xOaNJ7vE9wfhVVae2bthM2ajXP1C9so/1faFVTFxUobRmsySd0b3ZmKF 79RtRIhjUSO8B18f/Ocf+5K92fPW1M5vmZWZNWfN/EvXVKVst2ZNyc0pzbLGwlfH5EwLq1m0/soS V0NP/fzvNpVOWXb9/PKGivS08iXlc5aVxWdMWwKVLlJPsk3yj7AvTBf7wp1VRtoYnk7r1W0Yuyv8 h5/52mSwpcaLL5UQu0KF4WX2V0qkJd4anxyts4k/+ZbFTeOGL4ngkXE25BsVP5MZw8zRrrASwZoC ZaZIU8Su8PWnxK6wSGwLlSprpDWRJe509Foy8dK0k/cJlUpIprFvqf4P9ocpFuNIszla3MPEZPpe bkmGZYoruyw/BVcdOq6Lyi+rzoFCqbaC+Rdfw9KjLGVpydgfxkbHx0RHXp9T6pqYnF9ijRW7Iltc nDUuxpxaMqcga+bsRUX1tD8swjxbMZrLpOVif/hklaV20YTaigm1tRMquLij6t4qu2QuKyuwTmKT HpqdWcAKHsiMjo7LzNTN7s2MY3EPh0OBdkfF1kPX4d/Zd9QusFtU/sEvAKeMV+Lcr/+wX7Q6alfN yJ5Zmhutj4w0pBVWFuZclBkdkz9j4qwIo3af2OqaBaVT00sL0vUKNpWM64wTpszOK198cWpszuQM x/SChGeKFpSmR0bZrMkpqTHRtihrcpYNV+0W8c0o0bEmZXJRTrE1Nloxx0aZos0GY6zNkuycnpte UpBuUFIc4rMXcepJebr8A9o1Ttd2jd8/u2vsrYpJyE/NdDHXQ+GN43rjhnMbx+u+3c4xdszOkYud 43SzqS58w/iIkQ/Ee6JMidB/xqMSc5LS8pONdUbLZ/LQi0+npF0n3jcWt8G8TsFytybEWI3sWiVC uwHwSCiRzR35M+01vpBj5Rukcqn6Geki1rtrwsQJE82pT2P2kySziNz7cQ1gxRw+VtCTmcASHhpd 7uI17bp//reIeeO2kAnjdpCxBXW+qsJqVxoWmU6vj0zMqyjKLM1LqJ3vmppoi46NY5ebLGbzyInY Ymvl1dXZr5YuqciMtFiMiUniJmPmaLMltTC9pNQQHcdSYm1J6emp2xhLnlRLv439Qi5CNItdS/Xj uZPFlt6YkGDE5DyMsRlFEN/ncOisdma/H6eyclb+4IXGdt6+Uf7GfWPe2G1jUfasayrnrJienjH/ +mVxzrx0s3gbX1zxFKRcNLswlmVeUjR98eTEbcWVmdVp0RlFaenO1Ki9RUtm5jrrQ/MXfW/lVF2E yWSzWuPMSkSEPqN0bl5MXGbZgovKpsZGlywoToyxO7VvK5OjMYPpklPsFl8L7xbfqDJL8TprDIt5 LKnHJEIPQfe1HSM/exe2sTc5i5Zlg+44N8WKvxGyygrTjQyZLBYT20VfArXEEmeLMY6YxclRiTQb mJqSnpHETfFir5gLzUugeY50kTRbuuxZqZBtluKkCWyz+LxWlvZ5rZJfsYfx0lrJHqmKMRZdrLPm s/x7k3szq1n1fWMm4ML7w2/4yNbYHaK42ce4z2tNkUvsszxzZrmr7PF55TkZk7JjUqctn129rDyl tnLukjtclRUXlVXG5aZabdbsydmJjkxbZFqJY1bZI465JWkJzqrCtEmFedbozHxXevbMSelJzoqc 0kvSMxczJaewICezKNkYn5w68ofYjJSUKHNSamaMLSMxyokYzIEeduhRKD4V/Hiy82n2yC8ks1kq EzGYmJWJTfF9aWk6EYoP5NEp9IGvh+DYT2h9/aQ5/hdo592q3Z5Zu64xrbQwzYwrj8iknGJ7UXVh rGxfNHH6ksmJ2dUrZs6+ZnradmumMy2lMD3alOzIyJjNli/Y7K2IMJkttih7stFkRNzlx8Sll9UW urTQnHrxguI4m92ZklqQbrGpqlQur5O9unQ5QhG3TL0BORfJG9gmXTJy4sM5lfINcgqVSQjnFKGW lXISwzlx8gZ5ui4OOUnhnBKUidUhUpXkcM4k5BRRrZRwTjZqRVOZ1HBOLsqUUJm0cE4OcuyUI7aX N0hMrVPf4X5dmbif5zNSrDpAfwIRG/4biViD+G2+lS0y0O0KWbGTvn1s/E0qxK1ws3VRcWlxCakm buCbdVHxqfHxqWZuMERGRnCDuKt3pMGk5xFRcSb63aL6jq4DfeZDJyu8wE9uEt+LqTjYd/FTJ12l fqDLVqroLqPT8TrslZY9i1fmu3GNa2L3PhVvhNkXVxvZvbjQvwr5tVhhd0sJUim7u8pmb7hnkfue 2b6p96QW32PNXQXfZ75w6HVcfmjfk/T+6ILSVpPuvPHo/snW7Z9t7dgyvRAkMd0CQer10fHpEMci R5x5NmuWd3adZ1pS1izP7PnN01NuismamGJ3pUXZcOLLKcLJsSZrtmf2wubKJDt+zvdUpvbbUCSr KC3KmjkxPacozSwbjBE8wmwzKvHiI8t6sy1yeNbq2rzC+asqZ7XU5jsWtMycMtcRlTBx9sSLZhXY klxVI9aqlrEFVldNmZsfPaaA2PfMk1r5U4jLYinuicIJGU8z8xNmfUz4+ubs3YbPfz9r8rjvCc2Q +VN6Y5Rh5GmDLS0+Lt2GVKTFqNcbLQY232BLjxM3QkTKYtLJVbGpMYaRn4gb+OjE21mthpjU2Bjk IWWJ1ImrcByNoe8yW87K+b/x+XQtlP4LcSlkepYZJUWygd/6goj/W2L0GXN0QpxN/jImbmyac0dm pmNCdvZIg/hyx9zsbIked2nGir/RPpJXjrE/acbrLmC/UJaN2ilhunkXtId1D+sLYevOWURuxMA5 M5R/gz0uLPIqzYyuMXaLZib7Be1H5pxR2zbG3tTMMv0b7dGo2DG2NGyPXcBORQdG7RWy0+PNGkF2 Cew52PFzZmuz/eWcxeR/g62HHYpdHbZD5yzOFbb1F7RX4q8Ytb0J+aPWp1li8Tfa75MuP2fJjhRT ysGUg6kbNEvLvoDdm74u40eZFZnH7SezfnC+Za8633KScpImmCb8JffjvHbN8ivyP9HMsfesFXhH 7YCwwpUXMmeM8zZhEyeTdZ2zooaiT8aaq+vCVmyB3TcpM2wfnbOL/kuzkhWaTbZMTj7Pbi6tLptS NuvrNoVN+eGF7OLacvuoPTY1dtQC4+yTissq7p9mmXbdtD9X3lJ5dPqU6dunH5uRPeM/ZgzPrJ75 SFV8VUvVvuqK6h9XfzrrO7MOzZ4z+//8f7dfzf7b/9r/2r9ucyaQ3R62A3MOzO2C3Q/7fJ7tW9rU ee55W8P2yLxdF7SRmkvIfl87p3Z77Rtk79XuJztce2z+4vNtQeyCQwsjFh5Y9MSi//y/tUsMl9Rd 8tyl7kufr59S/0T9ycs2XHZ88dzFdy2JXvLw5ZbLNy8tWbruip81pDb4Gh5pzGh8+sr0K3/aZGu6 ounjZc0XtCeXfXVV29XGq9uvPnj10eUVy2ct33nNyhXJK55xP7oy0JzfXNz8cvMbnps9t3ru8jzk edLzrOd3npc9b3r2eQ54jsJOeRWvxdvovd17ZtWNqz5dfeXqV1uSWn7mS/Atht3oe/Xa5Gs91963 xrLm3taI1lDrJ22utqf8Bf4S/zT/HP8i/xX+a/wt/uv81/s3+X/9T+1l/8vtW2FvadYR+68ZfR5F ivuFxPh1ZkmKNNyHTVOM+gWYT6yQEsE69QDoUVeALeo+MKjeD4bUn0sK26HuAQfUt8Eh9U1J4YvU Z8GlUjTYKJnBAFqzSYr6GehRXwGD6sdgSP0E7FZfB3vFUeYgOokuYjmxhlhH3EEcIO4WLaNfpPlS 9b+kGHh+GKxAvzHir6NADy4OYnD0ODaDivoBWKEeBD0YVxI8+QQMqUfBbvV9sFccRfkXwUZ4m4Za B8EYlExD+4J10CFNWo5+01D+mJTGZPU90Aof0lgKekljGepfQYc6ADqJLmI5sYZYR+yhktuo1g7R PkaHftkgtTkk0tDwIykPnvwAjMG48mikeRjLj8E6Si9XPwS74W0evPpKyoNXL4LCqzx49RmYgV7y 0KPI2UY5/eq7Uh7GWwo2qjPBVvW3Uj70OQYGiSGolw+vPgQH0X4+lD8KDqG1Cnj1LtiN1irQzkdg I/yphJ9PgPmIk0p4+O/gcspvQTuVaPM9qZJ0q4SHb4Ep6t9AoVsldPsYdBJdxHJiDbGO2IlZqGRd xB6qtZXS26id7ZTuFz1C1bfBXZQzoN4ODqp3gUPqw1IltH0Pl4sxGNcMePsqWCElg3Xqa6BHvRZs QZTOgBptYEi9UZoBDw+ATqKLWE6sIdYRRb8z0OMT4KD6NDikPi7NwOqwSXXQ7QBYAcXq0MuLoFgX dWj/INiN2KjDPL4t1UHtL8E9mIs6KPwK2AjlG9CCD6xQQ6AHc9RA89WAuu+CvdC5AQq/DlrVvWAK RtoAhd8EHVgjDcxJdBHLiTXEOmIPldxGtfqhXgPbQflDgvBEBhtHToGt6k/AgPq81ETx2QQlD4Fi zTZh3j8CPZQOIvaaMEaUgSfvgD3qG+CAuh8cxNw1QSUQZw+jtBxj/AKswOiWo4WjYJAYovxu9e+4 AhyAkstR93NwCBouhyfHsfIVnLU88OcNMF/9HViB2PbAq93gcmjlgaVJHqiEklDpUjAFs+yBbwvA eijsQaRtALuIPZS/ldLbqOR2Sverq8FdlB5Q7wEH1YfA3ep94JB6N7hHDUge6OYCG9TrwUa1DGxV bwED8KEFPr8GVmBFtNA5rQVl3pGCyL8TFNoGMZaPwQqsrCDG8hG4HBEShEVKQYzlJtCq3gamqA+C GeoOsF69A+xUXwa7iD3wMIixiPQ2Krmd0v3wOYixiPQQYikIzx+TgvAH8wfPfwk2qpPBVvWnYABr KgQP7wbFOgrBQ8EK9QGwjtJC7RDNVwgePgNasS5C8PBpMEPdBdarfwA71RfALqLwMAQPRXobldxO 6X74EIKHIj2A+AzBz5ekEDx0gI1qCRhA793wZwjMx7x3wxORFuftbvT7Opih/gWsR7R0o6+3wW2U vwOvBd1oX+QMYG12Yzb/BA5hHXWj5Z1SL8b7FRiDueil14VetC8YUk9IvRjjMdCKeelFX4fBDLTZ i14+BLdRzgDmuhctvw0O4QzWi5ZfYzLOLV+CTqKLWE6sIdYRd6iHQIwdHFSPgrspZ0h9m0Wjhc9B J9FFLCfWEOuI/eoxcId6HByg9CBxt/omOETpPep/MSvG8jnYA2ag5cOgk+gilhNriHXEHepXoGgz g9rMQJvvg0Pq38E96mfMwcS33zqgz2tgivoSmKH+EXTQUSfRRSwn1hDriPXqC2CPuhfcRnX71Y/A AckCDkp6cEgygtQXomIj2KiuAwPqi2CvhDGQD07ywUk+OMkHJ/ngJB+c5IOTfHCSD07ywUk+OMkH J/ngJB+c5IOTfHCSD07ywUk+OMkHJ/ngJB/q4cPbIOIETMEM1sOHz8F6KRbswczWo32Rj5hk9Xjt SARbpfmsieKkieKkieKkieKkieKkieKkieKkieKkieKkieKkieKkFb2/C1rVV8AU9fdghvobsEf9 FbiNcvpRvhXtHAN3qftZK/x/knVS753Ueyf13km9d1LvndR7J/XeSb13Uu+d1Hsn9d5FLXRRC13U Qhe10EUtdFELXdRCF7XQRS10UQtd1EIP8o+Dg+owuBuz2YP8r8A9mIseaP5XtpXWwlZaC1tpLWyl tbCV1sJWWgtbaS1spbWwleJ2K8XtVloLW2ktbKW1sA3zYmTbodsboFX9AExB/nbo9hFYT+ke9W/g NkpjfwUOYDa3IypMoIiK7fCtHsSZCgwglvrh5yHQSXQRy4k1xDriDvUAOIBI6CcP++HhQRBnD3AP Vt8O+PYxaCWmoPwO+HYQ7EEc7oBXImeH+iHbgX4H2QDKfwCK8gNilwhmEB3wdgA7BEEXsZxYQ6wj ivEOoOVD4Daq1Q8NB7BPMIIDkhkcJA4R9yB+BjB2N9ioNoIB9VU2CB8OgFa0MCjOlmAG0YF1NAgf BF3EcmINsY5YTyWFD4PivAr2E3fgmmSQfBiEDwZwiNJ7MOODpP8gfED0wIe9bDd8+CtoVf8M4tUB zFD/APZgte4WrwtgP2JyN1rWg7vg7W7UfY4Noe77oBWjG0LdT8AM6DkE/42gk+gilhNriHXEeqrV Q7W2EcWKGyINh8j/IfJ/iCJniPwfgv9+sFHFaxK9auwRe2nQSukUjGIPfBB0IE72IK4EXcRyYg2x jliPNvfAB1F3G9XqR8zswRjF0QHouUfs/MEh9TDOQYq44sI+OQH0qN8Bg2onGFKvBbslI1+KGNuL PZwimcEY9W0wn1ghxYLYFYAedTXYgjYb0YIPDKkdvBE+vwU6iS5iObGGWEesR++N6OV1cEB9EhxU nwWHKL0HPjRCmZtxrlTUZ8AK9a9cnPEErcQMYr36LhdnPMF+9S+8lR8b+QQ8rs4Ch9UI8MTIcfDk CMrzU6oePD3yMXhGnQmOUBlVTeatik7UVfSirhIh8hWDqKtEirqKUdRVTKKuYhZ1FQuViULdgHht BZ1EF7GcWEOsIw4Qd0PJgLjy5evFGQn0STP5Md468jw4rB4Cz6j7+DH4gDT6EmnHyEccvowcBs+o n/PjyBd0qDP4MPLfA4+px8FT6jB4Wv0SPKO+zIcVnciH/8hXTCIfdUW+Q53HT6DuIHhGfZWfQL6g QzXyk9TXSX5S0oOn1BHwDKLiJLRCWokU+WhTpM0iHzqItAPKnELd/eAx5JzCXHwJDmO8p/gJSp+C P6fg4WlQtHkKbSINP1Ee+qMMxo7yioHSRlEenosyoq9T6EukHSNf8dPYx+rB4xIDh6HJafQyAp5S VfCM+gkofD6t6EUZtIwyaFnkGEUZtIky5P9p+F/Az8D/fvCY+gF4XMoBhxFvZ9Ay5oafRNyeIU3O YBRvgWckKziCdXEGfeE5xoK66BF10SPqokfUVSJFXdLtDEaEuopZ1EUsoS58EHUdI4/yEYxLBocx ayiLCB/hIxJy0Bpy4DNyFAvlONQsrsLnP4HD6sfgSbSvotbbXEV55KBf5KCWyHGMHFF0ItJARJqi E5EGItIUvYguRS+iS4kQEQUiokBEFIiIUiJERIFGkS8iCkREKQYRRYpBRJESKSIHhEogZhlURVpE DmiktFnkC+UVo4gWENECIlrAE5RGtICIFlC0YxTRohhFtIB6UUZEC2igtFGUF9ECivaNIloUk4gQ EBECIkJARAiICAGFbyYRIWCEKCMiBDSKMiJCQOGnWUQFiKgAERUgogJEVICnqAyiAkRUgIgKEFGh mEVUgHpRV0QFaBB1RVSAQhOziArQLOqKqAARFYpFRAKISAARCYpFRAJoFjkiEpQoMfsgZh/E7CtR YvbBSJEjZl9x4Ax5ADyurgCH1TTwhLoIPDnyOXhKnQueHjkInlE94IhqB1W1QnHgDIm60Bx10TLq wn/UxRkSdeE/6uIMibroC3XhP+rC/wpluiK+hVCSimTxJiyn92E9RE6/zYyiZ5z+NiyKK+E0lybx mHBaGVNGJyXxWeG0fkx+hHSSN4XTBqmQvxJOR0p25fJw2ijfOVreJF2hhMJps1So/CGctsi3Kl+G 01FSa8R28ftWepREDIfTTIowFIbTshQReX04zaWkyA3htDKmjE4yR94WTuvH5EdIPZH3htMGKT5y XzgdKVmN2eG0kdWPljdJTmNJOG2W4o1Xh9MWttAYCKejpCmm38ATJv5GKzxakdZ01tKazlpa01lL K2PKaDpraf2YfE1nLa3prKU1nbW0prOW1nTW0prOWlrTWUtrOj8oiXvqT4JNQWqR5JOapYDULgXx f5UUQt5spAJSB9GNHB9SfsmFI9VSK8wuLUbeaqkFx4L0zIufXpTuAj0oORv1WlFmJfJ8KOGjcm78 b0NbHirrx7Mg8vx0TKvvgwd2/HejnA8tdOPZWqRC6EuU6USLIeR78Uz43InaHhz3wxvRSnu41RBK tIX7FCXsGGM79Sl6CdJY5tNYVyFHjLET+V6qEaCcVvI6FB5HM45MpJbbKKeVWnRDIy3/bC9taKeV FOsIe+lHThv1qrUpxhka44HosYPGoul9Vm3Nd9FTOxSwY/ya4sKrNpR1o/8QPRMjDo3Oh6aZ1oud fPeHx9VO2q6kkuc8Hjsiodo6qqeNeg2euygexs5mPrXWRi10kw6d4Zkfq7eYMW38XvJfjF+blwBF g/ip9Sjm2o42OkZHo/m4OlwmiGfXh1sPYRTaDHWNzpKbYsSN3LZx4zobzc3wxE39N4f7d1HErqa5 EkfOXwMV5426YnTVlElXhKPIF463MnEXetiFo94bjl9tNO6w/6vpqOaPN6yY8NFDkSu8WkNzdrbO hY+u+h+t4HPRos3NUjzzkQ+i/yUU7aFx81gc9qB9zAiaw+suRKP0UiwvRE6z5KA5LkAZD7VfQ15p dUOwDqhYDFtL5qI1Pt5zF7XehjIhxJbwfzWNoAMtdCNXzOAqGotYOeNbPZsvzh7aDKwZbe9K8lmL 2m6KtiB5GKJ1FaTzgFbbTmMQa9JLEeWjPjSFVlLds+rNhX4LcUbU6gbGHNHWs4c0ObdG11JfzbSG L9Sv9lyUbUYUdZKGntGY99DxDorY7jFx3kEj9YcjXWvLSxQr9+vjFse1M4QDtQooOtswLu/omj3f K/95LX97jc61fvYsbQ+fZ7XoaR53vjt/7Ofidbxf08YoIEaijUU765+N+sDoK4iHzqF+Ope6v3Gk ms7ucZp6w9H/9TUgVBWR10k1PXQ+EqPxjrYjSrbSOe0fzdD/q3Vxbk0UkzdiDWivRC6aqw5p3YP2 kkmTptgX+ZoD7cH2VSH77PZAR3vAHfK1+1326tZW+2Lf6pZQ0L7YG/QGurwe12x3q29lwGf3Be1u e1u7xxvw24Nuf9CO475V9lXuNl9rt32tL9RiD3auDLV67YH2Tr/H518dtLejaMjbhpp+j725PeD3 BoIu+/yQfZXXHeoMeIP2gNfdaveF0EdzcKI92OaGB83uDqRFlbbO1pCvA036O9u8AZQMekPUQNDe EWiH38JttN7a2r7W3gLH7b62DndzyO7z20NiHPAMVeytPj/6al9lX+lbTQ1rHYW860Ko7FvjddnD w8wP2tvc/m57cycGr/kdakH/3rX2gBtjCfgwbFR0t9k7O0Q3aHE1coK+61E81I4BdYkhue1r3YE2 rS8hc3OLOwDHvAHXYu/qzlZ3YHQGKs52XSGmpuwKSIRB2ctckyaNkd4LfdGNG+2v9gk/vHAs4PZ4 29yBNfZ2cWTM01UXnmCSBaNZ6veFUH9JyB3SxliMBtqpg2bMXSjg8wZdCzubHe5ggd3jtdcE2nE0 FOqoKC5eu3atq+1s467m9rbiUHdH++qAu6Olu7g5tKrdHwqGi4r0KjcGsEaUu7K9E9J22zuDXjiB IYnDdjdm0hto84WEQyu7yb25SxdW42iAnmCePZ3ajK5t8TW3jKmLnz5/c2unR2jRbvf4gh2t6EBo 3hHwoUAzSnn9IZf9bN/tfgSEw1dg97atFJXONeU/W/iCHlFxEdKQPwh5mrW4G+2ddA23NY0ccPjQ C0JfSB8QC8TTvtbf2u4e2yl8dmueQvjRGWjvDHV0hiB7l6/ZK8q0eFs7vjagbzMXNBPFHu8qNxaR yx3sWDd6PSipSdL3pQs9GErgikKKlSJUFdeRcvgqSmIO/L9K+zzMP3goSrXZzFBG3vxty1ssojzf 923LR0eL8rrKb1veahXl9bd+2/I2mygf8eW3LR8bi/L4KYmrSoXKi6vqy4g2ySLFSClSEvbLaVKp lIedQr50Ca4WluEc3YIzfqdUKW2UZkg3S3OkO7CbeFCqk56SGiTxKYFXpOXSuziTH0TJ41KQKVKI 2aRulif1sslMZlXifUpmZY0shTWzDNbBHOw7rJ5tYU3sFnY1+w/mYztZK/sNa2cvsU72FutiH7Ie dphtZSfYNlnPtsuxrF/OYDvkArZLLmMDchUblOvYbvkqNiSvZnvkEF8g9/JF8na+VL6NN8h38Ub5 Ed4qP8H98nM8IL/K18tv8l55P98of8U3cYXfxGP5rTyd384L+We8mh/il/DDfBn/nLfwI7yTf8E3 8qP8Zv53fgf/kj/Iv+JP8eP8eT7M9/ATfK8ylb+nTOefKtX8K8TFmfHaKuxf0PZxaPsbaPsStH0L 2n4EbY+ipAptzdA2Gdq6oO00aFsLbZdAWze0bYW210Pb70HbH0PbO6HtY9BWvP/3B2j7FrTdD22/ gLan2VY5AtrGQdssaDsR2l4MbedA20uhbRO0XQNtu6DtJmh7E7S9A9o+BG2fgLa/hrbPQ9vXoO2H 0PYAtD0BxSKhbTK0LYC2k6FtNbRtgraroW0I2m6AtjdB29uh7QPQdhe0fQ7a/gnavgNt90PbI9D2 pDJdiVaqxV+6KBPGa2vIHaNtIrTNhbaToW01tL0U2l4NbddA225oewO0vQXa3g1tH4e2v4e2b0Bb 8cmVo9JyNOdhUVILS4O2hdC2Gto2QttV0DYEbfug7c3Q9nZo+xC0fQra/g7avg5tP4S2X7BWWWbt so11ynbWJU9mPfJMaFsHbZugrQ/adkLbDdD2Zmh7O7S9H9r+J7TdDW33Qtv3oe0RaKvyBm7gjTyO t/JU7udFPMCr+Ho+j/cidyO/Ftp+B+pth7Y/hYL3QtsBaPsytH0H2h6EtsP8C0XPjypx/O9KNv9S mcS/Umbw48pCPqxcwU8oK5SpyrXQdhO0vRna3jpeW/Ovx2ibDG0d0PZiaDsP2i4VnyWDtmLfthHa /hDa3gltd0Lb30DbN6HtfmirSk3QdDlLh7YToe00aLsA2jZD2++KT0yIzzxA2/ug7VPQ9jlo+2do +x60PQxtz7CrZQvzyanQdiK0rYS2C6HtNdB2DbRdC22/D21vgbZ3QdtHoe2voO0QtH0N2u6HtkfZ Hs74Am7hi7DGl0LLBj4FKor3geZD22XQ1g9tQ9D2Bmi7A9o+Cm0HoO1L0HY//0zh/JASww8rWfxz 6HhEmQltL4G2V0PbVmj7HWh7I7S9DdreC20fh7a/hrZvQNsPoO2n47W1PTBG21Ro64S208RnEKHt Mmi7Btp+H9reBW0fh7aD0PZVaPs+tD0t1bFEqYGVQNtZ0HYxtF0JbXFlz34AbR+Ats9DW/EZksPQ 9hSzymaWIiezDLmQObC26+Va1iQ3QlsftF0HbW+EtrdD20eg7SC0fRna/hXafgptT7F+bmA7eDzb xSewAX4RG+Qz2G6+hA3xFdC2A9r2QNuboO2/Q9sHoO0uaPssVP0TtMU5geOcwM/wjYqNb1Jy+U1Y 1bcqc/jtihva9kHbfmh7J7T9ObQdgLavQNt90PYI/1In8a90Vn5cZ+fDuon8hK5cmaqbo0zXXaNU 69bgdTU0XtvEtDHapkNbF7Stg7Yt4nOU0PZGaHs/tH0B2u6Ftvuh7XFpDjNIc1kutJ0Fba+Bth3Q 9gfQ9mfQdqf4tBS0PSB1y3qpV05kslzKouVZ0PZyaLsS2oag7UZo+xNoey+0/SW0fRHavgdtj7BO LrMunsx6eD7bysvYNj6PbecN0NYLbYPQdhO0/SG0fQDa/hba/hHaHoS2w3yRYuRLlTTeoOTxRqWU tyrTuF+5jAeUVXw94q9X2QBtfwptH4a2iFtlD7T9lH+mM/NDunR+WOfin+tm8iO6ev6Fro0f1a3n f9fdDG3vhLaPQ9vnoO3L0PZtaLtfma7nSrXehj1IithPGSLwz2p1OOZ8d+NGg44ZIvb19x/ZsmXL EfFE37GlD48tHQY9MxiObNmMB44oOHKkrw//+sY96aNi5XP6+u7YPKecnqDCaVHLwJhB6Qs/DFwy KHbtMUD9bOm/c+DO/v4tojVduNQRg4EZjM8/fy8et91Grb3wwj33/OQn27fTk3Wb6bGOGiCXRdNi CPSkfwu1pl/R31dlt/avMOgkg3443OtZ37QGhAYbN86Z43BYrQaTZDBttm+2L6haUHUZzN5nx7hQ d3Nt7aRJtbWb6clpxWC1V/Wd1uuYPuKIYd2WLeRHBNzeInrXK0yv6xDD6KB8gyiCQlS+Y8twX986 gwIVJlUdqRIPFNLr1/X3r+jr0KRHSz//vaiiKSdpmhi5auB2aVQ7McC+PiHenf3jJNYbmN741Itb 8aAutbbCveMhvNJHaL6SavoIzUGDuL2AXtmntYJR6Dv6BiZZ90UoUoSiOTuJmhGlb23R6yS9bsuW +nq7XR8p6SO39G3pW4qXkGyYdgxH6rcYzhWrqhId6PYh0bdvjM9SH41mn9W6oqpKquKyxP6bt3MB j6o6F/bamWTuCVER03M4Eq2nJdjWaK2mkuKASGnKJYCiWJUAGiogTTmAEQNMQsCAlBLAG/dLDJBY LwQUrKZDCYEQGsACiRwwIYCTQHQ4/hyIGrP/91t7coFS/8ee03+WbzJ79lz2Xmt977f2BNey8RS7 Ydhtfhnd+g1uNr8nSrminM7Y2Hh5L6rEiJA6aLsZNpRR547gfWWv3Hw+vSl35Ca1KP1P7sp2vNsm e+We3h0lHSV+U8ameKeDXkKTJw5fuHCKy2U4PTeqm9QQ/xL/en+Bf4XyYRjdrXSV6kplI22tbpzm 8B6ndJT2jQynM/y0xMTU1MXNdDjdL3V3D+9J8ulOZG006zOVDmJ9Tkb7ngzdXLF1kRHKafMFfL5I OS3qtc6646N/OJXTNXbZsl93S0gYwHnZ7RxXfLwtSkXZm1XzNwQ/8eGQQPb7w4H8zwt+x9WDX6p7 p38nVb3ev4wiPetyCdA6rqT+Odz4vPa4/9+SgPdvJKCf0Z/dPfvn/D0JuKIMl8Pf2QJ2ywJ6h7Nd A7IjbfF52RGpXGjgah5oe7O/I4LIDhG4Ig2XBIFlApdhuNrr+3+kArHYW4ErVKDF5bu6C+zf4AJ7 hwvsV3FB56NWfn1GaYu/rQ08RoSrkw3COvBE8NZtOiDS9XabD+RVNtrAin5tBI9N9vs6K8FlKcHl MFwuUcLYJTjB7Tac3h4q3j/Et4Tyku8FDt3HmEP3wA4rsNFhBb2nzQrWRtgKbHRYgY0OK0g0tltB 9rRbwfqcjPY9bVaIilBubQVflE25IwM8uy58j+J0IYYxaolaxtDJo7r6b/HfpxxRymGP14aIj5RG alaq2eVSLpdTdaVIO/ZVs3UPdNkNl1OOp5ngaZZacSb307XbL1nXUXOuBGYO+6QTN/stSXRsNet3 kWfK6xbl5IRfJy9qlR+Xd2KJkqjY8K1Of3qu5Y28XHnP9jZvdrkNlzfAbZ1vnW6VJb6FFJfTcLl3 rluXP3/+3Llz9FZyv2y58cHydvpE2k9Nb+XhPH3AMgzSbeRyKJejte042g9YK0jXlLxBX2pJ6krq zKlcHsMVLS5ZELbJ7X6xCXXqcmb3u+WWuFtu6ZdtvW+E5ZNWR5ThkG6RSVC57YbbyZtuL+OIyrbL LmtUlpehd0VGRk5dyK6FUx12wyGDoha/P8sdqdxR7VLx8UyHI0v6iJ8nZF72npyirumwWPxem+nq MAtucUcZbrFQuLrdhuHuaBe/w2U4vCVqv/azVfSBhN+77aByrY8NP162XRQmm+Fj5ywckYYj7Bq/ 3BdvpklbS8u3nUmifj/9dpywVJOIBJM43Mrh6e/r7+vll3IN1wfWbnampua5Oz2VsNHvfz5WjHGe 8YO7LetQB/psJT4T46USSK4RkaIAh2E4OG0xj19PmOX3R9uVxx4Z2ck+MYbN4/BfdjNsRmRUXbTN cEfFdzJQvH5E7lg3dnkjDd1mYQn5Er3SiAHZG2u1RJQcm9aQ22m43Un9+zM0WZA771mP9LEufl4c //P4+fFL4pf4fqdNdK8K99+wivRWWEXxzeF9+gR8HVtWTycKHHE9ew4cmNfidLaFLTpyht8FH1lC 0s9s0dXAcbZ/Xkb7PktJlpM8kZaTIpUnqo5PPR++lxZb53Yrt2eMytdWekK5/G7ftb6bfTf5HdYw JVbiLtKh7I5WpVrdLuUmhjrMNJuo05nRYbhdOnzFQC1SU64+fa1679tHV1xLjg78bPZKJLS06ahF N367nfz6yfq1v8/ODr9WXmfqV18RCDrkYtsVpd85t21okyubHT2jxe0x3NGBtEDaWm758fnIYUG8 SEJ/hmjK8pTbZbg9fcJn1nbrS4LRby9naTmr/aSRVm5uTrgTSwBJe7kdyu1st1Zs+3lY9tM1+bfe cio5yJjc+LZxUIe73Oyz3KXlZb29yMuylxXykVmEqMdueMQ0nfXlCOtL74u8ur880iskFtoE5mDf LJGIn6Fq1uVv+/80mCfKsMIyrDCPYXg6tdw/yWFyqpk6b5z/ZzuMUY+nzWFSDfqEJZT/dy0WYzM8 nSwm9tIPdWhMdsZEGlbbtYnMlxgjzalNFlZZfIBxo8eJy5CZx2V4PEmqP2WgSlTD1Hw1V+VApt/r pQt2CSTG+2IHLJ6/ePHi/Nil8QsDPpWmevh1DIS/BZCmiYpwO+Pb5Rbeq88s3tfSvplJO4VTYFy7 3/RmFofaaW+yL9y/rM12w/naPzczt31vZrgLOM87bMobGT4KLpq9yE1edL7tvuS0b1Sds0N1Dqeo zuNWHrf8/9FSbqL4/LP9HBzV63EYnnDca9t5nGzfOMZqId+YG2Xb3TzP8l3OvGYdOOK7sPA6tvUP v26KHirN71P0I/V76338af4eSu/q6BFmp95xZTzp6I3tcKE+ypz28VqOfGqnDtbiiTY8XQJxgbi1 Pdf2XDxw8UDJVXOdc505Tv2pAf9aymJKnj+XkkPJto61uxp3mR37st1dhatFjz/1AbVtW3rUB0CT cWqJTmlvj0N5Ogky9opz7XjzPko3hlQ9//lv0s0hzeKl6NPI4aDvj7VKTzmftbG+WJ/HRf3JG1h+ dbaPpjk2J59tGm36NMPfbaFPOpTXYXi1m7eXySCzbPtlF+Z6bwS3ewbI3gH3hC/BRaHsjaLDJXU4 VDqLs0OiOVlXvHlOjpXR2msz2ma6O3s0PuC1G17t3bam9BqGt3PL+50ewxmzI1Aen9up6Cv1tg+5 7LLd07FH+1Rvt50NJ6Yv3sNC9YevbySpkdNIcXafr9k6tST9rtYHUA0SRVe9lm/zqvW9g5gUsXo6 P51YbbvCImr9zV4jwttxQUnd6DrIyMMTV8rVaUTI9xeqs11jHMrriIho86u4s4thsyqx0w2/RkXV dbEZ3ij9vZR1k+tP/Zi+1yZYn79LJI8l+i5TbBfRi6XYzo71hh3rdRter+XY/qonlk0llsSy96nk QLR0XEcgLjE+9ucDB+4lAvMW5+UvXpRmeVZHj9VibY3mcSWmLg4HS6vezsylufT1S8c2ro2IILpE St6uXW/p3z/XpN70fku2EXq/bFu27Xj/1nCdcS7tn9/f+tFxPNJHIpsxbnSHcY1oe7txrftiXI9H ebwZvjz/fLWAMi3gjnfHXxt/c3zfwFWd6/UorydGxah/1eV2/+3+tMBsRmwyaPM6Da+7pby8vKyl fNeuXeUtXhcP9FAZ/jQV6FTSeKSH0lXfqnb5d/oDnW47/bv8rUrHYKtst+hHWzseaLWep1/ew5/h s957T/jlaYGMQA+/3tnxnmbnDwh4I+i6lz2AEexx7bdXMvSJ7Crfv7/mfE3N/vLyXfLpzk6vaPXG GN7Yuu513c8nH/xBzaSaSXsH7d9ftnDPwl3eXV796XWB84GDgRrKfko55c+BXYGdAa/H8Eb3UL8N 11lbSQv8NkCdWDWoK886NKnBFlWudulSruS+tbXTr+skOT0QqMvsHmO378/0OpXXZXacSdwV9dBx G+O/V+m2tD5birSl1arSvt4uhveanfad9l3zxi0ctzB9f/r+u2rufDg5My4xLtGqn13p6clxccnp 6bt2eV3ywX7Db1N2ilfF6X9kK01jWt9mZJXb7bPKy6umRzuNaLccwvFPdsntk+PWtyTp+rjSk/V+ G7fe4/X+8b3lSwlOs7yclh+bHG2n9yanpaU1p4VvXtk/m25XnhWYxStmXfkRu3ZFRxjRkYGAUu0V EBtpRkclJiqV2HGri3YY0S7ZW07Ln6/Zv788/MJON5fXcHU5XhdMLL+s6G9O2j/P+h4lXd9PT/Z2 2vfJcWlVeaD9/DhXfXVYU9f2EfJNS2aZNKt3YaYMWu0dp5uk3zv8OVSOfLsi3wePU1LuonSnuGL4 T/riuLjxrzzxyp1vJZ+PS4tL09+u6HaTZvNe/bVxuvX0QbR44+IS6R8t0RER0Z1ihnrUdZW50G63 e5OoO+oxymZERHGEAT/J1xUl1a2kxiUTs3WNQ8U4eLaX94yT6panBmIjbFaVd74ZkUYUY3jxlPUs 68bdRP2gvhe+yf5Yu4q2d7c2A+E93fWDdfp+nDcu3MIOp4p2xT1ixpmPxEV7jOjoPso6+XSVrJIC kwhTEdK4QHJaDCF+jaMuLikxbvykSU0E+f6a/R/VVGVogfmQjERBuJHb2tnrTsqsaYs+Uz+QVU4D c95UZMcD9mQ7j5Zn6fiOUTeqblT+9ziKAUS36bdbYSTPniWNnhV+tjxwo26Q8o5PNG3SCFatth9T uj6w8DP0/XH3ylE0M96Oicp4S1cHmSBGV1Fa4HzbfaqvjssLb0xGfJ7OC/PVFBVZ54p1xV4Te1Os r84l19Sx4cRAZjAcLskM4X+F5VaTVZmyjXt2yiTVdfyUJyeqxEljpk6mdt3KGDG8XzxDPJkjNcJ6 PvcM7stfrq37NhWrIoYPHRyv4h4Y/kvGEeHHI8O/o8K/7coxLuM/MtQPJj45ZbK6Q/9M0j/76J/9 9c8U/TO1/V+IGfr3N/2M0P9nj7XFkTAkNdSPwM0n9+Sd5FgjGR+oiMSIVDU7oiCiWq21rbKtUoeV sfktOc6IzMgvr1YciY5E9xLv2o4SXWgV2XNlicm79q72cpxy8dqL1z163aM3LJHyL+9fWRyJ/7rl xr09lljlptyOcvNqKd+Pu2pZdGtBW7lt3x2PtpW7L1rlnoV/W3oX9i5MXvazCR2lzy1WkT1Xlj7l 9za1Fd+Qv1Me9u3z7et7Qcrle+773tVK78L7Gu6/9v6tVhnwRkf5+etSBhZdtZz/xdm2klLzy9Vt ZdAmqwyefrUyZPuQ7anuYVmdyjF57MoyPDLVneoeHimveeBHUh7MaivWO408NvL0yIsPJT404aGC hz4eeeyhBilXft6oflcrcgyp7lF5o1Zb5ZHTHUU+69G75OfwSOGxhaPPtpWxA8cVtZV0p1XGfzz+ 4193hX6UrF8X/rqO+4W/Lnwq4qlBT72kS81TF5+6OOHOCY9TnpiQM2E75EwondAy8R4pE3ImZkxc QHl94jsT35/4ycRPJjknDac8MWnypFfC5b2nb3l6ydPbn/5kciLlnskPTJ4+ednko+HSMPnz36jf 9KEMyrgxY1nGRSlTtv7HWClT1dT1U/eHy1H5Z/f8vqC3LkzrNa3X1P3Tlk2/ebpv+tjM+Mz4Z0tn PDxlq/Vsfl+wnjXjM3nejJbn7nlu0nOrnyt77jMpWclZObpszTo2M27mzfzeOvNOyuSZm2a+MfOw TLA6K3XWcp6XPCswKzDzTn5+LvdmBWZHzr5x9qDZ03U57x+gS6Z//cw4fmb69/rP+vfyjBuzndk/ yr4zO4eyN/vL2ed57l5rT053/96cfjmD5qTPac5dMi913iPznlhwz+/65xctmdr2e9mQZUNeiX21 /tULK7qtiF/x+Ar/igUrlq1Yv+L9FVUrzq/4cmXkymtXxq+8a6Vv5ZCVj64sXLl35cereq66a9XA VbNWvbLqw1VNq3utfnj1kjXeNX3WTF1TtOb9NfVrWtb2WZu59r11d64buc6/bvm619cdXdew/tr1 j65/af35DdduuHPDgA2pG6ZsyNqwekNdwbUFTxTMKnil4MOC0691ey3xtRmvbX3tYqGvcEbh64Vn N6qNd218YOP6jXWbvrdp6qYtmxo2L1C/0/PtXQdd4XroBjeAzMDXExKgF9wKMh9fb5C5xQbBYBgC QyEVhsFwGAEjYRTIvH1PQrrMLWXWqadgAkyESfA0TIbfQAb8FqaAzPEnM/xNg+nwDGTCDHOCeg6y YCbMgnzzkFoCS2EZvAgvQSFshE2wGYpgB9ngPdjH/UrYD3+BKjgAB+EQfAh/hcNwBGrglPmMOg1n IEh9NEAjnIVz0ASfwmcQgvPwX/C5uVr9H3O3ugD/DRfhEnxhrlRfwlfQAl+bK2U+Q2MFrITVsAbW wjpYDxugAF6DQtgIm2AzFEExvA5/gDfgTXgL3oYtUAJbTZlR45jMl2jshQrYB5VmtcyeKHMnysyJ tkfMX9p+ZW6xPc7v0fyeYv6XrVTdrWr0jIRRYAcHOMEFbvCAF6IhBmTewuugK1wP3eAGkBmrekIC 9IJbQeY1HASDYQgMhVQYBsNhBIyEUSCzaI2GNBgDY2EcyHyIfsiGHMinFy6BpbAMXoSXoBA2wibY DEWwzwzSK4L0iiC9IkivCNIrgvSKIL0iSK8I0iuC9IogvSJIrwiqE2az+hhqoQ5OQj2cYt9pOAOf m8foAfX0gHp6QD09oJ4eUK+a2feFeYRecIRecIRecIRecETPpGKDSIgCOzjACS5wgweiIdY8bVwD 18J10BWuh25wA8TBd+BfzHqZb8ToAfFwE9wM34Vb4N/he/B96GkGjAToBbfCD+CH8CO4DRLhdrgD fgx3wk/gLrgbkuCncA/0hmT4GfSBe8EHfaEf3Af94X4YAD+HgfALSIFfwiAYDENgKDzIuYyEh+Bh GAUzOe5ZMBv8kA05MAdyYS7Mg+chD17gNcvNBqKtgWhrINoaiLYGoq2BaGsg2hqItgairYFoayDa Goi2BqKtgWhrINoaiLYGoq2BaGsg2hqItgairYFoayDaGoi2BqKtQebTlNk0jT/DLiiD3bCHx/dC BeyDSvOgnmlzjp6tNArs4AAnuMANHvBCNMSAzGn6JKSDzOAo85pOg+nwDGSCzHI6w9yDO/fgzj24 cw/u3KPnPfVDNuTAHPO/VS7MhXnwPOTBfFgAL8BCOGVeoHdfoHdfoHfX07s/o3d/Ru/+jN79Gb37 M3p3Pb27mt5dTe+upndX07ur9exmCdBL5iWDH8APQWY6uw0S4Xa4A34Md8JP4C64G2QutJ/CPdAb kuFn0AfuBR/0hX5wH/SH+2EAyAxqA+EXkAIyl9ogGAxDYKjMUQUrYCWshjWwFtbBetgABfAaFMJG 2ASboQiK4XX4A7wBb8Jb8DZsgRLYKnNVyfxN5n/JLDr0giZ6QRO9oIle0CQzL+Lf07j3tOqrunD1 JfOt9oQE6AW3gswz2xtk/tVBMBiGwFBIhWEwHEbASBgFMh/tk5AO+XhpCSyFZfAivASFZg1urMGN NbixBjfWkDlvIHPegCOP4chjOPIYjjyGI4/hyGM48hiOPIYjj+HIYzjyGI48hiOPkS1DZMsQ2TJE tgyRLUNkyxDZMkS2DJEtQ2TLENkypGT2mwfNS7ZHyEC/UqNsj/N7tBqlkvTsuVFgBwc4wQVu8IAX oiEGusg8sGSf3iAz7T4J6SDz7cpsu9NgOjwDmSBz784wPyI+PiI+PiI+PiI+PtKz8fohG3JgjnmO +DhHfJwjPs4RH+eIj3PExzni4xzxcY74OKd2UNPv6Ri4oFrJQqZ50VBgmBdlbl+Z2Zf2DXGGNto4 xBna1Dk9v24U2MEBTnCBGzzghWiIgS7mOj0b53XQFa6HbnADXLWvmEupjaXfqq/IjL6jIQ3GwFgY BzLHr8zw64dsyIE5ZgE1U0DNFFAzBdRMATVTQM0UUDMF1EwBNVOgFpst9Lu99Lu99Lu99Lu99Lu9 9Lu96mX2vQIrYCWsgtWwBtbCOlgPG6AAXoNCXrcRNsFmKIJiHn8d3oA34S14G7ZACWyFbfAOvAvb YYe5mRbbrP7I/ffhAyiFP0EA/gy7oAx2Qznsgb1QAfvMCuKigrioIC4qiIsK4qKCuKggLiqIiwri ooK4qCAuKtRRXlMNNdz/iN/H4D/hOJyg7j+GWqiDk1APp8xarFuLdWuJqSZiqomYaiKmmoipJmKq iZhqIqaaiKkmYqqJmGrC0Kcw9GkMfRpDn8bQpzH0aXrnXgwdxNBBDB3E0EEMHaTHHqDHHqDHHqDH HpB5nBmPVDAeqWA8UsF4pILxSAXjkQrGIxWMRyoYj1QwHqn4FuORJpkNmvFIPeOResYj9YxH6hmP 1DMeqWc8Us94pJ7xSD35vol830S+byLfN5Hvm4w0dZ0xRg03xqrvGOPUTcYT6hpjIszkvWfBbPBD NuTAHMiFuTAPnoc8mVGR95I5EvNhCSyFZfAivAQvmydkdmqZm1pHK5GqZ6hOIAIv6lmqn4R0kLmP ZabqaTAdnoFMmIGPnoMsmAmz4BStfBrOwOfml7TOV7TOV7TOV7TOV7TOV7TM17TM17TM17TM17TM 1zIHtp4H78+wC8pgN5Sbn8ts2OSRevJIPXmknjyCK6knL/V0DfXkpZ7c2joYR31Hz5sdBXZwgBNc 4AYPeCEaYqALveJZPT5oIsqbiPImoryJKG8iypuI8iaivEnJnN4Ldf46I7NwG9F6Fu7roCtcD93g BpB5uXtCAvSCW0Fm6R4Eg2EIDIVUGAbDYQSMhFEgc3mPhjQYA2NhHMjs3k/BBJgIk+BpmAy/gQz4 LUwBmQN8GkyHZyAT8s1S3FSKm0pxUyluKsVNpXjmAzzzAZ75AM98gGc+ICd2JSd2JfZLif1SYr+U 2C8l9kuJ/VJiv5TYLyX2S4n9UmK/lNgvJeZLifFzxPg5YvwcMX6OGD9HjJ+jZ+yjZ+yjZ+wjxg8S 4weJ8YPE+EFi/CAxfpAYP0iMHyTGDxLjB4nxg/Si3Ve9yrSuMXbTk3bTk3bTk3bTk3Z/y2uMGmK6 hpiuIaZriOkaYrqGmK4hpmuI6RpiukZmUP8W1xhBRoFBRoFBmWedUWCQUWBQZltnFBhkFBhkFBhk FBhkFBhkFBhkFBhkFBhkFBiU+dgZBQYZBQYZBQYZBQYZBQYZBQYZBQYZBQYZBQYZBQYZBQYZBQYZ BQYZBQZlFndGgUFGgUFGgUGZz51RYJBRYJBRYJBRYBDn1OKcWpxTi3NqcU6t8bjqTjx9l3h6kHj6 N+Lpu3jn3410sw733CQzwst88MYzkAnPwgzIgm97fTKf17wg87jy+3ewCH4PMrdoPiyBpbAMXoSX 4GWZf5Ur+xWwElbDGlgL62A9bIACeA0KYSNsgs1QBMXwOvwB3oA34S14G7ZACWyFbRzLO/AubIcd 8B78Ed6HD6AU/gQBc4XMeI+11mGtdVhrHdZaJ/PfY6xijFWMsYoxVrGeDX8fI9579Uze10FXuB66 wQ0y+795CHMcwhyHMMchzHFIz5jfG2TO/EEwGIbAUEiFYTAcRsBIGAUys/6TkA4yv/5TMAEmwiR4 GibDbyADfgtTQGbhlzn4p8F0eAYyYYY5Cs+PwvOj8PwoPD+KK7nvqFyYC/PgeciD+bAAXoCFkM8o YAkshWXwIrwEhbARNsFmKIIdKgXrpGCdSqxTiXUqsU4l1qnEOpVYpxLrVGKdSqxTiXUqsU4l1qnE LhuwywbssgG7nMIup7DLKexyCrucwi6nsMsp7HIKu5zCLqewyynsMh+7HMAuB7DLAexyALscwCxT MMsUzDIFs0zBLDKLaCOR3UhkN8r6BER2I5HdKKsUENmNRHYjkd1IZDcS2Y1EdiOR3UhkNxLZjbKO AZHdSGQ3EtmNRHYjkd1IZDcS2Y1EdiOR3UhkNxLZjUR2I5HdSGQ3yuoHRHYjkd1IZDfKOghEdiOR 3UhkNxLZjf/fIiRgbpFVF+j12+n12+n12+n122UNBnr92/T6t+n1b9Pr35YVGcjMvW2/Mp8mO/e2 jeZ3FtcJM813baXqHtsp82XbaZVoO6PusAXVrbZG85DtrIpQP9OrOESBHRzgBBe4wQNeiIYY6EJL ynoPvUFWfHgS0sH61uAsPfosPfosPfosPfqsXgNiBvufA46GXl1Br67Qq0L4IRtyYA7jiVyYC/Pg eciD+bAAXoCFsIPRwXvQDK1sm2aIMWaIMWZI1piQFSaMv0AVHNBXSgdlpQlq5jPGXl5q5jPGX161 W688EQV2cIATXOAGD3ghGmKgizlVr1HRG2SViichHWS8JitVzODq5TnIgpkwS+bVp6b8kA05MMfM 5wzzOcN8zjCfM8znDPM5w3zOMJ8zzOcM8znDMs6wjOweIruHyO4hsnuI7B4iu4fUKa7zTsMZ+BZX xbKKBtn6MNn6MNn6MNn6MNn6MNn6MNn6MNn6MNn6MNn6sKy1QbY+QrY+QrY+QrY+QrY+QrY+QrY+ QrY+QrY+IqtxyFocZOtqsnU12bqabF1Ntq4mW1eTravJ1tVk62pZrcNIgF5wK/wAfgg/gtsgEW6H O+DHcCf8BO6CuyEJfgr3QG9Ihp9BH7gXfNAX+sF90B/uhwHwcxgIv4AU+CUMgsEwBIbCg5zLSHgI HoZRMJPjngWzwQ/ZkANzIBfmwjx4HvLgBV6zmGyVD0tgKSyDF+EleBmW81krYCWshjWwFtbBetgA BfAaFMJG2ASboQiK4XX4A7wBb8Jb8DZsgRLYKjNuw16ogH1QSe9/0IyQ1U5sj6hooiHR9ji/R/N7 krlMr3xyB1kzhUyYQCZMoKcfoqcfoqcfCsf3BeL7AvF9gfi+QHxfUM8SSzPMD+n9H9L7P6T3f0jv /5CslUDWSiBrJZC1EshaCWStBLJWAlkrgayVQNZKIBP1IxP1U83cbwVTJRgKDEhVvY1hMBxGwAPw lBpqlKse2O4p20iVzFk4OQOnbZLKk9UIbNkq3jZH3aiyvuGbjU/J/Z+S+z8l939K7v9Ur/EyCAbD EBgKqTAMhsMI4OqRnN+kV4IZDWkwBsbCOG3DJmqridpq0ivEyPow02A6PAOZcLXrOPoKebuOvF1H 3q4jb9eRt+vI2yfJ2yfJ2yfJ2yfJ2yepLRu1ZSNvnyRvnyRvnyRvnyRvnyRvnyRvnyRvnyRvnyRv nyRvnyRvnyRvn8QVl3DFJVxxCVdcwhWXcMUlXHEJV1zCFZdwxSVccYlcffqq38d+wbl9CV9BC3yt r8CPE//Hif/jxP9x4v848X+c+D9O/B8n/o8T/8dljRxi6SixdJRYOkosHSWWjhJLR4mlo8TSUWLp KLF0lFg6KqvpyFo65L5acl8tua+W3FcrK+uQ+2rJfbXkvlpyX61eZ2eAXmcnCuzgACe4wA0e8EI0 xEAXrpplRZ7essqO+Tkt9zkt97lemUfW5ZkG0+EZyARZ9WUGZ/wcZMFMmKWvZluxeitWb8XqrVi9 Fau3YvVWrN6K1VuxeiujphpGTTWMmmqo3YPUbg21W0Pt1lC7NdRuDTntGDX8HjX8HjX8HjX8HjX8 nqwNJCsDURMhaiJETYSoiZCsE0RNBKmJIDURpCaC5LkmRgCfk+eaGAF8LqsIGTfqVYSiwA4OcIIL 3OABL0RDDHQxR+r1hq6DrnA9dIMbQFYg6gkJ0AtuBVmPqDfIikSDYDAMgaGQCsNgOIyAkTAKZCWd 0ZAGY2AsjNNrGXVXT0I6zDGTqNkkajaJmk2iZpOo2SRqNomaTaJmk6jZJLXYLCGGHiOGHiOGHiOG HiOGHiOGHlMvs+8VWAErYRWshjWwFtbBetgABfAaFHL+G2ETbIYiKObx1+ENeBPegrdhC5TAVtgG 78C7sB12mMvI48vUH7n/PnwApfAnCMCfYReUwW4ohz2wFypgH21RCfvhL1AFB+AgHIIP4a9wGI7A UV5TDTXc/4jfx+A/4TicoCd9DLVQByehHoLmUpywFCcsxQlLccJSnLAUJyzFCUtxwlKcsBQnLKXX vkOv3Uav3Uav3Uav3Uav3Uav3UqvraXX1tJra+m1tfTaWkZnJxidnWB0doLR2QlZn4rxRxrjjzTG H2mMP9IYf6Qx/khj/JHG+CON8Uca4480WcWK8cdQxh9DGX8MZfwxlPHHUMYfQxl/DGX8MZTxx1BZ 50pWucI/KfgnBf+k4J8U/JOCf1LwTwr+ScE/KbIOljEMhsMIeAAe5PUj4SF4GEbB4+p7XKH35Qo9 hyv0EVyhj+UK/RdcoWdzhe6TlbRkHS2u0LO5Qs/mCj2bK/RsrtCzZWUtHJeC41JwXAqOS8FxKTgu Bcel4LgUHJeC41JwXIqswSUrcMn6W1yhZ3OFns0VerasxMUYYjxjiPGMIcYzhhjPGGI8Y4jxjCHG yxpdXDlnc+WczZVzNlfO2Vw5Z3PlnM2VczZXztlcOWdz5ZwtK3nJOl7Yowh7FGGPIuxRJKt6yZpe GGQDBtmAQTZgkA2ywhcj6CmMoKcwgp4ia33ZRpqLZLUvWeuLsUO38NihW3js8KKs+2UrNQttp7i2 YFxq+4Trjkb1K/Vvei2wKLCDA5zgAjd4wAvREANduG6XVcN6wxycmwtzYR48D3kwHxbAC7AQOq4H WvRfvB4m00TplcaiwA4OcIIL3OABL0RDDHQxJ33DWCGoZB2/BOgFspqfrFnWW3/TeAbfncF3Z/Dd GXx3Bt+dwXdn8N0ZfHcG353Bd2f02majIQ3GwFgYp9c7c3GmmZxpJmeayZlmcqaZnGkmZ5rJmWZy ppmcaWb4rx6r8dxqPLcaz63Gc6vx3Op/8K8eq/DcKjy3Cs+twnOr/sG/euymBXb/D/7qUYznivFc MZ4rxnPFeK4YzxXjuWI8V4znivFcMZ4r7vRXj+Kr/NVjJ57bied24rmdeG4nntuJ56rxXDWeq8Zz 1XiuGs9V47lqPFeN56rxXDWeq6Yn/RV3fYG7vsBdX+CuL2Q9Oty1CHctwl2LcNci3LUIdy3CXYtw 1yLctQh3LZJV63DXq7jrVdz1Ku56FXe9irtexV2v4q5Xcdersq6drGqHu5bjruW4aznuWo67luOu 5bhrOe5ajruWy7p3uGsl7lqJu1birpW4azPu2oy7NuOuzbhrM+66rZO7BuKu6bjrftxVhbvulpXz ZN083FWFu6pwVxXuqsJdVbJOHe4qwl1FuKsIdxXhriLcVYS7inBXEe4qwl1FuKtI1tyTFfdkvT3c VYW7qnBXlay8h7sKcVch7irEXYW4qxB3FeKuQlmTD3dV4a4q3FWFu6pwVxXuqsJdVbirCndV4a4q WbkPP53ATyfw0wn8dELW8cNPb+CnN/DTG7KiH35aJmv6yYp+uOkneOknsq6frOqHi97HRSMNl17d Lwrs4AAnuMANHvBCNMRAF3PuN3x7eBYrnMUKZ7HCWaxwVq8T2BtkpcBBMBiGwFBIhWEwHEbASBgF f28UJGPNOWYeVsjDCnlYIQ8r5GGFPKyQhxXysEIeVsjDCiGsUIIVSrBCCVYowQolWKEEK4SwQggr hLBCCCuEsEIIK4SwQggrhLBCCCuEsEIIK4SwQglWKMEKJVihBCuUYIUQVghhhRBWCGGFEFYIYYUQ VghhhRBWCGGFEFYIYQX5nuYdrPAOVghhhRBWCGGFEFYIYYUQVghhhRBWCGGFEFYIYYUQVghhhRBW KMEKJVihBCuUYIUSrFCCFUqwQglWKMEKJVihBCuUYIUQVghhhRKsEMIKIawQwgohrFCPFeqxQj1W qMcK9Vih/lv+/TPE6CfI6CfI6CfI6CfI6CeILSr/zt8/T2OQ0xjkNAY5LetFYpAdGGQHBtmBQXZg kB0YZAcG2YFBdmCQHRhkh6wqiUG2YJAtGGQLBtmCQbZgkC0YZAsG2YJBtsi6k7LqJAbZhkG2YZBt GGQbBtmGQbZhkG0YZBsG2SbrUmKQfRhkHwbZh0H2YZDtGGQ7BtmOQbZjkO0YJBaDfB+DTMYgt2GQ 2zDIrRikDIN8X1a2lHUtMUgZBinDIGUYpAyDlP0DBimTFTFlPUwMUoZByjBImayMiUHexSDvYpB3 Mci7GORdDPIuBnlX1szEIGUYpAyDlGGQMgxShkHKMEgZBinDIGUYpEyvurfHrMQilVikEotUYpFK WWUTa8jqpXdgjBiMEaNX2yzQq21eB13h+v/L3L3Hx1mWeQOfzIRQpq0oIIj4ihUXEeUkICgKHlYF FAWRk7BIddfCrnURhGi1CFIRC61gtaLwAgIBREkR2u1Ct5kCLWnTA03aJG3SNuSZHCaTOUCaeRIo 9NnvDCMvYrur+8d+3j9+TdI8931f1+/6XYcneSYD+8MBUH7/zcPKv7WFw+H9lXueZtneLNubZXuz bG+W7c2yvVm2N8v2ZtneLNubd/u04a1m6J/DPPgF/BLmw/3wADwIv4OH4P/9tnCR7FgkOxbJjkWy Y5HsWCQ7FsmORbJjkexYJDsWyY5FsmKRLMjJgpwsyMmCnCzIyYKcO9NV7kxXuTNdJSPWyoi1MmKt jFgrI9bKiLUyYq2MWCsj1sqItTJirYxYJSM2yIgNMmKDjNggIzbIhjWyYY1sWCMb1siGNbIhkg2R bIhkQ1R5b7p3RpspdzPlbqbczZS7mXI3U+5myt1MuZspd3P5nU0pd4xyxyh3jHLHKHcj5W6k3I2U u5FyN5bf+5T6uqivi/q6qK+L+rqor4v6uqivi/q6qK+L+roq74ZXfj/K2+EOuBPugrvht3AP3Av3 QQPcDw/Ag/A7eAh+D3+Ah6ERFsAj8Ed4FB6DhbCo8rP8VeV3YDWHP2sOf9Yc/qw5/Nny+7FSZzt1 tlNnO3W2V+7gX717X1DzDX3rUn3rUn3rUn3rUn3rUn3rUn3rUn3rUn3rUn3rUn3rUn3rTApeSsFL KXgpBS+l4KUUvJSCl1LwUgpeSsFLKXipvnWLvnULJTdRchMlN1FyEyU3UXITJTdRchMlN1FyEyU3 xcq/+/8qXAJT4WvwdXjjc7PXuwOfBT+GG+AncCP8FGbDTXAz3CKTbo0ulwWXy4LLZcHlsuByWXC5 HpbSw1J6WEoPS+lhKT0spYel9LCUHpbSw1J6WEoPS+lhKZlTL3PqZU69zKmXOfV6WEoPS+lhKT0s pYel9LCUHpbSw1J6WEoPS+lhKT0spYel9LDb9LDb9LCUHpbSw1J6WEoPS+lhKT0spYel9LCUHpbS w1J6WEoPS+lhKVlaL0vrZWm9LK2XpfWytF6W1svSellaL0vrZWm9LK3Xw1J6WEq21uthKT0spYel 9LCU7L1L9t4le++SvXfJ3rtk712yd6Ps3Sh7N8reVtnbKntbZW+r7G2Vva2yt1X2tsreVtnbKntb Ze8TsrdR9jbK3kbZ2yh7G/Wzu2VwqwxulcGtMrhVBrfK4CWSd4kMXiKDl+hnM/SzGfrZDP1shn42 Qz+boZ/N0M9m6Gcz9LMZ+tkM/WyqfjZVP5uqn03Vz6bqZ1P1s6n62VT9bKp+NlVVmKkqTFcVpqsK 01WF6arCdFVhuqowXVWYripMVxWm1xwWPVXzPjgc3g8fgCPgSDgKjoZj4INwLBwHx8OH4AQ4ET4M H4GT4KPwMTgZToGPwyfgk/Ap+Hv4NHwGPgunwmlwOnwOPg9nwBfgi3Cmu+ez4EtwNnwZzuHfuXAe lN+18wL4h+g5Pfewmq9GT+i7R+m7X9V3j9N3z9Z3T9F376m5TJX4F9+7yudXQz18F74HM+AHMDOa pvpNU/2mqX7TVL9pqt801W+a6jdN9Zum+k1T/aapftP03ntUwJl67z167z167z167z167xy9d47e O0fvnaP3ztF75+i9c/TeOTW36de/UTlvhzvgTrgL7obfwj1wL9wHDXA/PAAPwu/gIfg9/AEehkZY AI/AH+FReAwWwiL2/Bsshn+Hx+EJWAL/AUuhCVKwjCafxPtT8DQshxXwDF7lpAqbUmFTKmxKhU25 i7jDXcQd7iLucBdxh3mg1jxwtbuIb5gJ9jUTvN1M8HZ3EderwjclgmjUnURLIhP1u5s4IpGNCrGG yvtn7wF1sCdMgL0gCRNhEkyGN0H5Xbb3hf3grbA/HAC7fhVDRjXOqMYZ1TijGmdU44xqnFGNM6px RjXOqMaZynt1XwVXQz18F2bA9+EHMBOugVujDhW2Q4XtUGE7VNgOFbZDtexQLTtUyw7VskO17DBn HG/OOF4F61DBOlSwDhWsQwXrUME6VLAOFaxDBetQwTpUsA4VrEPl6lCRdqhIO1SkHSpSVkXKqkhZ FSmrImVVpKyKlFWRsipSVkXKqkhZFek5FSmjImVUpIyKlFGRMqpRRjXKqEYZ1SijGmXK70yu+oSq T6j6hKpPqPqEqk+o+oSqT6j6hKpPWHlf6rfAPrAv7Advhf3hAHgbHAjl9+x9p159MLwLpsC74RB4 D/wdHArvhXNcey6cB+Vn1C6Ai2NvkcGHy+DLZPAJMvjTMvg9Mrf8Pt9p2ZmWnWnZmZadadmZlp1p 2ZmWnWnZmZadadmZrrwH8LJoQ/l91Sm6i6K7KLqLorsq75O8ElZBC6yOuqn1SGo9svwuurHPiHRa pNMinRbptEinRTot0gMiPSDSAyI9INIDIn20SB8t0hmRzoh0RqQzIp0R6YxIZ0Q6I9IZkc6IdEak MyKd0ZN26kk79aSdetJOPWmnnlT+XcftFHA7BdxOAd0U0E0B3RTQTQHdFNBNAd0U0E0B3RTQTQHd FLCAAhZQwAIKWEABCyhgQfl5biqYTQWzqWA2FcymgtmJM9zxnxObWH2l0ZmmpicSF0UXJv4hWpG4 2NdqauISX0/19RXRK7GTTCQZE0nGRJIxkWRMJBkTScZEkjGRZEwkGRNJBoMZDGYwmMFgBoMZDGYw mMVgFoNZDGYxmP0f/S5uq3XboAeeg14IKjmQxcAoBkYxMIqBUQyMVp4Bf9FE9RLsgJfhFXjjc+H/ ENszMRXKrwA5/q990pIH4zwY58E4D8Z5MM6DcR6M82CcB+M8GOfBOA/GeTDOg4gHEQ8iHkQ8iHgQ if1qsV8t9qt5072be+b1vFnNm9W8Wc2b1bxZzZscb3K8yfGm/ARoWlwHxLT8vOlAojxvHhmb6/7n 1mib+GwTn23is018tonPtl3G5/HY/hS+Py+zvMzyMsvLLC+zvMzyMsvLLC+zvMzyMsvLLC+zsXQs GeuDfhih7PFoM8t3sHwHy3ewfAfLd7zu1QYXJS6KJcRhcvVVBxclLvH11Njk2GHikRaPtHikxSMt HmnxSItHWjzS4pEWj3Rsrug97vQnyha4e+qDfni1Qu7qVTJrWbWZVZtZtZlVm1m1GZ8ZfGbwmcFn hpUt1VcNZHA6iNMMTgcTX4uCxNejIHYaC+ezcD4L57NwPgvns3A+C+ezcD4L57NwPgsfFoM+MegT gz4x6BODPjHoE4OcGOTEICcGOTHIvfYz4haerYY1sBbWwbOwHlqhDTbARmiHTbC7p1xHoq3Y6MFG DzZ6sNGDjZ7Kz29fpNCXYAe8DK/AzmgEGyPYGMHGCDZOx8Zp4raXuB0ubnuK2xRx20vcDhe3ci5N wc7p2DndJLA88WzlvQvmVl4TuJP3O3m/k/c7eb+T9+XaVxKvkniVqj8z2lU29+zqZ0Z/yt5Y3GcT fDah8lvQbhHpFpFuEekWkW4R6RaRbhHpFpFuEelm0+5fR/jqs1JvfAVJ+d3ru520h5P24GU6UX5d xulODJwYODFwYuDEwImBEwMnBk4MnFh+bqEBAw0YaMBAAwYaMNAg/g3i3yD+DeLfIP4NcnCSHJwk /g3i3yD+DeLfIP4N4t8g/g3i3yD+DeLfIP4N4t8g/g28yvMqz6s8r/K8yvMqr7P06iy9OkuvztKr s/TqLL06S6/O0quz9OosvTpLr0j0i0SXSHSJRJdIdIlEV7WzbBOJbSKxTSS2icQ2mtiDJg6liSSG TqaJPWjiUJpIYutk9bUr9vnY9bGDY7Pgx3AD/ARuhJ/CbLgJboa5sU9gax221mFrHbbWYWsdttbt Zvr6U0/uxlY3trqx1Y2tbmx1Y6sbW93Y6sZWN7a6sdWNrW76e4j+HqK/h/7G+8F7MHQnhu7E0J0Y uhNDd2LnRuzciJ0bsXMjdm7UcyeoIafot1epI0fqt99RS07Rb69ST47Ub7+T+EG0NDEzWpRYH3t/ ojX2zsSG2Pt4dD2VzoIfww3wE7gRfgqz4Sa4GeaW67aYPVHJ/91NGc/w9BmePsP6QdZnWZ9lfZb1 WdZnxfeZv7LTtMqG3upTghN4tbb6pOAEHq2VHf2J8jM+5eyYy4O5PJjLg7k8mMuDuTyYy4O5PJjL g7k8+IGYF8S8IOYFMS+IeUHMC7vuUmr4E9AiT1fDGlgL6+BZWA+t0AYbYCO0wybYqqZsgx54DnrB /QqGihgqYqiIoREMjWNoHEPjGBrHULk2dGNoO4a2Y2g7hrZjaDuG0hhKYyiNoTSG3oahd8iMvTF0 nKzYS1bsjaHjZMReGPowhj6sSv5IdnSWu11siuyYIjumyI4psmOK7JgiO6bIjimyY4rsmCI7PkTx 76H49/zZTzNG5O12VXQUShDCGIzH9mFxP4v7WdzP4n4W91Pl5xLnsuYr4nhR1CN+vWLXk/iavP06 fDM2K/HD2MGJ6+D62EGxk8WyXyz7xbJfLPvFsl8s+8WyXyz7xbJfLPvFcVgch8VxWByHxXFYHIfF cVgch8VxWByHxXFY/IbFb1j8hsVvWPyGxW9Y/IbFb1j8hsVvWPyGxW9Y/Ib/i5/MDmFjCBtD1ddf 7eqJrAATASYCTASYCMRuVOxGxW5U7EbFa6/KDPVVH8sz1Ck8z/M8z/M8z/M8z/M8z/M8z/M8z/M8 T8UjvM/yPsv7LO+zvM/yPsv7Eu9LvC/xvsT7EhWPU/E4FkpYKGGhhIUSFkpYKGGhhIUSFkpYKGGh hIUSFkr/RZ7nsZDHQh4LL2BhBAsjWBjBwggWRqj4uV121K9EWVVqnBayqtM4ZY5UvJ/H+3m8n8f7 ebyfx/t5vJ/H+3m8n8f7ebz/Me+X8X4Z75fxfhnvl/F+Ge+beN/E+ybeN/G+ifcbeb+R9yt4v4L3 K3i/gvcreL+C9yt4v4L3K3i/gvcreL+C9yt4/zLvX+b9y7x/mfcv8778TMOpiXMp+Ty19XyffyV2 oHieV+1MX5SDB4rredXO9EV5eJM8vEkeNvD2ZhPLpxNt0aOJjdHORHvsa7G38H4L77fwfgvvt/B+ C++38H4L77fwfgvvt/C++09PV7Ciy+mb7N5l965K7iy0y0K7LLTLQrsstMtCuyy0y0K7LLTLQrtc g8OtONyKw6043IrDrTjcisMuHHbhsAuHXTjscuISJy75H06KO3C4A4c7cLgDhztwWJ7Ov4bDNhxu 4MXHcbgnDk/D4d44vASHe+LwNBzujcNLeHkLL2/B4VwcNuPwdBxuxN8FlXvIRp438ryR5408b+R5 I88bed7I80aeN1Zn5N3die/i2U5d+An4n/0FiV2qR16U59zzeN/O+428P73q/Ym834v3V1S9P5H3 e/H+Ct7/mve/rjwPfMxf/Vz+rdGjPH2Up4/y9FGePsrTR3m6gKcLeLqApwt4uuB1T7Eu5ulini7m 6WKeLubpYp4u5ulini7m6WKeLubpYp4u3t00yKN38WgPHk3jzbt4U55rp/HigdgneTGHF3N4MYcX c3gxhxdzeDGHF3N4MYcXc8Tsn3b7yuL7o2aeNPOkmSfNPGkWs2fF7FmetPCkhSctPGnhSQtPWnjS wpMWnrTwpIUnLTxp4UkLT17iyUs8eYknL/HkJZ689BfV+xyT1bnROvHrEL+TqrPpGbw9kLezq7Pp GTw+kMezxW+2+M2m3p/y/hHq/ST1tlDv0bFjMTGCiRFMjGBiBBMjmBjBxAgmRjAxgoly1e/EQicW OrHQiYVOLHTuZl6dIJ4TsNCJhU4sdGKhEwudWOjEQicWOrHQiYVOLHRioRMLnar5mGo+ppqPqeZj qvnYrn7SweNjeHsiT4/h5Yk82xw7s+YwHL0PDof3wwfgCDgSjoKj4Rj4IBwLx8Hx8CE4AU6ED8NH 4CT4KHwMToZT4OPwCfgkfAr+Hj4Nn4HPwqlwGpwOn4PPwxnwBfgi/CbK19wOd8CdcBfcDb+Fe+Be uA8a4H54AB6E38FD8Hv4AzwMjbAAHoE/wqPwGCyE8m+5n3Rf+xQ8DcthBTzje81RV81KWAUtsFoN /4o7v4vV9y9jsIDBAgYLGCxgsIDBAgYLGCxgsIDBAgYLGCxgsIDBAgYLGCxgsIDBAgYLGCxgsIDB AgYLGCxgsIDBAgYLGCxgsIDBAgYLGCxgsIDBAgYLGCxgsIDBAgYLGCy/FrGEwRIGSxgsYbCEwRIG SxgsYbCEwRIGSxgsYbCEwRIGSxgsYbCEwRIGSxgsYbCEwRIGSxgsYbCEwRIGQwyGGAwxGGIwxGCI wV4Mbsfgdgxux+B2DG6vWePOYS2sg2d1yPKdQ/n1xBdhtIjRIkaLGC1itIjRIkaLGC1itIjRIkaL GC1itIjRIkaLGC1itIjRIkaLGC1itIjRIkaLGC1itIjRIkaLGC1itIjRIkaLGC1itIjRIkaLGC1i tIjRIkaLGC3W3MKrW+HnMA9+Ab+E+fAr+E00hvExjI9hfAzjYxgfw/gYxscwPobxMYyPYXwM42MY H8P4GMbHMD6G8TGMj2F8DONjGB/D+BjGxzA+hvGx/4LxToyHGA8xHmI8xHiI8T6M92G8D+N9ldnu 4vITWTVxXiWgFvaAOtgTJsBekISJMBlmwjXwQ7gWroMfgT5Xo8/V6HM1+lyNPldT7nPJmr1jB9d8 Bb4J0+Ff4XL4NlwB34Hy3f5sdmxixyZ2bGLHJnZsYscmdmxixyZ2bGLHJnZsqnlztKHmLbAP7Av7 wVthfzgA3gYHwtuj1TXvjNbWHAzvginwbjgE3gN/B4fCe+H/97+Kc2a0vOYs+BKcDV+Gc/h3LpwH 58MFMDNqF6N2MWoXo3YxahejdjFqF6N2MWoXo3Yxahej9pqbrLkl6qfqfqrup+p+qu6n6n6q7qfq /pplsck1T8bqap6Cp2E5rIBmEV4Jq6AFVsMbc/sc97TnR9+tzt7TqzP3dD1oVeU1R3fHDkgsiR2f eNLdZxA7JJGOnZ3oi+2T6I+9PTHo60xsv8SQLpz1f8Ox42NnU8ogpQxSyiClDFLKIKUMUsogpQxS yiClDFLKIKUMUsogpQxSyiClDFLKIKUMUsogpQxSyiClDFFKllKylJKllCylZCklSylZSslSSpZS slgfwvoQ1oewPoT1IaznsJ7Deg7rOaznsJ7Deg7rOaznsJ7Deg7rOayXXwebVivSakVarUirFWm1 Iq1WpNWKtFqRVivSakVarUirFWm1Iq1WpNWKtFqRVivSakVarUirFWm1Iq1WpNWKtFqRVivSmJ+I +c9ifiLmP4v5JzG+f6Ip9u7YedjswmYXNruw2YXNLmx2YbMLm13Y7MJmFza7/obfBuaxWcRmEZtF bBaxWcRmEZtFbBaxWcRmsebM2L41Z8GX4Gz4Mpxj/blwHpwPF8BMHfka+CFcC9fBj8BMhuERDI9g eATDIxgewXD+f+sJpcQ5NPzqqwLPrr4q8OzEN2OnxeL+p/yc//6xWt+fULlvurjymrvTYm9SGyep jZPUxklq4yS1cZLaOEltnKQ2TlIbJ6mNk6x8r5VfsvK9Vn6psvIgKw+y8iArD7LyICsPsvIgKw+y 8iArD7JyPyu/ZeV+Vn6rsnKylZOtnGzlZCsnWznZyslWTrZyspWTrTy0MjVe7KOp8W+y9tDKz7he XXlchYPDy78TiJ1La1tpbSutbaW1rbS2lda20tpWWttKa1tpbSutbaW19bS2ntbW09p6WltPa+tp bT2trae19bS2ntZW0loTrTXRWhOtNdFaE6010VoTrTXRWhOtNdHVSrpaSVcr6WolXa2kqyV0tYSu ltDVErpaQldL6GoJXS2hqyV0tYSultDVErpaqV7m1cu8eplXL/PqZV69zKuXefWyrLuQ7kK6C+ku pLuQ7kK6C+kupLuQ7kK6C+kupLuQ7kK6C+kupLuQ7kK6C+kupLuQ7kK6C+kupLuQ7sKaRdGAbH4s 9hbzwJh5YNw8MG4eGDcPjJsHxs0Dm8wDJfNAyTxQMg+UzAMlVbpfle5XpftV6X5Vuju2h1xMysWk XEzKxaRcTMbOErUOUesQtQ5R6xC1DlHrELUOUesQtQ5R6xC1DlELRC0QtUDUAlELRC0QtUDUAlEL RC0QtT5R6xe1flHrF7V+UesXtX5R6xe1flHrF7V+na9P5+vT+fp0vj6dr08k+0SyTyT7RLJPJPtE skcke0SyRyR7RLJHJHtEskcke0SyRyR7RLJHJHtEsu+/+8tDOt++Ot9EnW+izjdR55uo803cVefD 4ZmVJ2K/EnsHzV8oA95B9xeK0PLKvULefJE3X+TNF3nzRd58kTdf5M0XefNF3nyRN1/kzRd580Xe fJE3X+TNF3nzRd58kTdf5M0XefNF3nyRN1/kzRd580XefJE3X+TNF3nzRd58kTdf5M0XefNF3nyR N1/kzRd580XefJE3X+TNF2XNDtHsEM0O0ewQzQ7R7BDNDtHsEM0O0ewQzQ7R7BDNDtHsEM0O0ewQ zQ7R7BDNDtHsEM0O0ewQzQ7R7BDNDtHsEKX27mZyze7q6QxKLVBqgVILlFowufYnyq8iPgejAUYD jAYYDTAaYDTAaIDRAKMBRgOMBhgNMBpgNMBogNEAowFGA4wGGA0wGmA0wGiA0QCjAUYDjAYYDTAa YDTAaIDRAKMBRgOMBhgNMBpgNMBogNHyX7cMMBpgNMBogNEAowFGA4wGGA0wGmA0wGiA0QCjAUYD jAYYDTAaYDTAaIDRAKMBRgOMBhgNMBqoAkWsBrt83uUZ/7+LZ2SxOoDVAawOYHUAq+uxuj72K9ke yPZAtgeyPZDtgWwPZHsg2wPZHsj2QLYHf8N0VX6lc06252R7TrbnZHtOtudke06252R7Trbnag6T Xe+Dw+H98AE4Ao6Eo+BoOAY+CMfCcXA8fAhOgBPhw/AROAk+Ch+Dk+EU+Dh8Aj4Jn4K/h0/DZ+Cz cCqcBqfD5+DzcAZ8Ab4Iu65Gf/n30WbKqWvgh3AtXAc/guthFvwYboCfwI3w6t9BG1ONxlSjMdVo TDUaU43GVKMx1Wis5jcqze1wB9wJd8Hd8Fu4B+6F+6AB7ocH4EH4HTwEv4c/wMPQCAvgEfgjPAqP wUJYppc/CU/B07AcVuz6ryL8hZLOiaaqgudXf9f10ervuT6qCrZW1DVEXUPUNURdQ9Q1RF1D1DVE XUPUNURdQ9Q1RF056spRV466ctSVo64cdeWoK0ddOerKVZ89K1BXgboK1FWgrgJ1FairQF0F6ipQ V4G66qirjrrqqKuOuuqoq4666qirjrrqqKuOuuqoq4666qirjrrqqKuOuuqoq4666qirjrrqqKuO uuqoq4666qirjrrqqKuOuuqoq4666qirjrrqqKuOuuqoq4666qirjrrqqKuOugrUVaCuAnUVqKuw y+fl/nZ1Ff77v1wVq6WuWuqqpa5a6qqlrlrqqqWuWuqqpa5a6qqlrlrqqqWuWuqqpa5a6qqlrlrq qqWuWuqqpa5a6qqlrlrqqqWu2qq6JlDXBOqaQF0TqGvCbtRVpK4idRWpq1jtsTN3oa722PnU1U1d 3dTVTV3d1NVNXd3U1U1d3dTVTV3d1NVNXW3U1UZdbdTVRl1t1NVGXW3U1UZdbdTVVn21RQt1tVBX C3W1UFcLdbVQVwt1tVBXC3W17OaVFatEapVIrRKpVSK1SqRWidQqkVolUqtEapVIrRKpVZVXVtzi HupW+DnMg1/AL2E+/Kr8k1FKuR3ugDvhLrgbfgv3wL1wHzTA/fAAPAi/g4fg9/AHeBgaYQE8An+E R+ExWAiLyn8PIXYsho/F8FOV/O3FcC+GezHci+FeDPdiuBfDvRjuxXAvhnsxPIDhAQwPYHgAwwMY HsDwAIYHMDyA4QEMZzA8iOFBDA9ieBDDgxgexPAghgcxPIjhQfmblL9J+ZuUv0n5m5S/SfmblL9J +ZuUv0n5m5S/SfmblL9J+ZuUv0n5m5S/SfmblL9J+ZuUv0n5m5S/SfmblL9J+ZuUv0n5m5S/Sfmb lL9J+ZuUv0n5m5S/SfmblL9J+ZuUv0n5OyB/B+TvgPwdkL8DVJGhigxVZKgiQxUZqshQRYYqMlSR oYoMVWSoIkMVGarIUEWGKjJUkaGKzH9/1/G/2h12lb+7+mnQG/P3W/L3e9X8PbmavydXnr296m/8 m4h/7c8A26irjbraqKuNutqoq4262qirjbraqKuNutpMlKGJMjRRhibK0EQZmihDE2VoogxNlKGJ MjRRhibK0EQZmihDE2VoogxNlKGJMjRRhibK0EQZmihDE2VoogxNlKGJMjRRhibK0EQZmihDE2Vo ogxNlKGJMjRRhibK0EQZmihDE2Voogypq0hdReoqUleRuorU1UZdbdTVRl1t1NVGXRuoawN1baCu DdS1gbo2UNcG6tpAXRuoawN1baCuDdTVRl1Z6spSV5a6stSVpa4sdWWpK6sWhKbMwi7/+mmz/18J q6AFVleeBCrf/bwjNjn+kSgd/xScGl0UPy26PP656PLEGdHTiXPcM51f+Yuo5fc5WFB9n4MFtJCP TYwfHWXjx8EJcAqcGrVavdrq1fEzoo2UtM3KLVZtib3J1TlX51wdOq/Hipwze+Jn+Xi+/7vQ5/8I 0+GnUXd8dtTtnMFY0sqSlSWr+q0qWdXvil5X9PLhCD4c4crVlTMGXDngjE5XDrBoDYvWsmhtvOJP tLL8FxSqf1d6cvXvSk+OTbD3g/Z9kBWNrGhkRaMzljljWeVpuH3sfZm9L7N32t6X2XvM3qP2HrV3 2eZNrt6UOGfnaOL8naXqT5uOqv606ajqk0PLKztdYqdLnLnKTpc4d1X81Nj/scMX7PCF6ms3b6o+ E3F49S9SHFv9ixTHVv8ixQWxN9vp23b6NptG7bbSbt+220o7fcNO37DTJDvdaqer7bSPXQ62w8F2 uMYO9bE9rVpuxXIrOqzocMU+rtjHd+fF9sbGdmxsj18WPRD/5+gX8X+Bb8L0aPsb9PF9+liKz+/T x1KrR8XtLJo4Hy6ji3+miX+Bb8K3nHNO9Nxr2qhxfZYtZ4nthWL7jzDdPeSFlZ9PHeq7bTR6lv89 P9pstzV2W2O3NXZbY7cn3xDXN1Xj+qbKzj38OCt6zNrA2jFrX7b2ZWtftrbH2gnWTsRysvI6g4t9 LL/W4NXfLz9TWX09u1aya2X8stg72LbSqq9j9kXMhlbPsvqA6k/jDqj8Dveb0a/Kv52u2P1tZ4++ tsOrq0+0+tnqa/o/U1n56qp5Vunvrl7r6rWuXuu7b/Xdt/rOLyn1KnZfHb0Yr6fvWbE94nOiQvyX cui2KB//tbyM++5L8VlRGKvx74viUC+7vsvz78GsqD1+g11+Ypebo0x8Pgtvi3ZYucP/XmGvK+Eq O9TT+cxo0P598V9Exbi7G9q9AuNXwlX+97uu/B78MFofvxaugx/BrNhb4zdEC+I/c90t0XPxW+Hn MA9uix531uOxWlZuc9UGV/XG50cvsHtWNMKmMRZfEY07ZdwJLzmh7E0vhYYUGroitMu4XcZZfDUr y/7NtPYaVs5SBW7wfz8T7flRMfZ2ezXZq4nFGVeutGfanun4DF/PjIasGuFBjgc5HuR4kHPeK85r cl6T816Iz42aedLJk06edPKkEydr8P4MW9rZ0h47yEn9Tup30nZ2PeW0ohO6nDDshIITCk4oOKHA zknsfNQpOafk4qZ/TGfY/bCTMk7KOCnjpIyT8k56gT9LndbjtJ7YXk4LnRZWvH91t1G7vWC3F+wU 2mlUjf6uOH8PZjnjBsze5MqbXVm5wufz4Ta6+HU1uhl7ZqzKWZVjdZbVWVZnWZ2tnPMni+3/F5be 5ppfy+VyLJ+v/MSyzp45e+Z4keNFv2tyrslVYlf6c/vseFPF8pCvoYpwtfWz7HmDc2/y+c108DPq mh9Lqn5/YuAq0ZoJ18QOdPXLLHyehc+7epyfz4veqFVHsiBkwehr6ilrsKyxF1jwgpXNr+XOaCxR +d4suEFm7O2sFme1uDrv6ryzytnVxbI9nDfovMEKtz/z9S/kxi8p6zb/92sdLFHJ11c9HI8dF28U w0Wx/eNLo2fjTfAkVT7Ftqeja+PLo9/GV0CzXrQ6+kF8XTQr3uaadh87oIjl52G7PUrRz+Jh9ER8 DF6Ud69E/zcRU3dqo0xiTx8nwGSf7x+VEgfA2+AweB8cEY0mjtLJj4maEh+EY+E4NfdEXfekaGFC n33tnY7Ojb05cV5sUvV1SEer9I+osEer9I+oSRmd6z6+NcJT2H862siLUV6M8uLF+EofV+vn61Sz jbxs97EDMjQ8JIol+RdS/xi8FL3Ag+dY/xzrn0scqMIeFaVZuZ2V21m5PWGaY2EQe1v11C78jTu1 06l5p+ad+rJT+5y6yamdTt3u1E6ndjotdNqI00acNOKkESeNOOVFp5ScUnJKyQn52L864Rvxh6Lv O2U8vih6JP7v0cz447BUXWiCJ+Ep1bM5uj++mnrafL1Rtm+K/im+OfqPeBd0wxbYCtuiafEeHwPX paPF8T6f98MgZGJXxYeiu+JZnw9DLro6nvexAEVTwvPwgs9HYHt0bnxUpQh5OAYvRifj7pn4Dt97 GV6J/i2+08dIBGsgDoloOWVcktjD53XR3ETSTDDR55PM+5Oj9sTe0bcTb4a3wD6wXzSFco6jnOMo 5zixuCzx9ug7iYN87x1wcOwbiSk+vhsOiT6ceA/8ne8f6uv3wmHRIZR2SOJwn38AjojenTgy+iSm 78V0PabrMV1PdZ8R09sTH3LNCXBidHPiwz5+BE6Knkh81MePwclmllPY8XGffyK6sPrUY48eerce +s868Lt033clLqvMH0/G3i9KvaLUK0q99NH7On1spY0B2tgkYr20sYk2NmF5AMsD2B2gk23Y3Yrd rdjtx2iaXrZhcIBmttHMNqwNYeh5DD2Poed5/DyPn+fp87wMeJnmZZqXaV4WeVbg0VZeqI2xk+TV x+TTNrm0LfZeOgvpK0NfGZa3s7yd5a0sL+fRmqqaO1jcXs2jDlZ30M07Wd7F8i6Wt7F2FWsHWNrF wj5x7GdlGyvbWNkmbhPFa0C8Bli8icWbWLyxmmebWbyZxZtZvLGcZ6xtix3GorUsWsuiVSwaYNG/ VbM6zaK1rEmzJs2afVkzzJph1vTisQePA3gcqNaoTXjsZN0wHjvx2EmB49U6lWZlmpVpVk5iXZp1 adatZ9021rWyrpV1rax7Dp9bWNjMwrTOdp8sL1u2XK6ugJWyfDUL1qkEG3W4dh87oj5ZmjEhHlx+ n1VrRvA+jvcQ76E1L9HVFnrqNxfdh/mHoBH+dMXT0RWv1eiVZozV0R3l+iKO94njfeaN+0y4D2Gk kXIWUNsiNv27rx+HpzGwHCMrYCX2VutO66JUvFXtezWmKTam1I+iWpFVA4rytCiGrWLWJWZd7Otk X2fsECf9zEnXOin9Z9Xpad1suT62Alb63uoocspotQ6OOmHUCY1OeEzFWe+UZ5zyjFP+6c9icEh0 pROvlNXDYhGIRSAWfRXucS4Ly8+OHMOaY3D5JC6bMZJxhxKLXhHdV0T3FUyfoNeXuXyah8t5vAIy sTrxfEE8XxDPFyq19jrezOfJMp78nCc/p7r1VLfe3s3x5TrmCmiO7uXRDqpbz6MBnly1m1r7k2qt /Q+1dtkbau11PH/sdbX22tfV2iup98rX1drL1Nr1r6u156q1615Xa5fuptZeWa2192L32mqtnV6t tdPV2ulq7XS1djrmT8L8qZg/FfOnqrU3qLX1au10tXY6Di9Qa6ertf/J3HmAV1VlfX/tvU9CKiiE QAAh0sFClVEEooiMiBBBQFRQEAQhCUESRFFwBlAUG46NEcvMqAhKAI2CoQhSLgpJaAlc0qSFGhIQ Qqg57+/sXOflm3E+dWae7/kenv8+uefsutb6rxLuvUlCKz3RSk+0MgRfm4SvTUI7PdFOT3xtEr42 CS3dhq8dDmvSkPIfkfIfkfIf0VwffO3L+NokfG0SDJqGr03C1ybBpGfwtUn42iR87VA0fAe+Ngkt e9+ROCjwLv00tD0JX1sXX1sXX7sFX7tQRqO9R9DeBLT3OdpLQXspaC8H7eVYL7YWJm50N6C5Y2gu B80dQnOpaC4TzWWiuUw0l4nmMtHcq2guE62tRmuZaC0TrWWitaFo7Su0lonWMtHaHLSWidYy0dpS tLYUrWWitUy0thitfY//KUdjq9HYfjSWicYy0VYm2spEW5loKxNtbUNbS9FWJtrahLbmoK1MtLUK be1AWxloKwNtZaCtDLR1O9p6FW29irZeRVur0dZGtJWBtjLQ1oNoKwNtZaCtB9DWA2hrMdrKQFsZ aOsFtPUC2spAWxlo62W0tQFtHUJbBWirAG0VoK030dYOtJWBtjJsbnYT186gC+gKupG3xbGHW/j5 VvdjNBWPptagKe/zj53QzhZpjnYWoJ2FeIrt+KSTaCkbLS1ASwvQTCnMXAgzd8LMnXiMNWjpOB7j K/zScTR1BK/xFV7jKzT2EdrZAKeOoIlsNLAeCfvhxj64sQ8pH4L7OUixDP7nwP8cpLkeiaUhiTQk kcYuvU8s9PditjTDRrZhI9uwkUzs42tWPoB9bEPX3dFpATotQJebWWUPq2xlla3oc5n2PsUoVNIO cqrGNQRE4KciiWrRyKwOqAsaybXIvgKZ5yHzPGS9GzkXI+cs5JyFnLOQcy6y3Q0D/MhyB/n6YaKP Fyc7uhfJ/RfZ/DIBCc1BQnOQ0Fr2+QekcI59zWNf6ewrndMfDeQJi9jTIva0iIpgnfsyI9czcj0n rGDkK4xa9ffMvSoiFv2UVTCiDD99ApxivnL3U3r66Onj3EX0Xkjv+Zz7FCPmM2I+efQ+epeTpZxB LxXgPBmGcLJg9yi9suiVRYTcBxfK3d30KqZXMb0OM5+XB2+l52l6bqXnViK4H7soAiWgDJs4AU5R hZwD5/Hkl4jWjruTUQXodwH6zMDqdmF1XmxaZt9J5b2LyrO+K5nhNDOcZobTgXzgB9b/gdmO2kxF sBrHrn+I9Q8FPunWhnqjPXE1l7iaa6VylFmOMsseZilglhJmKWGWPcxSxizLmcU773JmWY5Uynh6 AlTlcxc8+dmc3yFuBfJ+tOvnqSe/MnqcAFW7/PGyrKWEM+9kZD4jL3Dmk4zOZ3S+aE7q/V6uA7Wk n6hWwjznmTnMPSXV/x7F98GwEqvLbcxaxKxF9Mpnxi/xPacDsv+SGb803t+H9UZuYOTXjPyRkcsZ efCnqsXzZJfbCyOWI/9+yH0ENan3GbpQxp9kzEnGHGPMsUBdVcZKRxhXxrgye/IVrOJjhe8u41oO J05jxBnLrTD726pnA9rdzSpj7O/jvNFLrC8ooaoqw0+cAKfw6uesbRxnLU8Ouxg9PvC7ri2Mvs/+ P0JNRhcxehknzMLP72SW1ex48WVcWhZgxnvIyPMoXt79Hjt/j1lXM+uLzLbIajmftfNt7lsOv865 6xh1nD3kM+I4I45jPX4ktw97L4e/Z4gTFeA8/kCItFVSeY6ez2FvD2NvD6PPcnZ0hjkrADGefCWG 7LANaIe+2oMO4Ab3HH4iCu8fw1o/5WhtkHc7zt8edAA32M/qHfa+kUDC6F1K77P0LqV3KT0r6FlB z4pAdXsUL3lCGirtblQGOCAIBINqIASEgjAQDiJZP4IKNsp9F+93DO93DO93jBUWs8JiPGApHvAI HvAIHvAQfu0gnu4Yq5QiyQ+R5If23b/eO389ztbGj542UXAwmlPVAXVBS3jTClwH2jBTOyypPegA OnLvBqmBH/Vq52JmPw6PyRqkHSffxcl34VOjyB5jyCKbYLdNQTP7W4iz/1Tf38/eHnSPIasIekcj uTqgLvjfmuCoXfNmesch1VDmLrO/L2hCntIUtONJe9AB3MAa3t+5DKHHj4Hfe2zh6Raebgms+Bor vibVeFr6f2jY08ZPXshbJZs5ylllF6vsujyHZR5vP8Wi2F251DKR/BTlfsD+S9l/KfsvZdxSxi3l 5OWXaeQ4ZznGOUrRiPeZyM/QyGdopCYa8X4X75crmenzf9DtN8z0DTOdYqbTzHSamc4y06mAbs8x 02Zm2vzTTFYDe9n/IUbvZvRuRp8JVH6X23Qx5zjPDOVILJpsvw6oC1qCVuA66u6qKmCPlUkh8xUy XyHzlTFfDvPtYL4dzLcDmzhq32PaxDwkTaSnjHT/LI+AUSDF/YtMRu5PgafBFDAV7HfnyAFQDH60 39k2W86DC+AiuOTOVi3draoVaA2uAdcCakV1PWgD2oJ2oD3oADqCG0An8DtwI7gJdAY3gy6gK+gG 4sAt4FbQHdwGeoDbQU/we3AH6AXuBL3BXaAP6AviwRipo9a4q9W37jK1FqwD68EGsNFdpb4D34NN YDMepqnUdLOlFsDKpDaIBnVAC9AStAKtwTWgN7gL9AF9QTy4G/QD/cE9YBC4D4x030Xi7yLxd5H4 VEl135OJ4HEwCTwBJpNJPAWeBlPAVNBcXiMf+BN4HbwB3gRvgXngEzAfLACfgk1gM8gEWSAbbAFb wTZAxSY7QA7IBX6w3/0CPX+Bnr8IfOPm90LeLuXgDKgA59zF6H4xul+M7hej+8WSLI5cKUEgGFQD ISAUhIFwEAEiQXXQWaLlZjDSfQo5PIUcnkIOE5HDWOQwFjmMRQ5jkcNYeZIZJrtJyCIJWSQhiyRk kSTTpYbMAM+C58BM8Dx4AcwCL4KXQIY0lOVgvzuZk03mZJM52RucbD4nm8/J5nOy+Zxsvpxlx+fc KZxuCqebwummcLop6h03V80F74L3wQfgL+Cv4G/gQ/AR+BjMA5+A+WAB+BR8BhaCNLAILAZLwOfg C5AOvnRzdVvieDtq6o5c48Ad7lO6F5Vbb9CP12Ooyce6iToBJLqJgf8HTg38P3CqSaVamkj1tFWC zDaJMjvkapNLvrkTz72f7PQA/rRYWpqDXA953yrH9Rh+SJst9N6PRryfvE+U1JFyNBqBRiPQaAQa jUCjEcgnAn1EoNEI+y8SVAc13TyYkgdT8mBKHkzJgyl5MCUPpuTBlDyYkgdT8tB+LbRf6zd9d/VI dzSWMhpLGS2PklONAWNBAkgESWAcSAbjwWNgAkhxx2BV47Gq8VjVeKxqPFY1HovqgUX1wKJ6YFE9 sKgeWFQYFhWGRYVhUWFYVBgWFYZFhWFRYVhUGBbl/Q3qAjhYAAcL4GABHCyAgwVwsAAOFsDBAjhY AAcLsL4YrC8GLpbCxVK4WAoXS+FiKVwshYulcLEULpbCxVK4WAoXS+Gi97dzH8NiH8NiH/uN3x39 NtY9D+ueh3XPw7rnYd3zsOwnsewnsewnsewnsewn8dl+fLYfn+3HZ/vx2X58th+f7cdn+/HZfny2 H5/tx2f78dl+fLYfn+3HZ/vx2X58th+f7cdn+/HZfny2H5/tx2f78dl+fLYfn+3HZ/vx2X58th+f 7cdn+/HZfny2H5/tx2f78dl+fLYfn+3HZ/vV3RKt+oH+4B4wAPy/+j7INW46sWIlsWIlsWIlsWIl sWIlsSKdWJFOrEgnVqQTK9JVpoQpajqVDbZ475Egx20HOgLv3RxxXKve0fEMjO4Lo/taRj9ANTMS jIHhlzFbJ9nPeHaF3WNhd1fYPZa841WTQsW+wl1rvpHq5ls8wBZyl21kEzukDkw/CtON2UUuU8X2 INje1P71vaPcP4Y3XCuOO0CCQDCoBkJAKAgD4SACRILqoIZ7MwwugMEFMLgABhfA4ALpjDXdDH4T g+UBeQSMAilyo6TCpIngcTAJPOH5eblGngJPgylgKpju3i4zwLPgOTATPA9eALPAi+Al8Irb5f/y Wfqf+ZuU7oeyHGyi/tkMMkEWyAZbwFawDWwHO0AOyAV+sF/6ywFQDH6U9nIK/3galIMzoAKck2Zy HlwAF8ElaUb9kE39kE39kE39kE39kE39kE39kE39kE39kE39kE39kK2ucP+qrgQ1QS0QBWqDaFAH 1AUxoJ77oWroLlCNQCy4GjQGTUBT0Aw0By3A3e4i1Q/0B/eAAYB6Qw0C9wLqDnUfeFD6qGFyjxou T6iH5XY1QrqokXKvmuIuV1PBM+AP4I9gGpgOZoBnwXNgJngevMhcs91t6jXwJ/A6eAO8Cd4Cb1OB t3UH6o6gs7tXx3G9jesdMlj3kmt0b9DPHQxL9sOS/XqMDNJjpaVOAIkgiXuB9wWQW3cnt77VLHfn mW/cPmaf+z1xLMocIIs/SDVxmJrsiNQ3R4mPx9wzKkacyrMSBIJBNRACQkEYCAcRIBJUBzUqtxPj VhLjVhLjVhLjVhLjVhLjVsKQdBiSDkPSYUg6DEmHIVNhyFQYkg5D0mFIOgxJhyHpMCQdhqTDkHQY kg5D0mFIOgypAUNqwJAaMCESJkTChEiYEAkTImEC8Qk8C54DM8Hz4AUwC7wIXgKvVK6T2e522JAA GxJgQwJsSIANCbAhQd7m2RwwF7wL3gPvgw/AX8Bfwd/Ah+Aj8DGYRyb2CZgPFoBPwWfcXwgWgcVg CfgcfAHSwZfgK7AULANfgwx3OqybLiv4eSVYBb4Bq8EasBasA+vBBuADG8F34HuwiXU3g0yQBbLB FrAVbAPbwQ6QA3LBTsbsAn5+3s01D+SDAlDoLpMi8APYA/aCfeAcmc55cAFcBJckBOYmwNwEmJsA cxNgbgLMTYC5CTA3AeYmwNwEmJsAcxNhbiLMTYS5iTA3EeYmwtxEmJsIcxNhbiLMTYa5yTA3GeYm w9xkmJsMc5NhbjLMTYa5yTA3GeamwNwUmJsCc1NgbgrMTYa5yTA3GeYmw9xkNZS9PijdAn9ToRPs vQb2XgN7b1Gj3B1qDJY/kevjYBJ4AjwJJoOnwRT2NRU8A/4A/gimgelgBngWPAdmgufBC/a9kMnq Ja4vg1fAq2C2Ox3WT4f102H9dFg/HdZPh/XTYf109RV9loJl4GuQAZaDFWAlWAW+AavBGreYOFxM HC4mDhcTh4uJw8XKhwf5+U/qHFJZIBtscQ/hYcLxMOF4mOV4mHA8zHI8TA3dr7ICzzILzzILzxKG N5mFNxmENxmEN+mMN+mKN5loVrorzCrwTWWJWeN+RdzdZda6G8w69xW8zAw8zFlTTA1/kDGHidFH iLVH3ffxMt5fuJzuxsHaOFgbB2vjYG0crI2DtXGwNg7WxsHaONi6Craugq2rYOsq2LoKtq6CeRkw LwPmZcC8DJiXAYs2wqKNsCENNqTBhjTYkAYb0mBDGmxIgw1psCENNqTBhjTYkAYL0rD6A1j9Aaz+ AFZ/AKs/gNUfMNnuR2YrPpLK0Gx3R5gdbobJ4XQ73XwyikLi9PTKcpkBngXPgZngefACmAVeBC+B 2a6P0/TjNP04TT9O04/T9OM0/fA9PnyPD9/jw/f48D0+fI8P3+PD9/jwPT58jw/f48P3+PA9PiTQ Fwn0RQJ9kUBfJNAX3+PD9/jwPT58jw/f48P3+PA9PnyPD9/jw/f48D0+fI8P3+NDaiOR2kh8jw/f 48P3+PA9PnyPD9/jw/f48D0+fI8P3+PD9/jwPT58jw/f40Pa8Ug7HmnHI+14pB2PtOORdjzSjkfa 8Ug7HmnHI+14fI8P3+ND6vH4Hh++x4fv8eF7fGhhGlqYhhamoYVpaGEaWphGzr+UnH8pOf9S8viP yePTyOPTyOPTyOPTyOPTAt9nm0Mun0Mun0Mun0MunyOV7gfiuh8oAcr9AI3eR36YjVbfRqtPme2V lWj1r2i1F7niV2h2Epp9R05Q6cVQ6cVQ6cWQucTg82Ko9GLIyGKo9GKo72KIPzFUejHEpo5EwmIi YTGRsJhIWEwkLCYSFhMJqS5BK9AaXAM6S32qvfpEwlwiYS6RMJdImEskzCUS5hIJc4mEuUTCXCJh LpEwl2rvVqq9W6n2bqXaK6TaK6TaK6TaK6TaK6TaK6TaK6TaK6TaK6TaK6TaK6Tau5VqbzTV3miq vdFUe6Op9kYH/mpsKyq+VlR8raj4WlHxtaLia0DF14CKrwEVXwMqvgZUfA2o+BpQ8TWg4mtAxddA XpE2WPReLHovFr0Xi96LRe/Fovf+i2+57kDV1wGL8WMxfizGj8X4sRg/FuPHYvxYjB+L8WMxfizG j8X4sRQ/FvAQFvAQFvAQVV8RVV8RVV8RVV8RVV8RVV8RVV8RVV8RVV8RVV8RVV8R1tIbaxmFtYzC WkZhLaOwllFylkr7nNsBa+mAtXTAWjpgLR2UlmBlgAOCQDCoBkJAKAgD4SDS+4wVUaUf6A/uAVQN VGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZVGFZ VGFZVGFZVGFZVGFZVGFZVGFZVGFZeP8peP8peP8peP8peP8peP8peP7JeP7JeP7JeP7JeP7JP1OF xVCFXUUVFoP391OFxeD9/VRhvajCbqIKu0n3oTLrJ7FEAj+RwE8lNoZKLJ5KLJ5KLJ6o4NfjxOhP pY5eJFp/zTUDrHMf1uvdL/QGsNGdoze70bpIbtDlVG9nyGsrwCV3qImSGqaN+7Fp5y407UEHcKO7 yKyUCKq4NkSTz2HpRrOVqLFdqsHML6nigmBmJdElh0ruqUAlZwK/tzFEmUPmCBHmKPePuceppRyi QhAIBtVACAgFYSAcRIBIUB3UcFeQn+aTn+YTnZYQnZYQnZYQnZYQnZYQnZYQnZYQnZYQnZYQnZZQ Xa376RvjfuNnxvLJhfLJhfLJhfLJhfLJhfLJhfLJhfLJhfLJhfLJg/LJg/LJg/LJg/LJg/LJg/LJ g/LJg/LJg/LJg/LJgwrJgwrJgwrJgwrJgwrJWQrJWQrJWQrJWQrJWQrJWQrJWQrJWQrJWQrJWQrJ WQrJWQrJTXaTm+wmN9lNbrKb3GQ3uclucpPd5Ca7yReWkC8sIVdYQvXxNTlBHjlBHlXFQDRSQry/ SKxfghZKiPXxxPqL5kzlYVNBBXLWrWbOVVaY85X55oIbbC5WHjKX3DhTyX3XjXGCKg87wW53p5pb zQmprHBCK/OdMDfYCa885ES4cU4k96u71CbE4CV46qMmV6433t8fvAMPNhcPNhcPNhcPNhcPNhdm 58HsPJidB7PzYHbe//ffseV9JsZn/7JACQwugcElMLgEBpfAyjmwcg4M3AEDd8DAHfoj97B9R0TV /5XvhVl7YZQf5sw1W6QR8W0PrHlJNJpZCC9mwbjlcpNZIUPNaulo1khd+i4za6n+1kkLky19GdfX bIM926Wb2SE1TY60Z44fYF5DCTH7uLtfWsO3vvCtuTksPZl3beD3pdew0rfuZ/R/3a65hGdjYeUK qc6973m1xfrMf/pmCDVG4tDsFmmHVruwwl3YTy/Wq7rTDuuq4G53rGsF1nXUfovPMVGssl8a8Kqb /f1sHfo2Yz3vr58elOvocT2vtkgcp4niWUPO5X3WZ7CbZVKlM3td63QlAmrufMerzfRe5RaSy5bx qpBXiRLJq/O8+k5qkg3EkQ3EkQ3EkQ3EkQ3EkQ3EkQ3EkQ3EMVMc2UAc2UCcGSi1zf3kEg+CRM60 gnxjDfnxt/iKEDvvcvc0dwtZ8aBZjYTXwKRv3aVk0MfYZyr7X84cq+jFzthnpNRUW6WJ2iZtOcWD 7Pk2cz+9qr4f4jr7/RCJ7rfeZ0HM4+4+85Z0Mm/L71inFA00g6WLnJukvdNZ2nKyB6QhIxqyTkck nyqxrHTcW9+uFMkKxayw0Qxh9FD6D+M6nGsqmt/q7iZvKiFnOmf1ulNCGEXMZITXO5qe0fQMpWcp PcqQyH6Yin8gel/0PpVl5U+tRS5WgoZqwOptdr4cpJ3LKOb0PD1zDnQPe+9zZERrLLSa7Z3rnibf unzOIdj9MJDE3lOJIFvck6xexj5L0X5t5i5n1AbmDWfes7QDkdFgkIqVZyPxLfTYym62IfHt7D2X Gap2cRH7Hcjdwe4Z+3393nf1T+BJqsQwMpQdBTPyDCMvMjKStSq9UzPygvf/K/J7OQCKwTlpQQXd ggq6BRV0CyroFsx8HzO3NUNg4VB5yAzjOpxrEnXHBPbzuPuheRq9viU3os8uSGwrK3a2st3uvmdX y3F3Yt9RZK7nAzpujwwGsofByHQIGOp9kz7X4VxTpR779tgVwn7D2Oshs0uusFpfyYi1jDjAiHqM OMCIeoy4kd5XsOZBq/nt7gXWPcvIA3ZUjv0O+6pPNcUGPtUUaybiLfZJYzxBGXwMw2PE4DGuxA+s xOaq5J9HL8OdMuQ4kJ8GW9u033RkUtD6JHzaQfZ9mBWPuKXWHvYw7gDjwpg9hJk1T/LY/0j3JNnx SbLjk2S8J+l58advWKR3Ndt7P1o+iKQOsacj5PxHmeWYW4L91rFa3mq/X/d+9vUgSGHHE/Fz+5Dx fjR8AOu0J8EfHeb8R9xM73dmdu0LrH2BtS8ETlby03ummUUzS2vWv4JZKpilklm87yQLYYa97EFj JyPlLnkEjAKTpYc8BZ4GU8BU6cGsNZj12sD3jvYLfN9oPzj/CZL6Akmtwk42Yie9sJO7zKfua+x7 M96wedWK+GNvxcNuHjbSGRvp7HQlrw5h5jMB3emA7rSVl3fSI94nG+mxiLXnBXpFB3pFs3YpPdvb Sv+I99elTWLlOmL9cWL7HmL5cWL3HqdlZTH6Tqws5W4Zd8qclm43Zk2sLDJnkMcFRl+EX5fcbCfI rSDun3XC3dP0zKZnTzv2W55u48427oTZsaXmPOtd4GSX3FxyiEqH7JyxlfTKJVeopGcc3E6sPMgq lWQhp9lZiTnH9QKrXsQ6qkZeZNVKso/T7LjECeEaxi7CuV8100VOUI51JJK3VIhiljJmqWQW13jv MPPWDhbF6DJGVzLaZeThwB5aeXKqnM0e9jG6CaPzGX3GUKXa3V/E3i5hGZXENde9xF72MVsTZstn tjNOqJtjTxXu+p0IuYJM6CgzX2JPaV4kcTUznmUfhaZSNKPOsnahE8nPLd2rvR6VW+hxiPU8SeXR 4xBzelLKYw5q3H/UF9oP6InRv6Af29fqhb6/oA/O+B/qAZ/2G+UP0//LcueM/0Le9snPylmqO1ES 6tRmf3UlzKnHbPUZ04C4eRU/N+RZI5415llTXjfjWXOetcCvOE40K9TnaSzXZugkwoniVW231KnD +vVYoT4reXM15H4j7l/N/abcb8Z95kELXm9v5fqBHt5K3lw12ZfmabETzZ06oK40ZH816VnMnA3Z n2Z/mlHFTizPrwaNud+UPs2415yfW3D26sxSyF69E2onhr3Wk6DALN7oQvbvnVA7TXjWlGdVozXn jQK1sb1o9lyXeetxlvpovwFrXeWdi+eNeB7L88Y8b8q9ZjxvzvMWnI9ToJvazBvN3TqgrruTPVQi nX1OA3R5FWduSJ9G9Inl+dWgMX2a0KcpfZrTpwXRxdNThJVrXYliH57EzrKPKPYRzj4irGwb87qp leBZ9hDFHsI9rYixZ68XkHPV7j3pGXvuqhFlgV1rqfHv2gSsLUV+/2AXsL2NRP5W22BUW6n2r+yD p82k1n/LRpjtWk79b9oJo1vKlf+prTDLTd6J/jv2giY2WT3+WzZjY0Pkb7Ub69VbUlcfwZMOw+M0 wKv1oa4uw6vdTl19FO8zEq8Wi1frTF19BI86DG/UAK/Wh7q6DK92O3X1UTzTSLxaLF6tsxNVeQaJ XIdEWiGRVk5dXse41yKR6uyqHVJpjlSaOQ2534h+sfS5GjTmdRP6NaVfM/o1p18LrCaU6iWCuiOO KjOS6rIWGWcU2WZTsoobyRU2kHHVgAVDqaquE5HO1E2t5Vb+tZXeco+0k0FyL3fvIx/qIo/KS3Kn vCILJVkWyTJ+Wi7fyBxZw7/3ZJ3slPfFT4b9hRxStWWNqq/qS5lqqK6TE+ou1UeJilcDlFb3q6Eq RD2kRqoINYZ/NVWiGqdqqYlqjopW7/Cvs3qXfzer9/nXRS1Qn6quao3aouJ0W91exeuO+neqv+6s O6tBupuOU/fq23QPdZ/uqXuqB/QdurcaovvoPmqY7qfvUcP1ID1YjdQP6AfUaP2Qfkg9qkfqR9QY PVqPVgl6jB6nEvUE/biaoJ/QM9Uk/YJ+Wc3Ur+q31Et6jv6zekN/pD9Xb+l0vUF9pDfqnWqZ9uv9 aqM+rI+pHbpMn1C79I+6Qu3W5/QF9YN2jah9RhujDphqJlIdNDVMTXXcRJkoddJEm3rqR9PINFIV 5mrTWJ01TU0zdd60MK3URXOtuU65po1po5VpZ9prbTqaTtoxnc3NuprparrpUHOLuUWHm+6mu44w PUwPHWn6mHhd3Qwwg/WV5n4zQpPvmCQdayaYSbqxedo8rVuaqWaqbmXeMm/r1maRWaSvNV+aL/V1 ZplZpq83GWadbmOyzS7d2ewzx3QPc8a4uq8T5FTXg50op6V+2OnqdNWTsBQFwlTn4E1iRjw5IVGi Rk94JEHGJQ5PHSfvUIure/p3j6X+Ede1764LlvpyNdV7ayyrIxZ1m8TLQOboJQ/IcBkd6BdJRd9A GkstuQbbu0FuJuu+GxtU2N0QeRgLdBhT1bc6MecqaSJRci3rdMI+b5d+WKvGcofKCBlD3Nb94/vE SpcB/XvHylg7rhb2HkqeX1eaSm1s/nfSVW6RntJfqHmoBe+SB6kBqvri5ThJI4mRZhIt10sHuVG6 wY3fw4z72ElL6SMPUS0kBGb23kkYK/WkOVVMG7kJLnWXO2SAUCtIK+krw2BRoiSNaJ8yQs+27Tu2 /ci2i2z7tW3XjhiemKozbZtj2wLbHrBtiW1Pjxie8oi+6LVG2zbEttVtG2XbeiNGJI03sbZtbttr bdvetjfattvIxDGjTQ/b3mnbu0eOS04yg2w7xLYP2/ZR246zbeqoCcNHmMm2nWHbV2w7x7Z/s+1C Jhtultp2pW3XJo6bmGS+s222bXNsm2fbPbY9mJg8ItGU2PZH2573Wkd4OMEJtm2EbWvatq5tG9q2 aTIXp7Vt29q2k2272La7be9InjBynNPXtgNse/947/4w246ybaJtJ9j2CdtOTUHmzgzbzrLtn2w7 x7bv23Zeyphxo5yFtv3Ctl/b9hvbrrftppSkEeOdrbYtsm2Jbc97bVCIbaNTJj6cEtTUtq1t29a2 nWzbxbbdUyaOTwm6w7Z9bTvAtvfbdphtR6Wy86BE206w7RO2nWrbGbadBZ0MvKwDI/6dn7T3ydjf cFVw4Zdb51e0Df6pDf/F1uAzQuH0v/OTwoP9Y3vFr2i1Pb1mJu+VCvhOrw35FW2NX9HW+6e2+q9o r7T7MvaqLmu9/V5+L+IX2yB8XxTetMoi/rNX0YFXv2ZdhWf+5TbyF9rGeP++xJgH8c7j5HGZKs+R 2bxFLjOPLGcpGY5PssltiuSglMoZqVTBqjp5SkPVXF2vOqluqqfqW6VXdUXgWi9wjQ1cO2H93rVL 1WsdW/Vazw683lp1NfWq7ptAf3N34P7kwPWtwDW76kpWWnUNPHc+DVzzqq5BHauu1T6yWlWhBVWv wzoFrrdUrRN2Z+D1rMD1YtU1omUV1yIKqq41gqvu13g0cN0UuOYEroF1a5xhvTAwQr1pGfCweoM2 hJPO9Tigyr1aVRxzu/m9ucP08viha+qaGF+UjrYj6Guqe31NJDaq0I7C51Rxh7xcItQJdYKX5cyl 1Hl1XrRylStGB+kgcXS4DpcgfYW+QoJ1bV1bqul6mipFN9aNJVS31C0lzPRi5XDmqsPppnnbVjXk GVVPXSV/UC1VS5lBpjpEniU7TZLnVbJKllnqMZUqL6pZapa8Srb6Z5lNRnq3/Emn6omSrieRG32l J+vJslRP0VNlmZ6hZ0iGnqlnynL9hn5DVui39duyknxyl6wykZzxJNldRzlFLtdDTrOba6WW/sDc ZeLNKDPajDUJJsVMNJPMk2aKed68YGaZF81L5mXznicF/b5+HyfV2/RGUn1NX9FmpHlEjHnUjJEg cr8JUs2kmlQJMY+bx6kHnjBPcHKyQQknG5xOdTDXzEWyxvqO/5VxQ08L+mbt6aaabqfboZtOGrvR N+mbeNJFd0HWPXQPZH2nvhNZ340cguldF/m21TfoGxl9m+6l43VX3Zv7ob9+Fj1NT2PV1/Xr2IEW ryZr6DRyYp2rncZOE6ep08xpbqt3ZZZT1Yjdfd3Ldt/IWk6i18Pxqt6qHg0u6xF72TPt/R8TvcXx qkXltHRaWrvw1o1yajvRTh2nrhPj1HPqOw28qvDv62qyyBpOTacWOXKwU80JcUKdMCfciXAinepO DecK50r6OEj6GbbgjdFk0N2oRm91boUBmry1rpln5puFZrFZbzYYn9lovjPfm01ms8k0WabEHDel psycMCfNj+aUOW3K7e+4PjYfM+Mn5hP28pn5DL2Tz3MObw3Hy97/PvvH9PqMp8vNCrPSrDLfmNVm jfnWrDXr6LffHDDF5qA5ZA6bI+Yo47zZ55l5zD7fzGf2hWYhsy82i5l9vcli9hL24M1+PbXkz836 M+ewMtvHOAmM+5mV/8VZPVln2XGNpboaqO5V96nBapB6VG3XE/VU/bx+07xjFpgvPJ+j7lYDUPBo NVqC1Fa1FVtK1anY0hQ9xfseM3gYankYZuaYOXDAk2CE+dx8TiTQ6oyclekyQ54lBsyU5+UFmSUv UvW+TER4VWbLa/IneV3ekDeJD29T+f6ZWmeuvEv1+758IH+Rv8rf5EP5SD4mdnwi82WBfCqfUS+n EUkWyxL5nNo4Xb6Ur4gry+RryaCCXiErZRVRZjVV9Leyljp6vWwg5myU7+R72SSbJVOyiEBbZKts k+2yQ3Ikl3i0i1p7t+RJvhRIIdHpB9kje2Wf7JcD1OAH5ZAcliNyVI5JiRwncpXJCTkpP8opvEw5 cayCs56T83JBLsolqRTXc8zUy/31PXqAHkjNfK8erO/T91M3D9FD9YNUzsP0cP2wHuFVz3oU1fOj 1M5jdYJO1El6nE7W4/Vj1MW7dZ7O1wW6UBfpH/QevVfv0/v1AV2sD+pDVMxH9FF9TJeYMH1cl5pw r3rWJ6meT+nTulyf0RX6LFX0eX1BX9SXdKVXSxvl1dLGMUEmmHo6xISafqa/uYd6d4gZ+j/VXAs8 VFv73mv2uJO7MGioJNc9LlFEIl3JnePOGJmIaQxCxUxFuqmkootBREpJuitKF6J7Kip1XCspXUiK b+1N5Zw63/n+3/873/l95me9s9aavdfaaz3v8z7vMj9oABqILkGXoqvRNWgymoKmo5nobvQI3Nej aBnMcU/C3PY6egO9id5Cb6N30LvoPbQBvU82J1tA1MgP8z/B5IkEM/PReZBR78Kc2gFpgNm0N/IA 9UP9kUaCJx6hLJSFPIZezUWeoFvRrcivBJpaCC5tJXyzjUBWO8RlEdJBeGgn4aHP0ePoCeQF4add 5KnkaXAnSOAc3MO/Bne/Rd1fhbnH/xHU/Yi7r8j7Ofa+ow/H33cE8gkM/ndQmInjB5CAPGQdZagZ 5AgGGk8oBy3gBxiIDsFGRvhJF2IMwqCWMIFaIh4xA8uhOrIFmWAP4gfKwQ2ETmJDflpJSiVlItuI yJ6PiqMySAF+aoQcQhVQbaQE1UUNkIsoDaqFKwTqmmA8mwYjrwyMgGqIJtQPxnBO+fCFlzAmEO9L iFrFSK0C1h7DF/4tOx2gA+euD/ThRpgBM4jG2WA2fNT5YD5ChhpnJ1Tmw2quBL6gKgC+IGSk5fio lt8rCHVCQfiQFhMKwpnkDD3Mg+QBY78XyQv2+JJ8YexnkBgw9oeRwmDsX0paSigIDfx/s/5GQThB VPwC7xUM95uFa8f/g5bARxYiRhYmRhYhRhYlRhYjRhYnRsb/drQNmQ3ugLvgHmgA98ED8BA0gibw CDwGT0AzeAqegV9BC2gFbaAddIBO8By8AC9BFxklk9FetA/9iPajn9AB9DP6BR1Eh/4/bWS4+GQ8 b1SG6CIR6lQKzyxgboHC3EMNduMaVQDiDT4lxJsXIgT3Af+GPY40Eahaw2E8xFWrGIgGMVAxrwAr YARNBamIJFgPNiBSYDPYjMjgJ66ILERgOURvJaiCeL4MriBjQR2oQ5QI7aJMxGAVIoJjhIKxJRSM HZzfNDjDf2PNRvzmb3wyiBxtQjN4Qa/5swywDrLgA8h4rZDb3kAe+wznLgzzQDk4byrMBHWBIfQe S2AL5gFt+Bxa8Kn0COsFfQq3vmAqYf3ANML6A3PCBsCsELeBYDphg4AlYenAirDB36w1YUOALWGZ wI6w4dBPcRsJJkNPlITeTII1XQQ/Z9cnfNMAln4Ag6U/oMEyABjCMhAYwTIIQLaAY5nAMhjmqSTA AKawDAEzYckENrAMA7NgGQ5ZgQRHmQNLFoB5AcyF5sGSDRbAMgvmwCSwC9jDcjfMqDDEDJmBzEEc EU8kAAlFWMgyJAlGtk3Qx7JgxCqA0ekojEbnYOSpBQfgE2TBWRcT1hccJKwfOERYf1BC2ABQSthA cJiwQeAIYengKGGDQRlhGeAYYUPAXmItsolV4BOrkEOsQi6xCvnEKuQRq7CPWIUCYhX2E6tQSKxC Ef5sBMdpEdYBaoUxiBZiiFgQZ0NjILIUiLUeS6yR4sjnyUDp27tQfCWJEzBxsJ1YK6LEMwMgBbGP AHkYPwCBcRKBXJT4Loo46AG9YACSgCBJnCRNUiBRSONJk4l8+T+Z/0ImJ3K07xmfMJ4Ffcuh/kke 9C2Dwu/hRwr/xvl4BMDPaBSIXlgjByBfT+6QkfOvb6dhFFto5YabKRYYj2ImKKKdPCe5TwIIkfg8 ymTYNJEEAE0MExEU0BmDkpQFECxQUFRHEJABz5QEyHwXzAnTHdWikquWpAI3CX8tRIKQKCQSCUcY CAf+WuIvTH3Uzchyks5ZQCFN28/Ye75UvlWgxa3YjWp8nnwzxkOr4a8eH4VkRZKafV4po3mjs51N X9OSORK0fZjEt6kCATgp7npikqgbWVCW5GVNk8dk8YqwrLgHI4rDYEdQbQJZDJocJoM3C8mK2Uaz gwIjYpjh4QyaJLwbbBWVFXQNDYzlMGiqGAVvEJOVG26g2jDYHGYIkx7IYUZG0MZhqng3Kqsw0u3K XAJHCVzCYkYsotpYY2pjJTAjmiFmjBE/XmMlaHjVyNDIZKrJVC/MZdRk3VxoYzH54fHHuDPYTBfm oghd6twIuj5NB5s8PJDG1w5iKKrL17FcGOwYJp0RhQ/KAxqjVwUIICgPSCKwXZTEAwApqj26r66e elh0RerBlOg3xxx6mqskzy8KrMgLVmk8019rVLwaS/VcuaEp7PGUvZLnb3UtextbsDLS4nz6YYnT oe/Dt9VWOOsVz5n+4fg9X38KKfuTQZjavr68rALlq6RniQucW8YEdM1QWXlK4onVlWPNKRX+8Ytp +mgmV7ZwNvU6LUrCQ69+mbFRhkymzKknoQYH2lsurNugfXG9ekpIxSpPj8jo8xYHNFN8a6XkLbJX v3CtEo2oHrw07/EpIekdGsubLCfdUlvWlU2r6WnXUGqqLpttk6Xsz1fb3Or3oXt5z4riIJD2wV7s yU0N98KM+pK1MSXdpyXetdo/5A+E8kvkzMtSqs6QUAj8PG4Txn2AGQsKQ8QKCAgB6HCYJjbhax0D yYqhHA5rmoFBJD2KpR8D1z0Krrs+PXIJgR1VWQCGyMKYIDQkgGDWeNs48jTMDJvCN+YbJmMjl9PZ 4b+52mAYK6OhYmOtDz9FIFV1IlkcE/06C1QYG4M3SuJjkaEHCMIZwro0GSJznxI29iu+UVlxVxdr CDQzPZqeidHvvALlcpF5Yf0vPC/YqtBS4zJ1tp/nHQQNKgvqj6zzjGgWnpznd7U2XbaD7CzxevYk A8TsSGtNukPWXY0g+T4rU/WFLFpSz3qzlLLOzh3I4A237Q4TbhdNcogvORFo/U77ekfNQ7/HZ3TW WJbvKX/4zGPo3LFLKz/cEN/7Zsegzh1zZwrFbFKf1Tzow0MYj9Qx4scSz3Xe3H0wea2ioYCIX1bM 2t/78V/iGT+6I2Y22h09/sVBDTC94UE1/2xQvI/B/lOXPOqoNefxndD41Yq2IdG+K6tPZtM1h6bb 7F4ubSY10S3qYfQk5heHU1SfO6L9fIr2Kzd39cAHak2tZ43Crrx+nGfK2ERJFz/uouazPMTEX2Dd rMEYh2aXpFwudU/JWp9c4b42rL9bw3TBTNHrzZfHVTe4PedalTvn6R4A8W9zD2w0Gcxu910skD09 rOX89srBuoD+GR1CfNuXXKeIfO23x9dJab1KeyTIT3bMSpgnLIGp1krtDet77llCLpqReVSrM03h oEWLS+T8OyZ7yiODVcu2656Z3hH3ckl8v0K75qHDrzNdTszQzTgZd2DwrnPxZM7KmV1T1XIXK7T/ cmZC6AMkyUYqJSlsxCVrMe6Vf9Mlxb+5JAlDMKNhZ9TFtDEtviZ/QrLGHzkjJypKjx5IuJ8C4X74 Lf6JBwpW/kseaPx7D8R3OWUZq9HBGVC9n8bV8LDqL6eUtldsQS5W1Ndffj/mwVC/faVRECZ96QOH cnfrE//dVNnS5bPOOdav6kgau2r/pPRFsnYDtSd3WqN1u5y8BdYnFka+ozhSJui/ZW4M1+g7U6uQ 8UqcUxka+/BlZlBKVdTmj6mc+PHFeTsTdpT2pU1eaq8fTZlj3fimXILq2hDL38GjM7+I3Fj3JvqM yK6H/dJumlmBhufiSUcSks/lXlyvobvslknM2a1RPv2n2hfIi46va71911h/7gx5C8mA+AmX80Ne b7/BemnZ8V5i5aNby/NiljKrdi+cjZmol+YeVg6y0Hm46YC2UMIDxTKfhF/35EcOWqQewnhkGUgB n4YpQBKpQtZbWKyVvmXZS+9qnjF6xciQAVhffVtMVsMmkhXHZi4K5VC16JOptKlTTan2TDo7Mioy hEO1iWSz9GlqmMrwh+V/2xPJHo7V6ti44W1S/N7vHBnJoVpHc0Ij2UxOHE4PU00xGg3DTEfowRCj GRrRRqp/w4z+NJSTKqpY7eZvHSha2TuW+WEvcos2TvT/OJixIO/E4J5cquVyp9xduWkBhmG3ZgbH dR+MqXFtfPtyd7JKWvbqkLJLYfFB4xtULZ5Igq2d26vP64VkZYVqZt6cpntevNxTs8quQ9TSbLtu kdbUwq65q2a2rJY8kxXuFniQtzwnQC92wfPMY8HmWY4qNOEJctlFHVt0FNun76TLBXgKMLJVTZ1T +va/3ka6TLlz3m1WWWrS+WldrtscSr7sj1/CcTisWLddREsd8dgcwDQ9M19GyMJ9yHtgX4iocMFt rrvH6+PmfgrcWHJj77mSpIzBI/WJDfuV2T4WtWffCOdpYGWCa2rKqLGya5pHeKMQ4+Zj3FzcLwGZ m4VxdyRJed9kvWay9453Wil31H7T0LUc9n9//3h/gnGCFTI6xSo3vtuhaPLqJJjwIFb6nU+AYfZe sWuWAlvWptVMa1d/+8YjXbecP/tq0OvP9+vMzb2KprgyBycssaqpO/BEYPlj2sbp2VKsxWcGZRYq Mis/37RpkfaiLnwRlHD4gNJVHdOJeucYOTLrJkrS8/pcVfrVaxrk3zkfjLAxFPrCG/uxbVG4hFNv RY/zlYqOauwzlSayVjVjsrL9PVVSfk/SU/SY9/vSx1c9uhlzrzi7Hj+GaskMbW54I5y28uSOS8Wm uq3xrYWxLTF85OZiq6rbU9Y9tZYpNFlMWdxk8uyuCrm1cBb5qpeRWYS9ikTQCdHcDXfuuVrZ1au4 FbCaZKalpEdn77/Nh6xwEYqDwyPCYLFY5sJKRLVYurGalBMy6fTXJEH176IEbArUC8Y0U2NjmjEu 4CHFG075Sgncgt9KBllMejjdEPUIjAqFUoADx5EiQghMNoScGcFLIiOCv85M9I9m9kePaQgH/eEx x2Pqw4+hPLonmEGID1yNOBJJAfVHJpHAmUSYYJKLddSNZ5uHLB274y/cnTCxN+a6+lC9trtD7e4T vKMmcXpIdaHwPXrNifze51VVDaUbtucKfZI8znPOesm7XCF1qbCyO2z1JhfKGcdPwSC1SuEuLxSZ scz2g4yZwwDd6emn6afaTEub6ULjzZfOMJ79PqzE7sOkKDWNazOV1JyOO2fdybspe1nJaqngkrcZ 6rb+M19V1mQGU09WGX/OtW1POKpqcLLgyfuc5l3qkoOeNGs3s5WHPTtau36Jm1jcp20gbWW2zHJm 4v7Q1pUaoWPb522tXmbrPDtn4erU9F2VixJeiAwkoyt6M5da6OwP2VnXrPerDklZ0ngO44OFzOGe FBVVTefIOog9NI8HtOF6aP5Mh6P/G/QiIygykoDLQ34hoShCJlJU1TFkBbLcxI86832vsl0PtfXy tccqDFT1u3AxpW+XyJHI4mqiiAsSDdN1G8QaEyOED5F32GGS3wSWAIZCM8ovCRqjtzx9J3DyyAsx MeNbPJplatCse8L7+wMZV/XRT2ZzrG+Uv5206k7LJXeXwnKl63XtPfx+9+Nzts2e0FY07lH83V6F eJmmd5spXcK+ZWs2n9rgeUalLuNOxjaj91ueDK3d5Td/ruNUzWlUiqvp5xU+8ukXH6lsehPobNEm 9CrkdVxX2nUPOiNDcS4/vplxolmzZPCqzPHLuXWX/dez3tU2FfMihB4xlE4V9iZfEJm5s0fzIDO+ tEpn/5GQcfmHU4TDdsiePDIlU00gT9Ysr/IgZnla/T5WUBsko3LYY2NbT7z0aT8LcdOe9Kqtax3I XgI+V240FD18tmLLskkDxyLy0wSNPEv9tKUlMZ6AEaQyyjCNiQba7b1GHLcwfjih+F+hjO/cN9XY yHgKni2ZQm0EqyZ4FeP8Jc8x0o/+Qf+fSqJ67nazEp/ct1XNT24WZ2xssNgzbv1F32R93zel7A/F B9cuLm8s1UgQu3o1f/4WPw3Z5/0fxu8pfx8RU/K6e5/FlerKX3ysisuijDQLgriBcTlB7yPWZtyM eHwl+/Y+J+mYwNOsdYyc7Qqp+325N21D2prc986o/fwoZoK+LYa0NaxIyJC+56ma17lQrGbto9wG l8zwWnpt5uKsrX4L7KU7De54e/v5O+dF6eWfWT1LYoOSfMw14casApZ8p30X84vv0bC0V5OdTM3W X7abK7/NceeR96H77j8RWbqIszd2g+qasB0vOvxn1T1tXypxi46kJ9B2bhI7JltRdrO7p1m9uygg sNvUZvrFYUnEA1vhimz6IXf5TgbdD8OKol3qF3ZTHJQE1fJ2F9/Y9uUPmK8Ibx1P5uZg3L1JP2WR HM6+v4P/fhQL84cTP1tsJjaDb8m3SJ42KvFb8vU+RObHCmPirQYsdmRwNJ0TZYA7AI5/iH1DIiFc OCoTtcGsMatvmSgp2WjkvrGxsT+7L4P94w05P8sJzR6+zjDb5bNTztc1gtlMutpRNnDngv0hg+JE V4lGw+MfF7dLDKgrx1rmh8Yfy1i5zuetTfWqXYwVax2dlvPkPqyKup97zqeWxLquGT72rLNcfmrl idacupzoPVuWTqdUuiPu5R9Xazb6GQ00TIz3y2osGHj/1lr5oJvdoTmPtpjJeorM7XlHSxl3lrzJ W4aBPhdzupkjvi6z4mFV4U1h+Ynq5cc9UlVueSeb5Nd+OZDSVWRqdcImrIXaM+vsypLnPW5Hc+ac ZZxzMX5Y0ylIJwsui3AcmnNm1wsbr5SmQ6JJH365pNvalug9r80wrltjzVZxvTJH78sXZnh6Ft+u bzGoqu9akm0aR+ORr0HavEICAOOW/8+Q428I/vsxNp/bicl9C6hagCaEChBfPMXD7MjWi6A08dEn 53Dq32titDHY6F55bPz3C8k06LcNOdnNBuLzneYszQmRaBJVfGFq+Rljj7pEnBaMBfHNkqYg9ggT oSNsJJI4fA9BOAgVsYPvIoh37ggD9kXBz+AtVMQE0UcwBMvRTJrwh9jmxLEiF7EDWaFxv1eTZB5A Er0aHQIWDWn4n709b4rPwOUE8xYdN7uDbMsEh8RT9yOyDlpX21t+bBTIIvWUe34KLVswP/2FjM+e VJlZ2mN3KPnMt5T/lOrNfqW430twboSOSmbeNJNtNXu3xDcHJjK2bejsNJ6rlCbcir3IiMsrVZ1E bzviWrzBN8MXVSoM1b9x13HPuOWes1D75clUD4FlBkaCBtueTVY43CevqBTxPvb4uwV+A3xxtMG+ 98vhWc9TVideE2NVbyT3rq7dGT/GMyRuX5zygk8WXVaD3Ofur3+dziFv0s+3oL8Z/+jkEXe7DvbL AEU6CXF/6JqXVsmTjG5j9btuM3O8MlDaeV/pTQfnKS/gg1wOD8oiHhj4vmOCNB7ogk2dOLwX/SWH mj85ShUXFB6eAAmyDP8XTHE09sS+/2kHQOh96xGgSeLxHgZ4Q/zIg2bqBfl3FPRkyFKOhhU6+9SF YzQ0Pz5VX7Rs+U8gkF6T7s0oUtx/77Xnxp3iukIVCV0FlNdWlDVOgceuTm3eFWeuOn9Lxa8k5inu u659kuOySlXDE8Xy1KSmiHxy0HEbtNFaUm9J7jsUzm5xXqgQtzRdosukY0XANjs/pcrJJZs+BV3Y MrWseDXDqOBJr2942YtduzVjcyfXdypzzUH+S7YzhvZ6qtZdnze0J+hZWGir8a3Tp1dM09N45RHE NjoaGdWqkuOJdf/qwri8fofFNc+NWfn3KdUH09SvmauWGs1wxCKPdphbHaLQexM72rbqJ/Z/5Dye SQHXnmwN3tpw8vIb71VH/BwvxnET1p2ODE5vs9Zi5i9qLfFdkWTn915bm4TE8/8B7ZhxrQ0KZW5k c3RyZWFtDQplbmRvYmoNCjEzNTYgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg MjM0Pj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeDEXbSLYGinFLLoD017AMdWUkNjG8VZ5PaV PcMUKrDhofeJJ8lT/9QHn0G+U7QDZph8cIRr3MgijDj7INoGnLf5oupvF5OEZHjY14xLH6Youg7k BzfXTDscHlwc8UbIN3JIPsxw+DoNrIctpR9cMGRohNbgcOJBLya9mgVBVuzYO+77vB+Z+XN87glB Vd2ew9jocE3GIpkwo+gaLg3dM5cWGNy/vjpT42S/DRX3/R27VaOULuqxraq9rezFVaaUZa8R7UbE 6epFaqwSyAe8Hi3FVKjyfgGKUHHfDQplbmRzdHJlYW0NCmVuZG9iag0KMTM1NyAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzODgxOS9MZW5ndGgxIDE3NDQwOD4+DQpzdHJlYW0N Cnic7H0LQFVF/v935pz7gAtyRUUElINXSEFFUVPR1YuAVogv0MA0ucJVMATi4StLephKD6s1t+xh j63s6QXNRa3VzZ6m2Vbbaysf2TvT2t4p5/85cy+EW+3C+r8/TOYzzme+M/Odme98z5y5Z4R7IEZE XUEqlaVlnTtOiQgII37jHhQuHZeWPnbVD9edS+y5wUT8qXGTJmZdMu3h9cRe+J7okYhxWVPHvDcm bzLxBZ2JIm85Lyt77Pz4IjPaP4Jee4zPzjpns7WDiyj2AFHwzIlZiUn2pEtvJWJoT3mTUsdnn7hk VCqxZ48jf/a0tMycSTfN+4ZokJOo45r8+a6yzB5sCbHlS9HmpvwFldrdUW98RuxW1Juz55TNnb9n ce46YivsyJfMdVWUUTgFoL/P0Z99bvHiOcdX5e4ltn4N7L+wsGD+oo/f3ZxAlPYaMeeGQrer4L2L s4+h76XG+IUoCB0UjLmyzcj3KpxfuWjgJbQdbXOIHCuLS/Ndb0S98Tixu78mitg837WoLLTE9hP0 34S+VuKa785Y4lhE7IkNRIG9ykorKvV4Wgt79hj1ZeXustjXM3cQu66ayPZXMnxv6rZu1L/uKZoV MvIba6SVDNzz/lnxRvrCIy9s/3Hjibl2sgYhGyD0DSC1jGqYQKl2+nHjj0vs1FTjg3qRURKcS0HE RQEnOyXSNNQ8gnENKMpKdgOZyGpaZxqEDiK9qfJ3msNDrSZuM6vcgHqA4vWdtChVWABkZ6Zq5KQY rafp1YbJbJBlFKtzEtN1Hb3HmbYbMyXV7DOJD6fG1EMSEgDfS/Pb2oaWQK3Qj7e1DRISEhISEhIS /1dgG/RtbW1DS2GK/P3YKiEhIdGWYKRvsyLaSe6bEhISEhISEhISEhISEhISEr9/BOdaGKOH29oM IrMfNCUkfgH231X+B1WJ/wLGpDclJCQkJCQk2gcUUpgBk6IwjmegcNPntp30vVUnK1n1BgqgAP0E BVIg2EY2cBAFgYMpGNxBcAh1ANspBNwRfJxCqSO4E4WCO1MncBfwTxRGncFdqQs4HPwjdaOukCOo G+RIigBHCe5OkeAeFKX/QNGCNeoOjqFocE/SwA7w99SLYsCx1BMcB/6OziIHuDf1AvehOHC84AQ6 S/+W+lJvcD/B/SkenEgJ4AHUDzwQ/A0lUX/wIEoED6YB+tc0RPDZNBA8lAaBh9Fg/V80XHAyDQGP EDySzgb/gYaCR9Ew8Ggarn9FTkoGp9AI8BgaCU4Ff0lp9AdwOo0Cj6XR+jEaR07wOZQCPpfGgM8T nEGp4PGUBs6ksfpRmiB4Io0DT6JzwJPpXP0LmiI4i84DZ1OGfoSmUiZ4muDzaQI4hybqn1MuTQJP Bx+hC2gy5BmUBZ5J2eALBc+iqfpnlEfTwC46Hzwb/CnlUy64gKaD3XQBeA7N0D+huYILaSa4iC7U P6Z5lAf5IsHF5ALPp9koL6F8cKngMirQP6KLyQ0up7ngCsGVVKh/SFVUBF5A88ALwR/QIroIvJjm g5dQCfgSwUupFHwplYEvo4v1w7RMcDVVgC+nSvAVVKW/T1fSAvBVgpfTQv0QXU2LwCtoMXglLQGv okv0g1RDS8HX0KUouRZ8kK6jy8DX0zLwarocfAP4AN1IV4BvoivBf6Sr9P20RvDNtBy8llaA/0Qr UXsLeD/dSqvA66hGf49uo2vAt9O14DsE30nXg9fTavBddAP4bvC7dA/dCL6XbgL/mf4Ivo/W6O/Q /XSz/k96gNaCN9CfwA8KfohuAT9Mt4IfodvAjwp+jG4Hb6Q7wB66E1wLfpvqaD14E90F3kz36G/R 43Sv/iZtEfwX+jO4nu4Db6X7wdsEb6cN4CfoQf0NepIeAv9V8A56GLyTHgH/jR4FP0WPgXfRRv11 epo84GeoVv8HPSv4OaoDP0+b9NfoBdoM3k2Pg1+kLeA99BfwXqoHv0RbwfsEv0zbwH+nJ8Cv0JP6 q/Qq+BV6jf4K/gftAL9OO/W/0xuC36SnwG/RLvDb9DT4n4LfoWfA79Kz4PfoOf1l2i/4AL2g76OD tBt8iF4Evy/4MO0Bf0B7wR/SS+CP6GX9JfpY8Cf0d/Cn9Iq+lz6jV8GfCz5Cr4G/oNf1PXSU3gAf E/wlvQn+it4C/4veBn8t+Bt6R3+RvqV3wd/Re+DvwbvpB9oP/pEOgH+ig+Djgk/Q+/oL1ECHwTp9 AJZ7uv/39C9/53v6Zy3e0z/5jT39k1/s6R//xp7+0S/29A9bsKcfbtrTy0/a09//jT39fbGnv/+L Pf2Q2NMPNdvTD4k9/ZDY0w8129MP/mJPPyD29ANiTz/wO9zT32qjPf01uafLPf13t6f/3p/Tf797 +m89p8s9Xe7pv76nP38G7OmEHZeCZ9jCrKT4XoDRplBbrCl/8i1xCmjFWrf4z4p2B2YLa2sTJCQk JCQkJCT8jaDwAOMH321tRmvOVvKJV+IU0IqzldV/VrQ78KDwtjZBQkJCQkJCQsLfCI4IxLHmNDhb mVqsKc9WEqeAVqx1ebb6/wceHNHWJkhISEhISEhI+BshPWw4W7X8YOM3tNwE+cQrcQpoxdkq0H9W tDvwkB5tbYKEhISEhISEhL9h14JOj7NVy79FFeBHKyTOeMizVZuA27W2NkFCQkJCQkJCwt/o2DMY Jyt5tpJoL2j5F/vI5j8r2h14x55tbYKEhISEhISEhL/RKa4DTlanwav3Wv4tKvnEK3EKaMXZKsh/ VrQ78E5xbW2ChISEhISEhIS/0SXejpPV7+psJZ94JU4BrThbBfvPinYHpUt8W5sgISEhISEhIeFv hA8IxbHmNHg9RMtNkE+8EqeAVvz+a4j/rGh3UMIHtLUJEhISEhISEhL+RuTZnY0/C9/WZrTmW1Ty iVfiFNCKn9F29J8V7Q5K5NltbYKEhISEhISEhL/RPTkMJ6vT4PUQLX8nm91/Rkic+WjF2aqT/6xo d1C7J7e1CRISEhISEhIS/obmDMfJ6jR4PUTLTQj1oxUSZzxa8aenO/vPinYHVXO2tQkSEhISEhIS Ev5GzJhup8fZquVvqJBnK4lTQCvOVl38Z0W7gxozpq1NkJCQkJCQkJDwN2LPi6LA0+Fs1fI3VMgn XolTQCu+WxjuPyvaHUyx57W1CRISEhISEhIS/kZ8tkZB1KGtzWjNGyq6+tEKiTMerfhuYaT/rGh3 MMVnt7UJEhISEhISEhL+Rv8ZDgo+Hc5W9hZrRvjPCIkzHy1/aQp1958V7Q7m/jPa2gQJCQkJCQkJ CX8jqSAOJyt7W5vRmm9RRfnRCokzHq04W2l+M6L9wZxU0NYmSEhISEhISEj4G2cX96GQ0+EP+bT8 fdc9/GiFxBmPVny3sKf/rGh3sJxd3NYmSEhISEhISEj4G8mVfcl+Ovwhn5a/71rznxESZz5a/kJK ivWfFe0OluTKtjZBQkJCQkJCQsLfSL06CSersLY2ozVvqJBPvBKngFZ8tzDBf1a0O1hTr25rEyQk JCQkJCQk/I2MtcOoy+nw6r2Wv6Ei3o9WSJzxsLdcdYC/bGiHCMhY29YmSEhISEhISEj4G1n3j8LJ qltbm9Gad7L196MVEmc8WvHdwiH+s6LdITDr/rY2QUJCQkJCQkLC35hRn04Rp8NrzbUWaw7ynxES Zz5a8d3CEf6zot0haEZ9W5sgISEhISEhIeFvFDyfQVGnw2vNHS3WHOZHKyTOeHRpuarTb0a0PwQX PN/WJkhISEhISEhI/B9A8cUoYiKfjRwkNp1UcY4JJCtxhBizU+uk9dR1lDXJ+vvHPQfuPOD2tfWB mampgHFOaH0yjErVv9NqEVa0XLW2tX3/z95zpk7NTnGOHvWHkSOShw8bOmTwoKSBAxL79+ubEN+n 91lxsb0cPWO06B7doyIjuoV3DevSuVNoR3tIh+AgW2CA1WI2qQpn1DfdMTZP88TledQ4xznn9DPy DhcKXM0K8jwaisaerOPR8oSadrKmE5pz/k3T6dV0NmkyuzaSRvbrq6U7NM/eNIdWz6ZPzoF8XZoj V/McEXKmkG8QcjDkmBg00NLDC9M0D8vT0j1jFxTWpOelobtaW2CqI9Ud2K8v1QbaINogebo6ympZ 11FMCLxrenItJ2swjPJEONLSPd0caYYFHiU23VXgmTQ5Jz0tMiYmt19fD0vNd8z2kGOMJyRBqFCq GMZjTvVYxDBakTEbukar7buz5tp6O83OSwgqcBS4ZuR4FFeuMUbHBIyb5um65HD4z1l0Hpqas6J5 baRSkx5epBnZmpoVmueuyTnNa2MMzs1FH2jLY8fm1YzF0NfCiRlZGkbjy3NzPGw5htSMmRiz8s7P 7Ug3SvLmaZ4AxxhHYc28PFyaiBoPTVkcUxcR4dyqH6CIdK0mO8cR4xkd6ch1pUXVdqaaKYs3dXNq 3U6u6de31t7R69jaDiE+ISi4ueBuqhOSUDekjClNnmWGRY5zsSA8Wr4GS3IcmNMwg9zDqCZ/GNSA XIZWngJckSJPQGpejT3ZKDfae0yxdodW8w1hBTiOfH5yictXYo61f0OGaKyTpqWG+kbZk5DgiY83 loglFdcUNo4S+SH9+i6o5w5HmV1DAvfRJPjWlZucCPfHxBgX+Jp6J81GxlM9Oceb12h2ZB05ExNy PTzPqNnZWNNlqlFT3VjT1DzPgZW8WdzMXTzWuKZ/IfawTumFyR4W9h+q3d76jCxHxuTpOVp6TZ7P txnZJ+W89cOa6nySp1NqjhLJfRKPVEQtFuWMJmUjkxPkUWPxzywWdUG9xYpVKUqYNtZjzzvHy7mB MTEtbFSvHzNaieTnZj4zPckJJ+dHnJQ/ybygGgUGq3E8I3t6TU3gSXVYat4Bz/UlWPGUnROjpXpo Ku7MWPyr13cOM2JupMcJl6UaClh/3iJf9iTFSJ+cCxirs1/fsdjoamrGOrSxNXk1rnq9erZDsztq tvKn+FM1Zel5jQunXt92TaRn7LW58FUhS8ZNwWlMrYOtnFzrZCuzpudstRNpK7Nz6jjjqXljcmt7 oS5nq4bNXZRyo9QoNDKakaEMhknWcavQj9zqJKoWtaooEPn8ekaizNpYxii/nnvL7I1lHGWqt8wp ygwYe0xqdk7z1SNuydx+RFspW+m9KS48+uUnlD50AJErfeoSukdvVc5SuteNiHbWK45NoV2SQlL6 KRrGTBSsgUsRNyLuQFRpltID5XbwMsRqxI2IOxBfRsQzAdio1RBLEdcjHjBqlO5KVJ0WbU85S+mG tt0whxClKx1F1BEVigYnIk5EnIW4GnE9olnoGSWliMsQdyAeEzVOpWvdTYNge9e6a0SyaV5xksi6 vNkZM0V20/m53jRzsjdNO9erluxVGzjYW9x/jDc9q683DY1NqjbSwOCknSlhShgmGQbDy8CMP00h jFE03aV0IQ8iV8y+EqcSuqlXXNL6HYpKTOEKowKK1ncqrC64Y1JKINf5UQqlaP4FP+Kt4Uc2deiY tD7lPH6INiLuQFT4IYSD/CAt4wcMn4NHI65H3IG4D/EoopkfQNiP8B5/j0L4u5SIOBpxFuJ6xB2I RxEt/F2wnb9j7E+CDXk0IufvgO38n5jWP8Eh/G1Ib/O3YdqrdUOHJ20VQkKiT4iO9QldI31CaFhS PX+l7oc+WFFxuNJYUduVnjSKBik962IHRtcr4XUji6Lr+fubtITou1IG8NfIg2g8OL6GkV8jDXES Yh5iGaIZ0uuQXqdqxBsQ70L0IGKVge2IGt+NuAfxdRqA6ESchGjlL9dhmHq+ry5uTHRKGH+JP0dd 4fG9/HmR7uHPivRF/oxIX0DaA+lu/mxdj2hKsaGe0MaO1I40EfUm/rdNvUKj9ZSOfAd8Fw1ORByN OBFxFuJqRDPfwXvWFUSHopPttNtK0KyjT0R6P91jJee8aGdcKhagZlBc8h8ggdZr6+O4M27trcga FHf9TZAMirvqWkgGxS25HJJBccULIBkUVzAPkkFx02dBMihuYjYkUD2/8y+9zooeOvEipqWE8IXw 0kJ4aSG8tJBUvtAI9INq2HZbXXw8PLbOmdAnPrp6G6t+glVPYdX3sGo3q76MVV/Oqkey6gtZdQKr jmLVPVi1k1VvZ8Pgimrm3HxSdrgznFXvZtWPsuoKVh3HqmNZdS9WrbGhznoeU3fuIJGki2RTinHT If3DKOw+ITwGHo3Bmo/BnrADvA9RFzknlLSeXuVuPYy056b40d58/+Sk0pRz+C403IXLsIv2I6q4 QLuwjHahk13oIAQ8GnEW4k7Eo4g6ohnaPWH4asEh4ETE0YizEJchHkU0C3OOInIq9Zm4URiW6DN6 opHjuxB6IsTwGGd3e5Q9wX6OsjqKhfRgE3voPfhQCjPeKxja0dqxngVv+S74+++CKSAlgF/PV1N3 XIgbfOnquh+6R9ezW+ritkendGF/oh4qVh0bTnEsFukwqhD5IRRlNdLBFMUfRppUFzUNzULq4vpG b2MdjFZbon+IOhz9SVQ9h/hx1PboN7R6ldVF/wMlD2+Jfi1qVfQLifVWlDwRV8+QbNOE6taoYdGP 7haql6NiXV30ZUayJfrSqHHRF0WJCre34sIK5Jwh0VPipkefg/7SomZHOyvQ55bo0VEXRo/0ag0x 2myJHgATErxiPIztEyUGdfQQHU4dWs8KnX0tay05lomWsy1Jlr6WGEu0pbsl0tLZGmq1WztYg6yB VqvVbFWt3ErWzvX6AWeCceLsbLYbiVk1WBWynRtsHE6NTY9ZOZ1Hnk5KBs/IGsMyPDvzKWO25vk2 y1HPAvG0YnKMYZ7QDMrIHuMZlpBRb9GneIYmZHgsky7IqWXs+lyUevhKfEpn59Qz3ShaHmmcC7YS Yx2XXxdppL2XX5ebS+FhC0aHjw4d1XH42LRfoTwfJ/yM8JPk7p61GVk5noe653qSDEHvnpvh+aNx cNjKvmLH0tO2si+NJDdnqzKKfZU+xShXRqXl5mbUs2lCjzT2JfSwYr4UelZ8MBt6pFl7ePXWefVi 0R56vYwEegEBFCv0YgMChJ7KDL3ail7pabW9egmdrhpVCJ2Krlpznd2x0ImNFTph1bRb6OwOqzZ0 PKOESlQUVHpECRUWQVFCJYpFCJVpP6sk+lRWNamsEiMp7GedKK9O8IFGneAD0EloKdxjEhLYphG5 +TOMQ1eeI92NmOe5ZkFhuKd6tqbV5uf6TmNxebPzC43U5fbkOtxpnnxHmlY7YsavVM8wqkc40mpp Rnp2Tu0MpzutboRzRLrDlZa7adykwUNPGmtV01iDJ/1KZ5OMzgYbY40b+ivVQ43qccZYQ42xhhpj jXOOE2ORWOOTcmqtNCYXz/gi3cRtgViveZExuWPC7GWjxOIdERN+WeQ2PK1sIBuOPEE4PgcjGlX9 UvqlGFW4p4yqDsbJ2lcVftmImMhtbIOvyo7ijo4xlFBZVVFF4elFad5/FQCKKqsMh3s5oeK3gLp0 HJLTKiqJMjzxWRme0XiarbVYUJpnTMmT3Fhms6Xj2d5b2B+FyUahojQpGmUjjbKAAJ/iL69/lS9N Ne6Car59E3P2YJVUkat4emRkc2wF2b4jzDY8SxkfDxW5mGAFS2AVjX34zE5IIG+ejDk3xsoqn+Tz RaUv9bZEk4pGlzTBcFZCk8cq0SGZtlE3xAjTA9RNjaNwIv0jxI+NtKFI/9ioN1L+KTa6el8k2kCP siJ6lHbQU+wYWm3EQWAzGY9AaXQ7LaU1tAIfa9NRsoqmIJhQvoZ10zdTIt2ND7a7aS90z6fLaBuF sXD9E1pGy5VX0Wo5BVNPSqFJVErXsfF6Fc2g/eqVNJTGUwmVsWo9R79ev0n/M91HW5Xn9RNkowjK R9irf2F6U3+H+qHFzXQr7Wc3BTxOToxSDc07qJzWKTNVps/Vf4QFMbQQNqiUSXvZTp6A3t30EQtn S5VU9HKv7tGfhlYUzaRCWkfb2BA2jseYZuiZ+l4KwxiL0OutVEdbEOrpSXqbBZmO6X/Wj1E36kvn Yj6b6SW2U2k4cXnDaHjMBC/1oeGoKaW/0nP0MnOwv/FSU5ApyeQ0LdFfo840kKbC2gfQ8kP2Hb8M YZnyrDpWH0Md4JcbDW/TM3SQRbBENpFN4314Kb9TKScrRhyIUEBF8Pct6P09LKMtPIjvU+5VH1Z/ MndvOKB3wBWJo9voDvobC8ZMNVbBrmCvs/d5Kp/Fb+OHlDXqg+orFhdmfSHNp+voYfqOhbJhbDK7 gBWypWwFu5Hdyvayl9nHPIVn84v4UaVQuVh5Uh2DkKVWqFearjZdY/64Iafh6Ya/N3ynJ+lX02Ss h8th/c10J2a2lfbRWwj76RAzMRvrgKCxGDaVXYJwGbuO3cM2sAfZZozyMjvEPsFH0jfsJ+O/QbmZ R+Lhx3gEcvByPGGu4bfzfQgv88/5D0pXpaeSoAxRRiq5SimsWqHcgPC4clCNUPepOvycZFprWm/a YHrY9JTpmDnIcgU+4/ccv/dE/In3GqhhZcPahrqGzfpB6oJriE8PHLhGwnoXwjxc77VYcRvpVRYE 30WweDaKjYdnZrF57GK2CJ68iq1j9wnbH2NPwEtvsKOwOZhHCZv78yF8DJ+IcCF384vxMHYT38xf 5z8qFsWmhChdlHhlnDJTcSuVymJlreJR9ijvKoeUb5XjCLoaqEarPdU4NUEdp85Sq9Q71Y/Uj0wz TC+aPjAHmuebrzbXm7/EU80oyyTLZMtMy2rLFstr1jyszl30OP2l+f8RswPK5Uq68jhdzwep3XCE eQnreRYVKJkcK5VvYCv5pWwz72VaZB7BR7AJdEyNg6+f5ev5t3yEkskyWBbN4wO9vZk7qw8hGanu oiPqE5jbS+h5kTmIXcaPmoOoDs9IwzHmM8oANUF5kd5W9jOLejf9Uw1kXdkR/oAyCavgSXWUKYdi lNvpMeVidik9ztOJAn+yXot1PIE9hH0hmyWx7xUdj8ETsIqGKu/TlXQRf5OO4D5eSX9iBepcup4G saX0Ed2Pu6KPqcQcb+7CXuBFag3vxDYTVx/E7IazXkwxdaar2Exlnfkof4uqaJ8aSO8pj8D6ffwx JVM9ZprCCnEHXEpX08X65bTYlKO+wuaSwqZRrHoAu9tSJUmNQboMu8oM7GlbcHdvwz6QomSiJBwr ZzzWxVTsEOsQbsE+oWIFFeEePx+72Eu02ZzN62muqQPDrkOkvtgwhabr99Ot+lwq0W+iftgPVuhL 0eMG+oBW0wa2vOESKsNR8i3c2+NNY/k+01i9H6/hb/Esvvbk6wtvx7Jw+hThMWRGmbZTjfoGZdFo /Vr9H1jdvbHD3kqz8cB6GLP8AiOco+ykQQ0TeK0+VinDfPfTZP0BPZoFUqFeTBPpCbrPYiKXJQHX 2MNewXwvITefolcq7oYi+GE1vOCEt6qw/6zC07DY8EzGz4YsRDEdYzrGgvDkTMc1Zedxp4l+Ik3d afxsxwNrV+NTxkQBdGmt2fiPpjpOpnq+0WmzjjQHBiSrI83JjCUePnGYRp/4cHRkbZSojUMtJ3Og 7UUlINk0TB1Jw6CnjORcY4y9GBhouzzm7lvw5DvB/vXMkZn2I/bD6OKw/QsaPTrTfuJDPPluMuHB hNlH2kfm5g4c0EnpOKijogwZ1OWjofsH37uPFSsBLL1h+/HvGtbs3Ws85s9nL/NCrGEbRW/FYshy dggw79FoAKZRFXT+A+EJ9m9nHqHEI+hr8NmDksK6dDY7esbNv7mw6Oabiwpv5i8VrVlTBBl96cfZ brWUXwAP9XCG4KzFI0zGf4x1UzctCYfJh2faP6TETHSlDInpoqoVbPeNNxrttuHabmCvol34k8T5 UWL8M/jxWK2JJdrhIbRgMUNi2IaGUPYFi33M18YU+d/bmCJ/XG9y/dyG0W+1+eDncahhGxv7cxtr C9pY6btt1mZt7C1oY6ej2+zeNga6+MJFMiDc6IfwqAwyyCBDm4Tn/BIOyiDDaRh+Yl1wopdBBhlk kEEGGWSQQQYZZJBBBhlkkOF3HIgomf+VvN+WI5onWBG/PBgocobMqQN9So3fqruQ9vhktZmO8Xsk P/pkM3Vg8T7ZQrObdKw0QPzZXUMOoBo2zCcH84fYU03fFxuiFvtkRib1bp/MyaIe9MkKJaqv+GS1 mY6JgtRPfLKZLCbmky00sEnHSuFqhU8OoHST1ScHs6mmTONbgqqCsYLM9wjZBNlurhOyWZQ/JWSL KH9JyFYhvyfkAJ8PvbLXh17Z60Ov7PWhV1ab6Xh96JW9PvTKXh96Za8PvbLXh17Z60NDDmxmv03Y 9oWQg5qVdxByg5Dthm0Wb5+dIIdaooTcuZl+F9GPVw5rVt5NtO0v5Eih4+2zezOd6GZyL6E/Usjx Qj5PyP2EnGPI1mb2W5uNFdSsPKhxLg+SRknwiPFbRhplUyG5kWZSKZUgVtJiKhMlqciVQzbYhfIi odEfNSlUjKDRFJTNRftKqhA5N1I3tBeAC6CZArkIbQ3dIqHjQqwU/RVAZz7ScroIZaU053+y5d81 k08a07BoLlVBNsZJpmnCugpfa42GoIeB8IRGvdFTEeWjthT1hjWV1KdZX5mw7ZdWZTdJacKuhdAu wYgaTUQPc0SPRm0/YUspVmSRGHeCqClEiWFZBfVF2SQxr3JRUyT8lAWugn6Bz2oNtg6nYbh2uWhZ hbzhv8VIq4TfDc8W+vw8R9haKcpKwQWivEyMt1hcB6NfDSXlwiZDM9/Xxu3Lu0RPZWL0+dCqFHVG q9mij0rf1Sr2zbOkyQpvi0Y7ypvplgkPF8DifDGG1x8Lhd2GR359Dt68oZuP0aqERwrESvx3Txgt ioXUG/p9kBqrbLbP7l/vu+QU5v5z7wVN175c3AeN17Jxrf7aDBpH/6VdI5pdI2Mm3rlUivEa7wKj f+9cC1CyUMy8VNxZ/2kluE666m5xdUp97J2VV65CrkywJqxd0LSavf0YmsXQ+E9rqP+DWtKAgQO1 7EK3lllaUlq5uMytpZaWl5WWuyqLSkv6aynFxdqUormFlRXaFHeFu3yBu6B/SnmRq1grqtBcWmW5 q8A931V+kVY657d7aSxM9rac4p5bVewqT57mLq9AtTak/8ABWu/Movzy0orSOZV9hFZmdlNX2Qal lbsWFpXM1SbOmVOU79b6aVNKZxeVaBOK8gtLi10VfbVJrsryovwil5blqiopQNfawOHDknJLq7T5 rsVaVYVbqyyEzXNKSyq1ylKtoKiirBgVrpICray8CIX5qHEjdVVoZe7y+UWVle4CbfZiNHNrxRiz xOgCFUYf5aK0rLy0oCq/UoMdCwthSLMRkBaV5BdXFcBfWqMRpSXFi7XeRX009/zZ6LuZdsl/HF2o FxizL3dXGLM0vPrzAEbzpr5GiBn1LsIole75xiUoL8KoBaULS4pLXQUnO8Hlnbq7XMOMSjEUuKqy rKpSK3AvMNwMnUJ3cdnJHuqP/bFU3HfGzluCFW7snItZMFbVPOQ/EbtwY30W1pn3TjHuiAJlnVKr PKnsQNyqbFMeadaXS+xUjfmDom/3SWO5T+pN9Kf2UAeqGeo49Q/g4dB24U4w7jHvJ0Eh87C78Thm 3PnGp0W52LGNPrzPhqSfRb/19yUV8UaAjsR03fumhUy+oycfrsYROd82bUNe8y7oRugAjdYbUqaM nzJggO+VX8aTWBCSY+x79DYJD33XEuPX8VtJ4ev4Osi38dsg385vh3wHvxPyen4M8pf8e8g/KLBA CVVCSVE6KWMhj1MyII9XLoO8TFlGXKlWvob8jXIc8gmlAbJu/PamSsZToVqpVkKuUhdDXqIugXyJ eiPkm9Q/Ql6jroF8s3oz5LWmJGKmQabBpJiGmIZCHmYaAXmkOY2YOd2Mcc3jzZmQJ5izIGebp0Ke Zj4fco45B3Ku+QLIM8yVkKvMVZAXmBdCXmReTtx8tXkF5JXmVZBrLH8mZrnPch8plvstj0PeYk0h bh1jXUqK9VIrZmddZr0d8h3WLyAftX4N+ZsAjBKQG7CQlIBFNjyN2gJtwaTYOth6Q+5jGwR5sO0B yBtsGyF7bH+D/JTtacjP2F6EvMe2l7jtJRueqW2f2o6g/AvbvyB/bfsW8ne27yB/b4PnbT/YfoT8 Ey6eEsSCduEJ7emg5yA/H/QV5H8FfU086JtgO7HgjsHdSAmOCM4xvrDku+acYoTnvT73etvnZ8xx CmaUbYXfrDlWtLJOt14I2WXNB8+xloEXWBeDl8Abhh8uB19hvQIlV1qvhHyV9WrIK6yrINdYr4F8 A3xleOkrn084vJEAua8tEXMZYBsg5vsZ5M9tn4u5PAN+NuhZzOg5zMuYRRi4a3BXzCU8OBxyN2Ne vvkE0lr2BJlc5a7ZpOUvLi+mUXPL3RfRhEL37HK6sNhVWYK7P5DY1ClpGnXGnaXDByrZfBLOMd43 iYi7yTjLBDfLM5wHOjTlGe489DQ++xyNwnwaHCeDkP/H2/eAVXVd+a6zzz0HkAMSQtUYRUIJNcYY Qqw1jM86ShnKGGIsuYEThiAq3uA/uJz7/3I593J1rIPGMpamljrWYahlLLWUWmqpJdY46jipgcSS aKwa479aa4yh1lh5v73vBWmavve++eZ7ud9v73X22Wvttddae+2zuffEKC3jbhLdt3K5fQ3ZRLlG lIYovXxDIlOUG0S5RZTNomwX5euiPLd65eqVNCjKu7yUVFEminKcKFOJRk5unyxZ9KW04Vrib7VC d4Wf1KDvGMxeE6dDaEvJdD/s8hnMaDzORPxX7w/SJJrMX1kV/xrAp/F9WhvD/C1/Vo8V/zjxp9eP 4Cm4FPlwFbKen8LUSFuphVppN3VRDx3Eme1NOkXn6SrdpDuSRdKkidJUaZaUKy2UiqRSyS41Sduk nVK71Cntkw5IR6U+SMYJU1qP0XEaTc6Cjqgn26Ap6jSK1A+dj6yF9HCknnU3Un/heKR+akakzonE hfR3g5E6/3Sk/vKBSP1sGln463/PtpPK/3c3L/pJRQBJS85Hxl+6nWtD0jI7rmNQb4+0L+uO1Mtn ROoV40Q/y0szXpr/kvWlqujVwEtXq6gqJXJVdaLqStXdlcmRq5Xmyq0rd63sifCvCkTq1VWRek2u 6BW7NnVt9tr8tWVrjbUb1+5Yu1e0JlS3VO+pPlg9UH21hmpSaqbWzKlZVLOsxl3TGNHWzt+x5XVZ RJq9MlLXzovURlekdlyJ9HOVRetKEW2SazNJY6uFhV6iU5IKv2VL86QyqVoKSccYYzOZnfnZRrYV 2M5aWSc7zK5g6STKaUCBXC075cNyH/aIiZZii92ywbLTslvJVnbIh5WjappapVarbeopOTFGjUkB Bz4x82OKY8pilsW0x5yPzYndHXso9njs7bhJcdlx8+Iq47bGDY6ZOaYzfmH8mvjG+Ob4HfHt8ee1 ZC1Xs2pbtRMJlDAmISthfkJ1wraE1oTOhDcTBhNjE7MTjcSmxO7Eo4kDiefGWsamj50+tgDRnjH0 Mn1h6CTNGTopfTD0svRH4OOhl5kExA2dZGOAsbgvUcqQDetDFv1t9BSQM9QFPhuV4L4OlAJ7cS3T 2KHJdB/ApceAp2sUj03wlKJtL+5acPckjb17i+4DMnDHIvR5CsiJ6IUVLfpAXhI4uNzJQKqQb6Ns 3MsFnQfkAwsheTHq51BbURej1sFXCiRASm5USi6kdEFKl5CSC+SjfSGkLUbNuTkn11MD18vgOgmu l8F1ElwnwdUFri5wcY6T4DgJDm6Fa8gIw7NKwjh8ZpPBmTrkGzVWblTTXPoKrotQF6NPCcDoy9yS 9LCw5Mti1L20kGca9LwPYCPtEv0YfWVhY6uw/0lS2GND5WwWsBB4dqiHFQ31YD2MHZoCnil4QmqF n3Ph51z4OZdNHNrFPkfFpKD1JFpPopV7fj88v59ktL42cmWRsofeY5OG3mYZQ0dY49B7NEaaMfSe 9DjwBPAk7iYB44E0IB3IBB5Fzzhp+tBb0mOQpgy9heiyQaoNUm1sHMaDTSGT/18VMBaloO8m9N0E 6XmQnAfJedC8HdrYoKMNOtogZxNLGNrOkkHfP9TFJqCeiPpB1JOBtKE8zKyCPTKURwxy38BobyDD 8yhGpP4/6aPy3rxntNdXh3vRWLS+Cv6XoeNFWOAi9LwIPS+i56uwwkVY4SJ7AJgCpAGZwCPAo0MX /0LuyOgjfnjrz/ygRmPqNuLp9mgrEINPtsMX2+mh6EoRfkbMTUHMTcEYJ6HlSWg5RcoCngCeFHHQ 8wlrnoQ1T0LzKQz8LGWoEJYohFWrhFUno05FXkjDvc8OLYJ1XmYPo+1z1MOmot8jaJ82VIj9dljT JNgd2kaj/+W/4tNPavHnPh0H+tP96hF+5fHXCet3QmInJHZC/05Y/W306oTFO9GrExbvxDMB9Pof j6tkSHJh/C5Ic8ET7ZDogg4ucJ+E9u3gPgl9tkPCSUjgkdUOCS7o5oIEF3RzwXvtiHysK0r4i2j6 tEhK/0Q0ca6z4DoLrrPg4l48i95n0fsser8Bj/0KHGfBcRZe+hW4zgrbHQHXEXAdAdcRcB3BWEfA eQScR8B5BBxHkAWG1z1f8/F/lW+YJzPCh1GO4Lll7JCKiFTpe0Muagc6h/qRufYOlYvShae2vbD4 XMplfzt0mX2JHmP5Q/3sy6D/HjXPYk8PtbFCZLJnQT+PNp3Gs1WoV6PPGtAueowSWQ5auIR8wXkZ nK3gfAOcl9kzuPcsrpELIeEyKwGWA6uhy2fA2cPmosc8IaGHfUlI6YGUHkhxQUqPGP8Z6BGRsgkS elgZ+lUCq0BzXdYCNaA9Q5fx1Pkp88ZILozkwij9GGUTy4N++aj/HlK5RB10KVCGPi8CFaCXA5XA CsCGtirUq1E7UDsBN+CBfJU9DVsUipnuY0tgTxuuV8M2TIy3ElqNiVqoP2Ih3H8a9i4CuE1fRDzZ hFUuU2zUCsO27IcVLgtbPgsa9sNOM9rakbH38fcZcfWCGHk8xUU5LkfkA1ynlZG7sNVl+G48xQvf DXuAj/s06mdgk8hY/bBHv/AXLIzn+rF365BZ6pBZ+pFZ+mHdTSOWnYde96w7aq4iGvqj0dAqpOrC h+WYdxvm3cZcaPNgtxw7oo+ISPQalrQQ9NMiEjZF99Z9Ip747MphRcwIJ43hJ6DvDbVBt7ao53mM 9bB56BmR2g+JrSKuIrq0wvNt0GUTvN7GlgHL0VYpdCtnL6Hmnl8pvL8JlmhjtYADcAJuwDO0iTJh neuwzvUR60S0aIUWl6NWao1aqEdEeaFYExE7vwDw+PsH9IlYxsXKcX+J0KqVLQW9DPVytFeiXgHw mHwJdRWwEvRa1NWAHagF3ACPz9ioVXvEyAsh8ekRD++DxB6KEXoNr7yIXvuiEdmPKM4Xa5/Hsz4c 2TyD8JWDUxsyyqg46olaeR981x+NAu6/J6NxVR7NA62IPuEXxP6wt58BVyTqeuDV8Vw3sc75utai nmyLxmrrqDWyKSqbR1Vr1HuXcbJaInJEJF/VYCZj4e03RJ8X0VIOLBHxzfuLdcrny9aIeO8RGcUA XEKDfkoCN1YYwPPPPQk8o70h9OQWWzkyZkRSDaQb0dw0Zjg3QVJ/VI/+qIR+cHMd+kVPBp5+sUbj oiP2j9K3Z1Tm6+d6Yq4vjFrbBjwUP8L34oiW9zQUGTyaNTES8hP8CxmPiVyxhNt+VM5YFZXN9WGi lVtTFiNwyTzjxI7SMTKfYcuvjVqf93gjenffJ++KWVuE122jMtSY4TUtbM/jQtgdOTZisehs0DMJ PZ9EzyepHfx6NBfe4xgvOCJeuog1E+HkNnBFIyxmxGKjtR/WLW7E+8P2vOftYVv2YwafuAsrvRi9 Wi2stworoEasSuEbbu1h/0d317Uj+gxbdFjz4bt8JDYy35iRHe9e5ilH5ikXO36cOCn8304JjD4v /vZElIKPRBnEv/l9BB+ZHsfHQk/io6DX5/FM/AV8YugpysH5Zg4+Y+jL+MTTc/hoVEI6znyl+Iyl H+MMlUQH8UmWHpUeo/vFbxjG4Tz/JI2XPpA+oAekj6Q/0ETpj9IfabL0sfQxpTL+4vcUpjCFHmIx bAylM40lUCYby8bSVDaejadH2APsAZrGHmST6FE2hT2EyM1gGZTFMlkmPcEeYY9QNnuUPUpPshls Bs1kMxl0Zznsb+kLLJfl0RdZPsun+ayALaIF7CvYiwuYlRXTQqYj/p9hy1glPc9s8IrOqlg1vcBq WS2ePp3MTUvZeraeKtkGtoFWsEbWSDaS1GVqO/+Wm07TTKLqFmAnSfZTqHcBHaDPoe4C9gG9URwC jkXRR1RjQz0AnAbOg+cS6ivAdWAQuIM+DIgFEoEUYCKQBmQC08FzDXU2MFvck+w3xX3Jfhv1XCAX KAAWAVaSauH2mlKggsjRBuwGOklydKPeDxyUllTvtOfYLbWB6l774soy+7LqK/ZqgTt2Z02sfQfo 3TWltZqoK2q1mqt2P7Chepd9XnUH0GWftyLLPq/m9dqiatWeV73PnjfSZ8BejLZ5aJsXkb9iS02r vaym3V5Wfci+WNw/hvo06nvj+kfRZdXXUQM1DHyJ6DsI3LHvwPWOmjR7m9CL1wP23RhjP66Pj9SD 9hMCd+ynBK7YzwGXajLtp2qmA7Pt54BL4D9Xs6hWFci13x6mh+deWVabylHjrZ0msL52Fuy2uKbR vo3PoWYP9NwJ/fbWUk1P7Rxui2Eb1Fyt1YFyPveojdEf8jnS7LeH7TcM2Gsht+Gw3YSsN+/Jq+7D /M+PsluvvVj47RB0GFjRPNL+yfuj7AibVHPAv2WjbB0a7fu/0sdZk4J5J9o3A1tBb+X+AL1NtA9j YsQ/3E+jIXwWG/EbdOqM1t1R/3VD14Of9F9NNvzE/TUXPpob9RXHntqwQBpsvgg1B9prN9aqHNE+ WwRGt3P/FgDTES87o3ENH0N2JL6tkRrtp9CePBz3oraJ+jauJ6DejDp5uL1mDeLDRGxwjKaNezRi KAPxkyXQCHsO2KtqmmC7VwBxvaK5Zjti6p6vNoj1Usp9UDt/GCImhsFj450ofQa4MDr2htch1h2/ d7W2EtdO1KsAe80N+7WaW7XumrvROuKHTtj/qJjXvXVyDbjJ4x72zIfdCvl9gRb7TLEmeRywqI8P wycHsA6idXVvbUDEv4hJsQ6GY7YY4/E6nesYaUc9nBtGx2w0Bnk8wkfVPOZETEXXvnGLywCuY41f t18y7mK9DwCDkWuHBfNYdO86Eh+OdIFRsTI8LxELsRG/i+tYfg35w9esNpkDPp3lmIq5i5xQG6hp dMzgc3HMhH5Yp44c1Kf5vHj+sKcLsFH5C7pjd4kX35yS+M40VnxbGie+00wU32Ymie8xU8Q3mA+K 7y4fEt9aflZ8Y5gpvu+bASm/ZL9n2E/kKfIUYvJD8kMky5+THyGL/Kj8KMXIj8mPQfrj8uMUJz8h P0Fj5CflJyle/rw8izQ5KK+jRPkf5X+i++VN8ss0Qf6a/DV6UP5n+es0Sf6G/A2aIn9T/ialyd+S v0UPyd+W/4XS5e/I/0oPy/8mf5emyt+Tv0ePyv8u/ztNl78vf58ek38g/4BmyD+Uf0iPyz+Sf0RZ 8o/lH9MT8k/kn1C2/FP5p/Sk/DP5ZzRT/rn8c/q8/Av5FzRLflV+lb4gvya/RrPlI/Ib9JTcL79F 8+Vfy2/Tl+ST8knKl9+Vz9KX5ffk96hQfl9+n56RL8oXaZF8Wf4dPSv/Xv6QrMpUZTq9oMxRcqlc yVPy6CUlXymgKmWhspBWK4VKIa1RFimLaK2yWFlM1UqRUkQ1ilWxkl0pVoqpVtEVnQylVCklh1Km lJFTKVfKyaVUKBXkVpYpy8ijVCo28ipVyiqqU9Yo1WQqdsWgBsWpuGm94lX89FUloASoUTEVkzYp ISVEm5WwEqaXlfXKetqibFA20NeUjcpGalIalUb6Z2Wzspm2KluULfR1pUlpomZlq7KVvqE0K830 ioIPfVPZpmyjbUqL0kLfUrYr26lF2aHsoG8rO5WdtF1pVVrpX5Q2pY12KLuUXfQdpV1pp53KbmU3 /avSoXRQq7JH2UP/pnQqndSmdCld9F1lr/Iz2qX8XPkFdSivKr+kHyqvKf9BXcoR5T/pJ8p/Kb+i fcobyhv0c6Vf6af9ylvKW/QL5dfKr6lXeVt5m15VTion6YDyrvIu/VL5jfIbOqicVc7Sa8p7ynt0 SHlfeZ/+Q7moXKTDymXlMh1Rfqv8lo4qv1N+R/+p/F75PR1TPlA+oP9SPlQ+pNeVj5SP6FfKH5Q/ 0HHlj8of6Q3lY+Vj6lP+pAxRvyqpMp1QFTWG3lbj1Hg6pSaoCfQbdaw6ls6o96n30Vn1fvV+Oqd+ Rv0MvaeOV8fTefUB9UF6X52sptMlNUPNoGtqpppJv1enqlPpujpNnUYfqNPV6XRDnaHOoA/VLDWL bqrZ6iz6SJ2tzqbbao76N/SxOlddQH9SS9VSSVbL1DLJopar5ZKiVqgVkoqnxhVSjPqS+pIUr65U V0maaldrpcT4uPg4KSn+h/Hd0n0aHn+lBzSLZpEmaqqmSg9qsVqsNEkbo42RJmv4T0rVErVEaYqW pCVJaVqyliw9pKVoKVK6Nk4bJ31Wm6BNkDK0idpE6WFtkjZJytRStTTpc1q6liFN0zK1TOkxbao2 VZqhTdOmSY9r07XpUpY2Q5shPaFlaXOkbG2uNk/6ojZfWyTN1xZri6VntSKtSFqsWTWr9BWtWCuW ijRd06XntFKtVLJqZVqZ9LxWrpVLxVqFViGVaMu0ZZKuVWo26QWtSquSyrRV2irpRW2NtkYqJ4nN ZoF7z8/L8Ty6vIKkFXiOXo5n4uVrQO9EbQBewIxiPdAYRRNR5VTUrwDbgVbw4Nl7eTuwB9gL9AAH gMPA68CbwDvAGeACcBU8HahvALfEPWlFl7gvrcBz+/K7GMMCjAGSgHFox3N85SQgnaiqElgF2Emq cqMOAGF6kGZTHi3CyYj/esdNIWqkZtqBs2oX7afD1Een6AJdp9uSRUqUJkjp0kwpT1pEsr73hXS9 54Wp+oEXkLn1jfppvUU/D8rUz+hN+gVQTv2oHtKPg1qlH9Pdeh+oCn2vbtNfB1Wsd+tl+lFQhfpO vUjfBSpXb9ULdJxW9Bx9s56nbwWVpW/R5+jNoDL17fp0vQnUJN2vp+ubQSXrlfoEfRWoWMhN1NeA Gqcv1i16MShNLyq5reugmD635LqeS6zklj6v5IKeB+qaPq3klJ4F6rw+vaRPzwZ1AHcP65NAdetz SvbrqWQpOa0XoMci9LCWDECGBWUBWheh1VpyRS9F740lp0u2lGD+tj0lZ0rW2/b+j+2Jivi9EYlf GkV+0xMnfk8zXvwa5gGS4JUQTsYa/DWdqAJxVIE4qkAcVSCOKhBHFYijijNRIJYqrkaBWFq6ATW0 rED8LEX8LEX8LEX8LB0HIHaWInaWInaXzgAQ/0tzgHlAHrAQWAwUj2ovA5YBVUA14AT8QIhoBc6U K3CeXIHz5AqcI1ecp+klU0tmADOBnBWJJXklC0vGlUwqSS85WrKsZF5JVcnikuKS6hJnSVmJH2Wo ZAM+m0u2lmwr2YGWtpLd+HSWdIPeX3JwRcGKRSusnOK/IoP9MUN2k31EjP0BvrAIX6jCFzHCFxp8 8RQ88jcjHrkPHnmWJqhfgV8mCb9MVnVVpynwy25Ki++Adx6O/zj+T/S5+CH4aNr/x5EkmkeG8PUM iv0/+wn5IrbYKPYWm8XrixuLm4pfqeS/TollH7IPQQyyQZKUHCWHmLpYXUwyYq+ELOoLiEAl/vvx 3yc1/m78XYr5b/FIydfux33SpP2EnGODrrZEIAWYSMxErNnSgEwAMWvLjl7PBuYCudHrgigWRftY gdIRSDaDWNBCDHmRBceImmwVoJNAHxqFfWgbB0yKgLchRFkwPcIvMDWKGdH+MwHMNDgPyBvpf08n 5H7bGgB53+YVMrjOgic6LtmwD9jWi34suDDa1vjfAPYP2yujgD3E1irswSpMYi+uHwHZ2iNtFXzs PUI3oZ+43vtXEbnfw2v2rnWjq7d+h5Hv8Na3WZs93fW7jUJHYn2nUeTZX99tFHoO4q6Olv1GOcqD RqXnaP1RY5Xhrj8uWroNu+d4/QnD7TlRf8oo95xCH97/HHj3118yAqCvCWk3jSKMcsnIB30bPc+h Z5HnkknWXe7tpmqEHYmmJlqSjY2ea/VtxhbPTXOC0ew5jrLFYUO50+E1U62HPLfNDGOX85o5zWjx kplldKBPqtHlqjRnGftQzjF6Rcsh91VzvnHMq5r5Rp9XQ8sAygnWQ95kcLV4J5iFxmlvqjnLet6b YRYZ573TTB3tyeh5xZtllhvXwVsJOhn0Fe8sc5V1wDvHtBuD3vkmocyH/rCb6TbueAvrux3MW1R/ 0BHr1evPgS7HHJu9HXwWo8oOb5egUToWiRY+uxa078O8/qJ0WL29pu4o9R7CfCu9x8ydKPvqj1oH vQNmqqPCexpy/kpp9HrPm7tEyXuiNHaKsgO8GY5Eb6UZMHTvKmhr814xOxxr0N5luP1jlux3pHjt Jjkmet0oY70B9PF6B81jDtN7x+xzGOi5zxr2sfpLK8u9YfRJExaIcGV6C81wtGW6d6O50ZGNcotj tncLyrneZrPZkStkji4LvC2wXoF3pyg5vd59A/HW4eo1B4x9xi7ztKPRF2tqjiZfolnueAWjdGFG +8zzIt46xbx64YtdZnJEQ6PQex1Rx9sPObb7UupPWQd9E80rjmxfGmy40bPfvG4dgP0HHa2+TPOO tc83HdZr57RjD6etfZ79QWbc8WUjPrnvBhx7fbODsY4e76xgouMANO90HEact4m10+143Tc3mOLo 8eXi7pu+gvpueOp8kDne8S0C7xmf1ZzvuOArxYy6rBs5jVgdMA45mkAXwJ4H0X+fOWFlM6cdV30V 0OeGz4Y11eFbA5/e8THoZvUZwYmOFEHf8h4LpsHyhcFM6x2f1zzvuOvpDk53WnxmMNs5Bl5oA70+ ONuZxGU6x/kazYwIbfT6mhAJnHeuc5LvFfBG6HROW5t92+s7nVN9rUuOO2f42usv8XgIZjpn8hk5 cyBhN7SqAD3Pt2eEzvPtRWbgtsrAjEAj9kA7F3LauVjQxZjRKWcZ5OQ6l0GO8Esw19B9PcECZ5Wv Ee3VQlun74CZ6vT7eqBth+8w6JBnkrnRucH3ev1Rx2zfm/VHnRu8xwT9jqCxOpybHU1L9iMnhIOL nFt9Z4JW5zbfhWCpcwfkVxgd1q6gzdmGTJLKM1gwUfRcw0cJGkaf72owF+v6ErJWnzcrmOuIhSbn nDOFL3Kj9A1zgnO3IzFY4ex0uZekYxUg2q13vB1Br2Hn8QCb3zJ1Z3fUzjeg+f4IzddgxP5inaY6 D/Jxrb3eZMz6qO+u2ec87rdg7ifQZwd8emPJBofVnWLOdx6tW2WqzlN1drMStFvQAUHfaz/h98NT hjdryQZD9ychcgb84xA55f7dmNGAr93McPW5ekNtrgHPzdDuleV8F3CdrguHOp3X/G2hbp5jQ/sd af62+m7X+bqN8KOgrYM897qu1G0JHXRdr2s257sGXeHQUVgvEDrOM3/oBLKrFjrlyAV9DrwtZq/r judc6BLaZ4WuObuR+W+ifSdiYLevJ3TTzep2mS3OE7D2Dncs2qM09J9ltqwsDzBEdZ+3K3jBdSUQ i3FbAomI/NxACjJGBc9jzqTARMyrl9PWZv8krGKMxfOnPx3ReAqRs995DntTp6PJP7X+hPOcfwai +pJ/Jix/zZ9jhp03/fPqdztv+/NgpUJ/TjATdluImOzwL0ZWyUfPDL5rBE3rRn+xaCkLzkXPZcH1 LvJXIZLP+auDjS7V7ww28UwVfMWluSvqj7qS/X5Tc5b5Q3yHck6F5k0uNbjdNcG/AT3LfT3mHVeq l4KtGHEzPOX2b60/58rwb8NO1+zfgTWV7w8hKnb724LtRpjvqtiDMsxy1zTkLs2V5biASLYYLcE9 iORTyEK7jPLgXk4HezD6Qlhji+dS8IBrlr8zeNhR4d8dfB3W6A6+CTmzgu8gc3YHzyBjIBMavVxP VyCQFp6I+VI4zd0YyAxnupsC08PT3a8EssPZ7u2B2eHZ7tbA3PBcd7vhDuW49wRyw7nuvYGCcIG7 J7AovMh6yH/NzHAfCFjDVvdh75VwKdb1djwhYL/GXIoDpaB38vXuToTvut2vByoadEN3dQQLePwE b8G/tmAB9y/oA4E14QqjN2AgPxwKeMM295sBE1q9A63WuM9AK8N9IZAynEOsHYH15h2+I4S94J1o hpFRsdtirEbEVRPoXsQVaB5XZi/6NJnhSPw4Twha7I+uK9itdjo3BBLNjcO0tzd00NnNY89ZFniF ZwNOGx2gMyBne/1N99VAa9h0pHHa2BVoNWc5Fwbah+MTvCO0YQ80hdc7Lc7b4UZjp6s3aHPfqEsN N7kzfXvCr7hvBfYgBjqQYVLcd/Hk0+XahX0wg/suvJ37LtzKV0dkFsELzmue7oYtfOUK60VWx2kz w2MJ7EXM3MFMW1ypvvbgBaPF3x286poDX1w18vEEleGaj0i4gfwzK8hceBoM3sLa8fOY9+8X5UH0 KfQfDd51zfcfDVl4f5RFKMc41vuPL0lC/xx4Z8B/gpdYfRNcupdCSdbr/lP1t3ksoV2MxcvQOKPL uILsUe4KjJSVRn5oUqQ09jmaQumI/HPBVtcq/6XQVFHOEOVMsV5sQn9bJNIwImFEu/9m/SmX23+b 52cema5AHYXmucJGIcqAK2PJJON0nRrKE2U6L81Zro3PxwatiMxZfKawj9e4UqeFFkKTotBi1xaj vGKOqxkrGmuqLnnJbVeLa0uo2Djv2rLkNix5wkx9PrZuAuwJawS9rqK6VEi4XpdhVrrysdK9zjbo 6eX+Mgd5GSozWnztoWU8D4eWubagj9VZxj0LPXVo0ofRqyJPZZA2LapPtWtnXRZmiqfTkNO1y9qM 0dG+ZIOrsG5WyG8d9PuDua6wdVfQ6qjALpnh6qibEwo5Euvmhza4uuryQ5tdal1WsMm1r64Q1uut KwptRamHthl6XTmyRHNdZf1NZMiQed51yB8K7RB7xG3rMc/NBnIn4un9NrLEcazrFIc31Oae6Dne oGKn8zZo/Am8IXklPxHscJbh7g7+PN8wgdMNqYLOcFRwmu+YDdOsg+hTxduDKUYv6GU8szVkGQOe 2w3EabQL2nGAn0Hcafxp35Hr9zfMwtqh0DJnEsa66XiH68PXSMMc1y7oMN+dydvd00fa80V7oaCL OB2qcm72HF2Szs8LoTxHGvpfcmejj+68hj3rJp8L9inQDeWCRgbmEowu99XQcfds0JXuudaNDatE eyVvb7AL2i365Llz/RsaAu6Cug6zw51b1yXofaAL6nobwu5FdYdQZmKPvin2017sMv6GjUYf9txT gp4j6P2C3iLoKkdK3THs6ReQG1tH084TsGGm28oj2bkDOje7S+vUhhZB5wt6J/r3IcdWOGwNu6wb 6/oaMtw20B28vaHLvcalNuz6C3qf6N/rTqwbgN+zrX0NhxD/Aw3HjErrsYa+UfSAoE9zOpQOnXMa ziNKs0LjBF3EaZ6Th+mGK/z5BM+Q6XVa8B3sa348Axh1WsN151F+EsQzzGmz0trl3t4wiHV0uuEO ngdO8f4OEz76c1o8JzhMswVxsp8/8zhMsaPtDzM3c5jhWE43HBN0onXQpeKpJrvufDjF7a27Yla6 zbrryIqn6waDF9zr6+6Ys9Y51/nXhTz++iRzvsdZn7RuHlZWCNGIjISY4afI6zxjm7rrGFZTQaT0 jAn0hNs9SYED4T2ecV57eK9nUuBwuMeTHng9fCByRvZM9RaGD/OTZvh1fooMv+mZEXgTTwWRE644 20ZPtaNOrNGzqjilemYG3vnzs2rkNOrJCZwJv+OZF7gQPuPJC1wNX/AsDNwIX/UsDtwK3/AUB26B S8jxlAXumhM8y+ot4Vt83PBdMW4WH3edJXqa5mfnLH52XjeGa7IuSWiSdU+TdeMis4hkSH5SXjeJ n5HXTYrMi5/cIVmcr3le4ryI80N8B1mXzneQdVN5y7oZfA2uG+epctjWzYxKaxF6VtePWZfjCdWP C/kjf52I/MXAs8HVuy7PKMJzTrdnc/2kdQujf4sQp37P1vr0dYs92+qnriuO/s1B2C36VwVxfvd0 1uetq4r+1SLy94EIHfl7Bbga8j076meE9nva6mc27PRU1eesK/Psrp+3bhn/v1WItw5p1FuHTLx1 aImdH1tMinjTcJJ40/Ah8aZhRqwz1k+Px9bH/hPNEm8RLhBvES6KfyQ+i4rir8RfpVLx5uOL4j3H pRgjmzLofxFRLv0DTaQKCtJM8W9RFNEW+ho9RzvoO/Q8teFTQrtpD+n0U9pHL9IheouW0Bl6n2ro Il0lFw3SENVJTJpG/yhtlBppj9QsvUU/kt6VztOHlirLavrY0mr5Lg1ZeiyvSrLlmKVfirNcsvxW us8yqMjSZ5QM5WHps+pGtUd6WO1VX5WK1V+qv5R09bD6hvSC+usYVVoeExczXvp6zOSYVKk15qGY eqktrj5uPVPivhrXxBLivhG3jY2P+3bcbvZg3A/ijrJH4/rj3mF/F/du3CB7Ju7jMSnsJf5NE2uI T4wfy8LxyfHj2fr438RfYo1atbadNWsfJTD2WsKDCQ+y/oTJCZ9lbyZMS5jGTiY8lvCY+Bc6i6hK /KU0lb+vtaAZaAF2Arto4oKWBTsX7FrQsaBrwb4FvaAOLTi2oG/BwILTC84vuLLgOurBBXdyWW5s bmJuSu7E3LTcTP7un/AtxS6IXUAstiC2QLwjmcyms+lEbDabTRLLYTnE2BfZF0lm89kCsojfc6ns afY0xbDn2HMUy55nOsWxF9mLlMAq2FJKFL/nSmKr2Wq6jzmYAzJdzPu/yfseqKiuc999zvxj+CcO VAkqGUZDKKGEcmHKvyDLmVo5M0OohZnBUGK51FriJcQaY1k+4/Na6/IZH02otdamXGOstdb6LLHW ayw1PmKtz1KrPq/lpWgsy1prDeV6XdTA+77fOWc4M8GY9N7X9da6a6/vt7/59re//e29v73PPmcG jkjF77mm03jPEenWX1l/xc/7xUXxFnrm4L+I9LSIZk+Lp9XT7lnpWe1Z59no2eLp8mz3dHt2e/Z5 DnoOe455TnhOefo9FzwDniuea5Tf9Ix4Rr3Ca/Umeh3edG+md44311vgdXsrvPO8C0jm8NZ467yL vIu9S7zLvMu9q7x0mPeMTiTocLrlvY3kiKS7Wtrk7fRu/aTs3UEkvDu9e6hsP3E93iPeXu91b5/3 NH06673ofct7lf++zvYqjea0qDjn/6FQJNopasvElynm5yHOfRTfB0SAIvwnoobi+7x4HG+DqcUY fdo22/aQWGh72PawqLc9YntEBG0fs+WLkK3AViAabG6bWyyyldnKxBO2CluFaLR9yrZAfNb2hK1R PGlrsjXRepHEDlpJPMoufs0LxYzw7CfqITpC1CsqPIOeIc8Nz7DnjmfMa/bc8cZ7U7zTvDO9Ls+w N8eb7y3ylnmrvPO9fsKFRGFvk7fF2+ptp7TSu9q7zrvRu8XbRbjd2+3dTbJ9JDvoPexd7bnkOeM9 5jlD6STx5wjPeA54DnmOeo7z3yLGPRP3LP7aND5qtL5MqUj8klKxeJuSm1b978QnxDVKJbZaW60o tdXb6kWZrcXWIsqFlDiShP+GI3L5PTZ1yURpQgreojyDyEn8baK7psK6uOBVUHLwOoj5tOCtuozg bXx2Bu/WZYdkyPNCcXWFoWTIuZxlup5eT+dLQmkR2yznukxsS+fZts5XhjJAXM45t6OX6eQNOVGu 12Oe2+NcJ4XaU7T+cNu1lAfJR85j7U3mk9E3I92rbixxXxtD2RiXpaG8SN91v9gXLufx0cdVmYSa qU0jcT2duC866b7xmHE9ttlGbepjo7dtnEO2ofWxKj5UGDWOtVrO5bq+nnPZilBJZGx125x3aD4w vzZUiXxDyBsZdz3X2+bPPJ96rvvI48V94j5sDinvqa/3Tc9fDNXWbQsF614ONUb5aexLrK9KzDjo eYbBN+6PPn6xsdBs4I0xG6f1QR8/luk2doWao9rQ8+R79F/vb3JM//XPHD/M6/WoraBVlcXmEZ29 oaV1B0JtdXdCB+rGQofuOS6T5R0fsPx+eh+mnWZtfPVxzoiZr/fLOyY+BxPVft8rj4xLzFgHHeo4 3S+PzLsySW7shzH2OT8UWhHZN46GOuqOh9aC13N9T9bX58nQhkjZmdBmtMtxr+/X50Iv1l0KbYuM WdxEbCAfDL0c6SPrD4V21d0gneHQ3sg61+rUm0NH6+NDx2FHj0nK61NCJ9lG/bTQmUi86rm219Xn hAbrZ4bOYQxzw4eDBeFjQXf4RLAifIr39eC8cD9kC8IXgjXhAejV0Z7I+2XsHNMYBtPJfqyc1n99 d3gh4n7RRBuROV8cvsJ9iIz1/WKvOWZtx8ZU7H4Vuy9pY8Q+BZeEr+l7SHBZ+GZweXgkuCo8Ghkr vc3Y/ViPm8muTzHyelfoEsaZKT80VF8UumG8TtWXhYbrq0J36ueHxqJs6ddZonp/2Fy/MBwPPhxO wTVXJ91OU3ga8pbwzPrWsKu+PZyD/t+D6leG85n0uKtfHS5Cvi5cZryW1m8MV9VvCc83Xnvqu8J+ 5NvJBo0j5td4bc9W46B+dzjM/UUf94Wb6g+GW1DvcLjVOF71x8Lt9SfCK+tPhVfX94fX1V8Ib6wf CG+pvxLuqr8W3l5/M9xdPxLeXT8a3veevXCya59+TTHuw/fKY+Mr1p4u5+tYsyHeJtv3Oyaxr++J +vlAXyf6mo8zxBLrcSxmatfnyok8OEedbz2P0P36eY+9NiqWjbm+bpJj1lHs9c+wl6I/hjxy3Y/Z k6Lye/lbGzOeMe1FrpWx19XYvM2w3xlzfU70/TpPHe+nVzzdoa+34JoGwesguL7BGtzUkBgU4YOg zgYHU+QcrtvTbbN/WxvSI2uY2zGej/X1p5+NtfrYv+k6EdzRkBlZ9yyndcfrz2gvuLNhzqRnb81u cE9DbtQ6jNmj9L0ouL+hIOpMxGW8J/Y0uOviGirqkhvmBY80LACf11BTl91QV1fZsCjY27AYn6m8 ztuwBOVUFjzdsApy0kGu2QDvbFgGnb6G5XwXH/dC3H8XIuHj+M9Vf0z4o+D/yJr9t32+YjGJcTxH eRLPUT5n7bW+IXXhCco2PEHZiScoZ/EE5TKeoLxtfz4+TZ6H5yIX8VzkX/Bc5Dd4LnIZz0X+wM9F TBn8XMSUw89FTB/l5yKmAn4uYvo43dHuEnsnnh64ZbHAXen2uhV3rTvobnTnuZvdS91t7hWEHcTL 7rXuDe7N7hfd29xx7kL3y1Syy73XnYx0gOiQ20l4lNJx90n3Gfc5d3LROvcl96B7yH3DnUZp2H3H PfYJszsDyenOplY4FcIif8oAlZBuoZtfEirFNfDvJ2PubTtoRv6LeJ7uavdTKsV9bpn4lThLd7Ln KD0m/Vw6JSrN/eZfiyp+XkU1JREWTYb+OoVL86CQ2lN7Xqj1Xe95h6HPm6nH3N8D1M+9lA6RVrP7 KHzkJ3/T8ReJgqInm2Q5lGS6l+b/t5tHySzyxaPCIj4uCun+uliUCDv55BVJYj6lZLGA0hShUEoR fkpTRY14nDz9tFgo0ijmwmIa/stmhlhJaYZYQ2mmWEtpljhNKZP6/mvxIL9jWmTh16FrJvpafcZU WH2m4lb1uepL1YOVW6qHqm8Un5rbW32jerj6TvVY9TnFXD2sxCspxWElpeKqMk2ZWdmquEiWU+l3 z6m4XnFXyVeKiruVMka31S0q/UqVMr+4u7K1os8tFH/1UOXqR1uUhdVnqs8o4epBWE0h+5GktJMd pLl1FXeLTykr2Yqe3EJNxdeUJqq5utLvS2dbxG9UtjzaUtlK/CBoUGlRWqm+mfpzjltB6qoeJv9S 2G/y4tLcrZWtVGuLsq56SMkn7e1Kd/W5Sj9T8TWyM6zsVvZVX3LPqb6kHFQOVw9WXGcLERpzCxDp K/FkOV45BusnlFPF4Yo+JYV6zUStadSvXGC7eiuwqBP5wKQMUH6DrBIpXcpKTjwSyhXl2txepayc fFSKSO+mMkIejvqEbk2J91m5/ai2iXyJPocyjUafekteEqcTS1CTtODXh6FB344o/6PIt6P4VHG3 b6dvj2+/ryfSXwNNJmeZ78iE51G9ILmvl2dZJfaB24j4f67iupLjy6xcTTiHonI1rF6qPufLLb7m K/C5K9t9FdVDvnm+Bb6a4lPVNxCnwldXPeZbRFqLfUsqu5R1vmWYw1Hfct8qHknfGt96ip0iilya Q98mXydFR9i3VakKtAdWBlYH1gU2BrYEugLbA93FVYEqZXX1UGA3ZpNaCOwLHGTybQrsVsrUGlwW OPxoE2InMprqyCldFWd5xifmVDFTbHXRurtGNMKxFTgWOAHbpwL9le0Vt4rbEavblXauwWNTcd09 p7iKUti/139A55Gq/IcodvIpP0p0nPovirs4zd0/d7//pP+M/5z/kn/QPcc/RONT5b/hH/bfmds3 t88/pqxTrhR3P9bmlyv9AXN5TiA+kOJfGpgWmIkW2t1zAi5anccCORTr1EYg/zG5ssq3HOuJWg4U Bcp8nTR2ix5rqzgdqArMD/iV0cDC6rFAmGcp0KQUcU8qbtEM9vlO+876Liph6hWtQN9bRFd9F33U M2V7+brIeG333fLd9t3l3lduqbirj3v1Db+s5kqRP86f7E/zZ/Aq0mXl3WR71O9k8mcXrPHn+Qur 77itEcLa9q33l1Cb8yb2hci8mGlvY8K691cSef1KwRqOHX+tP4gY0nhE0UXawBr9zb7l/qW+ef42 /wp/h3+tf4Me3bSj+kl3s7oy/S/S7rqaiWdT3Tv8sn+b/2X/roq+6iGK/uHirif7ebcNXKB5uBAY CLQEWgNXlPm8H5KPwzT3eb55lduVHNqd71KfhFJV3K3uxjw/gWvK9oCLZ16potZzAjcDI4FRJb9G 1FhrEmscStWjTb5NNek1mTVzlHBNbk1BjbumomZezYLiqpqamrqaRTW51cOVXTRbKbzn0p5Nu1PN 4polPCbsd80qdafkCKZZ7atZVrMc18LP/yc6QS0V7Xhmzv9TXuSvFBJRWv5ySqsoraG0mNJ6Spvy T+d3UtpKKZfSDkqbKO2ktIcSy/ZT6qF0hFIdpV5Kffl9/N8t456MW4z/4vlJ8Ska12pa2CYRoNOB VXyGRi+BxvmzIlVIidcSh+ERvusq7RFSRQXlRyifZyos3V96F9SjEfNHiHq1z31EpzX5WaKLmrxX k/XG1NP5t7Rcl5/V6LSB7zPwVzU6reUXDWU6XdfK+wy2erRcJ2N/9Fz3MdbeZD4ZfTPSverGEvf1 ltbmbUPfdb96tfK3YvyNpdj2ew3UYyDdt6tavdNam/rYnDXI9TnsNfTxbsw46vlZg76eU1mZbBhb Y5nuA+VlcVqebPChJ6btHm0+9dzoe5+al6VNUv9IaVQfyzKInETZ0X5G9SXW19hxiM1j24ydCyMZ Y1bvgz5+VydslOW9T1uT9T/Wh9j8LcM86O3rsthc0ykrJCohWku04X3G5f+XXB9fPb/XfN0nj/T7 PnnsGOvjdL88an3F5mcn8V+3X1kaWTtlXiJF4xWDniGWy2oNOkHVPuJe26/LGomaDWNmjA2e/6Wl UeuwrI1oBVGHYdz1WNlM9GJpZC1G1uQ2zZeXS6P3miOlkb2u7ADRLpUv30LURbSdqLsU+3r5bk22 j+ig1jbvibcnmUO9D7Fyaqs8R+2bsQ29vPyw2oeoPfB+sRa7377ffjXZvtSn+lR+bEJefoLoFFG/ YazutQ/pfZ3s+hQjL9urjTPTIaKjpVHXqbLjRCeJzsTYujpBZeeILmn8oDo3EdLtDGn5DaJhojta /+9BZWMq6XFXbtby+NKoa2l5CtG00qh9unymlru0ccwx9F0nGqvyfLW/3MfyIqIyrV5V9HiVzyfy Ey0kChM1EbUQtRK1E60kWk207gPEh/Ga8n778geNNz3X19a9rj33yo17o3Gtx+b6nN8rv3gPul/7 99t7Jxu/2PUz2fX/frlhL5o0/zDzY7R7j2vmpO1Plp81tG8Y95A+T7wGLqjroHyA6ArRRo2uqRQ5 r+r1ddscyzdLJ9ZwX2n0+Vhff/rZWKvP+zdfJ8pHJnzA2pumrj+jvfLR0snP3prdClEavQ5j9ih9 L6qwlkafic6q67gicaJ/FQ5DXGh6FekxcaKNd8WcibGMzJtxDbBOZuld/t0T3rIg/vPca0qd/F/4 RaKUzC82ye0l6iM6TXSW6CLRW0RXia5rn28R3Sa6q35+RNYoTtV5JJkozUAZBh0nUTZRHlGhVr+E qFKTe/8KUohqDRQkatT8aCZaqrYFansfWiGqclflrsldn7spt/OBjtytD6zglNtpSDt07oEXc3fm 7nlgs1a+k2j/A7W5Pbk9D89h5FzjjqifSHMn9Lhub+6e3L7cPtI4bUj8DgbHe3/pizeLmPFOkY/g 3SHT8O6QB/DWkJl4X8gs/MbXid/4fgzvCPk43g5ShPeCFOO9IG68EaQEbwQpxbtA5v7N25Mkh6T+ avaIeESIhymWHr4dQ3c1mqfmORQ3ORRbOckGorjKobjKcWoka5St5XkTtqBLc59TohLk8yaIy1wn 70uPPNz58NaYtOM9kveXT5L4bYL4JbfAm2PUd8ZY8EvuePySOwnvjEnHe2Jm4g0xs/BuGCfeAePC 21+y8caXHLzl5aN4v0vu/zO7ktgveia+A5rVJQIPXZp1mNNDg7PCDw09dOOh4Ydu4PMdzkFjsw5n m7PjNa3D2Sks55Q9jWXZLkopanroEifdYvZMshixBxxTLel2ZoVhIZ50dnM9lqstzzrMTw5lHmOr 3C2/Ttv6z+T/KTLlN+UhMdv6nPU54eHdU3gTfpLQKz6JN9akEzm0d8FkReqbqf4uqr9bPiIs8lGy lYE6M0ljGlAbjxn5QmLitz4x8tuMRImoNGikC0f62fSzMzJdba4VMzJnzJmRO6OGUvqMgvS3ZriJ KmbMm7EANrbxL3Dl78rfpbZ/IP+AJD+Ufyhk+aB8UJjk1+TXyLN/Jm8s1KeTIg69iSfPXhcJCT8l /1JoxW2UTuLZ3UIxlSJ5rRAPBlVybZjgjeTaPLmcSHINi4DL7zrsvOo65ixwneD8gRbXwaw416kH c1z9zOufM3JdF1jHtdA1wDJX2HWF5c63XNegk+wacDW5bnLOukyuFtcI6pCuq9U16mqfLXRC3YLZ 85jYJig820pUFyHyTSfyjdqfPUfzccS1ZXauys92u8pmV1B7J9BWF+wkan4d1ny6afDnAmy3zl7k 2j67ICN3dqare/YC1+7ZNXr/H/CTHytnJ7pWz3agX+uovzq/cXY65pHfCSbwBi3Jvsj+WSHbn7Qv FlZ7i71FxNmX2L8g7PYv2r8oEuxP258Wifbl9i+JJPtK+3NiygeOYUnah3eSJYqVdG4RWbQbZh3S 6CjRcY1oV8s6Q3SO6JJKs5ZQPqTmRsq6McFnXpog+iy5poEPOEucJZn96dMyZ2YdnE7c9NrptZkj lI7NSiNudHqtE5+z/OnTHlySOXP6IUq1WYedXmdz1kYqOZV5inVIazR92vRDVONQ+sz0aenTso5l bSHptfRpTm/mFWdw+tLMfmdjhGDTuZkp82DmKJPTO73E6c3qj1DJRFJ9zLyp+uispXodWd3MZx3O 2u3MzvJT6UzVP/ZN86uEWlfIssIekXXNH7LN/ow4N5CfJ8iLU+x3Zr/af9JbmtXlbHYupdaobuY1 skR81nb6tMLJ71VJlF+QaY+WvyF/Q9jlb8rfFPH2BnsDRUCTvYki4O/tf08R0GpvE8n2Z+zPiFS8 9SwtYSRhRExPuJ1wW6TjvWYPfKg9jt9oVkvUhl3Ohb8xWYTfMlRoO58Leh34xYEk5hv0CsUSfjtP RE+i3ehbFNEy7UdoH61lojV+n24cIl0g0s2IdCsi3YZItyPS4xHpCRTpK0USLHEfBPpgQR8egj9b Nb/3oe3ZkK2D15LoNcjOaH4b9Y7Aa0m0azL+71n/nrHnUU+/Z6+tsCRgSYIlGZZMsBQHG/ymZct7 fUArCbCffM+xkPHOLx4NdR7moI+rtLFoj8hk0ajNolFviTYWCzTZXzNL95v3e/m9VRw2+K3Kjohd hthTZW3aLBplL2qzqMv+o+bwg8zCv2eWJxsLSRwSp3EqyOD/Pp62MEKBNIVSRlptWjCtkbCZPjVC thSo8gqVKmltlJrTVuAz84qW1lJS0jZopBgsxlFSQLo93ZLRThtyLulA+0vVz9wX++fsn6M+t9sp yuzP2jkCPvC1SRzEDGrfbKY2Ee0WgdSdlOYB90TynZG0J3V/hO+hROg46NjiaOdk0Ox1HATpn1VL +5FPWNgfsaTaWZmaqEocYaITjhbHidQjqUcYHSc4yu2fty/9a3vouEk0IgKOW47bjrupcmpcanJq GiHnGanO1GzweamFhHJqSWolyZyp3lSF+NrUIFIzaWakLqVUoiWuExex2Ja6ApiR2kE6bC1Os7RW s9PsuE1lLIlDbSYvShrRw2b7ig9x/ZDp/H8Bu6u6DrP5/+dLhVKJOE6ft0VJc6R87MLroqSZ0hzs 5cuipGlShlhLn4NR0ngpBX9nWRUlFZJV1NHnXINUFrdxzk6LyCb6dv8V7pB3yq+QxqvybtrZvid/ j07W++R9VPOAfIDG5rB8WNhobH4m4uQTNEJ2+ZdyP+0/Z+VfiyT5vHxeTJEvyhdFinxJviSmyoPy INl8W36b9pwjCUdoz3mdTuUfoVP5Tyk2+Gz/NeALwG++h/+agX/RwHcZ+K9rPPVdckrUX0l/T+nD kKVLmfTpVpQsReLWB6JkcVIyfToZJeMRlmimDTJxR4zRp+4o2S0adYmuRUbZNXETVyOjbFAM0aeW KJn6d6a1UbJ+xFZFlOxk1LVAlfWKPsNcP4x7NJ5XgT1Zwp7Mu/EyXPGiRtXe+p5RfdEgfwl8s4Fv Moz8C4aR/9oEr+l83VD36wabKv9U1KypPPfFhV918n2k2pucCW3yX70HZTxIGC8sdNqLj0ij9pvE MSGSzCKQJJKsSYlEjqT0pExCzufQ59ykAkrpSW7CiqR5JF9AyUHymqQ60uC0TMvnoJ4xZZKeg+pa k5aTjVWUs06iVlpBtCZpEcrU2kyLkAqSFhMuTlpiODd80PuZZKkOPVxO/RaOeKIUA9H9h4PGzeEi oghx5Gty1uuOod1avk/jDxIVEZURVamfU7aKQPz6qYNTawmHpt6YOjz1DqUbU8cc5vj1nBzxU8c4 T1kwddCRMnXIkeKY5kgh7WFOjniHy+GCXoqa1Fq6RUcOWySEPUc+22JLE3YcRWTXPHUwQSF+ZkJe /LL4HY6ZhOvjl/2HnXg+6NXsCnaLRPyWWCQUELmJKrScaR7RAi2v0cpYr06jRTSeaxKyqR+bEgoT ShIqE7yUlITa+E3xazgRryD3klYhpeyEYEIjPlOivJZ0ubxRTVqtCYttRntsS7Ok2ylJyCbNbLYV vyq+M74zoTlhKeVr4jv/yvuTvypyp9DaTKH9OYUiM4UiNIUiN4UiN4UiN4UiN4UiN6VI0/MT0Wkw JUxEp6QU2jdTWonatbKVRBS1KVUa0efCNSJgOzUlO3krYd6UEkqVlEqmDE5RbKc4Tamd4kVeOSV7 SpB0glMapwTxmVPblKVTlqI8qCatVrTFEtKCPbYFSxN2SuiTQlRJfHPccttB25UpzYSnbAf/5pHL 7+MdNZwA+H7HOtb+7lU93eeKwfoSZo/34JPjJfqebFpv7SR+yMpzO2TbBAyz3HZUSOY1lgHamW9a +So2ajonJMuAle6SzRkst+ebrgnJNtPsJ8kV6waKkSaL4LrjfIUbYiQN2v8lBVeBobF25hlN61li Wv/uJdZhNK9hiXwUmqOM1Aah+fOQ32S0LRvbSfJV43Q1Ny1klPLGW/mkYL3OaNsDzIKkDtgJZP8H rPzby1vWBkZbPzS/wlco6yDhVivfyRXa4iBfBh3GbqCw8P2p4FLSb4AEzxEsPZBwXWG+Aj4Z8gHo vwyEBa2tC0Ae7VHUGuUeiVHuBfHnuHSsElgExN3vGM3beCpbHvs/sG83/xQtHqKR+YHNS/gKsMtK My3/DHgTeInlphnMm3oh6Qf/S2AuJI+Y3yD0AqtVZLk0Br6fUboO/mfAlcAyVQd2EmFnLsvH35Hf IYnTQr0zbzHTedmSZ6aruvmPzJt/CvlzjJYnzHuJH2Ne6mA01aD0W5AELP9MxzYHNCXgP8DCcdgM A5Mg6YCdf4JOPDCV0abA2ttA1f5O007uO/A7Jop203nLQR4ZlsgLLaeIv2qeTfhjlkh5Zj6HPspo coPPZn2rQ7PwfcI3WC4/b55F/GdN5I/0r+Zi4l9HrZcYLV8CvwS4A/g/GK1NsHOX0TqIFttYbrZC fh2aC8Gnoy0n+PXQLDfnwENeKe8wms4ymiGRnwG/1nSR34IOzSbonALuYxQzpCBHEdAOjJNoJY7f lF/Df2Yp4DUr8X3QgGkGe873OdKgzOMwxmiaQetSkguYl18G/xXTAo4H8DeBv2WJ/AqwnyXSLMjv MNKuwn/BNMq8aQkwF6X95gzur2qHeXkP+C8AL0HzFPhXgGHgIxLtlnIN/HkEWAZvzeD5nWLUI/MB RvCXVQn7QK2zzlxgGPJbqDsCyW8Zx2+ZC2lU/ZY2wgO89k1PYUaehbdLwL8Eficj6bQh5knTfIZR fgW1ciHJ4FLTNeis0CQ9iOQeHiVoJkLyj4yWL4Evgf6LwCAs9IJv5VLbdOi8CPwoLLwEa2PYqcbh WyKjuAybb8DnDjWuMM5fMP8d8TbEWKrlSdL5BGqVqn0ELmAcv8InfPll7PPTxt/B7s37v5N5aRZK X+FSOQz+PPiDwE3QX6bJWX8EkgKgF+gYa9Tv7qiUrylnoZ8NC9modR34HHTGgJ8EqveObwD5bQ20 jviJIs30Fwm3wM7NsUPcd+gM4JrSzrwFrZA+a67n/ZnupWneaSXg6sZofhD8s8AOaC41f4s0n+Cr gBSUS5mXF9IovSavBb4GvIrRuEx4FXGVJNMuJEtYTQuB2xB1PvMf+Hpvfpsk32bLJifsh8FfY5RG IDkKyXrgQkZzBuTZkBwC/hL4FKMlBzrfAJ8G/gD4VbB5HBI/9LcB2xnFqJmfap4EfpVRSgffzUhe MX8ZeAySmbDWCU/iNAssgWW5AHwe8DTwMORdwGXAtZA3oa7QWmcefooB4F7gLU2HcStwM7CNcXwx +BZgBdsxFcEy5kvahbb60dNzGIf5qrVxXMEpxvk88xMejfED3C/gTUaS807Sw0jnEJYcQulRoBfy TuAgo9kPnYVAJzAReA36r0DnCmyeRK0RYDpwNXQ2Qb8dOnfNtFdLheZfEf9nSyv4MUKnJYUjn+NH sjAvpVkyCRMsicyb+Rx52crPUi5a+Exy3ZqI0VMIP8ZXHDHD/CghrndiLng7X93Gfwcdh3kt9LOB LP83RuL9wDRgCc45BcCP4ET0OaALeIJqHebYJp7fyTEd19CwxcQjxmdIcRlnrW7gZfUkxj7L2Rbs AJaTjHy6k7P5vCo1WfOAI4yQHGdN6TjkxyEfgWQEkhFIjltaGPmsK40wkg+qTif0T0KuWjsJO53Q 4dbD0MlT7UOnE3wnLHeyRIyiLyeBozhpj6re8vjIc9GXueZ/Y+RahGwhD211qvbhzy5gncZzaR1r 0tUEeyz8eQW+vcI9Ij4Pez76wm3RmaEd/A72h/Ywih/xaZ59fPNyXfBfwgrhBrK3dvF94LO8j43/ kOp+D/tqKu2mZGEMVwdgJySjjFKeyvN5nk6zh7iUeSlPRfXEjlp5uBfoxOm9k8+9hLzTZrNcDkNn BDaboNPE9ywWPCGzpLEdwlbspYu4FjRH0Mpx8NuBx9HiduAIbDbBw1sofU5F1HoOpb9BW7+B/5eh eVm1ySdwqUn1E+Mzqkq0Uj7Dn0Stkyyn0krwlehpIq/3d/ewRG0ddvJ4xsUt1BJ4BjYfKMZ/Tpg2 fpYwE5I0SDLH/0Ln/16WUH3GQ4wynrPJcfAKTz2pjywpAJ+nXj1RiueVchewX71So3S12iP12gr+ h4w04rSWxz2M1BbzGYxkjdtdCXwG2MZI+9XPeUbYc5qXePC4+rPncgt0DgM7NV71mXeMzcAh4Flg N/AyWlwKfkDgLoOvmOKrEu5bbc3YbTCG2AmFuqvgVz0fY8n4TZbQzsCrKd3Gv1o5i5EXvGpod8KO ZE3HyGdgdhDV2Bk6ee7kubxmaW128l6t3i9rd7XqSuGx2oHR82pjuJXPq+CTgHOBVzHa18FvUk8g wDDr03mDSx/XZnOr0J51S7sgwa94pHpVn2xQW4zSCLCTUYyC/x7wOHSygXsgyQOfBJwLvAr5dfBH gZuANxlNC1H6JnA18HG0cgs6ZZAowF3A7wDHUHoeuAySOnhehxmv4wiR/OAfB/84xwb1Wo18vq59 DKM6Q4tA7u9BxOpdnLvmwdqPgFXaE+atWO+sWQb5aeCbwO+oJ0xofgRX9nnABOCngCU4J/wjeCsQ JyjxIDBFO73wVViB5muM7/rGsWeObwTuALYC84GvAfnUatHkK4C864qxP4I/AVzD1nDWFe/eQSnx Y//bQlfzd3/DV+exP1kTCP/ISBG+F/gLxG0mePVpwG3g8/BQ1eHfRHxR4+GP6c/gjyD+b4B/A/Lf gz8D/Ccg71QCd3/CDP95BMZvsH2RhlbeAS/Mi4Hoi5n6OHbFRjPy7lVbGXvO126S4BmItQr4J+Dr wOVAPt0J1ievcH6wjEL+D8DVQA/wv+L62w38GV0FgnFFhG8ymt9mtJYyykCzAH4J8r2MthcYJejL kMRBxzYrDs9boP8HlNYD9zGaILdcBg8L5vOQ/ByWB8DPBW8BToWkCnwH9FcAx9BWItCJ0mFohsDb garlJ6CPUlMCJH9BaT4kv4Pk9+C/Dz4J+lOAq4Ay8E/oxcvANkheAi6Dtc8A4bl5CVDtdRrwF5Bs Bi4G5gDrgI1A9NH8FDxRfStH734MRGmc6v+PUPo0+F60OxO8AoTnpiuwVgLJ84zxmCM75iuuBQi5 aQfsb4GdRyCfD/ka1N0NOxeAGyDB+FswF/It1E1H6auwUI3SHliA3FIEvht8GDgELIAcETL+BMch IcWh/DxwNSLzc/yMSPqudQrHJ0e+5U1G89uM1lJGGWjGs0HzlyDfy2h7gVGCvgwJRfg2RPg2xPY2 jljVAvO2Wapl5s1/UK0xL9dDZx+jCfoWnKJNsG8+D8nP0e4A+LngLcCpkFSB74D+CuAYPEwEOlE6 DM0QeDtQtfwE9FFqSoDkLyjNh+R3kPwe/PfBJ0F/CnAVUAZi95BfBrZB8hJwGax9BgjPzUuAaq/T gL+AZDNwMTAHWAdsBKKP5qfgiepbOXr3YyBK41T/f4TSp8H3ot2Z4BUgPDdhlzOXQPK8OpuYtQHg ecyRYJTU2dzLGA+0Y8bjWoCoa9oBC1vQ1iOQC1Uf/HzorEFbu9HuBeAGSDBfFsydjOfYtnSUvgpr 1SjtgQXILUXg8azbEgYOAQsgR1yNP8H3wuP14xTn435cVb8/FiB8G/gMo2kmowSUBbAU8npgH6OA vgSJGTqmLZCr+s+iNBcYBK6F/BZ4WJBbgVdRtw38d8DLwDhIusE/Br4M+DwkG4CdwC8DzUDV5g+A kEtfAf8uSqdDMgzJCPjz4GFNtgErgBLwOeg8DvwEJNVAN6x9FPggJH8HVPsbD/w8JPOBBcA0YD7Q CSyG5jeA34a13wDRa7MFOv+C0h+DH0RpMvhXgV9F6Tvg1fn6KaNFnRfMkbkQOBeaZ2DhTeBHIJ8N OWrJvwY+BfQAjwBfh84q1NoMyULwc8BfQqkq3w6+n08+FFeNiCvGfcBSIM5FQpX/mZGiqBHxxpJt 4P8VOjnjt/m5K86NhxCrd3B6xK9xzFYgTuwm/O7HsheSjTglDkGCu2BTI/g2lO4GZsBaH/Aovsla glqvjnXwnQUk7bi3HYSFSmARS2y4R5NcQPW+IAzNZLSi/sLkLPtvwz2dRT3/p6v3a7gv9jJaKhjN VuAByO/ge6Ie9Xns2AI+sTPKX2GvTL9Un1uiraXAKrVdWLiI0mvq/SDGsI7RtA99OQfN/XxPZFLv GYswDtgBaMVx6dvwvAezcBMeLoIEciv8pzGhUstJRrMfuIPvguVNaHEX7Beh3Z3QT0TribC5UrXA T3HpItSLO+te9JrRATwKXAtcCSzQ5OcwzoxdkOwBvxbjtgx4E08e8N2iCb/4MmtPtsfW465/J9rd idnhun2a5+24W1QtnOO7A2AdI42k2gpLTmv657CbnYNNNarbobkT/E70iOVxGJNB1jQ/pt6/wEIL 8NvAk2o0avG/E7HRiFlWZ7AdfceYI5Z6MC+rMOMp4P8bLJxQ7y6hX6Y+k4GFdPR6OSJwKUZ+OWrN V6NFjQptjdiJ38C1rHjOYNnMpdYLsNzMdsw3YP8SWnwBXm1mtCP24oYZbXguYT2sWejAjBDacNds bWLeIiDfg3E7pdpEWy+rd814znOd0bxejR942Iu+VPEvvy3qM5CnpQGSz4LONvQlHXwj5nQUPR2A ZCckW9HWVUgWYgzXAFuBGUA/Sg9Bcw++L7gAy2ZYwJhY/hcif626m8E3rHTTbHj1DL5F3QR8Bd+r OsGfxzetLvB/Aa5E6UKgDZI9wGesswiz8P1sFiTZ4B2w0AmJl1H8AXhZ1QE/AGtL1O92gQX45ncX MBUWRiD/LbBL+96Zzxjn8S2zk9GSBptd2smNdY5q5zEvP4XA+dal4f9t7zugqki2tet0nepzhAYV UBEREFAQEQ4IEiVIEFExoA6jjEoGRUBAREUFBMwYxzSImB0VxAQmzFlEUTEnxjFnjOgof9Xu9owz d25463/v3vXWerrcvXtX9a7qr/b+uqq7T+vL0IY5honkh8nu8Ow+FlqUgzcV9C0H2o0HqWQWeU+w l0EPrcG+Hjy/EdEAzx4grUDCPI1rAaVLQTrBUdPB7kVesCsO2PexO0sczIUQzH+4ELA7QovtoZVk sMQDeg2gZ0LNayC12Flw4pNxDOdSLY4vvFPRAfzALBfbQv29gNUx0IOgNAB0Q9BhvkpHivl8Dfp4 EVXwbAH90Rd18Yk89Pw8tPgrSB04061QJwP05+DhObR7TXwrACyPoP5W0G+L5yU+3ycNrJ9S1M1g /WGrdezCdJwDnq2h5geoMx/0EGhrlYgzz94k8oLScVAaBGNXCaVa4OGOqIO9Hu5OPAF9iBjzTMcj QCrAfkiUMAovQb8O+kKQ98WYJ9ms/0wnG0DOFeOZ3ffDD6GOIWC7F1ovBIue9C5EBmQNlTJYbVGf oEtvWUSwaJRiktVMA9xyoTQYWikByzmQsFrhfEGOgvh/ArkDaygcKo41nEUWHJsF+gvQX4g6HIuh xUfQkzcg58C6AKJdAf3nA5lUQHySE9CfYiaVW6D0R7C7g4QVE04SMQE/0BMFoMHHAtqwRpBliEwC rbeDnoSLnsHDTOj/TJEf+HTAJx3iZAawE9P78c7UwxKo40IYY+eyJ1OUc56zdRyrg+4ynY47vF0A 0h8k3K3ibKD0BsRGLWCyk/nhlkv8xp4TvebHMP8SExoBgzH7YsLe8HkLbf0CHFIKciKc1xjo/ynA RxvswLcEgewIlkVQZyVgcpZJuQGT5CNYboFFE6QzWFqBHC1GKXlN9WdgeQjyFdTsye6M0Tj0gv6k Q7tewKVe0DqVCrg6kHRo/SHU6ckkrcN0A8B2Osi9rD7linQ4lslIkB2ZxCshZx+CPEvgWkPE7IZ4 BrmXSbk51LkFuiaT/GoC0cKkohwipAWc+wDoQxX4H03EfkKviJhlrHV/KC0Dn/Wg1wOewIpyDnAo BvspOAtDsT6c729EzNl0eKuB9fAc+JkPegig2opJuTP0diCUXoSjisTrmni9kHrrBaOfDjqzd4O2 fhPZUvQvIclanAy6K/j8DUbtGdTpwFpUzAY/N6DdVIicS+BzMrS1D1q/BRLyTl4Asj2MphPUrwTd UowiUYc6N0U/IOdBTUCMZIMO0U5R1YPRZ5bOYIEc5EtATwGfkaBrgDwMpd/DUQMB804gf4HzWgb5 YgiW9iBvguwGPOAFugx0bfAMOcjFgPwMHg6IfsTMAt0EjnoH+mI4yl+8FjCpyAVvwPOKeLE/IktD zblgeQo6sDFFm5XCFUEBVyWyDzyvJBYQzxZwtQqG8bKA6LWAaLeAvJvH7lNBi3CV5PuD7ge6PrRV BT3fD/Ip+C+C3h4TddEPyAPQVgzUdIaMmw4yXop/LxgdlteTmAeNQUxvNI/pSgeQHLQLs4hGNpBN 8E4dgZmYYhV46AOxagD6BokfmJRJkU+lRgrUh/f65FFSbDPJEzHGvCA7mN4D7N2gFXum88DefDgg HAHRfoI9ccA3yUUqkwGTFLkH1TXl61mEy6fTmjDblB1nOs2I6ew+G8hQJmVDYETc2VHyFIYSjVhn dn9PztYCycwiq2GtyIHP5eL1Bdj+c5D0PCWLysagN5aepMCz6QZ40tEwGWQ8yD5w7+gJ6DPZUwlW v+Fdw0WwzGNXc+aHG8Ukbg76dJB7weICeg2TMlOQlWAJgdJ+IE3AsgB0AfTnINNArgf7WdBXgVwC UgWyHUhf8NxItHy+yq5ucHbpoNeCh2go9WQWuoph9YeA/AL226DfYaWc2Icapss7gX4OSq1B6oPn j2BXwhNqC9AtoZVQ0OOh5hvw5ir2ELz1hDplYIFzRzfEmmDRgvrTwecdeHdXIfZZPHdm4fqB3AvP te+Dh8NQulUcBfYcXDYE5BywxEiYMG8m4NlPfKoOx/YAb89BeoLPzaDXgNQScYb6pmDJBD85cOxl EQFxNKF0K6zIdKF+Btg/gP0gnHWSiLboB0oxyCCwdBd1cRQkxJif6ywaZdVM0hFnej3UN4TS76F+ f+hVALQSALqIUgeoEwi9fSKeEZzjQrDbQSs6DeZMQqmr1CKzdwDPO5kkc5mUf2KlVDdn/AAWA7En YsyztxG4diAdxfgHXQVvKbQGb63hvYVaJnFzKO0AuknDXIY5rG0x2AtBrheRESVYMkG6iqUgDUEu ALkVap4GBDzEuBX7A/I5yHCQt6Gmjhg5YImHvl0G+US8ewN+vhOjGuocA3kOjr0G5xUIcgjIF3CO 96BOOXieDfY7IGPFjAY9AuKkM9RME72BxIB/PWByVuwnyBg46gvoStCToa1LMLL32VFKB6YrIE/5 /iC9YOwGsFIFcBRvAW/CP4VxNILzGge9CoaoiISawFq86F8O9pdizz+nQWYxeUjss5jpcL8Iw12p meBzJmRxIYsTyofmELfmwGbmjHlEhgHpAlyUC35cgR+Ao9BdsPhL2cfqNBJ5jEkcLfIb2L+AvA6y Gnz6frGiEoFuAzXTobfLxZwCDF/D3UsXkPCEnVsM5/tWPGt4t2SY/FfanzR5ENMh2g/CemQY3J0+ CE/3OiAkvSOggQplGxAJSw4LRyYRY5PjUf+Y5KgRaEhsVHgyGh4flpqA0pnfAf18TZARvXI0sP/j DzVCmqgp0kVabI/alIj9ak1AjZEO0kPadJ+9acpKkFqTsV9jSDqHeISZ3579A0zYt1igXC6VEdQE NYuIGJmEMkHmgZwJciHIQpDrI+PjYtDW6LiEMLQT5L64hLhUdATkqbiUxHh0DuQlWjEM3QD5S3xi RDx6CPL5yKjIOPQG5MdkWixDIOFeOJKrJQaN3ZxiveP/YPldkyG4Zy2++yJJzW+k8hup9Y1UgBT9 aHwjBUk2RebIGjkgd+SLeqL+KBRFoniUijLgCwELUAFajXj2WgKaKvZZpiNuefH9NZmSfdOZfWHb XNouQOyXnzKNIAS/gNHYDv2VaVRJ2xvitomRuNXdSo+j2xb+4lY/VvSjf4C2Rf3rn5P2f5XOgr1P BG8QwVdNONrrXuxNBoUr7P2bv0dFhrOIkplyDthfHoIMkSvqigJRPzQIhaPhKBmNQ9kUuTloMSpC 61EpKkP70DFUhS6hW+hX9BS9Qb/RS4egKENYsUlRrCiHbYliJ2w3K3bBtlSxm26LqbYHtsWKvbAt UVTAdrNiH2xLFfsRR7cH6F4JrX0QtsWKQ7AtURyG7WbFEdiWKo7S2iWKY3RvM619HLbFihOwLVGc hO1mxSnYlipO09qbFZV0r5TWPgPbYkUVbEsUZ2G7WXEOtqWKalq79E+IsC+Tp6PMfwmR83DmmxQX JGQuSsjUSMhckpC5TNvZpLgi4XNVwuWahMt1CZcbEiI3JURuSYjclhC5IyFSC4j8IiFyV0LkVwmR exIi9yVEHgAiDyVEHkmIPJYQeSIh8lRC5Nk/QWQhKkRrUcnfReS5hMgLCZGXEiKvJETqJEReAyJv JETeShHzTkLmvYTMBwmZeoiYjxI+nyR8fpNw+Szh8kVCpEFEhBINIKKUiYgoORERJWaIKOUiIkoi IqLkRUSUChERpVJERNnov4DIEVSJLqIbFJHHqA59lHEyDaWGiIhSU0REKYiIKLVERJTaIiLKxgwR ZRMREWVTERGljoiIUldERKknIqJsxhBRNhcRUbYQEVHqixGjbCkiozQQkVG2YhGjNBTxUbaW8DGS 8DGWcGnLzlRpIuHSRsLFVMLFTMLFXMTlv4zIUzUi7SRELCRELCVE2kuIWEmIdABErCVEOkqI2EiI 2EqIqCRE7AARewmRThIiDhIijhIinSVEnAARZwkRFwkRVwkRNyli3CVkukDEeEjIeErIeEnIeIvI sG9rsn7DFWgevRIIKIG9PEavBoaoHVJRvHxREAoRLlCm91H2lc8TLkrafKEGtH7UdknS5guXqeYH 9a5I2nzhKmis3jVJmw/fVzFHNsiZjkdPNBANo6yeiiaiqcJ1dUs31C3dVLd0S93SbXVLd9Qt1apb +uVrS8ITqnVT+lDbU0mbLzwDzY/ankvaP+rRXXWPflX36J66R/fVPXqg7tFDdY8eqXv0WN2jF+oe vVT36JW6R3XqHtHcl9nIbOgExoAzoPNBM84MrsV05qblALOAVMS+FsX/YbTo7Ad3Qxz3HrQAtdZd rQWqtR6gEfgGnj6dK5rDkXVw1Gs44g3Ufgs137Fo4eroESxaFqCWf4sVWkrnNSVoJzpP8+cDzRxB 1lxmIrOSOcg8ZAEy9r6zXPMQ9bUEtMNq7chXjTtDtcWgVam1s2rtnFqrBo3NSgXuPNO5u1QuhLIL 6loX1VoNaJiip430uEtwBOvJLI714keoc/mbOs051qeF3FGEac2F3BW1p6tq7Zpau67Wbqi1m2rt llq7rdbugKag82Z9ZEJHzwZ1Ru4cnRtwy2h7J6HVZdxxWmsZR2cKXCHdPwXWQu4EtRZytWpfv0hY KLh8bg6NlyJuLa25ntuENLgSrgQ15kq5LagJt43bjnS4Mm43nfFjmBnr0ahhX3Fh874m0hcVV9CC jdxG6nM7rY+5Cq6CzhVp5HEL4Jfi7Ht5LA7pVYf9H+l05kt5llvKLUWtuQKuABlRH/uRMfzy2xN+ +e0FX77D/BQ+j2OrBYyheayBNdh9KCyAP1oDP+JbYxb5Mt6Yb8N6KAtFG/FjbIwtcQdsg+1xZ5yN c3Aunoqn43w8Gy/AP+IluBCvxGvxz3gjLsab8Ra8A+/CFfggPopP4SpcjWvwVXwT1+J71NdT/Ay/ xHXEkliTLsSTeBMf4kv8SXcSSIJIPzKQDCJDSDiJISNIIkkhY8h4MpFkkmySQ/LIVDKdzCT5ZA6Z RxaQhWQxWUoKSCEpIqvJerKJlJLtpJzsJnvIfnKYHCenyVlSTS6SK+Q6uU3ukofkKXlJ3pAP5BNp 4DGv4DX5xnxTXpdvwRvwRvS8Tfg2vClvzrfjLXkr3pq34VV8J96Rd+bdeE/em/fhQ/lhfBSforlV c7tmmcAJvKAhaAs6QnPBQDAWzIR2gqVgJVgLdoKj4CK4C16Cn9Bd6CX0EfoLIUKoMEyIFNhXK9Zh JWZTDmNsTMfBAlsgjqLcgY5DR9yR8oMdtkMEO2JHxOMsnIUUeDKejJQU/VzUCE/BU5AGnoanIU08 C89CAh2N2UgLz6cjqE1H5UfUmI7MEtQEL8PLUFO8Aq9AOngNXoN06Uj9jPToaG1EzeiIFaPmdNQ2 oxZ05LYgfTp6O1BLOoK7kAEdxQrUio7kQWRIR/Moao1P4pPICJ/BZ5AxHdlqZEJHtwa1oSN8FZnS Ub6JzOhI11I2u4fvobb4EX6E2uEn+AmyoCP/DFniF/gFao9f4VfIikaBJepAI8EaWRN34o46Eg/i gWyIF/FCtqQr6YpUNDp8kR2NEH9kTwJIAOpEIyUQOdBoCUKONGL6oc40agYiJxo5g5AzjZ4hyIVG UDhyJdEkGrmR4XRF404SSALqQpJJMvIgaSQNeZJxZBzyotE1EXnTCMtEXWmUZSMfGmk5yJdGWx7y oxE3FfnTqJuOutHIm4kCaPTlo+40AuegQBqF81APGokLUE8ajQtRLxqRi1EQjcqlqDeNzALUh0Zn IepLI7QI9aNRuhoF00hdj/rTaN2EBtCILUUDadRuR9+RMlKGQlj0ou9p/O5Hg2kMH0ahNI6Pox9o LJ9GQ2g8n0VDaUxXo2HkArmAwshlchmF0/i+jiJojN9GkTTO76Io8oA8QNHkCXmCYsgL8gLFktfk NYoj78l7NJzG/yc0gjSQBhRP8wCjkTQXFCiB5oMmSqQ50Rgl0bxoikbR3NBFyTQ/WqAUviXfEqXy rfnWaDTNFVOURjPFHI2j2dIOjacZY4kyaNZYoQk8+0XbRJo9NmgSzSAVyuTteXuUxTvwDiibZpMz msy78q4oh/fgPVAu78V7oTy+K98VTaEZFoqm0iwbhqbxkXwkms4n88lohuYWzS1opuY2zW1oluYO zR0on2Yfh2bTDOTRHJqFGmguzURtNI9mow6aTzOyOVpAs9IA/SgYCUZooWAqmKJFNEPbocU0Sy3R EpqpVmgpzVZr9JOgElSoQHAQHNAywVlwRoU0e93RcprBXqhI8BV80QohQAhAK4WeQk+0imZ0H7Sa ZnV/tIZmdghaS7M7FK2jGT4MradZHol+FuJprm+g2f4UpeA2uD1WYQf8Gs/Ac/Ei/BNejlfhdXgb Lsd78H5gzEp8Dl/EV/B1fAffxQ8oXz4l7fFr0p50wDNIT9KH9CchJJQMI5EklsSTJJJK0kkGWUnW kg2khGylsbSLdCD7yCFyjJwiVfgi3V4i18hNUkvukcfkOakj78hH8oXneJ7X4LXwA9KTb4ZN+VZ8 PN+Z9KfaED6cjyG1mjsFuaAUBKGJoCfoC4aCiWAu2AidBCfBTfAUfIRuQg+ht9BPGCgMEoYI4UK0 kEDPNRk4DQGnyYDNOGAzDGwmB9YiwFc8MJUCmEoJTNUImEoDmEoTGEkARtICRtIGRmoMjNQEGKkp MJIOMJIuMJIeMFIzYKTmwEgtgJH0gZFaAiMZACO1Ai4yBC5qDVxkBFxkDDxjAjzTBnjGFHjGDHjG HHimLfBMO+AZC+AZS+CZ9sAzVsAzHYBnrIFnOgID2AAD2AIDqIAB7IAB7IEBOgEDOAADOAIDOAED OAMDuAADuAIDuAEDuAMDdAEG8AAG8AQG8AIG8AYG6AoM4AMM4AsM4AcM4A8M0A0YIAAYoDswQCAw QA9ggJ7AAL2AAYKAAXoDA/ShuW+M+kIu94MsDoYs7g+ZOwAydyBk7neQuSGQrd9Dtg6CbB0M2RoK 2foDZOsQyNahkK3DIFvDIFvDITcjIDcjITejIDejITdjIDdjITfjIDeHQ26OgNyMh9wcCbmZALmZ CLmZBLk5CnIz+ZvctMWd/mFunsZn8QV8mebmbchNGkNSblr9y7m5k1iRCnKQHCUnyRl8gW5ryFUp Nx+RZ+QVeUvqyWdexhO+kTo329DcHAG52QZyM5rmZvlf5qa90FlwFTyEroK/ECgE/V9u/l9u/i/O TZmM/Y/UhmgIKqJX0e1oHzoBq9v76CXcJ4F1M7Ki6yi6fsNvaSxn4/dU5uB6KqfiT1Tm81MRR7rw 6VR68uOo9OYzqPT5Cw/vwMMH8PARPPwGHqaBh7HgYTx4mAAe6PqPn8hqgDZJrWWqtSy1lq3WJqu1 HLWWCxqsqIXXTBfefLVQtrmDEPlMviCO8gJdJ1Ju4BFP+UEDKWleR8PvXgPhDlI75ABemmhW0mym R+LHXzUaF2y1f4buvaart5tQTxtPorlPy8QtfgwrRLaiQLA2kNEjb7M1ITyjUMKK9wFdjW5i90C4 InHliGo0G2tq/82TC9Yn9mzKFFlTdL2k+wWnYS1bqV73/8q+fgjaPbV2/6vGj2G1/+HaGJ7YwBM5 AZ40Uai4l7iVPEYeK4+TntzJxFoItWC/s9ADK2oxRJXdYhDfyCovIO+9lkzBFWW36EFN3TiZzE5T 1YgnHbQxZ0CQKozX6MDL5LJsJ04mLwpW9VVZf2MxXGmUaYjc4W9vFI5SUCKKR1Eolf7zYH9Vbb5x JtezyeVn3thYdWShatyTktZdDG2aTcsvytaxU2XLh6mycc8izMk4TsNmY9MbfRpCl50+8PXo1rQr SXYdVO15PECuqWvqk5g0NjkuJjbVxDKivYmdi4uTSa+4iOTElMToVBOfxOQkGzsjlaFYudkfSxKT w1LjEhPs2qiMWTnW1f+9vF9iYqqJ9+jU2MTkuNSxKqMWWionlbM9/dPJTmU/qIWWnT3ddaRG+meQ aixgRZ3wutyAYDtdVVO2o9TV+C4sJTYuISaVNtNEpc2MCl1Fv6jIkYkJkV87pvH3OmamaiN2zODb 8sgok+C4mATq1aSPj7cqW2aq0lIPoExGEM6WNUbUrsFly2SofOyESz9s83NZ77DJ7lp9W8fuYw58 Mi487jfqRbX/w4szD4/o2S/8zRLucK8r3eNtzT2i9leZlWsGlE8afdOvYsNs7T5H23aoK3qgZWZc 7W3+MXzJ2ZZ+a+YHGi85s83W9HBgx4zEq82M3Ga6NHG5WdH+TbRbR5l9wxeLgLU74mVTCj7t3hox Kbs+tCgrJze/tG7nglVnndf2yW1hMSXopuod6vLmWH2XrH15z+Jd1tk4vNtus1ljQvjc9OiCxSla eZvrjrw22dVbZ1bEaeur9n4tn+8JXOjWJ1i/Krrv2A3FU04M9Fie3WdqAtnieHC8eUW/6C5Lgio7 TOyUkNONry48F5jHJeSh1Qem3A7m2FeBV2V9VGW9V+lSOFu3lQsqDV5JQ5cQBcaqrJXMKpNnLVVl LcpsMvhc0ou45EKzvhP1tvbKbzi9IvnfH2/ZjdFBNMPdfWrTao93EU9ve6kasz7qymQNcqLCdKNq zQza8uZyvcrWVWkoafDmV9eOBC3t62uzyjfipUqTFTeWy2ka5X2TOphFxPiNJRMD29VV7Q1KXRli kWo1elve5409F6SjXo9OPdG/EXdUe2XGa87n2KkplR+CKw8trxiY+DLC92df9HzhiaU1hjs1l7fU WnD5mlFx+wkvnq1N2TT7lkt+l8XD9zqPPD91s9nn248uxTWaO7XiSy3a4/D6fUZ9Ex0b8qT9wvld R1iOKneefUehdfKH2DMVmd4jotfvKd+T73CqDjfJGPf2/J2ut8d/qa3d9OXd7RqtbUmX5t3tXea8 MqPjxS7XHTTDnbjlWcPNpr0LjZhdOmiPy+VhMwfkGHR667a4KFtYOXTGNuvyFWtOb7xmUrZf1TLX RE/Lam+/N953hqjuzrOMm3Iw6ZfX6zZWZXZNTtOmHDOOcky4xDFhsq0/ARc2+zaPCOWZ/2BWU8Kx o0RjT2nGsZOdRDiO6l1V1uT/kb5pQeDQ0JX36t2n39fq+O9U/6fcs2ZUqv7p6wW2H19FtMxcld9w ImmysKKb1cePg0qrejWucLvW5gypmZDhuWNJWlvXG0W9Te4lX/AZdb8hXq9+ec7WtlMq9Hb8sM9p ms3RjbnDRuVmWezqhOuLL83nnpcNaMqdnpz77mBuRFjLIr2CZcsL/COcrjR1/+54gElw8/eVIV/e HTA4VeYfr/XQlVStNbw79eXNDYeSJg+urqvz3Hl19bJVKGFD1pnnrvLiA4HzrHXvPPJOa5Qpi48x 2W5X6jHivJdyck2Sapbqwb6Z52yfX8zzNBi05kBs7sNpGXNxYML3PiYBBVO/nPQrf9hTLtMMr1r5 1HB+28/ntmgf+1BmbjD+U8al0KDqmEcS93xQZb39a+75PYuvJl88LYQPvbkqdflQ7cXe6wfr+rSD 4WvdmGU9TWRFJvBGazO5vqp55l+nvS+rYCzvonJTuRQ5FTnmdYpNTU1ytbWNSI63Gfl1DG0iEkfa Jo2IY1bbpOTEyNERqSm2PsE08GyoSRXwtYcymdxd5apy/rqv4vKsJYdjxoz5K4dRyd94Sv1TQgH7 DBtmcSVD1V2nm7eT+5DR239diTo3DSi1DvlpccazVTorFj/X37bo3cj8KyoDw+I2Ed7+8y9vNrDs sajzBK/+wyrD9z76LW7d0ElHp6zNEzJ+/uX7Cden1oxJJ2vNT0V+COpb7muZb2DdX2mZfNRYv4v1 WWSRqFu9JqzuUrhrBQoitktiJtyL8PF0E/bNUIyrTffafzu9aorJypYr9g57uXxTv9A0vc+t0snl iNEjsj5P8S8u/r7f/vH7N7dcPW9rnab1RFWT63Y99uUMmvT+J530R7cmDtuodczO6F3yUo+Ys87P natcWqVcd7vqcHvy+YIztTNuGXyJVA7d/M5mp33btLi2r2tmOZodvt7Wl7LPMso+uSL7NBmuuaT3 AdR2Y9PrfsYh42JW/pmD/jNznc4qF7vOKjuVg4MTox4XuvsfmOv0jxsZlZIaNjLpX53r3HBK+LT5 RNfAUfonqgI8gg983Ki329p+j07vficmP/PodLW73TzLsrmRd4z75Ow+1KN6EvnwYvS+GcfX15TE JUWnW0Q/LCt/kbvrzPMNn3VWa35v2t72rNfVgfJWaTtGRo4M7H/95qtb+5dPPp55e1JPzmnB2wOF yoFGsd3OXD2QFmo7oaytfPvAwcMNIxoyM9yf18jb9nIZk6r44VDolTwn69EntR8buTTKSPuyLD5h 3J2nHrMXFY7SHmrVWz98mH3h+clBHUxDY/1m3LLNadJna/0Og1nxz9v+pPvhdJPLudpvstNSOh/7 cdzKymH8U1Ka16n8w4LBOd45IbkLEkqNrQMqEwt87gx/OKld/giRb7JllhQR879iHOX/jtlOE76R tLJoJmNTGPQNUSY+DPJctMthY4+82XsLHm9y8/Y5dk7VUn2AHicXjDRQMBpNVyE+yPuPM6G/mUb9 BUEt6NXU7lBGnz1N81eEKWTaM5P8Zr1I6V/h2Yh0bNjZNzjX8JnL3PJVAzVvzSxza1X9adO6k+Vb +rZplaiMmzgCrzT1fxa/fWSG6U7/CzmvZzXep5je+eCTiY+SfvBbPu98ZdXN/AO1+63OZDw9WWJf M2XX6Ygjnav12+xPu+W2dFurlMI2U69s367Tf+abgkNRgUst2xUMm97Y7bhuVHrAnrPFk117l4aH 3FI9euTS+u60umsuWfW6bWZGZkbw8oV1Szkf2/H+U3c3cFej6gNvXcOp87eRBKFy2Q3LsIyAVy0K mrZx5gynbOKPLrTfec/rWHCXip+n3XoY7TTrjenCgsrSMf37ul5K9t1q9o4S1AZKUPO+To/IShVM j5T/uenR3xAB4yhnlZO9I6UmOztHxlGdxF07tqvK2vbvmB5ZqNqKu0YJPnFJsVHJJr7BfiZ+wUGu zo6+nTp2Ujn6dHTs6uNv11ZlJp6T4R/PqWMwOymT4KjktLiIqH9Kby/lHbcuPGCQFdN2S7vwbbo9 qlS7D+g4/5YV5aA40nmreew7hfyAYtGb8lfjjcKt/a/2WN3XofxC/LNBbtsnr+jWpanSxnGE3/1D 7jO5aO5n/bgngc8srJ+7jxm8+mLSkh7f5TQ5t7njh2mt7z9uv/3B2UI+fF1y/0Nux8567qwtDWkS f2/N5cOHRjtVvMmtzXpoeaXVq7qSV9mrLl3GK5c3y/nU5ePG2jL7E0Vc5Ov7DQbtRimDpzfj6iZb pHXPHrXuRbF9+rHL8c17m0YtCu/lb9tgtjn36dqkCnz62hV7crTDHK+ywhrrvPjy07r2E2Ydm1jS wtb+t+g9rUv9Bnwo/tgxZnJM+/k55wetMPt2OvU7ITxc9O79i5mv7sfd/T426P3i6eNu/mTzh5nS XzLG/89MKTUlKSLsv2Wm9NVT6l+T9R/mf/yBv2IrLc8xQ+e671vjuPo6ITnGA+teLFl7XDnLdtsZ z1E1eRljjG8+abG1IuNu/ZI6Db+AYr09cdZ1HjHh/eueT7JoOs/ladXVKUFT3w/rZjbeopmXcvl+ LTt59hXHMqEAXZixIT3s6I6p3ss8Ot8IWW3xk+u1Cv4HvbVbG/c8mO8+oy58yYfoZzWvDS1L7a+f smu095NprH/PjxdSTB+0zzdFnwbu50uyiprtdqi3zDcODCcrpr3N6vZIa67ycojbbKMRjeJ+PhCQ MSDbcyhy9ingKz2v2O7vndKoy+fdQ94cf+p0KDKsqNfFLkmVg0t1sw5eXGVnUBF5aeH5cZ5Wg/2D G7mfwfWe36PKacFhdtnynyhjLeJkMlXWlP/gku0PC8nfb3UVZR1jVydp2BphO+Hb+2i03d/3NO20 Vd+WNqOsoT5QbkdD/cSFcp9ax7LpZ4+93Dn95ZEVdyZtCVRFf3OIYBeiGlhknWmFeqE4FIGSUSLc iotGqciEXg4TqSUJZBi1xFEtYUW7TPO/G6mpY5MSY5LDkmLHmvyJmeTZMjSrV+TH2d5nc5uMT7t/ WmthUfdPD7x/3K/SfFwX6rfk8eBuMxLGvqye0+xi9k7tzgtdYg5O0fro67UuvqA4yTDq+7k3z2/J eFCwy2GT7OPB4p6vXHS+FO26dkV/Xr82VlZDwxKjYp9FxC169V2F7O2Fq2YP92bXHPnQoeFLbPC1 /C7vjjmWTbtUsG7joZdt9Cbc0qg4UnL44YRN3ZOK5q99ZNdqd7PVxwcuzrsYeGnWgsxZ8SZC1FWN /RmtNMZO8Om31CzkQmKruKLbOKmvm6z+0Dqr+gU9r5dom+aHfxo4/bHeWPsDn0znTPgwTzlUr/AC Md8Qahl0oqQ4WmlbHfXjxuhdM45vuXAtdvzb0ukzBqzI5oxV2Vyr30eJt8vmBGpS/tvD8c+XyD9c uBVSOBb9oNL/NhY1f7/xK6NtqkuIXWO4/9DJ3s7Oyb6zqtOgvwnFZsPnnuy4Zk7Gk5ej0w833zey 8vSD+j/xEwuRyqYjTuha7Bvl3TnEaMjmEzEXChrvJd1w2IMPRX0qZL1+s7HT0pQ5Lqk9P/pJyMOQ bQXZ/TemDXKe13fvi5qqpFXXfxoz6lrtvfRtn5akrphpNHTr3GuP1vD7/FK89zqmdXVwb9XU5dF3 D1623esh+0mbm2dm1vlotdmLNUFHBsy+n+He/XXR9LfVRc3wmaV1M72sOl4dcHnGgTmjlSMrj5aa rf4lrcWre2cVa1M7xmcMRtU/Hj808Nm9NTEdp6w7rxNsnf9bl5AxEcFdDMvbN5v4STftErm36eVQ 10u1TnNMqk9wF/Lu7LCfHHHi0Zfbll7NJr/RvvvDntAVAZUnL210tnNLch7oY7+perX1RzeE/h+F YF5JDQplbmRzdHJlYW0NCmVuZG9iag0KMTM1OCAwIG9iag0KWyAwWyA3NTBdICA0WyAyNzhdICAx MzVbIDM1MF0gIDE3N1sgNTU2XSBdIA0KZW5kb2JqDQoxMzU5IDAgb2JqDQo8PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDUwMz4+DQpzdHJlYW0NCnicfVRNj9owFLznV/i4PawS27GdSMgShCJx 6IfK9lT1EBJDI5UkCuHAv6/9JmWBlRIJrLFn3hs/2y8ututt24ws/j501c6N7NC09eDO3WWoHNu7 Y9NGQrG6qcYJ0X91Kvso9uLd9Ty607Y9dNFiweIffvE8Dlf2sqy7vfsUxd+G2g1Ne2QvP4udx7tL 3/91J9eOLImsZbU7+EBfyv5reXIsJtnrtvbrzXh99Zp3xtu1d0wQ5jBTdbU792XlhrI9umiR+M+y xcZ/NnJt/bQ+qfaHd7r0dD+klv3yo0gIptz+DvL/xJuu+lMOQcYz8FILGs1/jC400YQBW9v7oOI5 qChAyyyhDVA+n8JbIJrCsH5IoZ9TKDhRCaVQn4EkIY1IKgXCDpUiZKY1ExBPBCHNZ63xhHbAOWqq xYO17Mka50vQKD3nsKYpPRcwozUhNQWEGTXpMqA1UE5Io6J6BYSK+slZ24ZKyQ3OTs9XlJsp4YZS ZDkhkwAhvRGEctg2Egi2Dba7wvH51HfWxAdrBYXgBQcb5Sg0JnG0JnvwK5/9FpOnZdDKFO4luZcK LsR8gSQukVQ53ozETkQ4MRGu/OzTkWpFPD5/ryXuplQbsAs7G5Tup6fJ+6Dh/Yc2dWsu1WUYfF+h XkYNJbSSpnW3dtd3fVCF3z88K2nPDQplbmRzdHJlYW0NCmVuZG9iag0KMTM2MCAwIG9iag0KPDwv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2NDg2MC9MZW5ndGgxIDEyMTcyND4+DQpzdHJlYW0N Cnic7HwHeFRV+v45905mJlMyM6mTTJKZZFIISQgklFAzpNEhbSABAgkhFOklNAFRFDWKZa3Yy9oI 6mQACeoqKvbuWnZ1Vayrq9h1V0ryf8/95oQE0HV/zz7P/vd59k7e+77nO+We851yvwlRxhljMbjp WEVp9bgxeev2zWT8QBpjrtqy4tKaPd5v7Yx9MYIx28Gy4oklxuciohn7JJExvWdMaVk5y9DNQ3kd WkkeUzGlevRBbw1jR5Hc9eGYan/xd6+Y2xm/62PGnJ4p1Xn5ixes7GCM/wkFGpqWNC5v3vTGSMYc nzGmJjatWe25/4p9PzNWnMNYmGne8vlLfvppkgUdRPvhCfMbVy1nicyL58PG7PMXr5+3sN9Xixgb U8jYhrcXNDfO/bD8fjyLz0T+4AUwWO8zVSF9JdJpC5asXqdE5bzJmILytsCi5pVLXc8kvMzYc+iP +cjiZU2NU1PXXs7Y4xij8eCSxnXLM39On4r66DPzLG1c0pyxYMo3jL35OmMRscuXrVrd5WLbGPv4 S5G/fGXz8q6/fXoIrvDgcWYmfBvG2EUD/rF5tm3EjyzeyMT10BcbXxD8WPFn4ccGdK4Kf8BwE5Lh TGF0oZ6edTJ+0DQZ+ReHP6C11ONS1wqLrpHdivbXMRU17SyPNTPmdeK5CnJVnYFfhlxj2I6wAjSZ TKy+wrYpzMgUW5iiKDpV0d3ClK99zHOmbHtStcfDYDiqoz4YblIyMJybtefuC4sQI0XrESd6w+FB 3a1iXv59l+5Ltuv/Uk+9l+0Ks7AZp7R37ER7iu7/1vavXfq38Ny+/552dam/3A7GN+a09k+ZrWc6 LJXt/FeeaUhmI/+V8r2e/QNW37946XTsVvV5tuS0ec1Y1z3b39I7/Yv9qGC36s5hi09pb92J+vzL X28L+Y5T2n2W6iiHTl9Xr8dzLz99nm4nm/fP+t3rWU+eaEc9fJIfprBxp61Th1Ox5zO30279Tc87 zlL0o9iQU+wvsMHq1lPnVV3ISnul32Azf+uzuvs3kO1Q57Dpp8szLGPT9e8CnPJRtqHX846y+t/y DGUFS9dfx9KNb7B0XRv09SE9gqX/lvr6Nb+tXK864XhGyanPEG3pDve2qQfZoJPrnzzWkG2H1PxN dt6/2qfu593eq50dpyujn8t29HzeKX0pPP2c/WL5Hm0pz/VuV01hlaerE3Zfb7tyH0vp1eanLEXX 0tt22mejTFgUSzFMwPr+8z8vL8qgv1f+s3LyUm9kqWEdp84h3sxZ6s0s9RR7Fqv7pbaUXaxU+YQt ViZrPFbpYGP4YyxNuYb1VT5ni3kTa9TKXQM9iy3WTUXZTzWUiXoij/+EdH9WzD9iXlFHOY+51a9Z jrKZ9VG2MbcyhBX/1rH9t15Y14y/9J/uxf+u/13/u/530aVcz01Sq3t7v7+VBnZYs89lGwTzLtZX s6exh5Qwdk3YNnZ1T7tgxHoXANmS/139VI91/STw72rvf9f/d5caQiL9NoH3R4praR2PBvfD93od i0CslAM9jBWx0Yj1x7HJrIL52TS2kC3HOr3FE+WJ9yR5MjxnHdV1dTHx24Ce5cvZJJSvRvlGtoit DJVP1MozUV7NUvuqSWpE1xNdrzPW9XdmQBtJ1MWupo8aPyrGp+ADEfFwtNvzStPuGUAfVnhSPFMu RqeOR24m+pPHZrG5bAFXuI3beQJP5n14BZ/O6/livoy38DV8E7+QX8wv49fxvfwAf4w/xZ/mL/Bs 3o+P4YV8AtPzL7V2vz35dy9IK6Hf1Cjs1y+qKXp1uunwA7Wnr6hO61aTmPjdnLic2thpdHSVsjLc qaw2XvDq03TjFC/A1sMPSJ3iiX8ysv/ohXNP7ZHCiNVZ6mzcT/mtj5jNf96eb8zc2bPqZ86YXlfr r6muqqyYMnnSxAnjx40dU15WWlI82lc0auSI4cOGFg4ZPCivX25On4z0NG+q2xntsNusZlO40aAP 06kKZzll3vIGTyCjIaDL8I4dmyvS3kYYGnsYGgIemMp7lwl4GrRint4lfSg576SSPirp6y7J7Z4R bERujqfM6wm8WOr1dPDplbXQ20u9dZ7AYU1P0rQuQ0tYkUhJQQ1PmXNBqSfAGzxlgfI1C1rLGkrR XrvZVOItaTbl5rB2kxnSDBXo413ezvuM4ppQ+pQNa1eY0SoeG1DTyxrnBioqa8tKXSkpdZqNlWht BfQlAYPWlmeh6DO7yNOec6D14g47m9OQbZnrnds4szagNqJSq1rW2np+wJEdyPKWBrI2fOzEkJsD Od7SskC2F41NqOp+AA+Epdu9ntYfGTrvPfxlb0tjyKJPt//IhBRD7HYT8qVm6Bt6iPGlpIi+XNTh Y3OQCGyprKW0h81xBZkvL7suoDSInAMyJ8YvcrbInO7qDd4UMVVlDaGfNQucgS1zPLk58L72k44f 5HsCakbDnKYFghubW72lpeS3mtqArxTC1xgaa1l7/zyUb2zAIBYKN1TWBvK8ywPR3mIqAINHzMHC 6lqtSqhaILokwBqaQrUCeWWlol+estaGUuqgaMtbWbufFXQdah/oce0uYANZnehHILYEk5JR1lo7 d17A3eCai/U5z1PrSgn46uC+Om9tc52YJa89kHUIj0vRnqjVwthOKi0Li5Eb0o2eWsWl1onZgsFT jpu3eAQy7JguLSlmtHiEp5a7mCyGp4RKCNWrHSTU9JKxIksVVUvGulLqUuj6lS65Qn0KSw8Ye7Rl h6G7T/ScX+walRYdyvKUNZf26GCvRsNCHQy1dvp+KsIXoQejhlFM51iZpaZj58KmoBnNJGbR6Qmw Ck+tt9lb58Ua8lXUirEJX2vzO6HaO6Fyeq0226FVUtMrRfmFlAqwFGTLhFKCNVie7ZLTqqXHaOnu 5NiTssfJbE+r0TuhulU07g01yDzYQRi0PmNc40WFkQOxNctxunnLG70eu6e8tbGja8uc1nafr3V5 WcOCYaIN77i5rd7q2hEura9VtZtcG8SjItkEPqGmODcHZ09xu5dfUNnu4xdUT6/db0ccckFNbVDh SklDcV17GvJq93twuGtWRViFUSQ8IiFaqkLCqJV37fcxtkXL1WkGLd3UwZlmM0obZ00dCtns0qbA piObT7OJC5PkXAAX47gt88wV07OxbkFrQ53YXCwWU4kfHuDeUSygeEe1c0VvCZi8zcUBs7dY2IuE vYjsemE3YGHwWA7niDOptcGLcwoLqpa5OC1FVTTp6ejqqqlNedF1uC4FS20mML02EJ6Nsz8sfTzK jRFogHlMYEtTo+gH89eKuob0cU11WLayQRQZFwhHC+GhFlCiXKsjliMqNWFuMIFa/S1IBLbUBeqy xUNrF9Zpy9keYGO9wzDt1GZYhnhQXl1rpDdf25vYCqb08wWFo2+supYsLiTxsDpyksGCnjd5kdXU 4IG3daypGkudzlKTiyzNOBJ1Gc0aTK5QJhPDUtPNVlMgvB8axI/Q5n5iS4alG+rqqPNa6vxQATzb HjCjRxk9XBmqAO8ga5zoC37OR1dF0cdEM5UdrMq7DieL6LTWkgHZAWv6uEYc/lTfDIu3UFY2ijPC HGrjIFkNYuQW+F1Nr+nousu7PqXHlZvjFS8HsTCZaz8WNqtrPdkQmJGdm2M82WrVzK2tRuvpK5C/ jNZuFkZPGd4ajAXDVU+Hcu6ecCcfD7FVinOkOFuKLVKcJcVmKTZJsVGKM6XYIMV6KdZJsVaKNVK0 SLFailVSrJBiuRTLpFgqxRIpFkuxSIozpFgoxQIp5ksxT4pmKeZK0STFHCkapWiQYrYUs6Sol2Km FDOkmC5FnRS1UkyTYqoUfilqpKiWokqKSikqpJgixWQpJkkxUYoJUoyXYpwUY6UYI0W5FGVSlEpR IkWxFKOl8ElRJMUoKUZKMUKK4VIMk2KoFIVSDJFisBSDpBgoRYEU+VIMkKK/FHlS9JMiV4ocKbKl 6CtFlhR9pMiUIkOKdCnSpPBKkSpFihQeKdxSJEuRJEWiFC4pEqSIl8IpRZwUsVLESBEtRZQUkVI4 pLBLYZMiQgqrFBYpzFKYpAiXwiiFQQq9FGFS6KRQpVCk4FKwkOBdUnRKcVyKY1IcleKIFD9L8Q8p /i7FT1L8KMUPUnwvxXdSfCvFN1J8LcVXUhyW4kspvpDib1J8LsVnUvxVik+l+ESKj6X4SIoPpfhA ikNSvC/Fe1K8K8VfpHhHirel+LMUf5LiLSnelOINKV6X4o9SvCbFq1K8IsXLUrwkxYtSvCDF81I8 J8WzUjwjxdNSPCXFk1IclOIJKR6X4jEpDkjxqBSPSPEHKR6W4iEpHpRivxQdUuyT4gEp9kqxR4rd UgSlaJciIMX9Utwnxb1S7JKiTYqdUtwjxd1S3CXFnVLcIcXvpbhditukuFWKW6S4WYqbpLhRihuk uF6K66TYIcW1UlwjxdVSXCXFlVJcIcXvpLhcisukuFSKS6TYLsXFUlwkRasUF0pxgRTnS7FNivOk kGEPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPl2EPXymF jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4 jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4jH+4DHu4DHu4DHu4jHa4jHa4jHa4 jHa4jHa4jHa4jHa4jHa4jHZ4yW4hEDUHk0e5ETMHk2NA51Dq7GDyMNAWSp1FtDmYbAFtotRGojOJ NhCtDyaNBq0LJpWA1hKtIWqhvNWUWkW0kowrgknFoOVEy4iWUpElRIuJFgUTy0BnEC0kWkA0n2he MLEU1EypuURNRHOIGokaiGYTzaJ69ZSaSTSDaDpRHVEt0TSiqUR+ohqiaqIqokqiCqIpRJOJJhFN JJpAND7oGgcaRzQ26BoPGkNUHnRNAJUFXRNBpUQlRMWUN5rq+YiKqN4oopFEI6jkcKJhVH0oUSHR EKLBRIOosYFEBdRKPtEAov7UWB5RP6qXS5RDlE3UlyiLqA9RJjWdQZRObaYReYlSqekUIg/VcxMl EyURJRK5iBKCCZNB8UTOYMIUUBxRLBljiKLJGEUUSeSgPDuRjYwRRFYiC+WZiUxE4ZRnJDIQ6YPx FaCwYHwlSEekklGhFCdiGvEuok6tCD9OqWNER4mOUN7PlPoH0d+JfiL6MeisAf0QdFaDvqfUd0Tf En1DeV9T6iuiw0RfUt4XRH8j4+dEnxH9lehTKvIJpT6m1EeU+pDoA6JDlPc+0XtkfJfoL0TvEL1N Rf5MqT8RvRWMmwZ6Mxg3FfQG0etk/CPRa0SvEr1CRV4meomMLxK9QPQ80XNU5FmiZ8j4NNFTRE8S HSR6gko+TqnHiA4QPUp5jxD9gYwPEz1E9CDRfqIOKrmPUg8Q7SXaQ7Q7GFsECgZjZ4DaiQJE9xPd R3Qv0S6iNqKdwVic1/weauVuorso706iO4h+T3Q70W1EtxLdQnQzNXYTtXIj0Q2Udz3RdUQ7iK6l CtdQ6mqiq4iupLwrqJXfEV1OeZcRXUp0CdF2ooup5EWUaiW6kOgCovOJtgVjGkHnBWPmgM4l2hqM mQc6h+jsYIwftCUYg8OYnxWMGQzaTLSJqm+kemcSbQjGzAWtp+rriNYSrSFqIVpNtIqaXknVVxAt D8Y0gZZRY0up5BKixUSLiM4gWkj1FhDNp57No+rNRHOpZBPRHKJGogai2USzaND11LOZRDNo0NOp 6Tp6UC3RNOruVHqQn1qpIaomqiKqDEb7QBXBaPGEKcFosbwnB6O3giYFo3NBE6nIBKLxwWjEBXwc pcYSjSFjeTB6M6gsGH0+qDQYfRaoJBi9BVQcjCwHjSbyERURjQpG4v3OR1JqRNBRBxpONCzoEEtj KFFh0DEGNCToqAUNDjqmgwZR3kCigqAjB5RPJQcEHWJg/YMOsTfziPpR9Vx6Qg5RNjXWlyiLGutD lEmUQZQedAgvpRF5qc1UajOFGvNQK26iZKqXRJRI5CJKIIoP2utBzqB9FiguaJ8NiiWKIYomiiKK pAoOqmAno40ogshKZKGSZippImM4kZHIQKSnkmFUUkdGlUgh4kTM12Wb4xbotDW5j9vmuo9BHwWO AD/D9g/Y/g78BPwI/AD798B3yPsW6W+Ar4GvgMOwfwl8gby/If058BnwV+DTiPnuTyIWuD8GPgI+ BD6A7RD4feA94F2k/wJ+B3gb+DPwJ+si91vWAe43wW9YF7tft2a4/wi8Bv2qNdv9CvAy8BLyX4Tt BesS9/PQz0E/C/2M9Qz309aF7qesC9xPWue7D6LuE2jvceAxwNd1APdHgUeAP1hWuB+2rHQ/ZFnl ftCy2r0f6AD2wf4AsBd5e5C3G7Yg0A4EgPvN6933mTe47zVvdO8yb3K3mTe7dwL3AHcDdwF3AneY c92/B98O3IY6t4JvMS9y3wx9E/SNwA3Q16Ot69DWDrR1LWzXAFcDVwFXAlcAv0O9y9HeZabJ7ktN U9yXmOa7t5vucF9sust9npruPlctdG/lhe5z/Fv8Z7dt8Z/l3+Tf3LbJb97EzZtcmyZsOnNT26Z3 Nvkm6U0b/Rv8Z7Zt8K/3r/Wva1vrX9PW4te1RLesblF/aOFtLby0hfdv4Qprsbd4WlTLav9K/6q2 lX62smLllpWBlbrhgZWHVipsJTd1dB3YvdKVXA72bVxptZev8C/zL29b5l86b4n/DHRrYeF8/4K2 +f55hXP9zW1z/U2Fc/yNhQ3+2YX1/llt9f6ZhdP9M9qm++sKa/3TUH5qYY3f31bjry6s9Fe1Vfqn FE72T4Z9UuEE/8S2Cf7xhWP949rG+scUlvvLMGSWaE/0JKp20YHJiegJc/Hi/i6f65DrG5eOuQKu Ay410pbgTlCybPG8ZEo8XxZ/Vvyl8arN+bJT8TmzcsptcS/HvR/3dZwuyheX1a+cxdpjPbFqjBhb 7KSaco2LSokHDNLGOinWm1Fui+G2GHeMUuaO4cxxyPGNQ4151P6yXbHZuM3WZVN8NhS3RbgjFHHr ilB9EQOGlNusbqsibl1WNdZnhUW0mGmpqCm3md1mxV9knmJWfOaiknKfObd/OVO5h3PG7SDViLJ7 eIy7XH2Yiz81CmOcX9ZeU52dPaHDyKomBIwVMwL8gkB6tbj7KqcH9BcEmH/6jNp2zi+pa+dKSU0g WvxDrZY+b/t2llQ8IZBUXRtUb7klqbhuQmCL0D6fpruEZihSlz1rVcuq7OzVs3CbtWp1tvaDFG8R qWxhFD+rViMtPi1ammX/6kXFQLNX4Vodsq3+9Ur/v1/8P92B//6rnYm/LxjdpZzL5ipbgXOAs4Et wFnAZmATsBE4E9gArAfWAWuBNUALsBpYBawAlgPLgKXAEmAxsAg4A1gILADmA/OAZmAu0ATMARqB BmA2MAuoB2YCM4DpQB1QC0wDpgJ+oAaoBqqASqACmAJMBiYBE4EJwHhgHDAWGAOUA2VAKVACFAOj AR9QBIwCRgIjgOHAMGAoUAgMAQYDg4CBQAGQDwwA+gN5QD8gF8gBsoG+QBbQB8gEMoB0IA3wAqlA CuAB3EAykAQkAi4gAYgHnEAcEAvEANFAFBAJOAA7YAMiACtgAcyACQgHjIAB0ANhgG50F+4qoAAc YGwuh413AseBY8BR4AjwM/AP4O/AT8CPwA/A98B3wLfAN8DXwFfAYeBL4Avgb8DnwGfAX4FPgU+A j4GPgA+BD4BDwPvAe8C7wF+Ad4C3gT8DfwLeAt4E3gBeB/4IvAa8CrwCvAy8BLwIvAA8DzwHPAs8 AzwNPAU8CRwEngAeBx4DDgCPAo8AfwAeBh4CHgT2Ax3APuABYC+wB9gNBIF2IADcD9wH3AvsAtqA ncA9wN3AXcCdwB3A74HbgduAW4FbgJuBm4AbgRuA64HrgB3AtcA1wNXAVcCVwBXA74DLgcuAS4FL gO3AxcBFQCtwIXABcD6wDTiPzR29hWP/c+x/jv3Psf859j/H/ufY/xz7n2P/c+x/jv3Psf859j/H /ufY/xz7n2P/c+x/vhLAGcBxBnCcARxnAMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARxn AMcZwHEGcJwBHGcAxxnAcQZwnAEcZwDHGcBxBnCcARxnAMcZwHEGcJwBHGcAx/7n2P8c+59j73Ps fY69z7H3OfY+x97n2Psce59j73Ps/f/0OfxfftX9pzvwX345Z89ijIn/T0HnFb3+eLqCncFWsS34 bGPb2RXsUfYOm8O2Qu1gt7A72T0swB5jz7K3fvOfd/+Gq3N92BJmUfcxPYtirOtI1+HOO4GOsIge liuQitJ5Tli67F1fnWT7qvOKLntnhz6SmbS6VuU1WL/nx7uO4AWLdNdgkVbOh7ZpNb413NR5f+dd J/mgkk1nM9hMVs8aWCPGL/4WfyE8s4gtZkvYUi21FHnzcZ+H1GyUwmGi6ROllrHlwEq2mrWwNfgs h14VSom8FVq6ha3FZx1bzzawM9lGtil0X6tZNiJng5ZeB2xmZ2FmzmbnaEoyWbayc9l5mLXz2QXs wl9NXditWtlF7GLM8yXs0l/U23ulLsPncvY7rIcr2VXsanYt1sX17IaTrNdo9uvYTexmrBmRdxUs N2tK5D7MnmJ72X3sfvaA5ssmeI08Iv0yT/PhcvhgI0a4tUePyX9ru721GWMXY2sNjXQd7Of0qLEm 5EdRcitKUis0D6KVTSd54jKMgfSJEVHqKm38J6w9vfJrVumPG3p45notJdTJ1l/SV7MbsQNvxV14 VajboEndrOme9pu6y96ipW9nv2d3YC7u0pRkstwJfRe7G3t7J2tju/A5oXsq4vvYvdrMBVg7C7Ld bA9m8gG2j3Vo9l/LO519d8ge7LbsZw+yh7BCHmEHcNI8jo+0/AG2R0PWg5qN0o+zJ5AWpSj1FHsa J9Rz7Hn2AnuZPYnUS9r9GaReYa+xP7K3uBXqVfY57scB7f/r0rlKfQ2nhsoMbCibxCazGQ8zK97v sWwY37s3prTUmGt4BO9uhXnw9jfi63mJz6ZTrPsSEoq8+wbpt6uOcR08d0+RYTvi2qLj7x1/Ke/4 e4cjh+Yd5nnvfvDeB/ZvX3IMzSv44PUPBvTnjhSHhugIxWCI1ntT+ymDMjMGFxTkj1IGDczwpkYo mm3g4CGj1IL8ZEWNlpZRikhz9bVj09Upx/XKZm/R1IKw5ARbtFUfpiQ6I3NHpNurZ6SP6JdkUA16 Ncxo6DOkOHXC4rLUtw2OpJjYpEijMTIpNibJYTj+TljEke/CIo6W6BYfvVLVD59ZlKZeazIqOr2+ I9kZ33d4yriptii7zhxld8QaDZEOS5/Smce3xSSKNhJjYqit45PgFm/XEd3msGiWyjLYjftZWtdn eyx2PtHbERIZHV3f7DFDmKUwQfgShEq3i7tVu1u0u68PTxfZOWY+Kc2bkf6DxWxxpiZ5TVYeq7Mw i92i3O991PuyV/VavJbIpKpIf5ifFRUVRQ4dmpdXX++IG+qAdBTYD+c7CuDx7Hp697Hs7PTYWL3m 8kw1RY1QvakZGYOHcPJznMGrpuhajNye7nanR4Xrlh3/9AzVFOVNTEq3cSMP6qzxmcmevgkRujP5 +/zxkbGuCJ1qsITz4Z3PhlvDdWERrlhd0BxhVFWjzbz9+JnivyzbxZjuUqyuSOZma31JRSk8ymnn k6LsNtyirbhFWnBzYrBRD+GLHWMJXZ/tRokE+GC3LcRWjX/abdH4s90onfAQvoKFMye3BCMqXR08 oz2shhUdLsKa+0Ab7utEA/rXi7XmTUnNGOQYOLggBUM1DOyneL0OseR0l06945s7O7+Ky8qK4+l3 f3Zj5d6By3Zuu799486VQ5Xr7j56R5U7U3dOpnva7Z/tWLj33PHHHKO2PCb+m7hdXUfUGowsk81s N0R1UK+jQr2OCvU6KtTrqFCvozoUx15rEktOMnRwy+6oqHh9B++zO7UyXkxhaM/kHXQMpc7nY/q0 zjtEt2NIyv0gR6PW6ExWQ2cGP2CwmnSa9hmjPQnO1GhjVpxSrlkPRiU6jJ1jDXZXTJTLEX78E4PV EBaGm+6+TDcWshjRjK6vdOvCPKyI3eZLSky0OcVMOcVMOe0Yi9NkEQqjcGIUPit7NJN7Mn2ZDZlq pi00flto/OAvxfjBX4nx20Ljt4m/Vc0byAc6O7hpT2rq0LxRD3ETTiETzwoOrY7u4DnteVPFPB5/ /bCD3FEfms/6+oOkYA75BW4QB0ZMdDKOhsFDHGKSxTGheQuO0vU4OHS6dTqjxWApnLV1+qKda4rK NtzTPOLMQZ2vOxy6cKzi682xkabIYTPnzB1w9Ze3T62/5/Bl489pLksw6WZFJUUZM/plTG59ZNnG A+eWJiXx9alpcKPRaE+M7IxKyEhKdVrqd31z5XVHAo0J3qyEVFofugqcCnmsY0/RAO61hFxkCbnI EloiltASsYRcZBHOTYxLMwvvm4X3zcL7ZuF9s9gn5g7F7otjvhg+ifmixM3uwNcvH/JZnPiVLjIE P4C8uL5VafCpz3bAwl+xcEvv8yKvfsXhIp4H3wq3hpacvXvp1ad3L7Weq46O4RjYpNRVGKNTnAme aOPx3VDxYuUZo1Od8SnRRmWSthahEuB9LDmLURl1/HGpdW9LdfyIopc6tL94LfwXwyr2FcVNibs/ TmUhF7KQC1nIhSzkQhZyIXsQZ4Op68A+eMJkr9KGi2F2HwjppwyG18p+h8ekxMX37O2JHoZ6pc/G rh/BdvnsDaOWj1Ks/fvH5eWZ+jmdCR2/8egSM5ycNsBiMYk5Nok5Nok5Nok5Nok5NokRsK4Dvngx nLTBlWZnnDXPOaCf3t2n0u2XU1gUicO+AGN7Xc4ejv1u5Rg6Mq+gQLwDeozYy8W5jzcA9/Y6SbRX AC8QLwPNI/psY7Q7Pi4lyqh0FqjmmKTomORos9I5hmM+452eKEOOa4Gnf5oznK8N49vMCe6M+CU2 V5TlhOPmH73SYDKoOoNJj5fsjm77nX3TLAl9XMemqXcm9403h0clxYT2y+YwBxvJztudabNFh5yp sS3EVo2/Ec6MDjkzWnNmsqlfv3zhzHynTdxQMN9uEQpF8kURO0surDL1s2Xq4sVpq69h5D7hvFN8 lwefaS4jT2VkZHpjY2NO469kNa4gI+PEOtJttsYkWIckZHq9MZ0LPKMTFUUxRrmdTnekMSehKinT neTgw5IG5w9wcoUjJz7WE2kcE42owpyUn6kcGrpp+Nirxx/7vvt43tkn1RSX5T7+zMCmhvq8KW1T lEfwztXhyDJo71e8hZ7GekxkWWxde5o+5DV9aAnqQ0tQH1qC+pDX9MIlcY4k4bIksf6S7BYrn5jk QV6S+KMt5kjHCb1br7d4O7h5d0ylpccLihxm7/2O8p78YtL1eM2qT/vW3rvuivColHixufom8Ji+ kxYumZi1d/i0+pybr588vzxNvaLxhqUjOvt1rxMM3RBXNHP9tClnDIw4/nOfMU1iB47pOqw2haWw ceyv+9lohFg2BE2jQ+PU2B5ii8baeEd3KDm+7HxfVDSfmO9zILLKT8u3uJyirktsPZfdLm6o4hJL xvWgMkDsv90u7VQ5sDs+xNHED9jEkWvp9xDPZEPw8srwmR2eIXyIz2zhEx3iX79MQg1xDHHEjsCb fu9oV1hWdWwHz2oP015viNAOO0TAlp1dbz9sF049cQZHUoY8r0KvOp2MgClU7qcPpfUxvV+FerWp ZO2t9aOXTRseZ8YrzxhRULFifGF9SVp+1cKlC6oKhi+8vCZ72qQRUXqdourNBnNeaf2wwRUDE/Kr z1h6RnUBXzTjkqb8WE+qM92NmNmQ2sebPKSiYMjk4QMKRtWsmFJ51tRcW7w7yuxwRkUmRoUnepOS +henD548Ir9gZPUKzJENq/ItrMpU1rzP6ROxg0N4bY84q3/zEhVHoKPrwF7kOfSRIkxKCq3CfBzm 32rOeTLbfjC7O0g68bqSr30tPnpLF241dl4pT3goqzEsDDf1XCPiVoqNjt7Uve7mGB2JUVEU4IsV t7PrsG493kTZbIcvqSGXe8Su8Yhd4xFLxyNObY9YNeK/K/E5er6ZsdJYbGjAsaEBx4YGHBsacGxo wLEPKnbx1hLvb/HP0L5wNGHKqLJXuU6sG+11HQqIsk8skXp+6vs5OrRSThxO68u2dLQsCmwupfAw yphT3TJuQktltuaalKhw/t6a/VuKR61/YK3qle449t30bXW5ObXnTFPjer4JR+JNeAheGcHm784Y wfM7uv7hKxGLPh3TYxSiTx7H1xthSeepTiGyUrnTI0TuAJ7bn+em8VwvH1LVt8rb36z2DE1wLhdh VLjE15fQJ737zaVKhe8vg3u8uXoofNMxhG3V2ROzkt3ZiRG6zm+VI2pEQpYnJSfRpnbu1HNHhsed FmVQuJfzaDU8Oj05MSU6XOVZCk9S9VHepGSvnYdlRDjEaeuIUF89lie1ri0OX4NUY4T56EHdMLPN qNPhK8/Rp3T/j7UvgW+rOve8m3S162q52vfVsixLluRF3nS9SbIs27GdxVlsJ7GdkJBgh4QGEhfI QlpaWmgJdNLH9NE3vLYz00ebxAkOYUrnN2lfoQ3De7+08/oKPNJOgULF0nltCSTKnHPvlSxvSYCH iHQtx9Y9/2/9f993Tpok4FqgMOmhb6aAFfxfwod4kAqk54xB75f55HMYyoj1Pgd4T+qTzGFNIDD5 vNZK/4cwN5tU3ya4jc/NYPqLGsOGS5eBn1AnTNSr3AWITCUW53eSC1kcwbI4/F9JnPI5nV6tCF9X YAYJicZjsboVmAjdQcgMfpvRbVBLRfjnsR+g25t1cClCmTj/jlgmwgUKC43/RKogcRQQaJno/oIE nrfybXj2HuFAbMAKGpCWk77YeQxHpIgd052maWnVHNYCViI1+X9bU0N636AmYn8mt7N8DC4lAWMG uLhMXebCBbGAj0EHRtpwfD5eaMpCx3+xxLrWjLcV/pfW49GiFWP3rq3SeOrcwd6E6z061NX8X88k 2iroJnP9UOePXqvtjFnRWHxtV9RFWZ34U06rq3O8zd/ZGFKIKjuG0W+6Gyt0hefNoeZCT7C92lB4 ShdsBdq8+/r7+BEigtQiTacMiH8Oa2UkMt3HYWvSilldc6gaOPht2IeOmkgNVlM1h9aeJHcggKSM 5NknQDovXWBzhgWUg15CUjhTxI+ITPHukfpdp+5Lpe8/vSu8LttkEoNEiZT6kiNMau9AVXjt/u6W dS0VcqFIgP8nq9PktGjSD75w+NAvvpqlLE6T26k2qUR2j61+++MjWx+fiNncNqHKAvUOyuoqkBXk 3K7nEA2WgLQa0zJiseGKYsJ8RbC9yJTZkgyX6CxLj/Gr3V/62Vc+ZpFXfel/Hun8YcWaL+z62iPb jq2vwuwP/eJYGwdy19Hn7x18aHvj1XdrJr8BvQO8BwUBz9SpOWkCcGoZrdihcWgQsemvPp/Q+KF8 wv+hcF5D0PBFGPRY/fAu5uv0Eg7M+nUFQUqF196EN4epSSlJgK/JwmZ0OymFNQhwfQL9LohvRCeA iuRuFBBgtdqoFBV+QVImjcpIkYW/JykjvOPrH2Hvgzt2I9UnBSp4x2qLVGpGLGbBFZVKT3zsmNDf tpCkh3l1Ft6IoOuw95XKwj3otFAG71AmLDwi0kB3qxUBUK8olfhvPI7CrIgyatQmcGOrRdxKRPiL TqsTYrnr+rv4u0QUYZDkaZtNaYCz50gFoNINjKTW/WejADwiEjh817gNMGj1ycgOHleIKKebwHes RJrd88ES5rhCknOuRR3G3xWQYkJZk9udW/ulLfH68QcHqrf4/1jEGx3TOSiVc9XqtYH7Xniou/+R Fw523LmmXivBH9KYKZHVa23e+dj6rY9vr9XRqA1ADeEnrfbCuNZKqk0aae6hnx6476VH+mm7XWPn 5AAitg/w5vhJQJox7SnAheGmTkRfOemBlihe4irZJD46rzy3wFnx/yOigRQcWrJgYxmNE3JWp8EI WCz6W1LrAOyVFulLy/xpobF4jf+ppGzj6H8uXiPcvaM94N5pRHMOWKJ2VkJNsncJZFB+ayXa2VP8 aDH8QPDRpQ/E/5+QuxJevw7SoI/QTYIHMB/yNDBlIeZT8Z+GfwV8WgPCnEPc2ObZUEjXEPsR1gLy LimmRXSIBBtn5IiuYtIlVVkmVSXEONZDfRC9HIZeef7W/OgyoPGRlfXSKKA8+FdEGrfR4tHLBYV7 l2A3JVTqHAaTSyMGuaW48F10v1AkxA0k0H4ckn/VtfdES9ZYqEVfBO/i8F2hVKGSFvYWxCKFXML7 EuzXYJ0GuN1fAzWBlE8CRVecJFgHAnwHuwQh7zRKwgbP2K8pZcGu9czfHszwujzAtPBfFD/96iFS ZeYRFUwCH9CApGer6JDfMIdeZ8QueVgSCrniEviVCnHVToR0Utzqm7DeRvGQlphkVA1INwAY6CKI 1uUyd6N80L4R8dbRgklS49AbHWoSK3yZcFfQFrUYL5zASLXDaLSrSZ9hl73KCVh3gECjMqMzYNlm 9Mxrzf6rR2UyXCgW4jNXHyy9+48uB2Tc1+LYz2yVJqnDxWvP+wDVJuDvnGq4vcFCRObQnwOFsdRN Siv10N/h28sVpmhhQhguOFqs5Qpti5aj0en0sWp8Xhb4+y7TXruPKrxV0e9HAfUlVRadwQqXM6My a1WiQnANyLvAf0K1RW+wqoTtLofdiUl7vplzZXuyrms/Kl+MSGmgCp6Bbw9WrFmztgL9M8hTCMh0 YPTbdv1dohN4Sw3iR/zPI1qsCZiMDTxLECOqPKXcBgit8qRgx5IQWNZjYCNgWcwmOtvue+7AgWcO Nrff/9yBu87MMKec2buHh+/pcTt6wOuBnBOzHf7fX+vr/MKLx+69+Ehf57GfPjz86K5mZurRgY2P 725qn36MjcwA851Av6wgi6o66ROeB1aqAjfXDEBX+f8sEMi8f6EnZLeVU+1iyrSUYev0NpyM+/w+ XzFa74yPPzx5vGiSPgMqd3c6GjcyrtPtrXRY9/VvNXXXGLHfDx3eGC58rRxQISmL9U1mM1tVAkFh t72+p3i3T4C7jYHI03IOOBN6toYKquJwa5iviQ2RSktQ9UZTkz7xF6gtnC0UM77LUZjzJX5V7l78 1fjSQkEx/9PrdbqyHBB/QkR7LWYnLcHXKj2Rtvj24sJA3DRtfmBjxFqbqzGHvE5qvYT8Ix3pYR77 amtf1KghgfrjYoX0T5WdYVOhv7TQnzutvtT2NpgdUlJnhKn4g8mIveZuDhoLTxvDDPQA3dffxa4C 7elBes4h7Zj6jC/uiyuscI8bogDmIWfEidYr1g5BcBtwB6qzDk1Eg2mAn5CzKsUmhGDR1y7luZQX ROB5/RLeKoPHrjZt++pQbCxXS5ECDAPJgDSU2tIcytXbg6kNIxvSlfFNM5nKwY4aBft9MSkOtAzG /EyVoSq9YXRDugr1Z/f1V6nNFkpK0ZTWqhVb3VZdoMkXaAl7K2NdW9qYHdkApTMqAYunNCCVNFlN tDdmDbZW+yuinaMACwuQfyuQvwOxn0QIIO7TOiVBAb972jwhuY0n4hc++EkxBVqBfrcqFYXLYrXT aLID8n25mJxhb0G54L/xOq8eLknoXpEK5GdmFQkdMor8LZv5+IC1eJ5DHJgGWLIO056R+CapSfO8 GScXm/ENSDD+bssd39o69sRUI9Amg8mpEbm7xhKJ0U6nSOMwWO0aEv3mvm/saIhNPnYfNl2MENee 2DLZ6QJUYhibKr4H7s8JEHoF3J8LiZ1C9EAL3jvj0jskehqkaIxEqrdO6gR8BqAGLpRlcxyVY3nc SiwWclfsDkKi99ldlQYZUfgbIaH0OOxuLWBlUQy4frHWZbU65QRp4/ptChn+E51Zzvbjrn4b3ySR QyZn1oF7rAc8nQT32IysZcRhiQxpjkRk0Tn0fUbSLNMb5F63W+aaw3SMyiCrn6ycjLghFZ9PryAV L965MQwZqIHirtXgumwZ+DK0XBPT8LScv4JLI94g5KYKmytokOKv45cAI62wO4ImsM5/IVG1z2Fz akj837E/4iK102pxqUn8Q/R3uEgDl6zAhPySKRn20TWBTLlo+ZKr/w0fksrhu3Lx1f/OXRMKsx5a dx2Q16MAixiy7jnEgzUgJqQCQxhJ1BiLmsADUcANnQYZS8xViMzh88lCkz6Zxj6pKU+ejOFY2GQA YmQlCWycjfjU5XJujvvJ+RZrGSL6+hIQKH5IiasDdrtPJxH8Xir9PSHVuk32CjWuQKsKv5MJ1BVu q4uWCH6tlF0CJB4kLT6lUFr4XavJIBfgIOChn9frC0dEkLfLDQb0VfTnLJsHOU7hSZMJHYWMXqgw aQsJsHpYj9jL1iPC5xA9IBFymQnuJPUYEOjLxTL7pEGonhQW1TX8QeKXcIWwa1+yrCWyZZXVKNa4 9EZgTIVZGan0uWxeWkxcxf4dKKrb4vIqBFL0sULJzNF7sX6u6gASxAj6skgqJAilEWprJ+CNXuBz AkjtOYTCtpx1aMED8cFN2xIH63yMExIfa/sw+YuyTugyTx7LuCP0P/XogoYgl8CCuAk+AdzFtb0G OyGi5OhvC06KgukDtkumkQlxkVJWcGKIQtmlBgzGbnMqdXqzBrvohD0/klRq5QElTRs112pcIEpu up7Hk/iLbJT8IeNQttvbw+24VKyPy2RobxxWCOOwOBinYLE5Pof+lVEgfr8SQWUIrCEijXytupHv cDTy9UD4yha3G+cwEaNV6X+CxKk41vTjOIrE0Xi8uq1yDjUzypddqMtFWN+uzra8IuslkDDPqUfY BurIntGRYk/8QnB0BJJWtmwPLHd0BORyQqiitbWc1rJgxWr59Id/h2AdJ8kFJx3kjHiSsphNdkXT 1wbSewdCrfu+t2NGV9OXaNnSXSMTycQEaW5fuy2+5YurfU99pXOi3b5+VdtUi0EmEwplsg3JlDe1 rS03nfWm4qtqzSAwAfKrNFpNbqumas29qy/oQ8lAaqi9E6B7AqD7S8EepBL2hc4ATyRx1vF10zq+ jlrH4wW/ZvGqm0M/ZMx0EE4WBB3gbwQh/kFYtQ1CxINzmIQRI7SkrtZJCEBQF5z1Zc0pKpcAlycF vWxIARDqE6Xe0DxmpUqrn14abThfV8weSZVOxyYyv4yNPzIS7E6l/CK1mdZa1EKQ4wM6ohZV9GQy FVu/vK7iaTq+lnG0Ml3+zpmO1uF6I/rmXeePplS+xsAdIq5wIBI0FPPca78PNLipviM/vKvr8ESL urI9WjgxtK55/CCwoA0AMQf+AlKLPHjSwvYsuI7p63yn9K1Z2FL080VpP1+U9vONej8PJnh9G/6A fw6TMvKwAlUY37QzEnnGDig4NqvJ4u/UwIq+WJ6B5TDhSXEvzH6Cefap1LS/wDWIgFUKy/JrkO8I uXRHuKAq5sAEpLG5Zzi85fHJ2rY9J9YHBzprDWIhppYr/c1rGvff52RGmhNrk0EZbCz+ncqokhu9 VjVz8PRdDzx/oIkyuQwKjUHttzsrnM88ve7IcNATdIs0bBUf4CL8jeBu5C7kntPbxwZ2wpORIvUD iGUOvXLa7x/TnkevICKQ80kZ01gwP5VONvY3YpEck8Mac425dPKt6EQmDZbKSDb0IhbclVPkjHDl eJZVGBgY8skY19UZGeG5BaTX0dcuXbqsghEf5VxnOWNiUSDn3/D5+CSQWB4kegGUOr3Px4OK08Td 6Yd7NhzscYkBVzTYtaQ+kq5pPdglYgmlRiR1K1vWNZg9IRZRuTcxkOARXZOsZBGF+Df1rGPxZ3Z9 tY+u0ui1Ndu+uSPQVeeS43U93S3bHtxy7RWRFOqhVIQpe0c7PcNrrn25+A7xzxhmr8sEkr0Rhcqk 8tttHjsnCTcrCZoyqmVGr4WV2dH/cXeCJC0dVe13rq4RkFKFnJfTGSCn/cgXT6/tY9ZDOdl9jG7f jzA/MonIgJR0yDZs19lpHXj0Sc5j8F9aqQFis/dNSgW3d5vyo+lkoD+ARZqYJizQFGiqq37LOZQB bkF4prtXlRPkWJpSLisoPV5ebCChPoi+TpXEtlx15DPIab6gAlIAFMTPM6TWaTa7DQph4egiYbnC 88K669AnEBa6hlQbXQYjSB8UysKz6JRMYoLuAyflYvRPBfligTWsCX8agV19Ff2cRC7GcVIqlgFS /mzBq6I5KQqeF0wh9yL3zyL7d/TjUIyZ+n4FSJKvMNJYS6wfPPZrfRugg9HtTw72D2KRCWYCG5wY nBhb92Z2JjMGjU18Z2/MkFe0ZICdEmdCvR15UYql7kB80XIhsmVOVnywjx+lfgqo8wUVNLoS9CAF 4HGHJFRXJiqCr9Hw6UIpAt6yfLF6nbZ64+Ghoc8PBt+AEVBFvVGf0nsstEggEuKkwuKPmtPjjG2/ Uk2I5eR+Y6g9UNFebbRFxAJMLZN7G0rWWPRv5d4QCLifDuKz5s5g+9RgdfXaQ2tGSZVJ43EUbHvG xBKxQGFQ21xyuZT09uzdin7k8ABSR2ab19WbLdFUZcNAVKE2louX84zach8KxNsghMx/M4ghTwh2 Iz4kgXyZsSebUKk5ATOZBOx1JmCvPAEjaQIG1gR0nAgS5iJMmA8sYT6whPnsJswHljAMviCVTUkT fjOhqITbvA1ZkBYRpxW9rGXm2dCbXDTHx8beUjWtPF0BxjXP7kpmyQqqHn+CVFm0cGgzfWLj+EPr KqJbvzbWf4QhtXYYf8Xf6fh8ZxJEWxB925wtTMpvLAbb/b1re4+c3Lrv/NF0VwcmLc5jXOsCcXbr DNN5eBLE3Y4aiNYIQOsEyACDSBx5mqkM1yXrpupwDcw8NA44DKhxVsHJgiqIVhWEsYrNBUHcvHKm M/hUEAsCkM7AzCRO8IGa4OMx+7WUfeWSQQLi53RW/eP9xCME9mMCfZlACcISfsWXNby9WTGtwBTi ty29fCmCzQP33FlMAKOvBrnADN7m28aAuK+o1eBrfx0LKImf8BuvnbKlpgeYie6wDNBfHAM2X7d2 DzP13Tsbm/c8Ob7zsc2h7+D37G/Z1OrCMMzv7Ll7bTVtokmFUS3XKGVSo0HTemDuwL5zh7o69/7N sObw8ercZD2Mzd7rH2HHgM9vRiZO6SiYrLBJipnP8MzFzM7Mp35mXpnM8ECbSKV37vrLjBpOwXkl +bq0yZePZBw5KsO6+SiMxMELsQ+4fCR2YVEbpNwllGq1836Aa4JgxwhgxiRtC5i9cYfiBZFULFAr X4AlAwNw1vdx/OE+d2Z31t3ugXRMqdErBGKp2BAbaNzKWerVd4pOF6c58xwZ/cLagFwp05ihHnlB 5GsEKEwidyO7ZisraU8Y5iYJyaZpeMLjAE0ntkFvKUU6WxOSPdObCMHtwHwY7Zbs2pQtn01XN+Y7 M/GcJ0Pl9pWnsiwIxYz2QozNSmKXo1yRuqwtVJbSCoWfDCA9H9JWSIGFjcDwYArcVSFSQ4NUkYRY KI5FavStq6pV5ziPeW4xnpXrjo2YGmIBvQJHSZXDBL8XyGa6/Vu/tK7i+zqYMre0dfk7ZjpbhxuW S5mJn+A4wNwYH6xfUQibR46tCRAkSUpEEpnkJvk1KyXRXYJ7EDXyJPL47PHjU09C6ZyZGRvLrh+H V1OaqWRQCsOcOOvIToHHDODXFsZee+z+mSczT+QfSk2Pz+SPZT6X25Fbn+nKJaWSIBFRQE/Y2CsA L89EADUayhvTrPh4f8jJMcr1O2J8psKGugT7zLUjOXkuQh8tSWkRU6E/seCdK+oArEaXhUqa/FlR Pr4OltKYPq6D8jQDeeoUBNvPAOKsYMUJGFCMVZCutJ/UQI7EKogEKIgOKIj6WWBwhEr5bFFBCrsW q4onc3u6qp2WANuTyEW0o8KUbUYvLRIf5toy8sBaTtjiJcLeWlIfMVeoEBM/5dSndqB+fKn6LFWl NfC3K8UEMGiNwwqsf9v0Ot6/ET8GOrMFGZxNp11DHui3qmU6qCT21S61S40kYtWi/Ib0UKY/n0y5 deF8IhPIWXIy1onxgoee7ELsAhR8jG3G8NY7D/pnkphz/m3ixxBEOwCx5QXONl/4hNAf94J3gx00 yHVwAeWwiCAYnxrELfPv8XgKhcBT7kZGZ2OxetgMvDK7wWbrgGZ3aneoHryc7U13TGqMFEwi6duy Yyl/fihd35HvzbTkQhkjzwLmfSMkABdjXNMCwstOmXtXJmqf2kPyHFAo5HDUkroSTWNh/bSOEZC/ 9QdzTuMNyNmn9YYc7+ORFzFAkx9DvjD7xS+OH5+AHm96aKi1dx2MVeOPjcdZz9cqax0Hj+kgrMVY 7Qf2TR/PPJK/PzWxbjp/ILMzN5LrzehNiZw3FwECesaUVaXSeUHR4cHy40rubqmzW+zbbk6y/8Oc nBMrLOPT0g9n18/0OEVqrshjqO6OtB7sBDKE89Rs4AvVfya/dpwwLOfHboGeA4cmEX9GhwZj4Ef4 WaAFGmQN0nGyCzmP3YFIEDuwvTUDDih/ui5SNZDpzTenHVX5OqWgLuPLGVmDu3SRyhelejn66geX Lr+0tP+K34IoFlSRaDi7gp8V6/w2q18vkej9VptfJ1bfANf0jk5dlccsERIYAFdl8lq6GjHSZCR+ YfHB3+CzWLxGsdjo/bjmRghxAUUklkgpg8phIUUkcHNmA5fPfST4gEVpBtkzu2pV6G6IzWzVSNUu kBBMnZVUgUfCDl3WzKYQGws6WhJ3Z5QCQce+/Hh6U2Y4350KORL5jkwsVwSwFAuAg7pYhLFYt3iJ tY4FG2RuiOkN4CWWCQ1LMRd8INaXY65nMWf1vHD7zbTaXlTqgJGNGCkgkpAbiESASeSk2ugzdzUB kZhuWSQrKbB8SSxZTmKsdxNcBnFlCpme7ewMt2Z+BKjtaoTGfIgQ8QD/Fr49TM5hu86qwuCx2j2H DTIW4+jw6ob8RDqzOj+a6cu1ZipzQo/MlpN1I6lix6hEREqujHVkH0Qvl9zYwlEbrjJEL1N4+hRx Bx+A2MOKkMFlNLh0sCJ0Dp2WSUQatu6kFBYeKEoIE5HSSG1Ed/PoU+vno49gD3z36j8vUwkSL1ty +uRhiI88FmBNjyOPnkMewHadeXhsrOn2Zhh/MsGgzstypaZdTY+eB9I6ikhhFNLdo2sCj4wECsqL DOYyR6WCL3Xfm7Ln70zfntmeH041hzP5wUx7rjbnzahKSUHJyJJJPjGYj0BAaAtj0EoDVJ86yixv e2URbpGaiCwijcs0L0jW/IAgZWFOkLccZuwLowwX2mr9OiVeDG3oalhWBEpESxQKoERTMunyZcVP lTkvsFOgAotD3LI6xukG/hSw21VI66zd7k5JoE9dZXRDn6pNxMI9KU0+mXZzSbUxIyg60lIcusRb ofczp3f4U5/Bktg8zvgZ0zXej/0bsJX9yCQjHhqKhO12KYvGmc3hcPNuNkvePxaB8FhTTPOdAJ5t 6bHMxnwuFXE351OZulwZTvPGUAKLS5EBZCr1J4Lt0+u84N+Kio1zik1/RsUGsFeU5WzG/0DNXYZk ctHlPeL7bH1n/UkmCxNj2aTbjcQnJ2Wp4RgC/ZeOkvXNoQRDj/UymVimsVEXylvSWUSW12WEbHEU igJgnkxy0QRI4wIUhro4jHxDgMvLXkWIb1oUR3cuKXOld2e9KZuMxHGhSCDSwqpYzKFEHxfBxhPI eN+AO2zUyjfrMjqvhSbBXyLElC0Q1qUnGCtevUIhjAOxvG72q+JWt1/xtW7JSLHWbXVRCrHQ27O3 D4NnF9QWHsUfxH+GtCJ9yBjyMkOrQ2lYoU6LZODJQWnQXDqWnLv+ISwfJvnaNHh9/Sz8VpLsB5eM XKlGc/1mQhnBYyQJK68UW2v8MSMHF6EYaTaTsRAB65NMHBYoh+FHDDso8GPDlV5GCl69ygiJN2T/ VTb0Fk1vbsD/0JypdLT/uiG78deOfn4sO8ltbf4VV5ALxi7CwqQeBBK460sF3qQuBsH/weITx/Hd xXzA5xeCPEynZ7nIfJJXD/scdfXFbodOD/IzNO4rte3hrgqf36/A+a/wBzXKQ25LdOT+vvpxs1rf VvdOx/Rgdfz27+zZfWJrFeWscdSEo167J77pUC6QtqOUSlUoTI5E0mH95MaaTFg/NDbwB0fAID76 uZ7JVjO+z233rAv33T1UZdWpq23uakyCOVvWN7VOr6nxMuvjztaGmNGYq2rZ7POOtPceWB0Si5yF DzZtdzR0V6zfZq/PXBttTGIiYyhQQbd1WCOtbC8CSPYJ/EWkBXj37KmobRXMoRGFAknBSri8wooM NnRHW1fZCHcbPCU2lO0BL2fcOcM7Ag5wrn6misXQ8OULrJ3M9/QWjuTVLhh9x/QlE1naV6jf9e1d NeNDdVoRjhFCSOm6d3QyW9odgWw67S+2GgLprnSgWPFc0mzw7j6xuUqqpuVKSiuDJS+NUWNqmcxN BhIeZe+RH2zd++yRtMrbFNgt5obmxIW/su2HZNfhiWZ1oKMGeJUTIPY9KdiDRJF7ZpNxtHL+qAG+ aF52BgF/JgHwPHobt6Gc3VrO7ipnWxJS+D0Jt5fcVskWT54JZT2pUrkEaC8a5rdSc0MRiYUbqhdT 7cWsHH9yAS2e6eR8hoYsjkSkH+necOMyRvkcRLEygSEPXP8IHRCEERpxIg89k3T3u6fcuI6fqVmw 107Dvr6+aE8etwfvPLYHsSA0hxTN/xTNf5cuQkoDmM5K7Az4SXhs9KyR6mbx+VU+yHda+K7V8rvN NTDSQWMFVoq2LgZAU9XUGIR/ShDgR0luwSQaaawMJMAfhJf8DJB8HHmMkSXr0EANWsOo0d6auesv s7dZwzeTauAwh4x9ZZtJNecxP+JCZPxqVj6JACiDSRcKIXChnFLoXFJBRbclVUqV2fT4AlCDMMV2 WKKvF9c9cmubCrgUFp+ZT2GPLkYEXS3ie9liOexl3yFfPumcV4zlE0UOM7QVYEYjDHuqwBR7qsDy pwgUpY3Af1ZLQqXYFfPyXf4UgSWyNC69Nf4uBC8Dn7YKeZsxq+GRGuwJKD52t6Sf3So5PYimlp4e wu1uLjtl5O2SRdtsOnBps0W5UwTY8wTYowRYw4YZ8TOr4H7UVa1+/teWzfq8v2gWiAXEfx79ELgV ChWe6sl6YB1V3pZtTYUaukM5Y5n8y09dSfAnEYDUkN+cCv0De2jujZzESl6D5mcNeWURvMw5D41I W9VZndjL1kxhTqir6qhO7Cv5EriJQGelyNzD3Q3rOyNUaKAn7Vn3uW77vFdxJxZ5laXv4EeBx8Vx 4Hv3r+k3hdsqajorNcDd5IpeF0gwihxnlJwE4RPvgBdLaYWzYOCYmk1KUUU/zB72UXbOB/rhM7wr ZqvYklC20ujpLkIP84iSLy7uxufRvgWHTN/MIZdA/EbvTRzyAqAAQJuhP4ZzaK8BhOA+jO8xlmQA rVCjARXqk6M+GeoToT4SrWR329r4kQEbD5iNd1s2vgdu4wGzwYBvC0tQiRbO8mkhXFrYZdfCST8t xEz7LCaB+/afUSK900BMRnhSvDILqA/Gd0PhbBoPWXFIjdtozP53s40g+GuNe//hzqm/v6Musff7 e8Fr/dPm1p39IPQ7zcmd/ZmdnQ7093ecO9bTfu/sneA1C15nug9vTcTHDvdmD29JxEcPw6nGwnH8 lwAbONV4P5xqdNZJeC2R8FoiKXofCb96CRu2aW6gkR1tZE8v4GYbl51o7Kb6V5xoXG6gcRkdWXmg 8eujFZ1tjKdMWbS0WU0Gcr0DIdidfZqOsQONKX/ngY7W9fUm9A+fe+5ImnLF3YXWoi8k/lBMbO6p bA3QuaM/uKvr0ESzBmQ2hW8ODTdPzPDeEvsuO2E7Pjtdi/qUPETzhwrxUCl5DJUQKnXZFnyIGWIC CHoZcTDrU9KObjqH8M6LDV/BUi5TPhywnNmwkAix72JCsUikt3poY6S20b3YaLxtjQmr3Omxyggc xbfqbCqxWCzSVufqr/1wqdkcqev0K3GRRCJWsP2tget57CWw4m7kJUYW7kn29Pfc1/ODHkHZMRd/ 4Y+3YC2mDY55ahYdf8Eee4G+wti5sy7YUy6gc+GPuoDjE9CCzM+if2GPmpHAIC9j2MAPvvSB35eU /UCGyapfrZe8o1ql2qyaVuHckRa/gedZZHVvcapVOsyCP8piBB5OUHaUxXwu9EmPssBeio0e7ous 64roJAQ8qiKYXNtQ2Rk1+5lVawYYf2Dw4KAn0xigARXFSYlQ7KrrDlcyAbqCGVwzxPhRRdcuIG+9 Ueuxa0wUaXaY1e46ry9eYXcFW9c2127prpKpaUqm1FFwM7DOqNO4IxZ/bYXDVdm8mpeFYLdgCvk6 8vXnkQb0FUDfNwHE2pBp9PVZT0Bz8AFYRmlUGpW72ybbNEqlpm2S6D2E9B7M2PN3pRo27Uz1vDO4 anDz4PQgXj1YPbgu9oJvZ3bdW6neB5R5Y+ZBwPfZ6dl8csFAGwVJYoItugCKz7FDNdfqp16D28L4 cXfhyqNr2GI46RvCXzakuEJRQLAbI0iZvYIl8raDSjU8ReOAsbo9UNERMbmtIhxuRXLVZstlcGMJ hlbd3moMqnX6yKYjqwdnVle+Ac/kKNYOtKRQJCQ2qnQqqVRZpPvlo201qQCTtThsywiv8caib9zS 5RMKDRlf+9TAgnm6Uo0BYXf4vIftJv4BaUQ2zQYQlTvEW1yIt8QQb4khPoaFeJ8UYss7enko785Y 5Xl9pgaKmeTEfBE6nRg/13bxQrTs4IAlVZsVJIHtFlGOQLU+NcFY7+Xk8Pli0vkmLDYCBOvTeo9F KxKIBcTG8nIJh9/KtRV+3cTHgruRCWT9mcG2tuhEDC7I2GfxRZGoCzzkw30TmdFRYczXlx/O1MOi lSTTW5WzZHR5YZoPOLBcBYtVYLUX+Or5RX5uAbY8FhameIq9QtnwxtOaRajwRndmd7erA45gsbWp YAQObClf4ApSLxbddCFYBs7KSOLPzE9osYUptXSFea7yypRTtSLU169DZPH3BGHMh34PHkWMebFv ITzi+CtA09qQllPhNgpyjqDNFlRC7yLDa4NtGSqYb6rNaOGopLdXzI1KXgQ+Aw2zDUBY2GAbSeUn Vd06ct+z6Yqzx4XwLaJjNl39xifGgNeufyL+BbjSzWCtCvjv0QX7htkOqLxdbgEPpDa4GunLtGWa mhyZSAbLDCuC+dqMGv5zQN7eTWXGBHXswgisiIJADguhpQlgFo55y1oExVK/WYRi/pAA1XKmR/yT SMXVMpO2QlsZUhhOKm0Vy2OFPl8sorLTwWrFm3XpUm10o9VJKSQ8XGUoqrQquVy+Eo4oWjyOp3B9 iQmzGJObgQV/Fbn/1NZ9HRDj0UN+WDxrv6udMkGwfb7DvoH2Wp9O56ttHxAgt40evOPgHbdJ8l9M H8rsy3T4TaP52+CeB+LUMMgxUeJMc29prpJDPsrVhADm0Ma5KMXBXyaDm85bLq+lt6y7ZQIrNQ7I zYRALCRpK5zYtCtLE5tqJ9coqCrDn1Q5/cvIU0Q5bypN9BKc+fS2ueQ3n/lcwT5u0WzKxc16JYUC TkNxHkU4xHqUWc6jCLCiRxG2ASvbiew8ZW/tZx3JzuhOxc6RkZ0K3NwHu0DtNbC6ccprHoIeXD/R m8m1ZmoywaCjIdKANfQj5rw3Q0Bzo/kUhTe2JBfDoOdhpc6KO8w2ID650G7BZaGT5ZJR2VfwSfOS wTqserZlBI/4CJdJe9568eoVGgo3wn5ln1fekUCR43CGHn8OiSJfZ+zJOCr1wwzcDzNwvwhWXdi6 jJ9iCzDolbMcU7HzeYWdzyvA64cst4EXMLGwF8mOnc/x7ey8lSbU7ZcKjN0eQPjmB+m5gxv49PtS WUFmySD9oh3TdfXzI/VPkGorrbf+f/a+PDqO4l63qnv2fdNsGo16NNLMSCPNaN+8yXiRjbwIg7Gx YomxNLYVa7M0kjFEJGQBHMyLSVgSJ7kJL9zcm3uSBwYMhkBinWtQEuwcICaQBRIHcpMQTEIWTAKo 31fVo9HIlonvee+8P96Jy/qmurq66vt+9avq6p7uGrtm/d38RgBbG4UZ2JNcU730hlVaVzH7zkef uz+wb/OGxbsO7BBKZq9u3v/Lxp4VZVs3C+OzKcw7S+S/izfAPpXk1cdIWMa1LbvtVcxXDisrpkEl EqTurM6C7Kdr7mYY/3RkP+1s0eQmRJrsNGKnURuNqWlJDAlLSmhpCQ2x6LIQLQ1RiadKtFSiUSud CNEQe4Bcby9YE5Jw1YOt37bpMZkLsaf32RZriRAr34QDQ7G1IaN/rXHd7Guy3Kokvp3fR4gr/ym7 m6DYna1dFufrXeeW3sz7imH2feCgIN5ABVGYOcVfjg7GfBbVzA9VarZIpKco7NSrZlTiu4LBGSr0 BO1a8SsqvcGkfe8b7GVolc5iELeYHHoRbioA9O/7TSbhv9jbv4LOyKzdIP9d/UlYexV55THSjsu7 JZDWzL4cK2+mTeyzLEEjIRqRaKSYRoI0UkSjARpT0XKRti6ii1rpoiq6uJLapAK63pa9fc4+2wxw V5uEEmzWbDL7bDOxC3GWbF2+ludjxlxm22gbtn3UprK1OdxrbHVry9a2HqqklWxfJbvqtDnda3ZV 7qsUViHVs47Pcl5gltx+YtmyU7CkYu+kcj1J+D2b3N0bxdCanJ1nX8FWXklfwOR5UfUnVeqZc6LZ EwsWV/hM4pOCcL9o9pcHi6PYmvkbxg3MjgIlmPb8RBCmBb0Dbl/s0AkvCvTHgt4Z8nuLWLNoXda5 RhFu1+vfH5trIqtLqzeihbRmtJBejxYy48KVLX7rnd0SdHzNm3L0jg60V5Lc1GaXatiKenR9gg0W ixLUC1d8hL1S7KWe7LDgnk1yUz1z1Ap2A5sds5jQ5jBtNFKjxO4zsgYxGmuqy9eGjfaitfbcvcSW ZXYHVd4KIcymzG8V191e5nbNvtO+4Bvtee+zr9A5o8XBcIFR9dKLKmNBSaCozE711DtzTkedUako 7DKoTj2rMtiLC4vKHIJ+5m+VFqdJLbKXwtMzX2RLQKhNTgt9lP6bxWlWiRqDduYI3ahhy8gaXdaZ bj5yzNwpfgS2KSWbHiOFENvAen0hLS+kXn4b3UsjlkaLENVTP7ud0eqnvmZmOR8tXuszONcaOlQb SUf29jVbZzCudFjWcUOiorXJGWFL3NTnVmZw8ktkt0sr1F2nqan1S3ZB8xG9TZz5rs5WGgyWuPRq SsV3NPYSKVBq18wctdnVJpeFtqgcBvFDBV6LWtRZze8nhB87jWp2voCSawgRXhQfJXGy6DFigxI3 W4U1wtdiTWJ/vX6lXtCX2Y9R4SHfGmuU38bsyL32vv0Uxpzszd5/8M47rhhf1Ogsuvd/XFDIfJHe PvNRm1OlN+sFldFu0rK0mXH6dVx8a1az19wDoRKL2+2zCR8OlbEFOTQWt12yeD1+2/t3a238fZWV wlNCm7qQVOHquONBbUEr+zF7wp5oOEavaSuylt0lSYUFd0gJWp1oSwiJhKHwrtjeps8ZMuJY9j0v vgS1na90M/fVLFW+HrvIK+lztyjy30gX2gqDIX/Z9tbKjsbiWMfAiqvMxXWRssVVQZ3ZYVnUt2Tl 9hb/zZtiiyKO2srKZaXCqyaT0VxdVu6uXFaRWFXlDhdWBMyOAns44HQFvUWN65MfM7kldzRaGmVa B6D1yxoniZAmUv+gobj623QLu7VNP91mJ85ig6XygZK9vkHLWN0RdWb2dmtLS3YBn5Z579icf8ZV XEybvVNfoNxjFb7M3gUM1CaqvIUlNrdFrbH5XS6/TV17TV3btmb//zAX15aWrU7G2svDtcU28dzq vZ1xgzvsXWwys++jxYCaLQ0DmPl+VVmy88Mry1Y2SOWNTyaqiutXsJUWoMir9pFqEnvQS8qOQYnV UHBPUcnnrXvFL1TGvqTNsJfI+Ers2eUN+cKNuQbIu1mnUVqB6xC8gkpbsm3RzZ+Od+xe6orHIh6j RmQ9WWuILQu1r+u4PL48YtRqcb1Ub3aYDd7Q3bdvHOso1RjtdoPFYTG6HAZVyHNt6tquorDe7oX1 14Dr9Ro7enwDqX1Q72v4Nt2KKW4VPdBmsxcP+vRi7AH33tovmvI8q0VZFSbnUJf61iB86XpfyO62 apKpxZd1tfil5T3LajbFtFZuf82tsfZYKa4oTMHaSOnahPCaYu/lyZrkxv7Fq8c2xiMRmlDrVCIG ffXMlYmEVL8iXLq6IRRvYJ7UDi1D6DVlJEEuO5LA3PqWhwvt9sLIMbqlzUMKnXdaLPrEHRJ7rc9b /llpr/4ub2Z2ncS9uZ/VcOSvPph7g89dMK+J5t7fE4b8zpk7HOWX1USW1YYMBp2lJF7TJN11V/Ty PStXYy58i2rVynB9qVNQEb8vuqTCbbSanP6Az2LSqz971+q9Gypiq7sb7as7PLH6IBuFS4Vn6OOa AGkkyYcdDmJxH6Nb2+wVkRLd3dVDJfe476kYDoxZhvm14lnlYaW3ak/MPZmcu9vjXujRusa5x5bo 44JKI2riHjaTHzdZzMZ9GkuhqwBtscGIXrzBU3N5raemQK8W1D+yOAyC2VRYUdTsDRR5Z5ahZVSs eeiUtyjgbWza1ODX6XVmF1vTtIKeE9LoAYvJOtJFDnyXXEFXkhhx0E0YkFfRKx+tiSOUFS5hP1at JetZly8kV9Gr22JlqjtbhmNX3NlW0FkgFKy5w5rQio0SW2Bfarujca+0hW65o02iElsiQWdcI02Q ZfHtZ/cqbYgLprM/3n62JbtEwOmfs7fMldfOz/DVVv7hwz6NFzzrgz/thc/6aDTZLSFt1nc4LKGl VzcUNzsM5oj0ucS6+kB47XDHmp3Lg5XRgBT2u30lS7fUBZIFjxiNT7Y2FZYXmlvrA/FCc6IheUvY 27Ey3hq2qn7mczvj3sSaWr/ZZPDYHF5BIxREmktiK+qL3JEGKbY8aE76w4s87pZ4ck1doUbt/Up1 k70o6qqutxWVznw4GBRUhVF3WLJ6Jba6pfCMcCNG1mqSPBJzMBsHiBGuZCUBe8xjORLfWzLoGVOP zT5+0jJ/UTRlKI188EMnwo04ZbmcGD2bmsNrytXKUKqZHVIT26pbr6h1C6/lvKV5TXuyauau2e38 wbQiVrr0yhbWk1PoAYL6Xf7ESfi7xE1/CuoEAtirEP6HfbYRzvqV2VXmnBfwa8p7EOSvaqu/YJZV gd+qNpdUJ0IlierQHC/Bq9FpBAHwaEUwWF5RzHsis2AKFqwni5YbSQ29ja3/CBpuEqZHcXY20GNs FUj25MZIYNA+a8usKZV1IPNOUOICdmyae1pD63S7hZTWEXC7A3a9+vnzjfmwyuDw8+8C9Zb7njHq 8qxaNfOjBSxa8hONQSMyUTqX44GZ3zusiibyZ2hSVtKkWx422AY5b76S5oWW/PP5NOaqnatKKVd8 HaPvatJ2pDHMfqE+sdjOziYBshrjr8tgObJ8r3SkZe/ixvLakfIxT561ss85JM+04P8Hut/526x9 lS/c3bnnhF8HUydjXN8grYhprH5nQaFVW9tQclnOP33hsKe2u2btZm9hXTLpbd1Q47q4j56/LXhN +HdZXaIpGYj4jKVLNjVnfeUG6K8kVUdK7XO9zUIClgeie0s90sisZOX5AtbXPljsnDjW025gDeCE ksbmcHtsVqMvHPLVXlu3aFPNvF62ljG+8wLGnKtAVuFMeS+4OnGuLHmCuOgBtpIjzvl6g+9u697w 55WZ1qUt4tgo3Fu+cXTNxpG1JdF14xsuH1pbdru1bEmiYknMxT43bBbPrRjZVBVdN9i+YviKyvKO wbWx9oZgoL69smJ1fVE3nwXSd4QvgxGbBTY9WFxtYAYs4LNAFylgU0BDdbJYpS4csY3nJoLs4cOz C0wEz+tmORteOBFc1r3EX1kR88z6hdritpX461KL5yaCa6piq2OldWwi2L53Y1zvLHLNvK9m6yBq cF48y7oBTFtTndy4h08E4/VPViXYRFDxCfocn8dHHirxEyubiJj8hhPRvSXWguBIwdjcN+VvnXC0 zL+fe6EnKAuR0+cwDVTrjNYCuxUnF3e+T3srImGnJeTWYo7zvN1r0ao1aqM3VjTz7/Ndob045tGp dBqLBywvE56iZ8FyGVnzGGmhVx2VKqVKk+8Y3dxWREwVd/yy5o81Qk3jZ30t6rK9hjuO25+1C3b3 Z9WZ/FUZty+0LGPe16GNuM5Qzf9aKju/haKzpcuuaZAWJYpNGlGtVRmKYo1lVUsrlq5dVi61XFEb rIv6jWrsUWvcpcni2nh82eXLKsR98cuqvEar1eQpMONS1+awlkQDIY8n1tYQXRx3601mA/bYTWqz zVzuD4a97rKlrFXC0Hu/+l5SSyofIuHiKGsVm9NqLB6O3uMz3uMcjn9Bq/j/Kf5g/om3nnohb45+ /jRq3lSLTdZZGr1fY3AHQ9Zrr9pgNBpN6zXZOe5t2DLeJlX4IxqVRi2INrfXqNOoPtRNI2waNanW qVUqwCSfZL1ZU2tVGR3ck54S2C+hJTC66MPKJL2IjS72sF4sH/GMSA/kpui5JXcWmKDn3Y10z7sZ KdzoCzs8ZnV1um7RFTVuDc7qLp9N09QSWlM+O/DkZuS1fCCh6zRKN9DMfK99bbKKDsxuMysXCycx B3SRKKl70BEqPkZvfdgZ0oVwZtjWZtRKoZDZP2IeIyPKgEh9Sb+Xzb2zKziyl7ZwSpy9yYTriPn3 mIRiV6FVJ6oeFw2ukkAgXGAQv61W620Blzvg0IifFcRbBZ2tUO1iP31kNc9YdOyZep1RR/9kspt0 sDyj3eN00nu1Oo0IvpXCSfE/wXcF2fyoFKpxJ5OuKpBuM4ZcjkUunXbJEtcydvVt17oaR5JLXGJh bKRwbFaBskxxbjFHvoDj7GqOym8LnK8oenFxeVHxRniNVlTdJ+qcIX9hqEAvDFEhLepdbMtlEP+n StTa/S5PwK4V9gvCBNXafAUFPotG/JggjFKdXbGB0WrJs0HaZJr54pxFLDZjziImE71XaUadZma7 MbsF+8RwftvMf3Vr8xOkhD5MvKQUo7M+4UUgHqPpGD34sNuYNBqO0Ucxx5TCxvKRsFFdNGLPnfa4 iZ7Ka+jc7Bz2cWdH72j2lxfqm5zRSNYunuw0SasVOtXUJvm9QadOuG5S1GO25Jdsmm99TUOtkt9X ZNeJmTFRZy0s8BdbBc1XhN/rTbggRpd65hkMIPyRKGqa0ZmRqNGqn/yOil1Pas36d5nP4rplJzSG yFI2N3rkIZ3O4DlGDxwNuSW923WM3tZmMrgDIwV664h+VJzInsznLz/Kx7/sra4mce5mXt7qlBvE eIWnyEpV63+upZag34v5nupO4WZBYy/yeoNWqhasZqNKZzYcEdxWl0klaE3GmXGB3q41wOmNThvh 4/Zz9C/8d/KqHyM2+tIjQRcCKTlGf9Jm1IfsX/ANW8OH1aMYpo/jf/5ijnTejS1nOHdjC2cZ5qR8 CPsLPEI782kr/MegPfuq0cKnFj02u8H6+t/4SsA6q8usdRd4DVarzUjX+Qst2HZ4fM6Aa+ZhNbsW FHA5+Ch/etxITMTF1m7f+7BGL7LVF145RZNncjellGe26RWzz2jP3K86lX0ke+YIK0cl0Q71p+bK 2cfL6btIOR2VLc0V8Zbm+MxRdVlTvLypGeWcIAI1yG/Tn6u7MbkoJxbsK1xvYy+Tvpz/srQYyT1P Pn/mQ5/Usp+oDDi0dqorCAcKwwU6i94XKy4u9+r13vLi4phPT8dnn8ITHzc5TGoNRpx3W0LxQqOx MB4KVfmMRl8Vf67+bXELmNSTNSTSZiktLda7HlKrq/UrW9l3T/RINV+P62X2G59n7blXj3M/7slZ Zh80Es5fVfKCl5S31G67cb02HC0IOnQain7jcC//UItfaktd1rqlrdygNepUGlfLFan6PYf7qmdO QE1QirGXgmNSEOrEX2y99dpG9VtWK7utTgs8RU5t+coP1bb0rIr4gl54rtvrcxb7HUt2H3xv0YVq z8pn6f2qHm536QniFvqIRAqElkeMtgq0Qj+BUNuJ82acUbH+Yi1xlxZ93F1o01C7xlkaKCxxavV6 d2lRIOLR6z2RQFGpW08b2GpfIkCQTTaDWm20mt6TiqJeo9EbLSqK+QwGXwzcrpfPioKqjzSTdWTt E6RFSOM0oKbPPmJfgRAPHBMcbU4Sj0SMoV/Xu7+GcurXG9cszXJmzWNj91pzM6DsiMYbK/viS/Qi jaVZsLGEqg172tQYywud7qBdo0HMY9O1bqpz++s7G+s3LY7oIEoliGpb3dot1V23dlXNvKt3lxUV RdywQqSoqMytF8va93YmNUd5V1XrdaddAZs23Lw2VnV5Q5G3yKvFad1oM+mtQb+j5urx99443zAY YypmXqFj5JekkBgeNHoCxHb6lPKGz6ywJmeuRcYwnbQfUJudPqfdY6CqTxm9pX5fqcf4meL6RJXv h2zs4r7j/FihxK4nJTY+fFs+R28X7+JPMxceIa5jwg2PGoJh3zq1FWPEqWWn+JfhF16E2M93iNtZ P5RirB/GpGLFc+dti5JUybyyUiqpYp9V78dCSgLc1G8y+auY4nvAZwiKjcRzhP2k1vFH2E9n6cV1 hFGJTynL9OcGmqHk0sUJ9jfYnkyswh+7/3W3fE71R/IKK4OEScV3iVf4CAkSk3ADcUDzRx7V4ERe aGVl1tWdqq3l177JM/OLVl8kTvuTi1sT7I/+Z4LFFi2qoidm0wZWJxMrF/hjbSmO0zH1dWhLPdqy HXrm++ilNKU6UlyXrPL+UGviX6/pqfOjfsmh0Tgk9rxEhfg8anhB0IhdZDva9lZxn5jgNTYR88Oa EnctaoVg1Dvv/brZs/sCqfx7oa8bPWGvt8Rt1Jg9tlvUJofPYXMbqHrGs8COAqNK1X5jlpU/WAfX O6UzKL+RMXP2IjuYJ8bFfcJzObbGqKcuxzZnJT4tmTWTekHjCc8xMreqzA4vIyN+0uAJ+zxht3Hm cN4O0FfxPYy9OloMNt5T7Oc72JfM1A6rotvbJf/FdsDat4qnYV1m7W6yHdtx8TT4s+0eWJ/iPHdW JQg3EiuxP0i0xsdogKgI/0Gg7M1txaPYV1gqwel8b5nT4XCKU3orrmsbI+FwpCyst7PnYOS3hWtQ 0usoOUMG+C/a36sEmrzE8KWLB0EtfHM2iOt4uOdSg2ql6hf/OKi35gdNRV64QwnawEXCtz4o6JwX DZ/Q/W4u6OPZ8MkFwnOGNbnwdR6ePy+8PBuMVyDcnBfeM+3OC48sHMzKv1uUYDHnhQ3Z8C8Lhj9a J3Lhr7b2XPiqEuwbLxp+68jMBecaV7zAgHCvEtyXLRCe8nze+6Bvm99T6C/81oUhcPPFQtFVwR3B 15VQfFTqVUKoMxd+ORtK+nh4+YNCeB8Pj8+F0i+WVc4Ljy8cIlfw8AMlRA/NhdhnlFBuzIZj5SfO DxWtFW/Ez8TPnh8qv1m1eMHw58QzsyF5TfI7s6G6aF74XPV7NZtqjtUGaifr2uq+XHem7kx9R/2+ +nMN6xvubqQIVzWebIo0fbTpxeZdzT9pqW75xP/z8G8tz/wz/DP8n4dWGw+3ZMMLrS8s2oHwOYSf LXp/8RqE/Qg3LX5pSfWS5iVtlxTSSwb/Gf5/DPw5XmJ8m1D6noYQnfq3mBxF5beAffK1wN3yL4EZ +QGiooflk8Dj8k+B0/KLRCWul58AbsbcSiVuJSZgl/wgsFvuAPYg7iUq+VfAPvl3wIz8J+IVN8vf B26VnwV24TrBi/x/APYgHkH+24FR+U1gt/wqiVAB+SPUJr8G9MtvAIMoM0Inecoh+WUSQZn1wK3y MiArM8JLi6Let4EZ+RyJgvmrwCn5deDTYBKFil+RSl77FtTbD+xDzi2o8TTQJr8A9MuvAIPQu4XG oHELjXNMcGzm2M6xg+Mkz3kIdttCD/OUaYZgKAC3zrwL7CLVwG5iBvYg3o3a3wL2gVU32CIOtr8D ToFbN3j+hnTDttgLtm8AexDvw1HXAqPyU8BuKO1DCJA+8Ec6+G8E+uVBYFC+HNgJjX10XL4JOMFx kqcf4PGDHA/Ju4BHefy4fB9wSv4P4NPy14HT8teAJ+VR0gdFCeAW+XrgVrkByHT1QZcbyHTtBsMf kd3I+Rpwq/xzkkHK14BRtEKGc86A7WNAG7wlA7bHgEH5KLBT/gFwXD4BnOA4CSYZsGXxgxwPyY8C j/L4cbRUBgyfIRnUGANulWuBXcQC7CEWKtCY/BdgnGOCYzPHdo4dHA/LZ4EoDTgl/wn4NE+Zln9K Bdj/Z9SKcv4AjHNMcGzm2M6xg+MhXHtYUdo54HEen+L4tPwicJrHT8qvUSvKfJ3aYIc/ACeBQZT/ JjDOMcGxmWM7xw6Oh+W/AlnJQV5yECWfAU7LfwaelN+gQZT8Jo2h5JeANvlHQL/8DDAonwLGkCeG WhgmODZzbOfYwbFTPgGclF8AHpJ/DTxOzMApogFOEwOQ1RWDzT8O3CpfB+wig8Bu4gP2IB7nHOKc Q5xziHMOcc4hzjnEOYc45xDnHOKcQ5xziHMOcc4hzjnEOYc45xDnHOKcQ5xziHMOcc4hzjl0gsNP gTa0cic4nAUGYe1O2kmcwEm0dSeseoZ2YkzzALvIlUD0U2AP4tu4/2zj/rON+8827j/buP9s4/6z jfvPNu4/27j/bOP+s437zzbuP9tRshvYAxwAq5eBNvlZoF/+HjAofwc4KX8beAjHDqDMt4FH5f+i 45zDOOcwzjmMcw7jnMM45zDOOYxzDuOcwzjnMM45jHMOE7ycCV7OBC9ngpczwcuZ4OVM8HImeDkT vJwJXs4EL2eClzOJveeAU/I7wKfRypPY+1fgSbTUJFrkZ/QA7y8HeH85wPvLAd5fDvD+coD3lwO8 vxzg/eUA9+oD3KsP8P5ygPeXA7y/HOD95SDs9mOgTf4V0I/0g7Dbr4GdPD4p/wKIswPwONr3ILzF CGTechCsOoEYH4BdpAvYTQLAHsQPge1ZYJxjgmMzx3aOHRwPy78DHoe3HOI8D4Hn68Bp6D0Enm/S Q+D5a3oYPH8DtHH046jD4Pk6cBIeexjlvEoPg0M7sBsMD4NDOz2Oo34FZEcdZ2c9YJBjDHmO4xzE MMGxmWM7xw6OzALHUf5Z4CHY8zjORAbgcWICTnGc5ngSHnUc1kgBt8pbgV1kMbCbYMwCk8V0Ckx+ B7Sh9ikweRMY5BhD75sCE4YJjs0c2zl2cOzkORmTKTBh8cOYPUxxJlNgogNO8/hJ+MAUb5cpMIE/ cSZTnMkUZ/I0mPwMaJOfB/rl08Cg/APgpPx94CF47NMoXwM8CrZPo4Q6YA9wGseeAdqgdxrH/hYY hG2nocIAjHNMcGzm2M6xg2MnP2qSH8X64zS35zRXMc1VTHO/muYqpqFiCLhV3g/sIkuBTMU0mCyl J8HkFSAbCU+CyfPAIMcYvOgkvI5hgmMzx3aOHRw7Uf5JMGHHHoIXnYRSln4ctj3J5jbAaRZHvQFg DwmI6xEPA3uAmzGbswP75BuAGfnD4mZ44AviZswucNZkMzdgD49n5B9gVqciJmBU/imwT94F3C2/ CczII+JWcH4JGOeY4NjMsZ1jB8dO4gYelk8Dj8sPAafkJ4DTPH6SGMStqP3DwG55CbAH8S6imnkH GEWeLsxqrGIX7LYHaJMHgH55GBjk2CmPAbcTHXBc/hFwguMkz3mAxw9yPCR/AniUx4/LvwZOcXxa fg44DTt0oQV/I3ahBVuBW8GHzc2uAkblnwP7SBcwA87d4PNDoE2+F+iXvwYMyt8Adsr/CzgpPw48 hJK7UdplwK3ycrQB09XDdfVwXT1cVw/X1cN19XBdPVxXD9fVw3X1cF09XFcP19XDdfVwXT1cVw/X 1cN19XBdPVxXD9fVw3X1MF38/mWVUELYnXr2r4+jyK8ILHyLxQViEVXZuEiqRUc2rsrLo8bc/bJs XJOXriV/F7dl4zpSIT6bjeuJpLoqGzcIX83lN5KrVZls3EQqVD/Ixs3C51V/ycYtZEB7kF2z8H+1 2neycUq0uopsXCBa/fXZOK4u9Ddl46q8PGpi0n8hG9fkpWvJpP5fs3EdKdD/MhvXE5uhJBs30M5c fiOJG2qzcRMpMGzPxs10nWE0G7eQRuN3wISq9Fk7K3HFzkpcsbMSV+ysxFV5eRQ7K3FNXrpiZyWu 2FmJK3ZW4oqdlbhiZyWu2FmJK3ZW4oqdv0EkUot5fDVpRGw96Se9ZJQMkzH87UQvkMgKxEbJCMcU UvoRGyIJ7FlOBhAksglpu3AlkMFRbCuNzzRyTwD7kHMFjhtAnh1I60eOfp4vhb9BlNXH8w5hawxp Q3yfcnw/GEj4SyFfP0rYj619iGVQF8szjhLZffo0thjncRzdh/1DYMNKGc6WmkGOwWydLIcEjcO8 TlbLGNeylmvdiRSmcRzpaX7EKE8Z4KwzWR292FPJSx7kKQO8xBRspKTP1jKIcga4xUayLIeQMshr VcpkOjN5DFiNI1yLYu9ZayvcWU3DsIAE/YrFGatB5E2h/gzfYoozufZQbKbUInHuQ1ldw9y2O3jO Ocb5ijL8V2Qy2Zr7yR5sJ7g/5LdmlJc2yEvYz+0wnm35fHuzFlP0pzl/pl9pl1HuDexTqZG1tYQy RnJqFI67snnGsHV9tvQMVCgtNJFrpRT3kRRSB+fpmvXmXjBJ8fp7s/UnuMfu4m3F9lzYB1ovUN2a 6zUN5OqsF/Vn/a0BJbI9C3t9Ouu/ippUlv8uvlfhk85ajHHs457LWO3hbTZ7zMJ7d/63evCctyht sxlb/ZwDq/9K7u2Zee2YzDIYzlPQm+13Ga4yzX15HVJ6SYy3cTny9PHy2zkr5dgMwgismETYx0OC 9/H5zBO89EHkycC3GP9dXMEIStiPVNaCO7kW1nPmlzqbzkYPpQX25Mq7hnNWvHY/97YxzjDD+9UY HweUoyWugfXJNPeofl6HYqEd/NhZ662C/dZhRFSOHc3bo/TnPm6TuT66j9fVy/vwQvUq2yxvL7xo nNuwL+fzfXz/CPfY/Xl+PsKVDmU9XSkrzZH13PN1s/3KCBHDUeXcOwehK53rsxeyGrqg5Eu30Vzp s6O0lB1nFe/pnTfeXah9zl/n81qUZwGmRNGijPqzXj+aO4P08TF0iI+lqYsqVeycmmfTdNb7z+8D zKrM88b5kX18PGJq0rlyWM4BPqZ9UAv93+oXc30iydmwPqCciRK8rUbIdd+QaqurG6X1/b2jw2PD OzPSiuHRkeHRVKZ/eCghLR8YkDb179qdGZM2pcfSoxPpvsSK1ED/jtF+qX9MSkmDw33p0SFpLDU0 JmF//05pZ2qwf2C/tK8/s1saG9+RGUhLo8PjQ339Q7vGpGFkzaQHceRQn9Q7PDqUHh1LSGsz0s50 KjM+mh6TRtOpAak/gzp6xyqlscEUGPSmRhBnhwyOD2T6R1Dk0PhgehQ5x9IZXsCYNDI6DN6MNkof GBjeJ+0Gcal/cCTVm5H6h6QM0wFmOEQa6B9CXcM7pR39u3jBSkWZ9HUZHNy/J52QsjKjY9Jgami/ 1DsO8QrvzG7Un94njaagZbQfsnFgalAaH2HVoMRdSBnrvx7ZM8MQNMEkpaR9qdFBpS5m5t7dqVEQ S48mNqV3jQ+kRnMt0DpbdStrmoarYSKIkhoS1dV5pk/DvqgmhfJ39TMeaRAbTfWlB1Oje6Rhtidv c+fCDczNAjWbh/ozOP7KTCqjaEyigGFeQS/aLjPanx5LrBvvjaXGyqW+tNQ+Ooy9mcxIazK5b9++ xOBs4Yne4cFkZv/I8K7R1Mju/cnezM7hocxYNiuL70xBwB6W75rhcZh2vzQ+lgYJSGK7pRRaMj06 2J9hhHbs5/RWbV63HHtH+QbauW9cadF9u/t7d+cdi8/+od6B8T5mi2Gpr39sZAAVMJuPjPYjQy9y pYcyCWm27uEhOESsv1xKD+5gB80VNTSbeUFGPDtzaZh/DObpVfwuVzu3a7asRZxArB+1wPWZ6UdZ B+kb3jc0MJzKrxScUwpTGD7XAsPjmZHxDMw+0d+bZnl2pwdGzhN0KW3BWyLZl96ZQidKpMZGrstd DxLZS24mC/2jyIErCuIkWlkmVvZUKr+KIjSGz9PKd0of8E8ljptMFHnoe5ea32xm+YVnLzW/1cry i/ddan6bjeVXXXep+e12ll+97lLzO53IrxLZ1a2OqHh+dlWd5OglZhIhfsyWo7hCqEfqcrKSbMCs oYtswajdzc9yH0fsMxilv0QFcoRayRPURr5P/eQ0DZIzsPwbtJP8jW6jGrqdOukAlegwraLjtJVO 0FV0knbSA7SLHqS76SE6Rg/TG+lR+ml6nN5Fp+hX6dP0CJ2mT9CT9Pvi5fS0uJ6eETfTN8Ut9G1x q0DFawSt2CWYxW6hQOwRisSMUIb2iM/XJCQvQVMvNI1A0yQ0fRqa7oGm+6DpMWg6AU3PQ9PL0PR7 aHobrFXQZIemYmiqhKZWaFoDTVdCUzc09UPTBDTdBE0HoekL0HQfNN0PTceh6RloegmaXoWmt6BJ FrdAy1bBAU1eaApCUwSaEtDUCA2L52tS7cnT5IGmMvYuBzQtR+pGaNoOTRlo+jg0HYKmf4GmbyLl cWh6DppehqY3oOkdGqRaGqPsm4YSaKqBpjZo2gBN26FpACo+Ck23QdM9UPJ1aHoQmr4DTSeh5CVo eg2aztFpQaQnwf9ycF8vVImbhcXQtAqaroCmrdDUA027oWkvNF0PTR+br0nz+zxNPmiKQVMTNK1m 7zVAUx80TULTQWj6Irb+A5oeg6bvQdMZaDoLTe9TP9VDkw+ayqCpAZpWQslVULIDmkah6ePQdBc0 3QtN34KmJ6Dpe9B0GprY3W12P/jv9GnBDE0+aIpBUz00rYSmq6BpOzT1Q9MINO2Hpo9D023QdCc0 HZ6vSf+pPE3sDbo4NC2CpquRuheaboKmL0HTo/+bt7OBi7JMF/7zMDDfKFlbdk5b1O7ZxNqNWitW ydCsNbI0K8u2D8pCU3N5zYzKjwHRJnNdEDIV5EMQBcwUJLFNxEBgBBEVAUnku5nBicdtOWJlPud/ PwNKHrffad/zvnP3h5H5vO/nuv7XdYvzxJwqmFMDc3KK3z4yfikPlUfKAfIY5jSROU1nTpHM6S3m 9B5zWsectjCnIubkYE6nmNNp5nROXuVjlON9fiFv8LlFLvS5Uy7xGSvv93mEOUUwp9eZ02LmtJI5 JTOnbcypkDl9wZwczOkoc/qSOXUyp6+Z0z9+PCdr9KA5/ZI5jWZOjzCnWfx0OXNay5wKmFMtc2pj Tt9Is2QdcwpkTveJ30Myp+eZ0xzmtJg5fcCcNjKn7fy0hDkdZU6dzOmsvJBjsNjn3+X3fYKY02jm NJE5TWNOkcxpAXP6gDltYk47mNMh5vQlc/qaOZFPOpPuGd11uum6G3V/0t2qe0F3p+5F3RjdAt2D OHiSqA9GA/8FBIwYMWFRbKxRLxuNZ+xxXOxnjL6yUX/GZuM/m027JWSCzZYSNyFE+wP3OS/uaJRl o6+t/2I0ykZzaelmLuvXa3crK8vKSkpatcroJ57NbreLp9OeOiLeFhYYEB9h9JOM+nOB3svAU4tL tNEiGS1xgXGB4WHhYY8zAm2BNr2frDecMUbb7dHiOQ28Qbt4Wr2vrPeLEm8iSvu5UdyFO2n3j7Kf s9mijb6S0Tc47EyYuHAnvT46Pj7CFsVcvc+0o1I8xDsjqX9G4q3abPHpJenp8T+aq94o682fOt7n or2G98H9L8dFvA3eqd07Z71O1vu2eh/IO9VH2UqCA1oNvpLB1/uGgrVHinuvm6X3k/R+dvuUKYGB epOkN9ltdttT5P8tDO9t3DLFbrx0t7Aw8QJ+rVyxtQ56m5J3Aq0BARFhYVKYzkeSddxFL8t6nU2U QJvMRWdDgLJxDTcbxc06HuM3JT1dx4L5TZmSLuslX/35/+VQMclGy37bftsmRhJDTPK/hYzhXwgZ 60+EjMlPNnGgB8WM3hsz2g3Gi0EjboiIPyNu8JVMBM2Vombgya4QNiZf2UTY9MeNSZZNFyf+cwNH xPWOkssCRwvlsCtHjv4nIkd/KXL0V4icwW9U8k4iIv5/EjsmETum/tgx9ceO6VLsmEySyWSUrmGI tzJOWqotlMkgm0zn4mLFJe6ctp4kqu3cxdtCx9tsq2Njx4dqfxJ3uyC+/HhBTWbZZC3hkhGWEbZG G6sYJqNsMu/PyEh4//3ly5eZ9LLJeI4Y8T65eKkou5CF0R5lMkgmw4WA/svFl+IyIcRkkU3+IqJW 9sfUnTYRUwY/2cATEC/rZpn1stnIkxaV8fRlReImvXhumz1Ku8nX13fBKm5atcCglw3GaNLBZltk 9pXMfhcDK4x7GgyLxOG3cYfoHz1nXJx3wv3BZTP7yWYReHYRXvF2syybL62GzWCSDdYCqVrLKO/Q Xrf/qQbeQ5z3Vfp/XlYkHukrG/pjTbsuciMiIKBV5IDfwDsN1p5AezwTEssgAolIMpglg2VC2ISw kTYxrpKukrw3c+OUKXbzoLsSbNrznwkQYXfGLPuY/S6GnXd6rK0xODBQCgz09ZF8iPUwG3FmYJ4i 8mw+suzDdR8DD12zxteHFRB38eWh+onx8fG+fhJXJk6Mlw2Sn+GCmW0R8XcpApcSg9pSGmWz+Xxs jHaJPa+99MUQ9N46dhzX/hoTM26s9kdxR1W7+2XrbrbIZv+SiJKIdC4JgQlEzMpAETnaw0QgeiNR O7QiEr2h2D9bsdIiFs0GyWy8GIsBF19SXMaHitcYEhc4YLhB8eg9qr6LOCgWvWwRsTM4IA39Aand 5nvliLT4ShYRkRdD0sBtS0Sc2DD+oh8/7eUxafGTLSImB4LSIsuWQYvzvxWVYirRWtqe+X8dlRbZ xzIQlWKa2gxFWP5P4tLEg8UciUzLQGRaDN7IFFdEZBolP6NqMUsWs1Uapo2bGWG2pbYwG/+FWYyy xXxuhTc4Y1ec0w7AefFuznuX3CRbLDdJEbYwifcn/VX7YZgtwnaTpN10afHVQQfi8gNj8ZctQ0uG lwxPH5E+In5i/ERRSZYblxtjjdqzlNjSGfEMuy2OEcuIsVkMssVrbm8Ua+8tOo7XDya84qItBsky KIwDLntDA5dx0lhJewOxvNyDAd4xQryT9ICwgDCttmtRzVG1GmSryRt/Qs1lReJWg+g0bLYJIdqt PlxGPyRufWh0fx8iIptb/SSrX8il0A7j/RsvxXbsosuePDbWm9wD0W2z6mWrcVB4x1ll2Tp4GW1G i2wcsqekPDBu0DDyMqaBp9T+EDLBW1csl27RolxrcPqj3Ka1PmQsSsAIwmlhYee8bzxEexbvEzJJ ejIjTzdhxIiAgB81PwPBrj2VVumJdsvguwfQO4kbzxm5FmY7Z5V9rPqL05H65xxlRxaXR7xR9jH6 2bxNwOCQt/aHvHUg5K0DIW8dFPJWi2S1DJGGsBsU407bnbaIkqWYU8jTapat1gtSKZ1hyaDLflup 7YKkHaUL4s8XvD/W7n2TLSosQiphVPTfO6IkquQmm3bjpadQBz9fidWH2f7oB0Nka0DrDa03nAmt vb1xbuPcyknV1WWrKlaVWkut2lO1lpwpqS1pZFQzyhlflJSW7C+xGmWr+Xx5aWlp+XnvU4m3GRpZ UtIafcMQvb462mqUrCZ1+KXLZW/t0uUl2/2SdahsvWq/fr++dMWMVTNWRVZHVt/TOOqZ0OjhwcOD te5kUblev6S8vGahv1H2N4vHnfyqVFy+OiluN4rX5hIZqt2u4zJmpnb7zDGiK+K9lZezgi+H+utl f31oRETEuYj+i1XcvrScy6KSJTxiyeUvUVrq7yP7+5aUSNLFd+1vkP1N4kp5deOZM43V1eX99xl0 MVll09CTrc7g8h8NrUu7+NTan0IjteuRodZBt311UjyHaNsaWweeUbR00WVila2rooWe9ZcmEqI9 Vf/TMm3RgIrtxgxJjHsYNzBMQ/hPHOAZw2eue2XdqB2hZ4ZHDI+gVTAZSyMjQ4eHRkaWWq/82OGM YEl7E+etw4cHR0SUnPf38fEfFFVS/9JEr9Lr9daQ4OBgKTjYTyf7+PEOS2z4yuQnFlISaynkxZ98 zDyHCDDu5++9nx/PYbwlsrq62s8g+RsjIyOr7bJo71Wb9jeWZmmeVCbpZrw9f650zcz5r86Rgue+ tGCeFMot8hNTxwfS9IjPv3rPDi6uyVwXf3vhva6TAiSfqZMfDZSGPzn1ETK9/+e+/d/9+r/rJcOM qDeipNvnvDp/nnSX9jVE+zpW+zpB+xqufZ1y8W9fZe37T3310f7VjPdPvBNJ/J9sxSeCzbzyCJ5J vFdfKVaSfIJ9pkhLfbJ8GqR03UbdRqlOknN2iPfpE+373ZWGIdgQbF5jTb80/LO9Q9xy+RhiH3bP xXGScXbY2aufu/q569aI8W+fXz4Mwf+ef2PlTWu84+a4S+OWVDFuHX7Fsfq2rIFxx8G7nhsY9571 jtGr/vsYkz0mOzTpvtmXxthfe4e45fIxtvx+z8AIe+yfjGfCDoYdHNcrxo9veeA3Vxpjsh9wPTjs wV3e8dD2S+OP28SYmHvFcebh7oER3vhI6sCYtNU7Hl14pfFY0WNFU8yPLxo0msTPLh9TfaeYp5in +orHPPk7MZ5aNDC8zzStaVrntLNPBz89++msp09Na3raJcblrzd9/JWGeA9TzNPt01O949nOS0O8 1nP3iK9TfQXPr3qxe2C8PHFG7sCINHrHzFMzT826BsYzFs3KntXK9exZ2a/5vDbptbXaaHzt7Gtn Z4+a/QLjldmxs4sgdnbx7PNzRosxO3ZO1JyVjG1zPp3z+Zyv5nw11zh3KuOVufPmrusfn73+69fX vF70+lfzghmj5z05b+G8pHn1/cM175s/S38ey5gUdWNUUtRZMebveuNlMRZICzYtqO4f9eJX2nzv 1f7U++bIN0cuqH4zaeEtC8MWvhwdGB34dvE7z8zf5b0333u993qnR9zvnfPvjn537rup75a92yPG otBFsdrYtahp8fDFt/B91+JRjHmLty7evrhuyTDGlCUbuF/okpIlJYtH8fUbcW1JyVLfpTcunbR0 oTbO2B7SRrRt0+LhfI22Vdq6bZXc48YYY8zvYkbFxDIqY75beob7Vnpvib3BVhk7PnbSsshl5+LW rJiy4tkVr6wc/ZcJCblrFgx8T3os6bF1Aevb1/cmX5scmPxCsi15ZXJS8qbkz5Nrks8kf5fimzIs JTDlnpSwlMdSnkvJTqlMObVxxMZ7Nk7cuGTjuo1HN3pSR6Y+k7omzZo2Nm1BWm7a52ntaefTx6ZH p3+WMSpjWoYtY0PGtoz6DNemYZue27R205nMYZmjMh/KnJI5P3NRZmpma9awrFeylmStyzqa1bn5 2s3Bm9/ZvGvz2eyw7Heyt2V3b5G23LPlyS2btrRu/c3WBVvzt7pyVkp/kYapf5euhmvgF3AtXAfi c2IjIAhGwm0wWrpOGgOPqG5pEjwKj8FkmAKPw1R4AqbBdBCfNHsVIkF83uw1mA1zYC68DvPgzxAF /wfmwxvqFu2TaW/CQngLouEddbb0LiyCxbAEEtQj0hpIhCT4ENZCNmyBrZADubCHavAZHOR6FVTD IaiBw1ALR+AoHIM6OA6N0KG+JXVCFzhZDxe4oRtOgwe+hh5Q4Az8Hb5RU6V/qAekXvhPOAt98K2a In0H38N5+EFNEZ/Dk5MhBVIhDdIhAzZBJmTBZsiGLbAVciAX8mAbfAzb4RPYATshHwpglyr+TXmT +JyfXAkOOAhVaoP41J/4zJ/4xJ/uWfUR8Zk/7d+Nv8j3+erfdcXSvVKj5Kt2S36gBwMYwQRmsIAV /GEIDFNdRJiLCHMRYS4izEWEuYgwFxHmIsJcRJiLCHMRWa1EViuR1UpktRJZrURWK5HVSmS1Elmt RFYrkdUqic/KvQgR8BK8DDNgqXpWskEMxEICUbgGEiEJPoS1kA1bYCvkQC4cVJ1EhZOocBIVTqLC SVQ4iQonUeEkKpxEhZOocBIVTqLCKTWr56RT0AKt0Abt0MFtndAF36hNREA7EdBOBLQTAe1EQLt0 jtu+VY8TBceJguNEwXGi4Lj2KQId+IIf6MEARjCBGSzgDwFqp3wVDIOr4Rr4BVwL18FwuB7+TW2X b1S/lG+CQLgZboFfwa/hP+A3cCuMUEvkIBgJt8Ht8Fv4HdwBwXAn3AW/h1FwN9wD90II/AFGwxgI hftgLNwPYTAOxsMDMAEehIfgjzARHoZweAQmwaPwGEyGp5jLNHganoHpsJj3vQSWgg1iIBaWQRws hxXwHtjhAx6zQXWRbS6yzUW2ucg2F9nmIttcZJuLbHORbS6yzUW2ucg2F9nmIttcZJuLbHORbS6y zUW2ucg2F9nmIttcZJuLbHORbS6yrVbez7H6AkqhDA5ABT+vBAcchCq1lizrkpaRYR4yzEOGecgw DxnmIcM8ZJiHDPOQYR4yzEOGeXBsLY6txbG1eNOJN11404U3XXjThTdd0ttqHe6swJ0VuLMCd1bg zgqyxUO2eMgWD9nikZap/ynFwXJYAe+BHd6HlfABrIIOtZfo7iW6e4nudqK7h+juIbp7iO4eoruH 6G4nuhuI7gaiu4HobiC6G7RPBQbBSPGpPrgdfgviE4J3QDDcCXfB72EU3A33wL0gPkP4BxgNYyAU 7oOxcD+EwTgYDw/ABHgQHgLxycOJ8DCEg/gM4iR4FB6DyeJzW5AMKZAKaZAOGbAJMiELNkM2bIGt kAO5kAfb4GPYDp/ADtgJ+VAAu8TnvcTnmNS/EwUeosBDFHiIAg9R4BGfqsW/nbi3UxonDWX3JT41 PQKCYCTcBqMlKxXZijd78GYP3uzBmz14swdv9uDNHrzZgzd78GYP3uyRXmFP9CpEQgJeWgOJkAQf wlrIVhtxYyNubMSNjbixkcp5HZXzOhzZhCObcGQTjmzCkU04sglHNuHIJhzZhCObcGQTjmzCkU1U S4VqqVAtFaqlQrVUqJYK1VKhWipUS4VqqVAtFaJGYfZ9umepQH+Spute4PuL0nQpRPu0uR/owQBG MIEZLGAFfxgCQ8mi0VSfMSA+n/4qRMIb5IL4pPqbsBDegmh4W20jP06QHyfIjxPkxwny4wT50U1+ dJMf3eRHN/lxmvw4TX6cJj9Okx+nyY/T5Mdp8uM0+XGa/Dgt7WGlP9NyoFe6QBVS1bOyBLJ6VnxG XnxCnuOriM+zi8+oa59oP619Pt4P9GAAI5jADBawgj8MgaFqBrW1h9raQ23tobb2UFt7qK09V44V NZHVSPxZsSI+o/8iRMBL8DLMgLdZiaVYwAYxEAvL1CxWJouVyWJlsliZLFYmi5XJYmWyWJksViZL ilfPE3eVxF0lcVdJ3FUSd5XEXaX0Ebetg2RIgY2QCmmQDhmwCTIhCzZDNo/bAlshB3Ihj59vg+3w CeyAnZAPBbALCuFT2A1FsEfN4YjlSH/j+uewF4phH5TAF1AKZXAAyqECKsEBB1UHeeEgLxzkhYO8 cJAXDvLCQV44yAsHeeEgLxzkhUOq5zEN0Mj1E3xvgi/hJDSz9qegBVqhDdqhQ23Bui1Yt4Wc8pBT HnLKQ055yCkPOeUhpzzklIec8pBTHnLKg6E7MHQnhu7E0J0YuhNDdxKdlRjaiaGdGNqJoZ0Y2knE HiZiDxOxh4nYw+IsDfQjDvoRB/2Ig37EQT/ioB9x0I846Ecc9CMO+hHHz+hHPOJcD/Qj7fQj7fQj 7fQj7fQj7fQj7fQj7fQj7fQj7dR7D/XeQ733UO891HuPHCFdLb8kTZVflq6XZ0g3y69IV8lzYDHP vQSWgg1iIBaWQRwshxXwHtjhA55LfJI4AdZAIiTBh7AWPlKbxRkoxPkntGwlU3Vz1X1SEBl4VjsH xasQCW+IMx6ofbilD7f04ZY+3NKHV9rxSjteaccr7XilnSN5niN5niN5nqPzHUfne47O9xyd7zk6 33N0vufI/MCR+YEj8wNH5geOzA/iPBfaJ0G/gFIogwNQrn4jznhBHWmnjrRTR9qpI7iSdbKyTlex TlbWyaxZR5wV43ps04xtmrFNM7ZpxjbN2KYZ2zRjm2Zs04xtmrFNM3N1kvWiP/CQ5R6y3EOWe8hy D1nuIcs9ZLmHLPeQ5aJ+dbFiPbI/jsrHUfk4Kh9H5eOofByVj6N24KgdOGoHjtqBo3bgpjTclIab 0nBTGm5Kw01puCkNN6XhpjTclIab0nBTD27qwU09uKkHN/Xgph52mR3sMjvYZXawy+xgl9nBLrOD XWYHu8wOdpkd7DI72GV2cLROcbROcbROcbROcbRO4aZi3FSMm4pxUzFuKsZNxXhmL57Zi2f24pm9 eGYvNfEaauI15H4xuV9M7heT+8XkfjG5X0zuF5P7xeR+MblfTO4Xk/vF5HwxOX6aHD9Njp8mx0+T 46fJ8dNExkEi4yCRcZAcryXHa8nxWnK8lhyvJcdryfFacryWHK8lx2vJ8Vqi6MAVd5nePcYBIukA kXSASDpAJB34mXuMRnK6kZxuJKcbyelGcrqRnG4kpxvJ6UZyupGcbvkZewwnXaCTLtBJF+ikC3TS BTrpAp10gU66QCddoJMu0EkX6KQLdNIFOukCnXSBTrpAJ12gky7QSRfopAt00gU66QKddIFOukAn XaCTLtBJF+ikC3TSBTrpAp10gU66QCddoJMu0EkX6KQLdNIFOukCnXSBTpzTgnNacE4LzmnBOS2y OI9AhPQr8ukp8umX5NOv8M5/yJFqK+65WX6T7wvhLYiGt+EdWAQ/d3/yPo/5QJzngO9/gdXwVxCf tE+ANZAISfAhrIWPYAM7+2RIgVRIg3TIgE2QCVmwGbJhC2yFHMiFPNgGH8N2+AR2wE7IhwLYBYW8 l09hNxTBHvgM/gafw14ohn1QoiZjrQyslYG1MrBWBtbKwFh5GCsPY+VhrDyMlcf+55R0kI73fszR jTm6MUc35ujGHN2YoxtzHMEcRzDHEcxxBHMcoRO+nk74egxyDIMcwyDHMMgxDHIMgxzDIMcwyDEM cgyDHMMgx3D3bNw9G3fPxhp1WKMOa9RhjTqsUYc16rBGHdaowxp1WKMOa9Th+dcxx0rMsRJzrMQc KzHHSjw/Hc9Px/PT8fx0PD+dndz1UhwshxXwHtjhfVgJH8AqSKALWAOJkAQfwlrIhi2wFXIgF/ZI 4VgnHOtUYZ0qrFOFdaqwThXWqcI6VVinCutUYZ0qrFOFdaqwThV2ycQumdglE7t0YJcO7NKBXTqw Swd26cAuHdilA7t0YJcO7NKBXd7HLoexy2Hschi7HMYuhzHLfMwyH7PMxyzzMct8MttNZrvJbDeZ 7Saz3WS2m8x2k9luMttNZrvJbDeZ7Saz3WS2m8x2k9luMttNZrvJbDeZ7Saz3WS2m8x2k9luMttN ZrvJbDeZ7Saz3WS2m8x2k9luMttNZrvJbDeZ7Saz3WS2m8x2k9nu/28ZUqLmE/VFRH0RUV9E1BcR 9UVE/U6ifidRv5Oo30nU79Q9JV1FZR6j+5P6OtV5jO5Fvi9in7BY3a0rlkbrOtSPdJ1SsK5Lukvn lG7TudUjum7JR7qPKu6mirup4m6quJsq7qaKu6nibqq4myrupoq7qeJuqngH+4Au9gFdRL+D6HcQ /Y7+vzXoJqK7iehuIrqbiO6m4pcQ1Q6i2kFUO4hqB1HtoPdvovdvovdvovdvoitQ6AoUugKFrkCh K1DoChS6AoWuQKErUOgKFHpsDz22h5rkocdU6DEVekyFHlOhg+mVq9khHYIaOKztlGrpItpZmR56 L6s44xH9l1U6oJ3Ryw/0YAAjmMAMFrCCPwyBoeoCZr2AWS/QzgH2KkSC6Nfeprd5h93Lu7AIFsMS WMpK2SAGYmGZmsAME5hhAjNMYIYJzDCBGSYwwwRmmMAME5hhGTMso7orVHeF6q5Q3RWqu0J1V6QO 9nmd0AU/Y1cszlpGta6jWtdRreuo1nVU6zqqdR3Vuo5qXUe1rqNa14lzm1Gtj1Otj1Otj1Otj1Ot j1Otj1Otj1Otj1Otj4uzn4lzn1GtG6jWDVTrBqp1A9W6gWrdQLVuoFo3UK0bxNnR5CAYCbfB7fBb +B3cAcFwJ9wFv4dRcDfcA/dCCPwBRsMYCIX7YCzcD2EwDsbDAzABHoSH4I8wER6GcHgEJsGj8BhM hqeYyzR4Gp6B6bCY970EloINYiAWlkEcLIcV8B7Y4QMeE0+1SoA1kAhJ8CGshY9gA6+VDCmQCmmQ DhmwCTIhCzZDNmyBrZADuZAH2+Bj2A6fwA7YCflQALvEmWegEhxwEKqI/qdUH3GOOd2zkr84G5s4 d5U4Exu7kSSqZql0F1UznEoYRCUMItKPEOlHiPQj/fndS373kt+95Hcv+d0rvU0uvaMeJfqPEv1H if6jRP9RqlYQVSuIqhVE1QqiagVRtYKoWkFUrSCqVhBVK4hKNJ5KNF46x/ULoEpBsgQyTJHGyI/D VHgCnoTXpMlyuXQTtntNN00KZRZGZmDUzZXsuqXSjboYKVC3TLpRWvQTf7PxNbX/a2r/19T+r6n9 X1PzPdR8DzXfQ833UPM91HwPNd9DzfdQ8z3UfA8138OuoYtdQxe7hi52DV3sGrrYNQgbelgtD6vl YbU6Wa0eVquH1ephtXpYrZ4r7uOIFep2K3W7lbrdSt1upW63UrfbqNtt1O026nYbdbuN1dKxWjrq dht1u4263UbdbqNut1G326jbbdTtNup2G3W7jbrdRt1uo2634Yo+XNGHK/pwRR+u6MMVfbiiD1f0 4Yo+XNGHK/qo1Z1X/PvYb5nbd/A9nIcftB34SfL/JPl/kvw/Sf6fJP9Pkv8nyf+T5P9J8v8kuVRP LtWTS/XkUj25VE8u1ZNL9eRSPblUTy7Vk0v15FI9te8ral8Lta+F2tdC7Wuh9rVQ+1qofS3UvhZq Xwu1r0X3jGSWHtLOkugHejCAEUxgBgtYwR+GwFB2zaOZ6RgQ51V8FSLhDRBnWHwTFsJbEA1vq//g 6Hk4eh6Onoej5+Hoid3sBax+AatfwOoXsPoFrH4Bq1/A6hew+gWsfoGuqZGuqZGuqZHVrWV1G1nd Rla3kdVtZHUbqWlNrPBnrPBnrPBnrPBnrPBn4lyP4kyPrITCSiishMJKKOK8j6yEk5VwshJOVsJJ nfOIM0GK80CKs0CS1X3yjdqZIP1ADwYwggnMYAEr+MMQGKpOI3fqyZ16cqee3Kknd+rJnXrtXJIj IAhGwm0wWt3HKu4jh8rJoXJyqJwcKieHysmhcnKonBwqJ4fKyaFycqhcO7PjixABL8HLMEM7Q+UN 0qsQCcvUEFY2hJUNYWVDWNkQVjaElQ1hZUNY2RBWNkSKVwvIoefJoefJoefJoefJoefJoeelj7ht HSRDCmyEVEiDdMiATZAJWbAZspn/FtgKOZALefx8G2yHT2AH7IR8KIBdUAifwm4ogj1qEnU8Sfob 1z+HvVAM+6AEvoBSKIMDUA4VUAkOOMixqIJqOAQ1cBhq4QgchWNQB8ehnsc0QCPXT/C9Cb6Ek9BM JJ2CFmiFNmgHp5qIExJxQiJOSMQJiTghESck4oREnJCIExJxQiJR+ylRW0jUFhK1hURtIVFbSNTu ImpbiNoWoraFqG0halvozprpzprpzprpzprFWUfpPyLoPyLoPyLoPyLoPyLoPyLoPyLoPyLoPyLo PyLEuUnpPybTf0ym/5hM/zGZ/mMy/cdk+o/J9B+T6T8mi7OXinOX4p9w/BOOf8LxTzj+Ccc/4fgn HP+E459wcXZT+XGYCk/Ak/AUj58GT8MzMB1ekH7DDn0cO/RYduhPsEN/mR36w+zQY9ihh4nzo4qz o7JDj2GHHsMOPYYdegw79BhxvlQcF47jwnFcOI4Lx3HhOC4cx4XjuHAcF47jwnFcuDizKj3D6+Lc quzQY9ihx7BDjxFnWaWHmEkPMZMeYiY9xEx6iJn0EDPpIWaK86+yc45h5xzDzjmGnXMMO+cYds4x 7Jxj2DnHsHOOYeccI87SKs7Rij1ysUcu9sjFHrnijK3ifK0YJBODZGKQTAySKc7eSgc9nw56Ph30 fHEeV900dbU4k6s4jyu9w7X9vcO1/b3Dh1gmQlesZus62FvQl+q+Yt/hlv4k/VI7w6sf6MEARjCB GSxgBX8YAkPZt4/Gg2NgGc6Ng+WwAt4DO7wPK+EDWAWX9gPntd94PUOl8eNV03nVdF41nVdN51XT edV0XjWdV6XbAn8YAkPVuT/RKzjxnRPfOfEduyYYre7gHYq/aezCd134rgvfdeG7LnzXhe+68F0X vuvCd134rgvf9eK7XnzXi+968V0vvuuV3pBMzDSamUYz02hmGs1Mo5lpNDONZqbRzDSamUb3/9Yj Fc+l4rlUPJeK51LxXOq/+FuPjXhuI57biOc24rmN/+JvPQ5wBA78X/zWIw/P5eG5PDyXh+fy8Fwe nsvDc3l4Lg/P5eG5PDyXN+i3HnlX+K3Hfjy3H8/tx3P78dx+PLcfzzXguQY814DnGvBcA55rwHMN eK4BzzXguQY810AkHcNd3+Kub3HXt7jrW9y1Gnetxl2rcddq3LUad63GXatx12rctRp3rcZdq3HX ety1Hnetx13rcdd63LUed63HXetx13rctR535eCuDbhrA+7agLs24K4NuGsD7tqAuzbgrg24awPu SsFdKbgrBXel4K4U3JWDu3JwVw7uysFdObjrjkHumoi7FuKuB3FXDe66F3fV4K4a3FWDu2pwVw3u qsFdNeLsybgrF3fl4q5c3JWLu3JxVy7uysVdubgrF3fl4q5c3FWDu3JwVw3uqsFdNbirBndl465s 3JWNu7JxVzbuysZd2bgrG3fV4K4a3FWDu2pwVw3uqsFdNbirBnfV4K4a3FWDn5rxUzN+asZPzfip GT9tx0/b8dN2/LSdrH8WPyXhp91k/+9x09146W68tBYvJeOiz3HRNNmknVvaD/RgACOYwAwWsII/ DIGh6vKf+NvDbqzQjRW6sUI3VujGCluxwlas0I0VurFCN1boxgrdWKEbK3RjhW6s0I0VurFC9z/t gkSvuUy1YwU7VrBjBTtWsGMFO1awYwU7VrBjBTtWULBCAVYowAoFWKEAKxRghQKsoGAFBSsoWEHB CgpWULCCghUUrKBgBQUrKFhBwQoKVijACgVYoQArFGCFAqygYAUFKyhYQcEKClZQsIKCFRSsoGAF BSsoWEHBCuLvaT7FCp9iBQUrKFhBwQoKVlCwgoIVFKygYAUFKyhYQcEKClZQsIKCFQqwQgFWKMAK BVihACsUYIUCrFCAFQqwQgFWKMAKBVhBwQoKVijACgpWULCCghUUrNCOFdqxQjtWaMcK7Vih/Wf+ /lOh+3HS/Tjpfpx0P066Hye2qPonv//sxCCdGKQTg3SKs5hjkD0YZA8G2YNB9mCQPRhkDwbZg0H2 YJA9GGSPONc5BsnHIPkYJB+D5GOQfAySj0HyMUg+BskXZ0MX50LHIIUYpBCDFGKQQgxSiEEKMUgh BinEIIXibOkY5CAGOYhBDmKQgxikCIMUYZAiDFKEQYowSAAGuRWDzMMgd2CQOzDIbRikDIPcKs63 Ls62jkHKMEgZBinDIGUYpOxfMEgZBikS52rHIGUYpAyDlImztmOQ3RhkNwbZjUF2Y5DdGGQ3Btkt zueOQcowSBkGKcMgZRikDIOUYZAyDFKGQcowSJl2buoKtQqLVGGRKixShUWqxBngsYY4M/1d4gzw 4vzv2GKrlEXWV5D1FWR9BVlfQdZXkPUVZP0+sn4fWb+PrN9H1os9TwXZXkG2V5DtFWR7BdleQbZX kO0VZHsF2V5Btlf8039tmEAPvQYSIQk+hLWQDVtgK+RALlz6bWEh2VFIdhSSHYVkRyHZUUh2FJId hWRHIdlRSHYUkh2FZEUhWeAhCzxkgYcs8JAFHrLAw87Uwc7Uwc7UQUYcIiMOkRGHyIhDZMQhMuIQ GXGIjDhERhwiIw6REYfICAcZcYyMOEZGHCMjjpERx8iGarKhmmyoJhuqyYZqskEV/4ssskElG1Tt 7Mw3qieI3BNE7gki9wSRe4LIPUHkniByTxC5J4jcE0RuH5HbR+T2Ebl9RG4fkVtH5NYRuXVEbh2R W0f0NRF9TURfE9HXRPQ1EX1NRF8T0ddE9DURfU1EXxPR10Tk1Wlnc0+GFEiFNEiHDNgEmZAFmyEb tsBWyIFcyINt8DFsh09gB+yEfCiAXVCo/V2+gz78MH34Yfrww/Thh+nDD4vz7xKdx4nO40TncaLz uLaD9+7eP5EjqVuzqFuzqFuzqFuzqFuzqFuzqFuzqFuzqFuzqFuzqFuzqFtTiOC9RPBeIngvEbyX CN5LBO8lgvcSwXuJ4L1E8F4ieC91K566FU8kFxPJxURyMZFcTCQXE8nFRHIxkVxMJBcTycVEcrEk fvf/IkTAS/AyzIDL/93sMnbgcbAcVsB7YIf3YSV8AKsgnkxKUKPIgiiyIIosiCILosiCKGrYPmrY vv9i7t7j46rrvIGfzIRQpq0sF7mIj1BBBOQq5X4HQUABEctFkKXual+sxl1BiFbLtSICLWK14sID CISbkCIUa+nSKdDQNk1LkzZJm7QNOZPLZJJJaJqZBlp6nvcMIy/EdtX9Y1/PH59O0pxzfr/v5/P5 XiaZmaOHJfWwpB6W1MOSelhSD0vqYUk9LKmHJfWwpB6WlDlVMqdK5lTJnCqZU6WHJfWwpB6W1MOS elhSD0vqYUk9LKmHJfWwpB6W1MOSelhSD7tfD7tfD0vqYUk9LKmHJfWwpB6W1MOSelhSD0vqYUk9 LKmHJfWwpB6WlKVVsrRKllbJ0ipZWiVLq2RplSytkqVVsrRKllbJ0io9LKmHJWVrlR6W1MOSelhS D0vK3odl78Oy92HZ+7DsfVj2Pix7V8neVbJ3lextkL0NsrdB9jbI3gbZ2yB7G2Rvg+xtkL0NsrdB 9r4se2tkb43srZG9NbK3Rj97RAY3yOAGGdwggxtkcIMMnid558ngeTJ4nn42WT+brJ9N1s8m62eT 9bPJ+tlk/WyyfjZZP5usn03WzybqZxP1s4n62UT9bKJ+NlE/m6ifTdTPJupnE1WFKapCpapQqSpU qgqVqkKlqlCpKlSqCpWqQqWqUFl2UPRa2cFwCHwODoXD4HA4Ao6Eo+DzcDSMh2PgWDgOjocT4EQ4 CU6GU+BUOA1OhzPgTDgLvgBnwznwRTgXzoPz4UvwZbgALoSL4CuePV8MX4VL4GswQXyXwmVQ+Az7 K+Ab0Vt67kFl/xy9rO8eoe/+s747Xt+9RN89Td99tOxaVeI7fnaDr2+EKvgh/Agmw09gSjRJ9Zuk +k1S/SapfpNUv0mq3yTVb5LqN0n1m6T6TVL9Jum9j6qAU/TeR/XeR/XeR/XeR/XeaXrvNL13mt47 Te+dpvdO03un6b3Tyu7Xr/9T5XwAHoSH4GF4BH4Hj8Jj8DhUwxPwJDwFT8Mz8Ht4Fp6DGpgFz8Mf 4AV4EWbDS/bzR5gDf4K58DLMg/+CV2A+JGEBT76K99fgdVgItfAGXuWkCptUYZMqbFKFTXoW8aBn EQ96FvGgZxEPmgfKzQM3ehbxbTPBbmaCT5gJPuFZxO2q8N3xMBr2TKIuno66PJs4LJ6JBoJqlTmn MudU5pzKnFOZcypzTmXOqcw5lTmnMudU5pyq3KMq96jKPapyj6rcoyr3bOddDGnVOK0ap1XjtGqc Vo3TqnFaNU6rxmnVOK0aF16L+k5wA9wIVfBDmAw/hp/AFLgJ7ouaVdhmFbZZhW1WYZtV2GbVslm1 bFYtm1XLZtWy2ZxxjDnjGBWsWQVrVsGaVbBmFaxZBWtWwZpVsGYVrFkFa1bBmlWwZpWrWUXarCJt VpE2q0gZFSmjImVUpIyKlFGRMipSRkXKqEgZFSmjImVUpLdUpLSKlFaR0ipSWkVKq0Zp1SitGqVV o7RqlFZ98qpPXvXJqz551Sev+uRVn7zqky/ev3o0jIXC/Vx2gV1hN9gdPg57wJ6wF+wNhXtXfEqv 3hf2g3HwadgfDoDPwIHwWZjg2EvhMii8Ru0KuDrYRQYfIoOvlcHHyeCzZfABMrdwf5yU7EzJzpTs TMnOlOxMyc6U7EzJzpTsTMnOlOxMycwBjl7J0a0c3crRrRzdytGtxTuILIYlUAdLozZuPZxbD+fU lcE5lE5ROkXpFKVTlE5ROkXpbkp3U7qb0t2U7qb0kZQ+ktJpSqcpnaZ0mtJpSqcpnaZ0mtJpSqcp naZ0mtJpPWmrnrRVT9qqJ23Vk7bqSYW/dTzAAQ9wwAMc0MYBbRzQxgFtHNDGAW0c0MYBbRzQxgFt HNDGAbM4YBYHzOKAWRwwiwNmFV7PzQV3ccFdXHAXF9zFBXfFL/CMf0IwuvROo6+Yml6OXxVdGf9G VBu/2vdqavwa30/0/XXRe8FJJpK0iSRtIkmbSNImkrSJJG0iSZtI0iaStIkkjcE0BtMYTGMwjcE0 BtMYzGAwg8EMBjMYzPyP/ha3znnroR3egg4IizmQwcAwBoYxMIyBYQwMF18D/o6J6l3YDFvgPfjo 68K/EewYnwiFd4Ac8/e+0lIEIyIYEcGICEZEMCKCERGMiGBEBCMiGBHBiAhGRDAigkgEkQgiEUQi iEQQ0X4p7ZfSfqlo2rbznHmFaJaKZqlolopmqWiWiqZfNP2i6RdN4RWgKbp207TwetPueGHePDyY 7vnPfdF6+qynz3r6rKfPevqs36Y+c4M9OHwPUWZEmRFlRpQZUWZEmRFlRpQZUWZEmRFlRpQZUWaC VJAIOqELhjh7JFpj55vtfLOdb7bzzXa++UPvNrgqflUQp8PY0rsOropf4/uJwdjgIHqk6JGiR4oe KXqk6JGiR4oeKXqk6JEKplNvrtVfLuzAs6dO6IL3K+S23iWzzK7W2NUau1pjV2vsag0+0/hM4zON z7Rd1pXeNZDGaQ9O0zjtiX8zCuP/EoXBeXY40w5n2uFMO5xphzPtcKYdzrTDmXY40w5n2uFzNOik QScNOmnQSYNOGnTSoJ8G/TTop0E/Dfo/+B1xnciWQj0sg+XwJqyABmiElbAKmmA1bO9VrkPROmy0 Y6MdG+3YaMdGe/H3t+9w6LuwGbbAe7A1GsLGEDaGsDGEjfOxcR7ddqLbIXTbkW7j6LYT3Q6hWyGX xmHnfOycbxJYGH8z+Fywl+gL7wncKvqtot8q+q2i3yr6Qu3L0StHr1zpd0bbyub2bf3O6M/ZG8Ti hbu6TAxGFf8K2kaRNoq0UaSNIm0UaaNIG0XaKNJGkTZ72v77CN9/rdRH30FSuKNTm5V2sNIOokzF C+/LON+KoRVDK4ZWDK0YWjG0YmjF0IqhFQuvW6jGQDUGqjFQjYFqDFTTv5r+1fSvpn81/avl4Bg5 OIb+1fSvpn81/avpX03/avpX07+a/tX0r6Z/Nf2r6V8tqqyosqLKiiorqqyosjpLh87SobN06Cwd OkuHztKhs3ToLB06S4fO0qGzdFCiixKtlGilRCslWinRWuos6ymxnhLrKbGeEut5YgeeOJAnEhg6 lSd24IkDeSKBrVPV19bgy8Htwb7BVPgp3AE/gzvh53AX3A33wPTgDGwtx9ZybC3H1nJsLcfW8u1M X3/uyW3YasNWG7basNWGrTZstWGrDVtt2GrDVhu22rDVxn/P8N8z/PfMP/h88FEMPYShhzD0EIYe wtBD2LkTO3di507s3ImdO/XcUWrIafrtDerI4frtD9SS0/TbG9STw/XbH8R/Er0SnxK9FF8RfC7e EHwqvjI4WES3c+lU+CncAT+DO+HncBfcDffA9ELdptnLxfzf3pTxhkjfEOkbdt9j9xm7z9h9xu4z dp+h7xt/Z6dpkA0dpVcJjhLVstIrBUeJaJns6IoXXuNTyI7pIpgugukimC6C6SKYLoLpIpguguki mC6Cn9B8gOYDNB+g+QDNB2g+sO0upYa/DHXydCnUwzJYDm/CCmiARlgJq6AJVsM6NWU9tMNb0AGe r2BoEEODGBrE0BCGRjA0gqERDI1gqFAb2jC0EUMbMbQRQxsxtBFDKQylMJTCUApDhXuyflJm7Iyh 8bJip8JdyzA0XkbshKETMHSCKnmb7GgpdLtgnOwYJzvGyY5xsmOc7BgnO8bJjnGyY5zsGCc7juX4 Azj+gL/4bcaQvN2oig5DDvKwCUaCXe24y4677LjLjrvsuIsrvxS/1G6+Tseronb6ddCuPf5Nefsv 8N1gavzmYN/4rXB7sE9wKi27aNlFyy5adtGyi5ZdtOyiZRctu2jZRcc+OvbRsY+OfXTso2MfHfvo 2EfHPjr20bGPfn3066NfH/366NdHvz769dGvj3599OujXx/9+ujX99/8ZrYXG73Y6C29/2pbr8gK MRFiIsREiImQdsO0G6bdMO2G6bVTcYb6Z4+FGeo0kWdFnhV5VuRZkWdFnhV5VuRZkWdFnuXiIdFn RJ8RfUb0GdFnRJ8RfU70OdHnRJ8TfY6LR7h4BAs5LOSwkMNCDgs5LOSwkMNCDgs5LOSwkMNCDgu5 /ybPs1jIYiGLhQ1YGMLCEBaGsDCEhSEufmubHfXrUUaVGincEVJ1GuHMoWL0M0Q/Q/QzRD9D9DNE P0P0M0Q/Q/QzRD9D9D8V/QLRLxD9AtEvEP0C0S8Q/XzRzxf9fNHPF/180a8S/SrR14q+VvS1oq8V fa3oa0VfK/pa0deKvlb0taKvFX2t6LeIfovot4h+i+i3iL7wmoZz45dy8mVq6+W+/nqwNz0vK3Wm iwr3L6XrZaXOdJE8vFse3i0Pq0V7j4nl7Hhj9EJ8VbQ13hR8M9hF9GtFv1b0a0W/VvRrRb9W9GtF v1b0a0W/VvRtf351hV20Wn21q7e6emsxd2a7ymxXme0qs11ltqvMdpXZrjLbVWa7ymxXuQmH63C4 DofrcLgOh+twuA6HrThsxWErDltx2GrFeVac9z+cFDfjcDMON+NwMw4347AwnX8Th404XCmK03G4 Iw7Pw+HOOLwGhzvi8Dwc7ozDa0T5C1H+AofTcbgIh+fjcBX+rig+h6wReY3Ia0ReI/IakdeIvEbk NSKvEXlNaUbe3jPxbby2Uxd+Gf5nnyCxTffIi8Kce5nom0S/SvTnl6I/XvQ7if66UvTHi34n0V8n +t+K/rfF1wMf9Xe/Lv++6AWRviDSF0T6gkhfEOkLIp0l0lkinSXSWSKd9aFXsc4R6RyRzhHpHJHO Eekckc4R6RyRzhHpHJHOEekckc7Z3jQoov1EtIOIJolmP9EU5tpJongyOFMU00QxTRTTRDFNFNNE MU0U00QxTRTTRDGNZt/a7juLn4gWiWSRSBaJZJFIFtHsTZq9KZI6kdSJpE4kdSKpE0mdSOpEUieS OpHUiaROJHUiqRPJuyJ5VyTviuRdkbwrknf/qnpPMFldGi2nXzP9TirNpheIdm/R3lWaTS8Q8d4i vot+d9HvLu79ueif594zubeOe48MjsbEECaGMDGEiSFMDGFiCBNDmBjCxBAmClW/BQstWGjBQgsW WrDQsp15dRQ9R2GhBQstWGjBQgsWWrDQgoUWLLRgoQULLVhowUILFlpU802q+SbVfJNqvkk137St 33SI+CjRHi/So0R5vMjWBF8p3qP4YDgECncqPhQOg8L9io+AI+Eo+DwcDePhGDgWjoPCHY1PgBPh JDgZToFT4TQ4Hc6AM+Es+AKcDedA4T7I58J5cD4U7oj8ZbgALoSLoHB/5AfgQXgIHoZH4HfwKDwG j0M1PAFPwlPwNDwDv4dn4TmogVnwPPwBXoAXYXbhPr7R+uL9l1+D12Eh1ELhbsyFezEvhiVQB0vV 8K975ne1+v614p3ED4ZDoHA/8UPhMCjcVfwIOBKOgs/D0TAejoFj4Tgo3Hf8BDgRToKT4RQ4FU6D 0+EMOBPOgi/A2XAOFO5Wfi6cB+dD4b7lX4YL4EK4qPhexBwGcxjMYTCHwRwGcxjMYTCHwRwGcxjM YTCHwRwGcxjMYTCHwRwGcxjMYTCHwRwGcxjMYTCHwRwGc8U7Shfu0/wavA4LoRYK90wv3DF9MSyB OlgKhfuJL4Pl8KYOWXjmUHg/8VXFe1kfDIdA4Y7Wh8JhULiv9RFwJBwFn4ejYTwcA8fCcVC48/UJ cCKcBCfDKXAqnAanwxlwJpwFX4Cz4Rwo3C/7XDgPzofCnbO/DBfAhXARFO6jfR/8EmbAr+DXMBN+ A4U7bD8AD8JD8DA8Ar+DR+ExeByq4Ql4Ep6Cp+EZ+D08C89BDcyC5+EP8AK8CLMLd53eLuMtxbt5 L4Yl4BkRxvPFe3svg+XwZvGzTTKFuS7YsywmqjiUww5QATvCKNgJEjAaxsIUuAluhlvgVrgN9Lky fa5MnyvT58r0ubJCn0uU7RzsW/Z1+C5Uwr/Df8D34Tr4ARSe7d9VvId9HMphB6iAHWEU7AQJGA1j oXB/511gV9gNdoePwx6wJ+wFe8MnoqVln4qWle0L+8E4+DTsDwfAZ+BA+Cz8//6pOF+JFpZdDF+F S+BrMEF8l8JlcDlcAVOiJho10aiJRk00aqJRE42aaNREoyYaNdGoiUZNZXc75xdRF1d3cXUXV3dx dRdXd3F1F1d3lS0Ixpa9GlSUvQavw0KohcJ9uRfDEqiDpfDR3J7gOe3l0Q9Ls3dlaeau1IOWFN9z 9EiwZ3xecEz8Vc8+w2D/eCq4JN4Z7BrvCj4R7/F9Otg93qsLZ/xfX3BMcEnxnu9xKIcdoAJ2hFGw EyRgNIyFwj3ed4FdYTfYHT4Oe8CesBfsDYV7xxfuHL8v7Afj4NOwPxwAn4ED4bMwwbGXwmVwOVwB hfvN3wQ3wy1wK9wGt8NU+CncAT+DO+Hu4vtgU2pFSq1IqRUptSKlVqTUipRakVIrUmpFSq1IqRUp tSKlVqTUipRakVIrUmpFSq1IqRUptSKlVqTUipRakVIrUmpFCvOjMf9FzI/G/Bcx/yrG94jPDz4d XIbNVmy2YrMVm63YbMVmKzZbsdmKzVZstmKz9R/4a2AWm4PYHMTmIDYHsTmIzUFsDmJzEJuD2Bws +0qwW9nF8FW4BL4GE5x/KVwGl8MVMEVHvgluhlvgVrgNzGQYHsLwEIaHMDyE4SEMZ/+3XqEUn8DD 778r8JLSuwIviX83OC+I+Z/C6/z3CMr9fFTxedPVxffcnRd8TG0cozaOURvHqI1j1MYxauMYtXGM 2jhGbRyjNo5x5med+dXCfdKd+dXimfs4cx9n7uPMfZy5jzP3ceY+ztzHmfs4cx9n7u7M7zlzd2d+ r3jmWGeOdeZYZ4515lhnjnXmWGeOdeZYZ4515oHFqfFqj6bGf2i3BxZ/x/X+meOLHBxS+JtAcCmv reO1dby2jtfW8do6XlvHa+t4bR2vreO1dby2jtdW8NoKXlvBayt4bQWvreC1Fby2gtdW8NoKXlvM a/N5bT6vzee1+bw2n9fm89p8XpvPa/N5bT5fLearxXy1mK8W89VivprHV/P4ah5fzeOreXw1j6/m 8dU8vprHV/P4ah5fzeOrxeplVr3MqpdZ9TKrXmbVy6x6mVUvC77L812e7/J8l+e7PN/l+S7Pd3m+ y/Ndnu/yfJfnuzzf5fkuz3d5vsvzXZ7v8nyX57s83+X5Ls93eb7L812+7KWoWza/GOxiHthkHhgx D4yYB0bMAyPmgRHzwGrzQM48kDMP5MwDOfNATpXuUqW7VOkuVbpLlW4LdpCLCbmYkIsJuZiQi4ng Yqo1U62Zas1Ua6ZaM9WaqdZMtWaqNVOtmWrNVAupFlItpFpItZBqIdVCqoVUC6kWUq2Tal1U66Ja F9W6qNZFtS6qdVGti2pdVOvS+Tp1vk6dr1Pn69T5OinZSclOSnZSspOSnZRsp2Q7Jdsp2U7Jdkq2 U7Kdku2UbKdkOyXbKdlOyc6/9clDOt9uOt9onW+0zjda5xut843eVufD4VeKr4j9evBJnr9SBnyS 76+k0MLic4Ws+SJrvsiaL7Lmi6z5Imu+yJovsuaLrPkia77Imi+y5ous+SJrvsiaL7Lmi6z5Imu+ yJovsuaLrPkia77Imi+y5ous+SJrvsiaL7Lmi6z5Imu+yJovsuaLrPkia77Imi+y5ous+SJrvsia Lwqe7eXZXp7t5dlenu3l2V6e7eXZXp7t5dlenu3l2V6e7eXZXp7t5dlenu3l2V6e7eXZXp7t5dle nu3l2V6e7eXZXk7t2M7kmtnWqzM4dYBTBzh1gFMHTK5d8cK7iCdgNMRoiNEQoyFGQ4yGGA0xGmI0 xGiI0RCjIUZDjIYYDTEaYjTEaIjREKMhRkOMhhgNMRpiNMRoiNEQoyFGQ4yGGA0xGmI0xGiI0RCj IUZDjIYYDTFa+HTLEKMhRkOMhhgNMRpiNMRoiNEQoyFGQ4yGGA0xGmI0xGiI0RCjIUZDjIYYDTEa YjTEaIjREKOhKjCI1XCbr3d5w/9v4zWyWO3GajdWu7HajdUVWF0R/Ea2h7I9lO2hbA9leyjbQ9ke yvZQtoeyPZTt4T8wXRXe6dwv2/tle79s75ft/bK9X7b3y/Z+2d4v2/vLDpJdB8Mh8Dk4FA6Dw+EI OBKOgs/D0TAejoFj4Tg4Hk6AE+EkOBlOgVPhNDgdzoAz4Sz4ApwN58AX4Vw4D86HL8GX4QK4EC6C bVejv/58tCly6ia4GW6BW+E2uB2mwk/hDvgZ3Anvfw7aJtVok2q0STXapBptUo02qUabVKNNZf+p 0jwAD8JD8DA8Ar+DR+ExeByq4Ql4Ep6Cp+EZ+D08C89BDcyC5+EP8AK8CLNhgV7+KrwGr8NCqN32 pyL8lZMmRBNVwctLf+s6ufR3rpNVwYaiu3q5q5e7ermrl7t6uauXu3q5q5e7ermrl7t6uaufu/q5 q5+7+rmrn7v6uaufu/q5q5+7+kuvPRvgrgHuGuCuAe4a4K4B7hrgrgHuGuCuAe6q4K4K7qrgrgru quCuCu6q4K4K7qrgrgruquCuCu6q4K4K7qrgrgruquCuCu6q4K4K7qrgrgruquCuCu6q4K4K7qrg rgruquCuCu6q4K4K7qrgrgruquCuCu6q4K4K7qrgrgruGuCuAe4a4K4B7hrY5uvl/nF3DfztT64K yrmrnLvKuaucu8q5q5y7yrmrnLvKuaucu8q5q5y7yrmrnLvKuaucu8q5q5y7yrmrnLvKuaucu8q5 q5y7yrmrvOSuUdw1irtGcdco7hq1HXcNctcgdw1y12Cpx07Zhruagsu5q4272rirjbvauKuNu9q4 q4272rirjbvauKuNuxq5q5G7GrmrkbsauauRuxq5q5G7GrmrsfRuizruquOuOu6q46467qrjrjru quOuOu6q2847K5ZQagmlllBqCaWWUGoJpZZQagmlllBqCaWWUGpJ8Z0Vv/Ac6j74JcyAX8GvYSb8 pvCbUU55AB6Eh+BheAR+B4/CY/A4VMMT8CQ8BU/DM/B7eBaegxqYBc/DH+AFeBFmw0uFz0MIjsbw 0Rh+rZi/HRjuwHAHhjsw3IHhDgx3YLgDwx0Y7sBwB4a7MdyN4W4Md2O4G8PdGO7GcDeGuzHcjeE0 hnsw3IPhHgz3YLgHwz0Y7sFwD4Z7MNwjfxPyNyF/E/I3IX8T8jchfxPyNyF/E/I3IX8T8jchfxPy NyF/E/I3IX8T8jchfxPyNyF/E/I3IX8T8jchfxPyNyF/E/I3IX8T8jchfxPyNyF/E/I3IX8T8jch fxPyNyF/E/I3IX+75W+3/O2Wv93yt5sr0lyR5oo0V6S5Is0Vaa5Ic0WaK9JckeaKNFekuSLNFWmu SHNFmivSXJH+2886/le7w7byd1u/Dfpo/n5P/v6olL+nlvL31OJrb2/4Bz8T8e/9HWAjdzVyVyN3 NXJXI3c1clcjdzVyVyN3NXJXo4kyb6LMmyjzJsq8iTJvosybKPMmyryJMm+izJso8ybKvIkyb6LM myjzJsq8iTJvosybKPMmyryJMm+izJso8ybKvIkyb6LMmyjzJsq8iTJvosybKPMmyryJMm+izJso 8ybKvIkyb6LMmyjzJso8dw1y1yB3DXLXIHcNclcjdzVyVyN3NXJXI3et5K6V3LWSu1Zy10ruWsld K7lrJXet5K6V3LWSu1ZyVyN3Zbgrw10Z7spwV4a7MtyV4a6MWpA3ZQ5s89NPF/n/xbAE6mBp8ZVA hWc/nwzGxk6MUrGz4Nzoqth50X/EvhT9R/yC6PX4BM+ZLi9+ImrhPgezSvc5mMUL2WB07MgoExsP x8FpcG7U4Oylzl4auyBaxUnrnbnWWWuDjzm639H9js5br90Z/dZsj13s8XL/d6Wv/xUq4edRW+yu qM06PUHCmTln5pzV5aycs7oc0eGIDjEcJobDHLm0uEa3I7ut0eLIbjuqt6NldrQsVownWlz4BIXS 50qPLX2u9NhglGs/5bpP2UWNXdTYRY01FlhjQfHVcLu69rWufa1rp1z7Wtfe5NrDrj3s2oU9r3b0 6viErcPxy7fmSr9tOqL026YjSq8cWli80jWudI01l7jSNdZdEjs3+D+ucKErXFh67+bdpddEHFL6 RIqjS59IcXTpEymuCP7Jlb7vSt+3p2FXW+xq33e1xa70bVf6tiuNcaX7XOlGV9rVVfZ1hX1d4SZX qAp2dNZCZyx0RrMzmh2xqyN29dMZwc7Y2IiNjbFroydj/xb9KvYd+C5URhs/4o8f88cr+Pwxf7zi 7GG6XcwTl8O1fPFvPPEd+C58zzoTorc+8EaZ4zP2cjFtr6Ttv0Kl55BXFn8/daCfNvLoxf738miN q9W7Wr2r1btavau9+hFdP1bS9WPFK7eL4+LoReeGzt3k3C3O3eLcLc5td+4o547GcqL4PoOrPRbe a/D+35ffKJ59u30ttq/FsWuDT9rbYmf9C2bfwWze2VOdvWfpt3F7Fv+G+93oN4W/Thf3/X1rD39w hffPPt7Zb5be039O8cz3z5rhLP3d0cscvczRy/z04376cT/5NafeYN83Ru/Eqvh7arBDbFo0EPu1 HLo/ysZ+Ky9jfvpubGqUD8r8+w4dqmTXD0X+I5gaNcXucJWfuco9UTo20w7vjzY7c7P/vc61rocb XKGKz6dEPa7fGftVNBjz7IZ3r8P49XCD//2hI38EN0crYrfArXAbTA0+HrsjmhW713G/iN6K3Qe/ hBlwfzTXWnODcrtc76iVjuqIzYw22PfUaMieNtnxddGIVUas8K4VCtF0cGieQ/OOyLvKiKuM2PGN dlmIb4pzb7LLqarAHf7vXmrPjAaDT7jWfNeab8dpRy52zZRrpmKTfT8l6nXWkAj6RdAvgn4R9Fvv PevNt958622ITY8WiaRFJC0iaRFJC07q8f6GvTTZS1Owj5W6rNRlpY329ZrVBq3QaoU+KwxYYcAK A1YYsM8x9vmCVfqt0h8z/WM6bd/PWSltpbSV0lZKWylrpQ3iecVq7VZrD3ayWt5q+WL0719t2NU2 uNoGV8q70rAa/UM6/wimWuMOzN7tyHscWTzC1zPhfr74bUndtGumndXvrH67zth1xq4zdp0prvPn Hbv+X+30fsf8Vi4XtHy7+BvLCtfsd81+UfSLossx/Y7pL2qX+8v9ueLdxZ3nxZpXEW50/lTXvMO6 d/v6Hj64l7tmBgnV788M3ECtKXBTsLejt9jh23b4tqNHxPk29Yaddbgd5O1g+AP3FDxY8NgGO9jg zEUf5M5wEC/+bCrcITN2tladteocnXV01lqF7Gq1sx2s12O9niK39/r+V3Lj15x1v//7rQ4WL+br +xGOBONjNTR8Kdgj9kr0Zmw+vMqVr9nb69EtsYXR72K1sEgvWhr9JLY8mhprdEyTx2YYxPLbsNE1 ctG9sXz0cmwTvCPv3ov+bzxQd8qjdHxHj6NgrK/3iHLxPWEvOAgOhsOi4fgROvlR0fz45+FoGK/m Hq/rnhTNjuuzH9zp6NLgn+KXBWNK70M6UqV/XoU9UqV/Xk1K61yPi60GXsP+69EqUQyLYlgU78QW e1yqny9XzVaJssljM6R5uJeKOfmX5/5N8G60QQRv2f1bdv9WfG8V9ogoZZcb7XKjXW6Mm+bsMAz2 Kq3air8Rq7ZYNWvVrFW3WLXTqqut2mLVjVZtsWqL1fJWG7LakJWGrDRkpSGrvGOVnFVyVslZIRv8 uxW+HXsm+rFVRmIvRc/H/hRNic2FV9SF+fAqvKZ6LoqeiC3lnkbfr5Ltq6NvxdZE/xVrhTZYC+tg fTQp1u4xdFwqmhPr9HUX9EA6uCHWGz0cy/i6D/qjG2NZjwMwaEp4Gzb4egg2RpfGhlWKvAg3wTvR qbh7I7bZz7bAe9EfY1s9RhQsgxjEo4WccU18B19XRNPjCTPBaF+PMe+PjZriO0ffj/8T7AK7wu7R OM4ZzznjOWc8La6NfyL6QXwfP/sk7Bt8Oz7O46dh/+iE+AHwGT8/0PefhYOi/Tlt//ghvj4UDos+ HT88OhPTj2G6CtNVmK7iunNo+kD8WMccB8dH98RP8HginBS9HD/Z4ylwqpnlNPs43ddnRFeWXvXY roc+oof+mw68n+67X/za4vzxavA5KnVQqYNKHfzR8SF/rOONbt5YTbEO3ljNG6ux3I3lbux288l6 7K7D7jrsdmE0xS/rMdjNM+t5Zj3WejH0NobextDbIn5bxG+L9G1RhqJMiTIlypQoB0U2IKJ1olAb g5Pk1Snyab1cWh98ls/y/JXmr7SdN9l5k5032Hkhj+pLbm6246ZSHjXbdTPffMrOW+281c4b7XaJ 3XbbaasddtKxyy4b7bLRLhvpNppe3fTqtuPVdrzajleV8myNHa+x4zV2vKqQZ3bbGBxkR8vsaJkd LbGjbjv6YymrU3a0zG5SdpOym93sps9u+uymA4/teOzGY3epRq3GY4vd9eGxBY8tHDhSqlMpu0zZ Zcoux9hdyu5SdrfC7tbbXYPdNdhdg929hc+1drjIDlM62+OyvLCzhXK1FhbL8qV2sFwlWKXDNXls jjpladqEuG/hPqvOGcL7CN7zeM87512+WstPXeaixzH/DNTAn494Pbrugxq92IyxNHqwUF/o+Dgd HzdvPG7CfQYjNZwzi9tesqc/+X4uvI6BhRiphcXYW6o7LY+SsQa1731Nk/aYVD8G1YqMGjAoTwdp 2ECzVpq12l+L/bUE+1vpXivdYqXUX1Sn13WzhfpYLSz2s6VRZJXhUh0ctsKwFWqs8KKKs8Iqb1jl Dat86y802D+63orXy+o+WoS0CGnRWeQe57Kw8NqRo+zmKFy+istFGEl7hhJE71H3Peq+h+nj9PoC l6+LcKGIayEdVNBzAz030HNDsdbeKpqZIlkgkl+K5Jdct4LrVrj2othCHbMWFkWPiWgz160QUbdI bthOrf1Zqdb+l1q74CO19laRv/ihWnvLh2rt9dx7/Ydq7bVq7YoP1dpL1drlH6q1r2yn1l5fqrWP YfeWUq2tLNXaSrW2Uq2tVGsrMX8S5s/F/LmYP1etvUOtrVJrK9XaShxeodZWqrWVVDmHKudQ5Sq1 tlKtraTOOdQ5R62tVGsrqXSWWjtR1jyH5VuxfCuWb6XcBWrtNLW2Uq2tlEG3qbWVam2lTLpZra1U ayvV2m9Q+Fy1tpLKhc9IvLT0Kv3nqF2l1u6l1u6l1r6p1j4bTKLet6h3HfX+QL3rqXc99VZRb1Wx ir0mExdFtZTro9wqyvVQ7geUq6dcPeXqKVdPuXrK3Uu5eqolqVZPtXqq1VPtG1R7iWr1VKun2v1U q6daPdX+SLU/Uq2eavVUm0W1JepPjmJJiqUoVk+xemrVU6ueWvXUqqdWA7X+SK16atVR635q1VPr FWqtpNZcas2l1lxqzaXW2dS6l1r3UuteaiWptYhac6k1l1pXU2suteZS60pqXUmtWdSaS6251Po5 tX5OrbnUmkutadSqpVYPtdZSay211lLr19RaSa251JpbnM1O8HginAynwKnmttPs4XRfnxFVU+oi Si2gVOH9j8dS583gQOo8TZ1nVYpGNWkDlZZT6WkqPU2ZAZn5rMxslpnNKsYCKmVVjJfUpSylelWN l1SNlyj2OHVq5VQvJZZTYCGGV8uNUG6EWO6R+6uwOCj/V8n/VdhciLHnMPEcJp6zy8I7Fr5a6NnB Z3ikgUcaeKSeP/5k5U7+aKD1mTRdS9O1tFxqlbesssIqK+g5J1Z4F2PgmXQ5nnb0OArGqFNjdbU9 cLYn7AX7BofifhPOW3Heius1eO7C8zI8L8PzMjw34XaNDFiNy5Xm9bTuU+iT46MtZv+a4nz5HQzd j6H7MfSafd6ChXfs6wn7etG+XhR9pjQn1NjT/2PuTMCjqu7G/Tvn3JAdEEIggBD2TWWVIoJxwQUR IggKCAiCICQQhOCCgi2gKFqLSxXFrVURlQASBVlF0EHFhC2BIclEloQlhAQEEtbc770nY0ut/att v+/5PzzvuZl7z35+a5iZLGZOi8kINrp/pOWXtPySFZbT8jlarf1b5F7pEfN/jCpoUYqdPgYn6O+U +yE1fdT0se58ai+i9kLWfYIWC2mxkDh6H7VPEaWUcS7lcJYIQ1hZFbeIWhnUysBD7kMXTrm7qVVI rUJqHaI/Lw7eSs2T1NxKza14cD9ykQ/FUIpMHIMTZCFn4CyW/ALe2nF30iqP8/2A81yJ1O1C6jzf tMK+k8p7F5UnfZfQw0l6OEkPJ4PxwPeM/z29FdlIRZAax45/kPEPBj/p1pZ8owN+NRu/mm13pYhe iuhlD73k0UsxvRTTyx56KaWXVfTirXcVvaxiV0p5egwq47lz3v7ZmN/BbwXjfk7Xz1Nv/0qpcQwq Z/nDRVFLMWveSctcWp5jzcdpnUvrXNGs1Pu9XEdyST9erZh+ztJzhHtCqv7Ni+9Dw4rtWW6j13x6 zadWLj1+gu05Gdz7T+jxE+P9fViv5Ve0/IyWP9ByFS0P/Ji1eJbsYnmhxSr2vy/7PpKc1PsMXTjt j9PmOG2O0OZIMK8qZaTDtCulXald+WpG8THC1xfpWhYrTqNFmdWtCPvbqieCp7ubUcba38d5rZda W1BMVlWKnTgGJ7DqZ6xsHGUsbx920Xpi8HddW2g9yP4/Qg1a59N6BSvMwM7vpJfPmfGSi3RpRVAz 3mCPPIvixd1vMPM36PVzen2G3hbbU85l7Fwb+55Cv864G2l1lDnk0uIoLY4iPX52bh/yfgr9LcNP lMNZ7IHgaSt35UlqPom83Yu83ct5nmJGZfRZDvh44pU4osO20J7z6gAd4Ur3DHYiBusfx1g/xmht 2e/2rL8DdIQr7Wf1DnnfSCAR1C6h9mlql1C7hJrl1CynZnkwuy3CSh6TBkq7m5QBB0KgCoRCGIRD BERCNONHkcHGuK9j/Y5g/Y5g/Y4wwhJGWIIFLMECHsYCHsYCHsSuHcDSHWGUEnbyHXbyHfvuX++d v57O1sKOnjQx6GAsq6oNdaAletMKLoe29NQeSeoAHaET966UathRL3cupPej6DFRg7Rn5btY+S5s agzRYxxRZBPktik0s7+FOP1P+f1g5jbMPcJeRVE7lp2rDXXg7zlBkR3zamonsKvh9F1qf1/QhDil KbTnSQfoCFcyhvd3LsOo8UPw9x5beLqFp1uCIz7PiM9LKE9L/uGEvdP40Qp5o2TSxylG2cUouy6O YenHm0+hKGZ3SmqaaH6Kcd9i/iXMv4T5l9BuOe2Ws/JTF53IUdZyhHWUcCLeZyI/4kQ+4kRqcCLe 7+L9cgk9ffyTs11HT+vo6QQ9naSnk/R0mp5OBM/2DD1tpqfNP/ZkT2Av8z9I69203k3rsmDmd7FM F7KOs/Rwih2LJdqvDXWgJbSCy8m7K7OAPXZPAvQXoL8A/ZXSXxb97aC/HfS3A5kosu8xbWLukSZy k4xyX5X7YDRMdt+Wqez7o/AYTIPpsN+dJwVQCD/Y72ybK2fhHJyHC+5c1dLdqlpBa2gDlwG5oroC 2kI7aA8doCN0giuhM/wOusBV0BWuhm7QHa6BBLgWroPr4QboATfCTXAz3AI94VboBbdBb+gDiTBW aqv17ufqC3eF2gAb4Uv4Cja5a9XX8A18C5uxME2lhpspNQEpk1oQC7WhBbSEVtAa2kAvuA16Qx9I hNuhL/SDO+BOGASj3NfZ8dfZ8dfZ8emS6r4hU+BBeAgehqlEEo/CYzANpkNzeZ544AV4EV6CP8PL sADeh4XwAXwI38Jm+A4yIBO2wFbYBmRssgOyIBv8sN9dxjkv45yXBb9x8xshbpdTUAblcMZdwtkv 4eyXcPZLOPslkiKOXCIhUAVCIQzCIQIiIQqioSp0lVi5Gka5j7IPj7IPj7IPU9iHcezDOPZhHPsw jn0YJ4/Qw1R3PHsxnr0Yz16MZy/Gy0ypJrPgCXgSZsNT8DTMgWfgWVgpDWQV7HensrKprGwqK3uJ lS1kZQtZ2UJWtpCVLZTTzPiMO43VTWN101jdNFY3Tb3mZqv58Dq8CW/B2/AX+Cu8A+/Ce7AA3oeF 8AF8CB/BIkiDxbAElsLHsAzS4RM3W7fDj7cnp+7ENQFucR/VPcncekFfXo8lJx/nJuskSHaTg/8P nBr8f+BUk0q2NIXsaauEmG0SY3ZII5NNvLkTy72f6LQAe1ooLc0Brge9b5XjegQ7pM0Wau/nRLyf vE+U1JZTnGgUJxrFiUZxolGcaBT7E8V5RHGiUfZfNFSFGm4OmpKDpuSgKTloSg6akoOm5KApOWhK DpqSg6bkcPo1Of2av+m7q0e5Y5CUMUjKGLmfmGosjIMkSIbxMAFSYCI8AJNgsjsWqZqIVE1EqiYi VRORqolIVA8kqgcS1QOJ6oFE9UCiIpCoCCQqAomKQKIikKgIJCoCiYpAoiKQKO9vUOehg3noYB46 mIcO5qGDeehgHjqYhw7moYN56GAe0heH9MWhiyXoYgm6WIIulqCLJehiCbpYgi6WoIsl6GIJuliC Lpagi97fzn0AiX0AiX3gN3539CtI9wKkewHSvQDpXoB0L0CyH0GyH0GyH0GyH0GyH8Fm+7HZfmy2 H5vtx2b7sdl+bLYfm+3HZvux2X5sth+b7cdm+7HZfmy2H5vtx2b7sdl+bLYfm+3HZvux2X5sth+b 7cdm+7HZfmy2H5vtx2b7sdl+bLYfm+3HZvux2X5sth+b7cdm+7HZfmy2H5vtV7dLrOoL/eAO6A// V98Hud5Nx1eswVeswVeswVeswVeswVek4yvS8RXp+Ip0fEW6+k4iFDmdyoQt3nskiHHbQyfw3s2R wLXyHR2Po9F90Og+VqPvJpsZBWPR8Is0W4+3n/HsjnaPQ7u7o93jiDv+ZCaTsa92N5h1UtV8gQXY QuyyjWhih9RG04vQdGN2EctUansI2t7U/vW9Iu4fwRpuEMftLyFQBUIhDMIhAiIhCqKhKlRzr0aD 89DgPDQ4Dw3OQ4PzpCvSdDX8Jg2Wu+U+GA2TpYukoklT4EF4CB727Ly0kUfhMZgG02Gme6PMgifg SZgNT8HTMAeegWfhObfb/+Oz9D/zNyndd2QVfEv+sxm+gwzIhC2wFbbBdtgBWZANftgv/aQACuEH 6SAnsI8n4RSUQTmckWZyFs7BebggzcgfMskfMskfMskfMskfMskfMskfMskfMskfMskfMskfMlV1 9y/qEqgBNSEGakEs1IY6EAd13XdUA/cD1RDioRE0hibQFJpBc2gBt7uLVV/oB3dAfyDfUHfCXUDe oQbBMOmthssdaoQ8rO6VG9VI6aZGyV1qmrtKTYfH4ffwB5gBM2EWPAFPwmx4Cp6hr7nuNvU8vAAv wkvwZ3gZXiEDb+cO0J2gq7tXJ3C9gestMlD3lDa6F/R1B6Il+9GS/Xqs3KnHSUudBMkwnnvB9wUQ W19PbH2dWeUuMOvc3maf+w1+LMYUEMUfIJs4RE52WOqZIvzjEbdMxYlTcVpCoAqEQhiEQwREQhRE Q1WoVrEdH7cGH7cGH7cGH7cGH7cGH7cGDUlHQ9LRkHQ0JB0NSUdDpqMh09GQdDQkHQ1JR0PS0ZB0 NCQdDUlHQ9LRkHQ0JB0NSUdDqqEh1dCQamhCNJoQjSZEownRaEI0moB/gifgSZgNT8HTMAeegWfh uYqNMtfdjjYkoQ1JaEMS2pCENiShDUnyCs/mwXx4Hd6AN+EteBv+An+Fd+BdeA8WEIm9DwvhA/gQ PuL+IlgMS2ApfAzLIB0+gU9hOayAz2ClOxOtmymr+XkNrIV18Dmshw2wEb6Er8AHm+Br+Aa+ZdzN 8B1kQCZsga2wDbbDDsiCbNhJm13g5+fdXHMgF/Ig4K6QfPge9sBe2AdniHTOwjk4DxckDM1NQnOT 0NwkNDcJzU1Cc5PQ3CQ0NwnNTUJzk9DcJDQ3Gc1NRnOT0dxkNDcZzU1Gc5PR3GQ0NxnNTUZzU9Dc FDQ3Bc1NQXNT0NwUNDcFzU1Bc1PQ3BQ0NwXNnYzmTkZzJ6O5k9HcyWhuCpqbguamoLkpaG6KGspc h8k1wb+p0BntbYP2tkF7r1Wj3R1qLJI/heuD8BA8DI/AVHgMpjGv6fA4/B7+ADNgJsyCJ+BJmA1P wdP2vZAp6lmuf4Tn4E8w152J1s9E62ei9TPR+plo/Uy0fiZaP1N9Sp3lsAI+g5WwClbDGlgL6+Bz WO8W4ocL8cOF+OFC/HAhfrhQ+bAgP/9JnYMqAzJhi3sQCxOJhYnEwqzCwkRiYVZhYarpvhXlWJY5 WJY5WJYIrMkcrMmdWJM7sSZdsSbdsSZTzBp3tVkL6yqKzXr3U/zuLrPB/cpsdJ/DyszCwpw2heTw B2hzCB99GF9b5L6JlfH+wuVMNwGtTUBrE9DaBLQ2Aa1NQGsT0NoEtDYBrU1AW9eirWvR1rVo61q0 dS3auhbNW4nmrUTzVqJ5K9G8lWjRJrRoE9qQhjakoQ1paEMa2pCGNqShDWloQxrakIY2pKENaWhD GlqQhtQXIPUFSH0BUl+A1Bcg9QUm033XbMVGkhma7e5Is8NdabJY3U43l4gigJ+eWXFKZsET8CTM hqfgaZgDz8CzMNf1sZq+rKYvq+nLavqymr6spi+2x4ft8WF7fNgeH7bHh+3xYXt82B4ftseH7fFh e3zYHh+2x8cO9GEH+rADfdiBPuxAH2yPD9vjw/b4sD0+bI8P2+PD9viwPT5sjw/b48P2+LA9PmyP j10bxa6Nwvb4sD0+bI8P2+PD9viwPT5sjw/b48P2+LA9PmyPD9vjw/b4sD0+djuR3U5ktxPZ7UR2 O5HdTmS3E9ntRHY7kd1OZLcT2e1EbI8P2+Nj1xOxPT5sjw/b48P2+DiFGZzCDE5hBqcwg1OYwSnM IOZfTsy/nJh/OXH8e8TxacTxacTxacTxacTxacHvs80ils8ils8ils8ils+SCvctcd23lIBy3+JE BxEfZnKqr3Cqj5rtFRWc6l841Z7Eip9ysg9xsq/JMTK9ODK9ODK9OCKXOGxeHJleHBFZHJleHPld HP4njkwvDt/UCU9YiCcsxBMW4gkL8YSFeMJCPCHZJbSC1tAGuko9sr16eMJsPGE2njAbT5iNJ8zG E2bjCbPxhNl4wmw8YTaeMJts7zqyvevI9q4j2wuQ7QXI9gJkewGyvQDZXoBsL0C2FyDbC5DtBcj2 AmR715HtjSHbG0O2N4ZsbwzZ3pjgX41tRcbXioyvFRlfKzK+VmR89cn46pPx1Sfjq0/GV5+Mrz4Z X30yvvpkfPXJ+OrLc9IWid6LRO9Fovci0XuR6L1I9N5/8S3XHcn6OiIxfiTGj8T4kRg/EuNHYvxI jB+J8SMxfiTGj8T4kRg/kuJHAu5BAu5BAu4h68sn68sn68sn68sn68sn68sn68sn68sn68sn68sn 68tHWnohLaORltFIy2ikZTTSMlpOk2mfcTsiLR2Rlo5IS0ekpaPSUkUZcCAEqkAohEE4REAkRHuf scKr9IV+cAeQNZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCF ZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZZCFZWD9p2H9p2H9p2H9p2H9p2H9p2H5p2L5p2L5 p2L5p2L5p/5MFhZHFnYpWVgc1t9PFhaH9feThfUkC7uKLOwq3ZvMrK/E4wn8eAI/mdhYMrFEMrFE MrFEvIJfTxCjP5TaerFo/RnXlbDRvVd/6S7TX8Emd57e7MbqfLlSnyJ7KyOuLYcL7lATI9VMW/c9 095dZDpAR+jiLjZrJIosri3e5GO0dJPZitfYLqFo5idkcSFoZgXeJYtM7tFgJmeCv7cxeJmD5jAe poj7R9yj5FIOXiEEqkAohEE4REAkREE0VIVq7mri01zi01y801K801K801K801K801K801K801K8 01K801K801Kyq40/fmPcb/zMWC6xUC6xUC6xUC6xUC6xUC6xUC6xUC6xUC6xUC5xUC5xUC5xUC5x UC5xUC5xUC5xUC5xUC5xUC5xUC5xUIA4KEAcFCAOChAHBYhZAsQsAWKWADFLgJglQMwSIGYJELME iFkCxCwBYpYAMUuA2GQ3scluYpPdxCa7iU12E5vsJjbZTWyym3hhKfHCUmKFpWQfnxET5BAT5JBV DOBEivH35/H1SzmFYnx9Ir7+vCmrOGTKyUBOu6HmTEW5OVuRa865Vcz5ioPmgptgKrjvunFOSMUh p4p7vRPqhjphFeVOeEWuE+FWcSIrDjpRboITzf2qLrkJPngplrrIZMsVxvv7g7dgweZjweZjweZj weZjweaj2Tlodg6anYNm56DZOf/ff8eW95kYn/3LAsVocDEaXIwGF6PBxWjlPLRyHhq4Aw3cgQbu 0O+6h+w7Iir/r3wvmrUXjfKjOfPNFmmIf9uD1jwrmpNZhF7MQeNWyVVmtQw1n0sns17qUHeF2UD2 t1FamEzpQ7s+Zhvas12uMTukhsmSDvTxPZrXQMLMPu7ul9boWx/0rbk5JDfR74bg70vbMNIX7kfU f9GOuZRn49DK1VKVe9/waou1mf/0zRBqrCRwslukPafajRFuQ356Ml7lnfZIVzl3r0e6ViNdRfZb fI6IYpT9Up9X19jfz9ambjPG8/766QG5nBpX8GqLJLCaGJ41YF3eZ30GuhkmVboy1w1Odzyg5s7X vNpM7bVugFi2lFcBXiVLNK/O8uprqUE0kEA0kEA0kEA0kEA0kEA0kEA0kEA0kEBPCUQDCUQDCWaA 1DKDiSWGQTJrWk28sZ74+AtsRZjtd5V7krsBRjxgPmeH16NJX7jLiaCPMM9U5r+KPtZSi5kxz2ip obZKE7VN2rGKYcz5BjOYWpXfD3G5/X6IZPcL77Mg5kF3n3lZOptX5HeMU8IJNENLFztXSQenq7Rj ZXdLA1o0YJxO7HyqxDPSUW98O1I0IxQywiYzhNZDqT+c6wiuqZz8Vnc3cVMxMdMZe647JYxW+Exa eLVjqRlLzXBqllCjlB3Zj6ZiH/De571PZdn9J9ciFivmhKqh1dtsf1nsdjat6NOz9PQ5wD3kvc+R Fq2R0FBbO9s9Sbx1cZ9DkPvhMJ65p+JBtrjHGb2UeZZw+rXo+xStvqLfSPo9TTmAPRoIqUh5Jju+ hRpbmc02dnw7c8+mh8pZnEd+B3B3oFtmv6/f+67+STxJlThahjOjKrQso+V5WkYzVoW3alqe8/5/ RW6WAiiEM9KCDLoFGXQLMugWZNAt6HkQPbczQ9DCoXKPGc51BNfx5B2TmM+D7jvmMc71ZenCeXZj x7YyYle7t9vdN+xoWe5O5DuGyPVs8Iw7sAcDmMNA9nQIDPW+SZ/rCK6pUpd5e9oVxnwjmOtBs0uq 21NfQ4sNtCigRV1aFNCiLi26ULs6Yx6wJ7/dPce4p2lZYFtl2e+wr/xUU3zwU03xZgrWYp80xhKU oo8RWIw4LMYl2IE1yFzl/udQy3CnlH0cwE8DrWzabzoykzn1h7BpB5j3IUY87JZYedhDuwLaRdB7 GD1rnuQw/1HucaLj40THx4l4j1Pz/I/fsEjtUFt7P6d8gJ06yJwOE/MX0csRtxj5rW1Peav9ft3B zGsYTGbGU7Bz+9jj/ZxwAdJpV4I9OsT6D7vfeb8zs2OfY+xzjH0uuLLiH98zTS+aXlozfnV6KaeX CnrxvpMsjB72MgeNnIyS2+Q+GA1TpYc8Co/BNJguPei1Gr1eFvze0b7B7xvti86/z04tY6fWIieb kJOeyMlt5kP3eea9GWvYvHJE7LE34iE3Bxnpiox0dboTV4fRc1nw7HTw7LTdL2+lh71PNlJjMWMv CNaKDdaKZewSanawmf5h769Lm+SKjfj6o/j2Pfjyo/juPU7LikLOO7mihLul3Cl1WrrX0GtyRb4p Yz/O0fo8+nXBzXRC3HL8/mkn0j1JzUxq3mTbfsHTbdzZxp0I27bEnGW8c6zsgptNDFHhEJ3TtoJa 2cQKFdRMQLeTKw4wSgVRyElmVmzOcD3HqOeRjsqW5xm1gujjJDMudsK4RjCLSO5X9nSeFZxCOpKJ W8pF0UspvVTQi2u8d5h5Y1cRRetSWlfQ2qXloeAcWnn7VDGXOeyjdRNa59K6zJCl2tmfR94uIBkV +DXXvcBc9tFbE3rLpbcyJ9zNsquKdP1OlFQnEiqi5wvMKc3zJK6mx9PMI2AqRNPqNGMHnGh+buk2 8mpUbKHGQcbzdiqHGgfp09ulHPogx/3peXH6wXOi9S+cj61rz4W6v3AerPE/PAds2m/cfzT9v7zv rPFf7Ld98rP7LFWdGAl3ajG/OhLh1KW3erSpj9+8lJ8b8KwhzxrzrCmvm/GsOc9aYFccJ5YR6vE0 nmszziTKieFVLbfEqc34dRmhHiN5fTXgfkPuN+J+U+434z79cApebW/kesEa3kheXzWYl+ZpoRPL ndpQRxowvxrULKTPBsxPMz9Nq0InnueNoDH3m1KnGfea83ML1l6VXgLM1VuhduKYa10JCfbitQ4w f2+F2mnCs6Y8q2ytWW8M1EL2YplzHfqty1rqcfr1GetSb108b8jzeJ435nlT7jXjeXOet2B9rIKz qUW/sdytDXXcncyhgt3Z59TnLC9lzQ2o05A68TxvBI2p04Q6TanTnDot8C7eOUXZfa0jMczD27HT zCOGeUQyjyi7t4153dTu4GnmEMMcIr1TEWPXXje4z5Wz93bP2HVXtigNzlpLtX9XJtDaEvbvJ3KB treV6N8qG7RqJ6H/Sj542kxq/rdkhN4uY9X/ppzQuqVc8p/KCr1c5a3ovyMvnMS39hz/LZmxviH6 t8qNteotyasPY0mHY3HqY9V6k1eXYtVuJK8uwvqMwqrFY9W6klcfxqIOxxrVx6r1Jq8uxardSF5d hGUahVWLx6p1dWIqytiRy9mRVuxIK6cOr+Pcy9iRqsyqPbvSnF1p5jTgfkPqxVOnETTmdRPqNaVe M+o1p14LpCac7CWKvCOBLDOa7LImEWcM0WZTooouxApfEXFVQwuGklVdLiJdyZtay3X8aye95A5p L3fKXdwdRDzUTe6XZ+VWeU4WSYoslhX8tErWyTxZz783ZKPslDfFT4S9TA6qWrJe1VP1pFQ1UJfL MXWb6q1EJar+SqvBaqgKU/eoUSpKjeVfDZWsJqiaaoqap2LVa/zrql7n39XqTf51Ux+oD1V3tV5t UQm6ne6gEnUn/TvVT3fVXdWd+hqdoO7SN+geapC+Sd+k7ta36F5qiO6te6vhuq++Q43Qd+qBapS+ W9+txuh79D3qfj1K36fG6jF6jErSY/UElawn6QfVJP2wnq0e0k/rP6rZ+k/6ZfWsnqdfVS/pd/XH 6mWdrr9S7+pNeqdaof16v9qkD+kjaocu1cfULv2DLle79Rl9Tn2vXSNqn9HGqAITaqLVAVPN1FBH TYyJUcdNrKmrfjANTUNVbhqZxuq0aWqaqbOmhWmlzpvLzOXKNW1NW61Me9NBa9PJdNaO6Wqu1qGm u7lGh5trzbU60lxvrtdRpofpoaNNb5Ooq5r+ZqC+xAw2IzXxjhmv480k85BubB4zj+mWZrqZrluZ l80rurVZbBbry8wn5hN9uVlhVugrzEqzUbc1mWaX7mr2mSO6hykzru7jhDhV9UAnxmmp73W6O931 Q0iKggjVtcq3YkY+MilZYsZMui9JJiSPSJ0gr5GLqzv6XR9P/iOua99dV0XqSSOy99ZIVick6gZJ lAH00VPulhEyJlgvmoy+vjSWmtIG2btSribqvh0ZVMjdELkXCXRoU1m3Kj7nUmkiMXIZ43RGPm+U vkirRnKHykgZi9/W/RJ7x0u3/v16xcs4264m8h5OnF9HmkotZP530l2ulZukn5DzkAveJsPIASrr YuVYSUOJk2YSK1dIR+ki16AbN6MZg5hJS+kt95AtJAV79t5JGC91pTlZTFu5Cl26Xm6R/kKuIK2k jwxHi5Jl/MgOk0fqubZ8zZbv2nKxLT+z5YaRI5JT9Xe2zLJlni0LbFlsy5MjR0y+T5/3SqNtGWbL qraMsWXdkSPHTzTxtmxuy8ts2cGWXWx5zajksWNMD1veasvbR01IGW/utOUQW95ry/ttOcGWqaMn jRhpptpyli2fs+U8W/7VlovobIRZbss1ttyQPGHKePO1LTNtmWXLHFvuseWB5JSRyabYlj/Y8qxX OsLDSU4VW0bZsoYt69iygS2bpnBxWtuynS0727KbLa+35S0pk0ZNcPrYsr8tB0/07g+35WhbJtty ki0ftuX0yey5M8uWc2z5gi3n2fJNWy6YPHbCaGeRLZfZ8jNbrrPll7b8dvL4kROdrbbMt2WxLc96 ZUiYLWMnT7l3ckhTW7a2ZTtbdrZlN1teP3nKxMkht9iyjy3723KwLYfbcnQqMw9JtuUkWz5sy+m2 nGXLOaiTQS9roxH/zk/a+2Tsb7gqdOGXS+dXlPX/qYz8xdJgM8LR6X/nJ4UF+2lZ/VeU2q5e05P3 SgVtp1eG/Yqy2q8o6/5TWfVXlJfYeRl7VReV3nwvvhf1i2UIti8Ga1opEf/Zq9jgq18zrsIy/3IZ /QtlY6x/H3zMMKzzBHlQpsuTRDYvE8ssIMpZToTjk0xim3w5ICVSJhWqiqpKnNJANVdXqM7qGnWT 6lN5rqp68Fo3eI0PXjsj/d61W+VrHV/5Ws8Nvt5aeTV1K++bYH1ze/D+1OD15eA1s/JKVFp5DT53 PgxecyqvIZ0qr6Hv2lNV4XmVryM6B6/XVo4TcWvw9Zzg9XzlNaplpa5F5VVeq1WpvF/t/uD12+A1 K3gNjlutjPEiYKT6s9WAe9VLlGGsdL6nA+qUl6uKY240N5tbTE9PP3QNXQPhi9GxtgV1TVWvrolG RhWno7A5lbpDXC5R6pg6xstT9KXUWXVWtHKVK0aH6BBxdKSOlBBdXVeXKrqWriWhuq4mS9GNdWMJ 1y11S4kwPRk5kr5qs7oZ3rRVNXlc1VWXyu9VS9VSZhGpDpEniE7Hy1MqRaXIHPWASpVn1Bw1R/5E tPqqzCUivV1e0Kl6iqTrh4iNPtVT9VRZrqfp6bJCz9KzZKWerWfLKv2SfklW61f0K7KGeHKXrDXR rPE40V0nOUEs10NOMpvLpKZ+y9xmEs1oM8aMM0lmspliHjKPmGnmKfO0mWOeMc+aP5o3vF3Qb+o3 MVK9TC92qo/pI9qMMveJMfebsRJC7DdJQk2qSZUw86B5kHzgYfMwKycalEiiwZlkB/PNfHbWWNvx 9z1u4J2Cvlp7ZxOq2+v2nE1njdzoq/RVPOmmu7HXPXQP9vpWfSt7fTv7UIXaddjfdvpK3YXWN+ie OlF31724H/7re9Ez9AxGfVG/iBxo8XKyBk5DJ95p5DR2mjhNnWZOc5u9K7OKrEbs7OtcNPuGVnKS vRqOl/VW1qh/UY34i55p7/+YqC2Oly0qp6XT0sqFN26MU8uJdWo7dZw4p65Tz6nvZYV/G1cTRVZz ajg1iZGrOKFOmBPuRDiRTpQT7VR1qjnVnUuo47DTjzMFr40mgr6GbPQ65zo0QBO31jELzEKzyCwx X5qvjM9sMl+bb8y3ZrP5zmSYYnPUlJhSc8wcNz+YE+akOWV/x/WeeY8e3zfvM5ePzEecO/E86/DG cLzo/W+9v0etj3i6yqw2a8xas858btabL8wGs5F6+02BKTQHzEFzyBw2RbTzel9gFtD7QrOQ3heZ RfS+xCyh9y9NBr0XMwev9yvIJX+u159Zh92zfbSTYLufGflfrNXb6wzbrrFUVQPUXWqQGqjuVPer 7XqKnq6f0n82r5kPzDLP5qjbVX8OeIwaIyFqq9qKLKXqVGRpmp7mfY8Zehhu9TDCzDPz0AFvB6PM x+ZjPIFWZXJaZsoseQIfMFuekqdljjxD1vtHPMKfZK48Ly/Ii/KS/Bn/8AqZ76vkOvPldbLfN+Ut eVv+In+Vd+RdeQ/f8b4slA/kQ/mIfDkNT7JElsrH5Mbp8ol8il9ZIZ/JSjLo1bJG1uJlPieL/kI2 kEd/KV/hczbJ1/KNfCub5TvJwANtka2yTbbLDsmSbPzRLnLt3ZIjuZInAbzT97JH9so+2S8F5OAH 5KAcksNSJEekWI7iuUrlmByXH+QEVuYUfqyctZ6Rs3JOzssFqRDXM8zky/30Hbq/HkDOfJceqAfp weTNQ/RQPYzMebgeoe/VI73sWY8me76f3HmcTtLJeryeoFP0RP0AefFunaNzdZ4O6Hz9vd6j9+p9 er8u0IX6gD5IxnxYF+kjuthE6KO6xER62bM+TvZ8Qp/Up3SZLtenyaLP6nP6vL6gK7xc2igvlzaO CTFVyKfDTLjpa/qZO8h3h5ihZrgZYcabB8ws84R50sw2L5pXzetmKee6zKST435GbptptpitZpvZ bnaYLJNtdppdztVON6SmVqX9t5b8cWuZ3za3YlGzyKn7yE6y6bvFb4aZeyTH2ok8M9FMlABa/QfJ Ny+YF2Sflab91pYWWN0stJJ1ALn8QA5aDT1kNfSwWW5WSJHV02LnKqcrJ6HVOs7wf0fu/lHq/rdk LvBfkbp/lrsfJe/nZe/v0ufJ398l8G0rg/83UviqJz9Kq1pYnbrEDDHWAjWxkUNLNUzdJ22sNero /aZLOqkkYokriSWmShf1GNFRD/WqekOGqU/VFhmpJ2Gfpuun9avykvXs75koU0MWeL81kjQTa1rL YnOZaSsbTXuihU1W6nLxZ13xvDXwgA2kOfFDJ+b0Hv+8Ep9gf15sX60NvlrLqwD/vHfZtVFtmPsV 6goOoovqgjTerG5mqb1UL3GIceYRmVdGc4v5R1SghqrRwTvLL7rz0wiikY0ghuhxNoLop/uhYXfp u/D9g/VgngzVQ/H99+n78P1JOgnf/4B+wEYQjb3vZv2HCKIvUjGIvkZx3hO92PE3xBLeyKF25DA7 crgdOcKOHGlHjrIje/939JLcrHaoLJWtdqpdyq92qxyVq/JUQOWr79UetVftU/tVgSpUB9RBdUgd VkXqiCp2jOOYMlNuTpsz5qw5Z86bC6bCuP/JPYfNd7y8sS7SpW10Wt3LLMgtDLlHAx57MWoI8sYq kbfBEso5eO+w9yQtnKg1GX/oRa3/U621gEO5te33nRlnchYGDUnO3nGIIodIOpAzO2djMJHRGGfF TOVQSSWKDgYREUk6SVESonMKlfbOqZJDhaT417wke7f3t7/rv/7v39dnrlnPrLXmfddaz/vc93ru ZfjgcDgCZMzb4G1gB02BUyBBeA+8FxKC98P7IRH2iSskCiKwCkRvLVwH4rkBvg0thFvgFkgKzV2k 0T1YBt3BETSDsUAzGEswvxVghv8Ln83i5h9cGYgcVTRn2ARQ83cKsAWw4DPAeN2A24YBj30Fc+cG OlAMzJsAlKA6rA3QYwxbwOtgVbAOZbAqDdRuAphiWw94OWo94RWo9YINUesNVCHb+sArUesLG6OW BJug1m/OmqHWH7ZALQW2RG0wwCnbUmEVgERBgGYMqKlD7HN2TRSbWqD0hBFQesFEUHrD2qD0gXVA 6QsDtgBj6YHSD+hUDEyG9UHpD68CJQU2B2UQvBqUwYAVMGAUK1CGwkAXAC20DpQ0eAMos4EGxsBH YWtQHgOKCoEMIFPICrKFXCFvKBAKhaKgBLCz7QMYywY7ViHYnc6B3ega2Hma4dNgBdlg1iWo9YBL UesJn0GtF1yGWm+4ArU+cDlqfeGzqCXB51DrB1eilgyfR60/fAL1RQ7qBRbqhVzUC3moFwpQL+Sj XjiJeqEQ9cIp1AtFqBeK2WtDOU4ZtTYgV1gAKUPakBF6NrQARJYE6uuFqI8kZ7+Pg6XmPgWyPYme gPHDmaiv0JKtDGAhEPsQLA72DxiNcQwauVj0tyj88Ag8Bk8CEuDE8GOEMRIYPGYxRgXVy/+X+hcw OarRfig+brYKmtNQ/0IHzSko9j08McFznM/eAdhnNBJoL6jhvKHvJ3fQ7PnX3GkY3gJYsZlmvBHC xBtw8qgmWiWOC8BcGBYTrwKalmBgmMiH8HByqC3AYqQ5IMSHk1eNE8bBTH0MjGM5IHaI+rwWmTy5 BBnwkNivjZAvFAZRoWCIDNHB25j9QuTn3QwnJmifDUukqXrquq0XKjDxMXoQmSrHYop3IUxsPXhr sLCArDBCa65LZXSl2luaj3dusRIgnkQE5qYKc4BJMfagk8Q64ThFMZvMiOKIKLvCLcrvQg6jk2kh BHOfUDJRDBFhN3OJ8lmE03x9QiIowcFkoiC4G2jlFeV0DPSJpJOJsgie3cAnKjbTQDAn0+gUfwrJ h06hhhAXIbLsbqyoxGy3I2ULGMVnSyglJIBgbobILRRAdIjaiC6C/m1aKEBkV3W0dfSW6y3fhDjM m6yTA3EhIj4z/gJnMo3iQAkIUSesDSFpEtUQlZmBFL53oEMRHL6P5UCmRVBI5DD2oExYYb5XYA4I y4QFIdDOi2HCMFTcfO5kSyuhnHdbSmlS+PB5m5GuOsHrAT41+X4yHdUTzTolO5EU1+17O4NeLDsh eP3BQNSHyMLtVKPr6eUCVwI/BR9qrrHXKLFaOXrhiYcXHpPzRStI7uR4fnahdCPm1/gN9q8XeA+Y ymy/LPDS5Pb5rqQar5jNRE1sFkO0aA3hLjFMwEWjNUpXJ0MkS+Tyy0Ct072vb+zeq3pzj3ySf80O Vxdq+HWj00pJHs1C4kY5O9861vGG1E/dWvfiMpfwYYW4TuOlD+SiBnKITSO9ClKd9ZVrzLOlvVhy +7s9RwfjRraV+MJpo9Z8L+8rOBdltJYlR5QNXhH42G3dzpoMZJWJGVYm1VVjsCDw8xmdCOMZosvJ DSKWg4MLBoBDlBDF73UETpQMpNNDV2hpUUlhoZoRwO9hwO+aJOoWNHZkRWF4GseNcAKDgSHEjN22 CLcCMUCWsXRZ2onI7OUkWvDvrtaaiZX5oWJupgm+hUaq7BIcP8L7fRZYbmQBu1GQPRYOIIATzBDU hXEgMk9KIQu/xzdWlN/RwQwEmoEGUUNP5w+owDIY0LqgibeuNyxkiCnRWWqZ15mlcJvMhtazu11D urhV8j0bm9NF+3D2AkNrlmpBBme7m9Jtsh8r+IqPm+jLbwwlJozsMUiq7O8/DE3dc8q0UXxYvNQm puyij9lH1bt9Te2eL6rVdhlXHa9q/9Vl+tr5W9tH7/GfGD48pfbI0B6PN1g6brIOYHgaYWL6ZnEs 8EZt+PEzlWRJbQ4ez+yI5D/i+D+CjJ/hiBjMh6PLvzmoFqIxM6jS3w3K7iPT/haS52yVrV48CozZ KWnhH+6xvf5SDklpeqX5sThhA6ElTmHt4Usp32wuE9wf8U6w8KrvnZzlfZ7JdXZf1Qm6PfQiX5+8 D5/Of8FBzj3OX8+LY/fqqQibLoeEPAbheFmyex73eA8yMaigv2EV792uhkX1bU5vGCZV9vnqp+GY D3mnU/Wmcno9NnPkrAx6fT2zdqrFe8K0j4tl8Y5hF1Kg+uHCbiHl92nPOVmJttmx67gFENlmoRNB 429cy3DFplnnlPvTJEqNXjtQ1z/SO15F9ZOtzFSvXtkX/W5LzIREr9KZ8qEsh4um6hmXok9PPbYv UaFvXzWwXC5vs0TvL9WKgc+gBHOhpISgWUg2I4zb/0tI8s9BEoNAiM4MGNURVUSZpcRSTFT4KzDS w8I0SD4o/CRQ+LFv8S8QyFn7byFQ948IZD/lpKjQDht7mOD2KrqJidR/uyyVWXMAulnT2trwacGz 6QnrWh1fRPjWKB3/+OBLr2ME0Yq41ddsW3f0JSzccWppeoCo5WTzpSNm2Jajdm4ce+KLqB/xtnhF zQ+U1GCF8epmiYz3/PTawMj2d1m+SXVh+z+n0GMWl+QfiT1cMZ6mstVaMxxvZdYxXCVAcGyLZB1m kijfeO7tHg6v5jnaPiHspJTto30tBnM2NvFa3s09CupRD/Qirh4Mc5+43LtBnHdxS/fDx7qaa03F jQS9YxQbCvyHMu+FvjPu+ySw/fmDuPyIrZS6YxvXIHryFXnl0r5Gau37TqtyxT6TrHSP/e14AXXK KOUMwsSJAAr4MkMBglAdtMfIKFn4gfEYaaDLdL7HcIABQr9jm09UwZwaGk2jBATSCcokFQJx+XJ9 gjWFRKOGUf3pBHMqLVSTKIfIzHxZ/Pc9VNrMXi2PLJp5TJI/+u2pVDrBLJweSKVR6NFseliujxCJ CKI/Sw/aCFFbhzhb/Qdm9LdbOaamLrTX8IMNXjnncJQn8javOHWJ1+epjA35F6eO5xGM4+zyjual eWsHPVjlFz1YGtHk2PHh3bFEmbScnf6Vt4JifBe3yRq9FIQP9mfWX9fwz84OVMq6v0L9On+Vq1Kd ZR+vsUGmerHy8qKBtTtWvd4pWJ0d7ORTyozL9daI3PAm67yfYbatDJFbUSynuO+AmmTvyiMkMW9X DnKOrL590vipoUOYBvyj606rK1MSrq8YcDxkU/btVMwWuk25ZEsmj7I85LLfm6JfvV6Ey8h52m3y pD8vd+FDhrPL0AVDTwlGJK5j7FpZQsbU2db4tlPSNHej5qvD3PkKSCXnrqZKQqTorq5Z3ihCGAUI I4+NSxjHyEYYhxOE3O6HDlFoJxbbbRc7Z71v+k4u7f//+TH/JsZRVsjo56tN/XhYUu/9JVjxWaTw R3dv7ZwTfHeMOQ4kpzWt6JX/MOySrl7FWtPoO/T1aYuh4abiZY6UKcUtJk0tp19yxL0gpq7MEQrd XD0lslGSUvv1vvlr4U2EjW99Y8tPSzWq6S/RuEbOFdm9RJCUP+4oMyHf1Cb+0b40xFyb6xtz4eee gGABu7GaEfvbNX31yFcCkSdZNkNF2vqJLKZgJOEV9rzbp4oXjS6D5LW37R0vnMcqi0zvbxvmTtt+ 6fCtEn317pjuosjXESzo/maTuofLdr8yEynS24zf3Kn362MZXHfRalzjJh2DEGsZAd+LvHl7Hz1x NLFslXEqDO0UWZGUHp5z6iELsMJNkByUzyYGm/myNtZCsiXCHfWYXP+lV76LBNl/ihKQZSBf0CXq 6+oSddkJPKB47WXfKYFR+PuUQRQRnpEbvC4+YYEgFaCDcYTQLQSIDS57st8Waojf95nx/tXM/mqZ 2mDQn5a5GJGfWYb0/B4/Mpp8sLMRW1QUEH5mEgE2k3CjTHKzhZB6tWva2HYw5sZjxSVjEXflp1tV nW2aj11kntOL1oDqi7ifkJouFoy9qatrq9ibmcf1RfAC0z77HbOhRuhWUe1g0M59Dvhq2y9+cEqd xGNmIGQaZTEqYmAzSbJ79WXl5R79ii4S12LDraa6az4FlVmOLg2TU7izSkrO7oJ99qP8+6INUiZb Obd8yJC38Fr1vrYpy49wqU73a55Fb+w5Wa1LhS8/5XYdlRecciWaORlsL3ft6x74JXpJybiqlrCJ QZTxqvhTgd3bFQIX9q47WB9lYb8md+POlPSjtQGxb3kmE7HbxrK2Gqmd8j/S0qXxmxpGWlDXijxq JFI+kiQjq2RPbQGxh81nwqrAH0p/lodj/zvoRYSTZ1aAiwN+wWCxEA6VqLILcBI4sSWf1dZ7NNIc z/SMsVQXSkzWTTgwEKm5S8QwOH45XsgBCgdy3RwyQ/jQxAfVHZaI4FyCxYFggZmHS5TGSK9ffeS4 dPYtH5/uAybROMV39RPuUxM+5EZN7BcDK7N7VR+W7nj0+pazQ1GV1N2W3hHWhPMFq0NrFHuKFz2P eTwmESPS+XE/foDbo3LX/st7XatlWjIeZRzS+XTg5XTyUc/1a22XK60g4B31v25zF0+/+Vxm37CP vVEP13v/oeiBtLsuJHKG5FpWTBf5YpdS2VSjyIWGvJYGrz2hH5s7S5ghXM/JUpeLxhJv8Kw6MqJU SompqFM7ddZ/UUF5EnfQYdFLZ5dlyXHkixrk15YixlfknyKFzb4iMuUuqT0jMcJXPI349UfS6w4m 2+A2cbjfvtdW3P7rtgNRSyfPhxSkceq4VniqCgsiTA4dQGX4GRrj9bE8cQc9biH/dELx30IZP7hv ua6O7jK2WtIHuRGo6rGrCP0/so7Zfuxf9P9tStTKyDQoc8/7UNf18n5JRmqb0fFFe256JGp6DFfQ RktKkzdXdVQoxPI1NhasP+CpIPpmYnTx8apPIRFlQ4MnjW7X1/7iblJSGaajVOjL8InO9f0Ukpxx P+TF7ZyHJ+2EI3yuhO4m52ZKpJzyYNy38O/pdD5h2vz1eYSipgUC9bRti80QfuIqm9+/ka8p+Xle m0NWcDOpOWtz9kHPDdbC/VqP3Nw8vezzwzQKqneuFtgrJR5xh7sjuzBUvN96gPLN41xQ2nsVO32D PQ2Wa8UP2R45+ynw5NOXPFsD6Cci98ruCjr8ts9rdcur3q0CD0hQeizxyD6+86I1lfcHR7rkB4u9 fQb1zVfenEmJmPBB4JF9P2mXH2Qw2B5UHO7QunEQbyPFKZd/rOTeoW9/wXzF7NbFOEYuwjiR8Kcs kks/+U/w38/JwvoZ4WeBrEJMWcYso8QV84Tflu/3QZVfaBCF3aoVSqP6hZPoYVpsALDjH8S+NioI N85TouaIGWIyp0QxiTqz942MjPyz+5JpP9+Q/mea0KB9KMPgqPsRMQ/HEEoXprGvcvLRDeszWiXx jgId2hc+b+4VmJSXjjQuCIw5n7F9t/sH8/odR8nbkm3t4phiozvCnuZdc2/GhN5VCl541V6sIKX2 YnduS2748QNbV+JrnSHnqs87lTo8dSbblsR4ZncUTn76YCZd6mR5xur5AQNRV561Ix+JSYuu4va5 iZCxb/js7ufy786qaa8rus8tvkS+6oJLiswDt0S9guZvp5MGivVNLpoHvSaMrL66vezNiNO5XKur 5GsOuu1N/ZwkHGdUiO20VfXRt+abkjrP8CaM/nJLvbsn3m1dj3b0oMKug/walbZuDTdMXV1LHra+ 1qprHdiSox9NZOLuANq8jYFhhFH1X0OOvyP4H8fYLEY/Ija3oSrDRC4sB/rDU/Y2O/voebBE/vkn 52DqP2p8xAXI/F5xZPGPC3FEgNu23JwuLf71dlZbc/0FOnkl3+obf0Vo8y7hJ/ohviyDhGWQNUSB SBANoqKH7/4QHSJAluBTCPrJGSKDvjDwHXYLAdKDNCEEQnKVEhT/Mrbp0aHUAJpPaGD0H7NJHBOG 4jd12HgHTCt4XX24bpn7ZEOs4Ws1J8tSmnGsTfzlpyHZpWb11safOziyMSNVrl8CKzesT38r4n48 RWS16sLDUu7rjcW/pLjR3kue2sS5NkRNJit/hd6hphMHYrp84smH9vb3666VSuPuRt5mROdXyC4l 9Zx1LNnrkeGBlSoK1Lz32Pb4ojjX1VjruESCC0eUlg6n1qFfVSTKx8UlpUI+RV74uMFzksWPbbMe +1a++k3Szvg7fKH1qbixnc1HYha4+kefjJbe8MVowGSK8cZ56LeVdNw+zQIj0vDi55fOOlv20d55 S5IwkHO7Y35aLVMwvCd0wvGQge3tyYr+p1LDffRXTO9RsVwmSIuY8OSPJ8ZJZMIDoKmfHd4B/5FD zT85SuXn5J6ZAAawDOsXRHJ+7PH9+NcODEJvroeDKMje78EGr80+8iDqbwL8Oy/0RHBCtto1aifl uSMUlD6/kg+IivuTEEhvSncjF0ueejLkmnqEX52rJnagED9kgt9l53O+cXnX0WhD2fUHan7DUC4z Pg6cFFyUXSEbHM+XLye0jOeLjZrTlLnyllZj3PiZYNpr+40S0VvTBQb0+rZ5H7L0lKpVKdv3xffG geWVJTvJOoUvxzyCK98ePaYUmafS2i/NMIQL3tHsEeyYq2zL3XXTx31/DQrs1n1w5cq2FRoK7118 aTrnqGHdMrmuyOBvDuSGPYeN7rimZhc8xdeXpsnfMZSt0DG1Rajn+gxNzuBJY/F9PQc14yc+01+s wsN3Xh70O9h2qWHYbcdZT9ub0YzY3Veofuk9ZsqUgoDuMo9tCZaen1RVMVAM638A8L/7AQ0KZW5k c3RyZWFtDQplbmRvYmoNCjEzNjEgMCBvYmoNClsgMFsgNTA3XSAgM1sgMjI2IDU3OV0gIDI0WyA2 MTVdICAzOFsgNDU5IDYzMV0gIDQ0WyA2MjNdICA0N1sgMjUyXSAgNjhbIDg1NSA2NDZdICA4N1sg NTE3XSAgOTRbIDQ1OV0gIDEwMFsgNDg3XSAgMTA0WyA2NDJdICAxMTZbIDg5MF0gIDI1OFsgNDc5 XSAgMjcxWyA1MjUgNDIzXSAgMjgyWyA1MjVdICAyODZbIDQ5OF0gIDI5NlsgMzA1XSAgMzM2WyA0 NzFdICAzNDZbIDUyNV0gIDM0OVsgMjMwXSAgMzY0WyA0NTVdICAzNjdbIDIzMF0gIDM3M1sgNzk5 IDUyNV0gIDM4MVsgNTI3XSAgMzkzWyA1MjVdICAzOTZbIDM0OV0gIDQwMFsgMzkxXSAgNDEwWyAz MzVdICA0MzdbIDUyNV0gIDQ0OFsgNDUyIDcxNV0gIDQ1NFsgNDMzIDQ1M10gIDQ2MFsgMzk1XSAg ODQyWyAzMjZdICA4NDVbIDQ2M10gIDg1M1sgMjUwXSAgODU1WyAyNjggMjUyIDY5MF0gIDg1OVsg MjUwXSAgODYyWyA0MTggNDE4XSAgODg0WyA0OThdIF0gDQplbmRvYmoNCjEzNjIgMCBvYmoNClsg NTA3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDMwMyAzMDMgMCAwIDI1MCAzMDYgMjUyIDM4NiA1MDcgNTA3IDUwNyA1MDcgNTA3IDUw NyA1MDcgNTA3IDUwNyAwIDI2OCAwIDAgMCAwIDAgODk0IDAgMCA1MzMgNjE1IDQ4OCAwIDAgNjIz IDI1MiAzMTkgNTIwIDAgODU1IDY0NiA2NjIgNTE3IDAgMCA0NTkgNDg3IDAgMCA4OTAgMCAwIDAg MCAwIDAgMCAwIDAgNDc5IDUyNSA0MjMgNTI1IDQ5OCAzMDUgNDcxIDUyNSAyMzAgMCA0NTUgMjMw IDc5OSA1MjUgNTI3IDUyNSAwIDM0OSAzOTEgMzM1IDUyNSA0NTIgNzE1IDAgNDUzIDM5NV0gDQpl bmRvYmoNCjEzNjMgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzU2NTIvTGVu Z3RoMSAxMzkwMjQ+Pg0Kc3RyZWFtDQp4nOx8CXhU1fn+d+6dLbMkM8lknSQzyZCEkEAgYQmLZMjG EgLZBhLWhIRV1rAjIG6oUVwKLrhb64rLZBAJ4oLWrWrVWq1tbRWrtbQVd60b5P/e+80JYdHS5fn3 1+fpTd553+87yz3nu+ec+yVGSBBRPD4MVFNeP35swbq9M0hRu4g8jRWl5Q19vnzRSqJfgMhdX1E6 scz28OGXSfiTiMx9x5ZXVFK2YR7qX4te0sfWTK4f85S/gcToHUT3/mFsfbD001dsnST+uo4oyTe5 vqBw8YJ29C1+jfrNrUtaln9K6QaiuBoita11zSrfA9v3fk1U9jsio3Xe8vlLvvyy2k6U8CBRVMr8 lpXLKZX8uL8F7Z3zF6+fV7p57laicYeIHjx/wdyWtj9UPvAe+p+B8qEL4HDcbzPCxnioz4Ilq9bF v1m+mEgpJnIlnDm3fWnuM1l5JEwDiaJvWbystcVmHXkb0RHUsTy1pGXd8pyvs1rRHmMm39KWJXOz F0z+mIT7FdRPWL5s5apuD20lkXlIK1/ePnd591/eP0jkRXkfG2mxxd373TUgcXbMqC8oWRs20f6/ bnxR4ydKD0V9N+joyqiHzDfBjCKF+EI7Ex0l8ZR1EsovjXpI76nXZeineQwtdCv6v4BUtHRSAc0l 8ifhvgpKVYNZXIFSi3GnsQhdpjOrr9BWhSykxBgVRTGoiuEWUj4KkO8s2Xd1vc9HcHxr4DGYb1Ky fUQ3a2XqXmO0NlP0Hk3/lstQTi2n9H9A9/a21UPH2//wfb471l4xnH5fyjYy6+37/nAb0xt0r7Hf qesYJ1Lr6d5Pv1fm999LvY/GntL/PsX8I/c48TKn0xn/bFv1c6y+f/AyGOhW9QVacsqyuVjXvfvf crz9veOooVsN59Lik/pbd6y9+OCH+0K5S2pldKTfn3Eb5eCp25pMuO+Vpy4z3EPzTmfs8lKfPtaP eviEOEym8ads04RTsfc9t/FuPa37HaEM02gadsqy805+rupCKj/Ofp1mnO69esY3mHaqc2jaqcrM y2ia6feA4HLUbT7uft/SzNO5h7KCskzXUZbldcoy7IK+PqJHUdbptDetOb16x7WJwj3KTr6H1pfh 8PE+9SkacmL7E+ca8e2UWvwKZ/0/eam3HdfPzlPVMbXRzt73O2ksxad+Zt9bv1dfyvPH96tmUO2p 2hjvP96v3E8Zx/X5PmUYVh/vO+W9UccYRxnmKqzv3/z9+lodjHfH36snL/VGyjR2nfwM9bKbKfMk Xy41fV9fyr1UrvyRFiuTdB6ndNFY8QT1Ua6hfsqfabFo5Xck7MViFi02TEHd93VUaO20MvEl7IFU Kt4lv9ZGuYC86keUr7fbSl5lGJWe7tz+Wy+saxIv/adH8b/rf9f/rv9dfCnXC+v3ljXT4d626KZ+ ur8P7VeMdM2/cxxqIgnlbfKeNIaVeIcAp9uPsoQuADac5A/Q+cCGv1fvn7nMOcAo5v/fl2EHzVZe IL/6Ac0Bag1BylTfAA+lzWqYhoD1n+3w8/A44H6gHZgP+IC5wJlAK1Cn1yuj+fiZMlk9h2aoK6lJ vZey1QXUou6lpep4KlD3UNW/NL6+pz2+gacaH/KyceIr5BAhqlLuozHKm5Sl3IE18jZNV66kQuWd k8cnHqFmoPFfaavcSMXiCxqk1NEoZTz1VyaQW6lEm1oaqBRTpjKV8+fTrtfZ/Q/F8d94qRGk8m9t xDpYQrcN+u+lCslHBopFTppLxTSCAth9VVRDDTSVFtJyWotdcx/tpn0+p6/ct9y3zneR77JvDd3d aJtBfZHTaW3KaBxVUz3atNCZ1E7r0Sbc02aVb5Nv27fU3a3mqlMwnDR1es/40qRQnlYr1dHvznn3 vXe3vruV6F3tpwv+TdMA/bOUKmmivi7qaA7yzDUnzHQRsBm9B9V2tVFdrH6gHlY/VD9SP1Y/UT9V P1M/xyyTMO98KsCYR+EnR22mU2kWtQlFxAinSBHpoq+oEdPETLFYLBOrxRqxSVwsLhVXiOvEHnFA PCGeFS8aVINBHDQYDSaD2WAxRBmsBpvBbnCIPDFAjBXFoopM+Mlduz458XdlsJXIb9YU+uEr0lKd cNzj3KyerfP3z5LUqb3qX68Tz1y75OypZ/7ahRjovOoUwzgpNvD1ig6sXvGBhQj9nZn9H79waumX 9jT/fu3A2LbZs2bOmD6tqTHYUF9XWzN5UvXEqgnjx42trCgvKx0TKBl9xqiRI4YXDxs6pGBA//y+ 2Vl9/JneJLfLGeOwWaMsZpPRoCqC8iv8lc2+UHZzyJDtHzeuv2b7W+Bo6eVoDvngqjy+TsjXrFfz HV8zgJrzTqgZ4JqBnprC6RtFo/rn+yr8vtDPy/2+LjGtthF6W7m/yRc6rOtqXRuydcMBIyMDLXwV SQvKfSHR7KsIVa5Z0FHRXI7+Om3WMn/ZXGv/fOq02iBtUKG+/uWdou9ooQulb8WIToUsDu22ITWr oqUtVFPbWFHuycho0n1UpvcVMpWFzHpfvoXamOkSX2f+gY5Lu5w0pznP3uZva5nRGFJb0KhDrejo uDDkygvl+stDuRveS8KU54by/eUVoTw/Oquq67mBCBmznH5fxxeEwfsPf3C8pyXiMWU5vyBNalPs CRPKpSaMDSPE/DIytLFc0hWgOTBCW2ob2fbRHE+YAgV5TSGlWSs5IEvig1rJFlnS07zZn6E9qorm yPeaBUmhLXN8/fMRff07C98o94XU7OY5rQs0bpnb4S8v57g1NIYC5RCBlshcKzoHFqB+SzMmsVAL Q21jqMC/POT2l3IFOHzaM1hY36g3iTQLuctC1NwaaRUqqCjXxuWr6Ggu5wFqfflrG/dRUffBzsE+ z+4iGkxN2jhCCWV4KNkVHY1t80LeZk8b1uc8X6MnIxRoQvia/I1zm7Sn5HeGcg/idhn6HfVWmNsJ tWVlbebmLIuvUfGoTdrTgsNXiQ9/6SgUOPG4dFN7oqWjfI3CQ7Ia7hKpoanj+oGhZpWN04pUrWnZ OE9GUwZfPzAkT2RMxqyQpVdfTjh6xsT3+d6hcW1tQLm+irnlvQZ4XKfGyAAjvZ16nIoWi8iN0cKi Pc5xskjNws6FT0E3ukt7ikm+ENX4Gv1z/U1+rKFATaM2Ny3W+vOtqvdX1U5r1J92ZJU0HGdxeTFb IcpAsTSUMqzByjyPfKy6PVa3e8xxJxSPl8W+Dou/qr5D69wf6ZB82EGYtCl7fMslxbGDsTUrcbr5 K1v8SC8qO1q6urfM6egMBDqWVzQvGKH14R/f1uGvbxzl0cda17jJs0G7VSxViaqG0v75OHtKO/3i otrOgLioflrjPieR76KGxrAilLLm0qbOPihr3OfD4a57Fc2rOTXDpxlaT3UwLHp9z74A0Ra91KA7 dLu1S5Dus0ifoNYuhX1O6VPgM7AvoPu0Cw8paQFCjOO2wtemPZ6NTQs6mpu0zUUJeJT4FiHhH00h xT+6Uygme8jqn1sasvlLNX+J5i9hv0nzm7EwRIJAcLQzqaPZj3MKC6qRPIKXoqp16evq7m5ozPi5 53BTBpbaDGBaYygqD2e/MWsC6o3V0Az32NCW1hZtHBRs1Nqas8a3NmHZyg5RZXwoCj1ERXpAjUq9 jbYc0agVzwYPUG+/BUZoS1OoKU+7aePCJn05O0M0zj8Cj537NGZrNypo6oj1F+p7E1vBmnWhRlEY G9U3sscDEzdr4iCZ7Rh5qx9Frc0+RNtArfVY6nyWWj3smYsj0ZA9V4fVEykkbVpqls1hDUUNQIf4 1rRtgLYljVnmpiYevG5dGKmAeztDNowou1coIw0QHRSN18aC7wsxVK3qE1o3tV1U51+Hk0UbtN6T GcUhR9b4Fhz+3N4Gj79YNrZoZ4Qt0sdT7DVrM7cj7mpWQ1f3nf71Gb2u/vl+7eWgLUzy7MPCpqaO Ex2h6Xn98y0neh26u6PD4jh1A46XxdHDmtNXgbcGUThK9XUp5z8YlSQmQJwnxblSnCPFFinOlmKz FJuk2CjFWVJskGK9FOukWCvFGilWS7FKipVSrJBiuRTLpFgqxRIpFktxphSLpFgoxQIp5ksxT4q5 UrRJ0SrFHClapGiWYrYUs6SYKcUMKaZLMU2KJikapZgqxRQpglI0SFEvRZ0UtVLUSDFZiklSVEsx UYoqKSZIMV6KcVKMlaJSigopyqUok6JUijFSBKQokWK0FGdIMUqKkVKMkGK4FMVSDJNiqBRDpBgs RZEUhVIMkmKgFAVSDJCivxT5UuRJ0U+KXCn6SpEjRbYUWVL0kcIvRaYUGVL4pPBKkS5FmhSpUnik SJEiWYokKRKlSJAiXgq3FHFSxErhksIpRYwU0VI4pLBLYZPCKkWUFBYpzFKYpDBKYZBClUKRQkhB ESG6pTgqxREpvpPiWym+keJrKb6S4m9SfCnFF1J8LsVnUnwqxSdSfCzFR1J8KMVhKT6Q4q9S/EWK P0txSIo/SfG+FH+U4j0p3pXiD1K8I8VBKd6W4i0pfi/F76R4U4rfSvEbKX4txRtS/EqK16V4TYpf SvGqFL+Q4hUpXpbiJSl+LsWLUrwgxfNS/EyK56R4VopnpHhaiqek+KkUT0rxhBQHpHhcisekeFSK R6TYL8XDUuyTokuKvVI8JMUeKR6UYrcUYSk6pQhJ8YAU90txnxT3SrFLinukuFuKu6S4U4o7pLhd ip9IcZsUP5biVilukeJmKW6S4kYpbpDieimuk2KnFNdKcY0UV0txlRQ7pNguxY+kuFKKK6S4XIrL pNgmxaVSXCJFhxQXS3GRFBdKsVWKC6SQaY+QaY+QaY+QaY+QaY+QaY+QaY+QaY+QaY+QaY+QaY+Q aY+QaY+QaY+QaY+QaY+QaY+QaY9ol0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0Lm P0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0LmP0Lm P0LmP0KmPUKmPUKmPUJmO0JmO0JmO0JmO0JmO0JmO0JmO0JmO0JmO6JstyaQNYfTR3uRM4fT40Hn snVOOH0EaAtbZzNtDqfbQZvY2sh0FtMGpvXhtDGgdeG0MtBapjVMq7lsFVsrmdrZuSKcVgpazrSM aSlXWcK0mOnMcGoFaBHTQqYFTPOZ5oVTy0Fz2WpjamWaw9TC1Mw0m2kWt5vJ1gym6UzTmJqYGpmm Mk1hCjI1MNUz1THVMtUwTWaaxFTNNJGpimlC2DMeNJ5pXNgzATSWqTLsqQJVhD0TQeVMZUylXDaG 2wWYSrjdaKYzmEZxzZFMI7j5cKZipmFMQ5mGcGeDmYq4l0KmQUwDubMCpgHcrj9TPlMeUz+mXKa+ TDncdTZTFvfZh8nPlMldZzD5uJ2XKZ0pjSmVycOUEk6ZBEpmSgqnTAYlMiWwM57Jzc44plgmF5c5 mWLYGc3kYLJzmY3JyhTFZRYmM5MpnFwDMoaTa0EGJpWdCluCiXQS3UxH9SriCFvfMX3L9A2Xfc3W V0x/Y/qS6YtwUgPo83BSPegztj5l+oTpYy77iK0PmQ4zfcBlf2X6Czv/zHSI6U9M73OVP7L1Hlvv svUHpneYDnLZ20xvsfP3TL9jepPpt1zlN2z9mumNcOJU0K/CiVNArzO9xs5fMr3K9AumV7jKy0wv sfPnTC8yvcD0PFf5GdNz7HyW6Rmmp5meYvop13ySrSeYDjA9zmWPMT3KzkeY9jM9zLSPqYtr7mXr IaY9TA8y7Q4nlIDC4YTpoE6mENMDTPcz3cd0L9MupnvCCTivxd3cy11Md3LZHUy3M/2E6TamHzPd ynQL083c2U3cy41MN3DZ9UzXMe1kupYbXMPW1UxXMe3gsu3cy4+YruSyK5guZ7qMaRvTpVzzErY6 mC5muojpQqat4fgW0AXh+Dmg85nOC8fPA53LdE44PgjaEo7HYSzODscPBW1m2sTNN3K7s5g2hOPb QOu5+TqmtUxrmFYzrWJayV23c/MVTMvD8a2gZdzZUq65hGkx05lMi5gWcrsFTPN5ZPO4+VymNq7Z yjSHqYWpmWk20yye9Ewe2Qym6Tzpadx1E9+okWkqD3cK3yjIvTQw1TPVMdWG3QFQTdit3WFy2K0t 70lh93mg6rC7P2giV6limhB2Iy8Q49kaxzSWnZVh92ZQRdh9Iag87D4bVBZ2bwGVhmMrQWOYAkwl TKPDsXi/izPYGhV2NYFGMo0Iu7SlMZypOOwaCxoWdjWChoZd00BDuGwwU1HYlQ8q5JqDwi5tYgPD Lm1vFjAN4Ob9+Q75THncWT+mXO6sL1MOUzZTVtilRakPk5/7zOQ+M7gzH/fiZUrndmlMqUwephSm 5LBzJigp7JwFSgw7Z4MSmOKZ3ExxTLHcwMUNnOyMYYpmcjDZuaaNa1rZGcVkYTIzmbimkWsa2Kky KUyCiQLdMXO8Go7GtHqPxLR5v4P+FvgG+Bq+r+D7G/Al8AXwOfyfAZ+i7BPYHwMfAR8Ch+H/APgr yv4C+8/AIeBPwPvR871/jF7gfQ94F/gD8A58B8FvA28Bv4f9O/CbwG+B3wC/dpzpfcMxyPsr8OuO xd7XHNneXwKvQv/Cked9BXgZeAnlP4fvRccS7wvQz0P/DPo5xyLvs46F3mccC7xPO+Z7n0Lbn6K/ J4EngED3AXw+DjwGPGpf4X3E3u7db1/pfdi+yrsP6AL2wv8QsAdlD6JsN3xhoBMIAQ/Y1nvvt23w 3mfb6L3Xtsm7y7bZew9wN3AXcCdwB3C7rb/3J+DbgB+jza3gW2xnem+Gvgn6RuAG6OvR13Xoayf6 uha+a4CrgauAHcB24EdodyX6u8I6yXu5dbL3Mut87zbr7d5LrXd6L1CzvOerxd7zRLH33OCW4Dm7 tgTPDm4Kbt61KWjbJGybPJuqNp21ademNzcFqk3WjcENwbN2bQiuD64Nrtu1Nrhm1+qgYbV79arV 6uerxa7Vony1GLhaKLTaudq3WrWvCrYHV+5qD1J7TfuW9lC7YWSo/WC7Qu3C2tV9YHe7J70SHNjY 7nBWrgguCy7ftSy4dN6S4CIMa2Hx/OCCXfOD84rbgnN3tQVbi+cEW4qbg7OLZwZn7ZoZnFE8LTh9 17RgU3FjcCrqTyluCAZ3NQTri2uDdbtqg5OLJwUnwV9dXBWcuKsqOKF4XHD8rnHBscWVwQpMmVKd qb5U1akNYFIqRkIeUTrQE/Ac9HzsMZAn5DngUWNjUrwpSm5MsiibnCyWJZ+dfHmyGpP0cpISSMrN r4xJfDnx7cSPEg1xgcTcAZWU4EzwJajx2twSqhsqdS4pZx40RJ9rdYI/uzImXsTEe+OVCm+8INdB 18cuNf5x58tOJSZGxMR0xyiBGFSPifZGK9pHd7QaiB40rDLG4XUo2ke3Q00IOODResyx1zRUxti8 NiVYYptsUwK2krLKgK3/wEpShU8IEk6QakHdB0W8t1J9RGh/amQkIa7obKjPy6vqslBdVchSMz0k Lgpl1WufgdppIdNFIQpOm97YKcRlTZ1CKWsIubX/UKvbF2zbRmmlVaG0+sawesstaaVNVaEtmg4E dN2taUKVprxZK1evzMtbNQsfs1auytO/YYnVmpWnObXvlatga1+rdZvyfvDiaqDZK3GtivhW/XCj /+uX+E8P4L//6iTt7wvGdCvnU5tyHnAucA6wBTgb2AxsAjYCZwEbgPXAOmAtsAZYDawCVgIrgOXA MmApsARYDJwJLAIWAguA+cA8YC7QBrQCc4AWoBmYDcwCZgIzgOnANKAJaASmAlOAINAA1AN1QC1Q A0wGJgHVwESgCpgAjAfGAWOBSqACKAfKgFJgDBAASoDRwBnAKGAkMAIYDhQDw4ChwBBgMFAEFAKD gIFAATAA6A/kA3lAPyAX6AvkANlAFtAH8AOZQAbgA7xAOpAGpAIeIAVIBpKARCABiAfcQBwQC7gA JxADRAMOwA7YACsQBVgAM2ACjIBhTDc+VUABBEDUJuATR4EjwHfAt8A3wNfAV8DfgC+BL4DPgc+A T4FPgI+Bj4APgcPAB8Bfgb8AfwYOAX8C3gf+CLwHvAv8AXgHOAi8DbwF/B74HfAm8FvgN8CvgTeA XwGvA68BvwReBX4BvAK8DLwE/Bx4EXgBeB74GfAc8CzwDPA08BTwU+BJ4AngAPA48BjwKPAIsB94 GNgHdAF7gYeAPcCDwG4gDHQCIeAB4H7gPuBeYBdwD3A3cBdwJ3AHcDvwE+A24MfArcAtwM3ATcCN wA3A9cB1wE7gWuAa4GrgKmAHsB34EXAlcAVwOXAZsA24FLgE6AAuBi4CLgS2AhdQ25gtAvtfYP8L 7H+B/S+w/wX2v8D+F9j/AvtfYP8L7H+B/S+w/wX2v8D+F9j/AvtfYP+LdgBngMAZIHAGCJwBAmeA wBkgcAYInAECZ4DAGSBwBgicAQJngMAZIHAGCJwBAmeAwBkgcAYI7Y+PcQYInAECZ4DAGSBwBgic AQJngMAZIHAGCJwBAmeAwBkgsP8F9r/A/hfY+wJ7X2DvC+x9gb0vsPcF9r7A3hfY+wJ7/z99Dv+X X03/6QH8l19Js2cRkfbvShzdftwfT9fQIlpJW/C1lbbRdnqc3qQ5dB7UTrqF7qC7KURP0M/ojX/h z7lPuo6uNy4hu7qXTBRH1P1N9+GjdwBdxuhenu2w4gy+Y55uZ/eHJ/g+PLq923m0yxRLVr2tQ3kV 3s/Eke5v8IKF3T1Us5ULoWP0Fp+Ybzr6wNE7T4hBLU2j6TSDZlIztWD+bbSAFiIyZ9JiWkJLdWsp yubjcx6s2aiFw0TXx2oto+VAO62i1bQGX8uhV0YsrWyFbq+mtfhaR+tpA51FG2lT5HOt7tmIkg26 vQ7YTGfjyZxD5+pKMnvOo/PpAjy1C+kiuvgHrYt7VAddQpfiOV9Gl3+v3nacdQW+rqQfYT3soKvo aroW6+J6uuEE7zW6/zq6iW7GmtHKroLnZl1ppY/QM7SH7qcH6CE9lq2IGkdExmWeHsPliMFGzPC8 XiPm+K3tidZmzF2bW0dkpuvgP7dXizWROGo1z0NN7oWfg9bLphMicQXmwPrYjNi6Sp//MW/vqPyQ V8bjhl6RuV63NHWi9/v01XQjduCt+NSiqqkfQ7O6Wde9/Tf11L1Ft2+jn9DteBZ36koye+6AvpPu wt6+h3bRvfg6pnsr5vvpPv3JhaiTwrSbHsSTfIj2Upfu/6GyU/l3R/zhHs8+epj2Y4U8Rgdw0jyJ L+l5FL7HI96ndB/bT9JPYWu12HqGnsUJ9Ty9QC/Sy/Q0rJf0z+dgvUKv0i/pDeGA+gX9GZ9HAP3f 4Tm6Un0Vp4ZKZhpO1TSJpj9CDrzfE2iE2LMnvrzc0t/8GN7dCvnw9rfgx/OyQIxBcexNSSnx7x1i 2qa6xneJ/g+WmLchry058taRlwqOvHU4dnjBYVHw+3feesf5yUuu4QVF77z2zqCBwpXh0uGOVsxm t8mfOUAZkpM9tKiocLQyZHC2PzNa0X2Dhw4brRYVpiuqW3pGK5ot1Fe/m6ZOPmJSNvtLphQZ01Ni 3A6TUUlNiu0/KstZPz1r1IA0s2o2qUaLue+w0syqxRWZvzW70uIT0mItlti0hPg0l/nIm8bobz41 Rn9bZlj87Q7VNHJGSR/1WqtFMZhMXelJyf1GZoyfEhPnNNjinK4EiznWZe9bPuPI1vhUrY/U+Hju 60g1CWrp/thgN6YjenN2p9LIvK7uQ7udohr88e4YnT/Y7dD5w912nQ/ttoEfww8z0ZQkCiiDskV+ OK7esF/0oyE0UAzojJqCUL52WIMoeEd/eTl/9dSggVnuaFOvcJjiI+HRAhfvTle0OGphMtgVo8Ud mH3W+M0vXF5df/Uvzi5eNK3SYzGqBovNEl04ecXkKdvahg1pvWJ69crawTFmq0nd60yKjXbn5nga fvLJjbd+98CMeF8/T3RcSqw7NS4qpyCnYusTG8969Owx2QXZJlc6FsS9RIbLsXZiyUtrA2klGSIu CTOPc2LacW7MOS4WE45Lwmzj9uPHNqIUjk1KJDY6O3T+UotNSiQ2KfvxA1YUYmMPR9d6ukR2p7GB Sg6X9MTiNaZBA2dqK8mfkZk9xDV4aFEGZm4ejGj4XVogDJdPuf3jO45+mJibmyiy7jp0Y+2ewcvu 2fpA58Z72ocr19317e113hzDuTneqbcd2rlwz/kTvnON3qL9r2PazNSNmFk+relMyYk80ZzIqHMi o86JjDonMuqcLsUViIqK88X5MPiULmEJOLZkiwPZ4pVskZ1tStZ+Ce6ozQF1mng+2CUzV7RjWgWx w4cXFDh5WoX6cz5+WvqDznCdINWNBqvDcmS7NkNlnsVhMRrxcdQkwhZHlMEQBT1JERaH1TA21hNr 4dlaYj3uWI/LcnRRlDM1LjbFaT46yOLy6PPu/sZQY3RTAXU9WDJI+O2RqdsjU7dHpm6PTN0embpd m3pqYh+b9vxt2vO3OVHNZkUdm/b8bV2KM5BIgXhRTYE47cPpwg8NAZRTovaLSBRo/BDKEvvV9ekS +YGYA3bxil3Y7bFpdbFBY5BKSkr0gB0uEQVYA1qoIgE7FriZWfLAwDHTIyOHRzx8UhpqLO6MpBSf 23JkN1RyUqbbYnFnJiVnuC1KtcXtS0mCSrHYzUaj2W5RRh95UmrDb6U68o1ikjoSP9GI+MVTzd6S xMmJDySqFAkhRUJIkRBSJIQUCSE9jDVv7T6wF5GwOuv06WKaPQs966TJiEY57qj4jMTk3qM9NkJt VObuD8V7GFVfatyH9O/0h5OG4bhEdVq0vy5qvyhEupmEs8kYOZuwanuGJ3h0JnlM6+f5sZG+l1q+ rC512IBMm9moqDiBLMn+Ad7MgT4nTyEuSlRWb5k2KCrGZbe7kmMTcEbHxMa4BtSOUW/S5mPAfDi+ 6leYSRHNCbgGOTHOgdrqKtBUhjUSaWtkatbI1KyRqVkjU7Nqi9Uen1OXYXV66pw9K2t4iTxesI7w yRHPzs4Rp1hIgl9P8W6TWYiEBPUrszvT489PMB/tc+JqEs+bnIkZKSm+OLMj9mi9eMllTtW2qslp VS48st7s0J6Uw9xrVT2hlETZzQYjHI6UxCPdR65LiePZm/JwKo2iewPO5tHLRyuOgQMTCwqsA5KS UrpO82jVJp/eZ5DdbtX2qlXbq1Ztr1q1vWrVomnVHj11Hwgka+ugz9BaW1KioyBp0ACTt2+tNyi3 Ykls4nBXEWL2mtyFriJnj3INP6OgqMhVdNzK9YtoVVM5wt8rpNrbP11JFEVaTPWgmvIsbm9yYkac RTlapNri09zx6W6bcnSswL5MTkIg8z0LfAP7JEWJtUax1ZbizU5eEuOJsx/bAPO/3WG2mlUDXmx4 xe/s8d/Rr489pa/nu6nqHen9km1RcWnxkXNvs9FFZ9AFu3NiYtyRYOocE2GHzh9rwXRHgunWg5lu HTCgUAtmYVKM9oGKhU67plClUKvipPTiOuuAmBxDcmZtclA7/PXwacE7KXYFRZHjnyOF9edPSIg/ RbzS1cSi7Oxja9Kw2RGf4hiWkuP3xx9d4BuTqiiKJc6blOSNteSn1KXleNNcYkTa0MJBSQIvhThv coIv1jLWjZzGllaYoxwcvmnkuKsnfPdZz4q8p2+mNTHXe+S5wa3NMwsm75qsPGa2a+8VbEbt/xjr Pmw4ZMzAsZBDGwMpbi0Gbm1BubWXv1t7+buTOExFgSgfDcTPbCqlR4KbHlmp6ZEEKT2SIKVHgpu+ HwmSlZJFbjim3t8l8vSDp3cSMPOE06cnSdRzgF4ZkeHQhO1v7fjR65eUT9jx1o7LX9tWsSdn+rXL l187Ozd72jXtK66b1Ve5+sbvOmdPvePLW3Z+88DsKbd/dvfSRy+Z1HDp/vntBy6pbrj8ES3fwenz LPZfKuXSus4+pshETJGJmCJbzhTZcqbIREzaEkh0pWnhSdPCk+a0O8TENB/K0rQ/kSNXVpew7jaZ 7JimbXd8rV3bYJEUmhfIsRecPtfjtw8yAUOvtEd9NrD2vnXbo+IykrXjp1+KiO9XvXDJxNw9I6fO zL/5+knzK/uo21tuWDrq6ICefYFHbU4smbF+6uRFg6OPfN13rPYPfNLY7sNqK57wePrTPhrTfejB GKeYOCYyT52dEbbrrM93TJeSH8grDMS5xcTCAN4ffQr7FNo9SVpbj3bUeJxO7QNNPNry8DysDNLO m90e/fVzYHdyhN3MD8VoqYJ9wH6RQ8PIKrIDNpdvmBgWsNnFRJf23xqtmhrmGuZKGIXkas8YjzG3 PqFL5EZWDI72wy4tv8rLm+k87NSCeix3iOWCE5aS4bgX2eCeF9uJCbdJbS1be+vMMcumjky04SVl iS6qWTGheGZZn8K6hUsX1BWNXHhlQ97U6lFxJoOimmxmW0H5zBFDawanFNYvWrqovkicOf2y1sIE X2ZSlhc/oZgz+/rTh9UUDZs0clDR6IYVk2vPntI/JtkbZ3MlxcUiD0/1p6UNLM0aOmnU/2PtS+Db qs587ybdq/1qu9r3zbIsS5bkRd50vUmyLNuxncVZHCexnZCQYIeEBhIXyAItLS20BTrp8Fr6HtP2 zXRokzghkL7C+73AFKbh0fnRdjqlDOl7BVoqIH3TliWR3zn3XsmKlyTAWES6usbWOf/v+/7fcr5z HIu3jewFMlIBrfwl0Eo3MvWkkQXwGtUQtTno1G9YRSHlq+efPQ2+pxZrzqJVp2yCFsZAEHKJA+e5 EH2+hFBFbOUqGR4XkP6SCzofKvlAcCUEpfgxLiQ9r7WqqY++Wda7bZTaqtXy6RTUuDbg414HHr4V 2XHK34rGzs6/z3ZB8frAQCh4URVBfTR3x4e6jfAi6EaNTngRrkPDUTTsRcMetHG4etgTleGVwSNg 3BRwSOALDY2VHr6yT8JLV35/Q0OFT6q4YhgxKTpK0Nag3RGyKoniJexDXGkOOl01VhVe/HsxqvY7 HV4tiaEeFNXhEp3PbnXpJDgaxFAbLtZ6bHYPjYr8SjXkUbUS/9nlSOma+AeDWUnglFL20XmiWaaC YY9K9tHzRIsUXIuUZgNkXRrI+/8SfsQL4rm+00ZDQO5XnMVQVmLwO8E9mR/ENy3A5fh9turA+zB6 ntLcJLpJiJ4Lak0SNUWMr1wEFqFJmunf8BfA54C5cbllIOAiIRIAhUZ++oSB9OAu/N9InPa7XD4d ha8rssOEVOu12jxKjEJ3EnJjwG7yGDUyCv8s9gN0RysDpyKWSwpvS+QULlJa9fhzMiWJoyAxl1N3 F6XwPJhvwzMYCSdiR0JIE9J2wh8/h+GIDHFgzCm9XlZzFmsDM5GZA7+tqyN9b9CT8T+TO0qZUyEJ 2RFcXKQv8sRILEmZSDuOLzCjtoIk/5s13rNmoqP4v3Rerw6tGr9zbY3W2+AJ9Sfd7+rDPa3//XSy o0rfYmkc6f7xa/XdcRsaT6ztiblpmwt/3GVzd090BLqbw0qqumsU/YanuYopPmMJtxb7Qp21xuLj TKgdaPOe+ffwo0QUJPUtJ40ISBDbWamc+ShiS9kwm/ssqgFUth1731kXrcPqas6i9SfInTC4Hitw T8DTvcIn/USFeyNWSvrxo5Q50TvWuPvkXenM3ad2R9blWswSEAKRMn9qjE3vG6qJrD3Q27aurUoh pkT439hcZpdVm7nvhSOHf/rlHG11mT0ujVlNObz2xh2PjG17ZDJu99jFaivUOyiry0BWMNt3/wjR YkmY0GM6kPIaP1BOWj4Q7Si5Z67Uw4cwyybm+OXeL/zkSx9xyKu/8D+Pdv+was3ndn/lwe33rq/B HPf/9N4OHuSeY8/cOXz/jubL79RNfR2yAxyDEoyhBqmDeTn4cJ0EpNtaRGL+K8yw31dMBt4XL2gI GrnA59UfI6VWEqRMfOVNODhMQ8pIArwni1vQHSTQbZC7kMXj6HcBkxPdACqSHyhJWzQak4oq/pSk zVq1CaTUf0fSJjji+Q+x98CIPQhInNRwxBqrTGZBrBbRB2q1gfjIOWm4acHbR86rkxFBncVXD+5q j89g76lUxTvQGbEcjlAuLj5IAYcPc1YA6gcqFf5rr7M4R9EmkOGDga2m+JlQ+IsumwtiuXv+Hfwd IoawSOqU3a4ywp52pEp1FmtipfWeP5tE4BGVwqa+5u06oKonojsFXCGivG4C7ogshF8L+tjQqPYs uAUYvYpJnlxLOoy/IyIlhKouvye/9gtbE40T9w3Vbg38sYQ3Os44abVr1eq1wbteuL938MEXDnXd uqZRJ8Xv11poyuazte56eP22R3bUM3rUDqCG8JM2R3FCZyM1Zq0sf//zB+966cFBvcOhdfByAL7J j0SQxAmPHLbxG7wyuFkUMVRPeaElSpZQJReexxaU5waqCvgvKT2QglNHFu1cruKCeaDLaHKCPPC3 pM4JMkI9ZShP8/lic+ka/1NZ2SbQ/1K6Rvixo31g7HpEC/J3MGYpPcWNEsigcmjldLuv9NES+IHg o8sfiP8/MX8lnp8HDv9DdJPoHsyPPAFMWYz51dxpT/Pvod8Cn1bFba8HnwbS/ykj5CYRpwBASS9e N+H/lrlpPGOOBm3gI0HcIyEpncVrtlcZpAADmApTaO3aWwZqSJlSJqcNKsauJuUqhdrbwmK/Kg1R mDv+JTCaJoR9CvFgW+bCYaYp/mOsDcQ7MkyHMIgUm2AVCFM15ZaprVPqsvz47Iq+FLsYgT5iAahr 5/PAZ6AgtcK/RGk9JqvXoBAV71wiyWmxinEazW6tBMR0kuJ30QNiSowbSWCLOCwWqa+8Sy1BvFiP vgju4vCuWKZUy4r7ihJKqZAKzIb9CszTCFHXQr0kFVPA7JQniB086he4KYgFCiurHnjGfkWrig6d d2F4MLLq8QJDx39a+vTLh0m+xgcQFU0BRmpCMnM1+nAAiHaelbgVEWk47E5I4Ts14q6fDDMy3Oaf tN1EC5CWM9aYBiT3AGBgGSB2qNRADyqEENdK8Bm9aIrUOg0mp4bEil8kPFV6q0aCF49jpMZpMjk0 pN+421HjAtl9kEBjcpMraN1u8i7o8IHLx+RyoFRifPbyfeW7/+R2wsz+SgL7ib3aLHO6Be15D6Da AtjXpYGbOKxE9Cz6z0BhrA1TsmoDZF98R6XClOxdDJ0Xn37rINBLpqNlGEO8Fl+QBf6e27zP4aeL b1UNBlCQYpNqK2O0wenMqi06NVUMrQFRIPgSa6wGo00t7nQ7HS5M1veNvDvXl3Nf+XHlZCiVkS56 h749XLVmzdoq9M8UXwajoC/ePv8O0U3EuMw78Ayiw1qAAdvBM8yXVSdV20EiqRLs9SqHfK0kubvj rh8dPPjkodbOu3908LbTs+xJV+720dE7+jzOPvB6MO/C7Ef+91cGuj/34r13XnhwoPve5x8Y/dru Vnb6a0MbH9nT0jnzMBcnAMx3Af2ygZiu5oRffA5YqRoMrhWArg78WSSS+/6in5TfVJnilgK4pZkt Y7DjZMIf8PtLscOuxMQDUw+VTNJvRBWebmfzRtZ9qrNdH2G++s2W3joT9ruRIxsjxa9UAiom5fGB qVx2m1okKu5xNPaVRvsoGG0c+MG2pwCZ6Ofq6JA6ATfA+Vs4h62yhtRvtLQYkn+B2sLbQin+vBiD EWjyF5X0EqjFlybopWjUYGCYiogUf5TS+6wWl16Kr1V5ox2JHaWJAS9u3nLPxqitPl9nCftc9Hop +Ud9tI99+MvtAzGTlgTqj0uUsj9Vd0fMxcHyRP/ZZfOnd3TAWJWWuaJs1e/NJuw1T2vIVHzCFGEh A/TOv4NdBtrTh/Q9hXRimtP+hD+htMGdfIgSmIeClSTbP7B1iULbAR2ozzi1US2mBTyh4FSKC0/B pLm1KW76K3uEa2TO2OWW7V8eiY/n62lShGEgNJGF01tbw/lGRyi9YWxDpjqxaTZbPdxVp+S+LyEl wbbheICtMdZkNmzekKlBA7n9gzUai5WW0XpaZ9NJbB4bE2zxB9sivup4z9YOdmcuSDMmFcieaS0I bM02s94Xt4XaawNVse7NAAsrkH87kL8TcZxACCDuU4yKoAHvnrJMSm8SEuDzl54rBWQrpL3tKmXx okTjMpkdIOm9WAoVsbegXPBf+1yXj5QldCelBtGiRU1CQkaRb3FxmB9Yi/dHiBPTAktmMN1pqX+K nrIsmHFqsRkv+ADdYveLv9N2yze3jT863Qy0yWh2aSlPz3gyubnbRWmdRptDS6Lf2P/1nU3xqYfv wmZKHuLKo1unut0gsRnFpssuGEVcAKFXwfjcSPwkYgBa8O5pt8EpNehBwMhKZQbbFCMS4hENoFAu t+QTSy6rXCmnhpk0dgshNfgd7mqjnCj+rZhQeZ0Ojw7kiDEMUL9E57bZXAqCtMuUEE6lHH+OsSig h5Vc/ja+SaqAeaWFAWNsnP9QTIIxtiJrWUlEKkdao1F57Cz6HittlRuMCp/HI3efxRhWbZQ3TlVP RT2wMLAQ7MHCQGnkpgjMh400f60B1xXTwJcpEmjjWqFIIFzBqRFvEApzld0dMsrw1/FXQH5c5XCG zGCe/0qiGr/T7tKS+H9gf8QpjctmdWtI/H30/+CUFk5ZiYmFKdNy7MMrIrlq0fSll/8eH5Ep4F2F 5PI/8NeE0mKA1g3rA/u4+kDkKcQAgnqF3Ax3jHqNCGQzidwxZRRrpsQlgUUuJX9+EUgLrs6XdWvJ 7DhxmSRat8EE1Kk4JydVfrfdp5cQl7H/AKLyWN0+pUiGPlwsKzp6JzbIVwFAiBRFX6ZkYoJQmaC8 ukEe5wNWF0Tqn0JobOsZpw48ED/cnC11cuZnmpT6Oe2H4U+MM8OLQjJXkctBC2xE4VXJFPV8CAc8 B/gEMIor+4wOgqIV6G+LLpqGDhTbLdfKxTilkhddGKJU9WhARuGwu1SMwaLFLri8WmibKp0iqNLr TdordW7gJzbNF/AU/iLnJ37IOlWdjs5IJy6TGBJyOdqfgGXNBCxmJmhY5kycRf/KKpFAQIWgcgTW fJFmoUraLKwlNAulN/jKlVWbz2IUq1MbnkMSdAJreTaBIgk0kajtqD6LWljVy27U7SZsf6jNtb0q 7yeQSGn9GFZ0ImN7N4+VCuPnQ5vHksJacgzo7uYxEM2IYT2nvl680D0QrxcCAOEOwVEHydMzA3M4 PEVbLWaHsuUrQ5l9Q+H2/d/bOcvUDSTbtvbWySm5hCAtnWu3J7Z+frX/8S91T3Y61q/qmG4zyuVi sVy+IZX2pbd35GdyvnRiVb0FUDNIRlUmm9lj09asuXP1eUM4FUyPdHYDdI8DdH8u2otUwxWY08AW pa4GoUTZIJQsGwS84HsOr4az6PusRR+CywwhJ+ywgPiHYJU9RHONF5iUlSB6aUO9ixABtyY6489Z 0nQ+CS5PiPo5UgUQGpLlVZgFzMZKNBvQL+Vb3tpL8ROpZhjOlf88PvHgWKg3nQ5QGoteZ9WIQZQL AnINVdWXzVZt++K6qif0ibWss53tCXTPdrWPNprQN287dyyt9jcHb6H4RJ4SNZUivSu/CzZ56IGj P7yt58hkm6a6M1Y8PrKudeIQsKANADEn/gJSj9x3wspVy/lF3deFxdy35uDi3TKtC+9c3bIw/we+ lQGTsYqIElWa3nSwUkXWAVJibE6bw9+ug7VkiSILy1PiE5J+6P9DBe4JjQgrMOfLTQuLmlPEvMMX X1WlcmIi0tTaNxrZ+shUfcfe4+tDQ931RokY0yhUgdY1zQfucrFjrcm1qZAcLuH9V7VJrTD5bBr2 0Knb7nnmYAttdhuVWqMm4HBVuZ58Yt3R0ZA35KG0XP0Y4CL+teh25DbkjlM7xod2wROQoo1DiPUs +sGpQGBcdw79AKFA1CNjzeOhwnQm1TzYjEXzbB5rzjfnM6m3YpPZDJgqK93Qj1hxd16ZN8GZ4zlO YWCaUEjF+fWEsTEhuoYJZuy1V165qIY+D+WpszJn4FAgF274/UIYRCwPkv4qKBmD3y+AiuuJ2zMP 9G041OeWgGzJ6NCRhmimrv1QD8WlVFpK5lG1rWuyeMMcogpfcigpILomVc0hCvFv6VvH4c/u/vKA vkZr0NVt/8bOYE+DW4E39PW2bb9v65VXKRnUQxmFqfo3d3tH11z5YukO8S8Y5mjIBlP9UaXarA44 7F4HLwkPJwk9bdLITT4rJ7Nj/+P2JElau2o6b11dJwIZv0KQ02kgpwPI50+tHWDXQzk5/Cyz/8dY AJlC5EBKDLId231mhgGPAek5DP4FnDogNsfAlEx0c6+5sDmTCg4GsWgL24IFW4ItDbVvuUaygBbE p3v71XlRngvUK2UFpSfIi3Mk9KXY63RZbMvVBz6FnBa3CIhPkzqXxeIxKsXFY4uE5Y4sCOu2wx9D WOgaUmNyG01uvVSpKj6NTsulZkgfOKmQoH8qKhYLrGlN5JMI7PJv0M9IFRIcJ2USOUhLny761Hpe iqJnRNPIncjdc8iBnYM4FGO2cVAJwsQPWFm8LT4IHgd0/g2QYJgDqeHBYSw6yU5iw5PDk+Pr3szN ZsehsUlu7Y8bC8q2LLBT4nS4v6tApbnkFYgvVilEruzIiQ+umMfo50HyeF4Nja4MPQgBBNxhGsZU iIoQqhRCuFD2gDcsX6yR0dVuPDIy8tnh0BvQA6rpNxrTBq9VT4koMU4qrYGYJTPB2g+oNIREQR4w hTuDVZ21JntUIsI0coWvqWyNJX6rZEMg4EF9CJ+zdIc6p4dra9ceXrOZVJu1XmfRvndcIpWIlEaN 3a1QyEhf375t6IdOL0hryFzrukaLNZaubhqKKTWmSvHyzKir5FAg3iYxzH23AB/yqGgP4keSyBdZ R6oFlVmSMJJJwl6QJFylTUJPmoSONQmJE0EivIeJCI4lIjiWiBDdRATHEoHOV6p1pWXJgIVQVsPt 3MYcCIuIU8p+zjILnOtNLero43xvuZ5UGa4A41rIb8pmyQmqEX+UVFt1sDkzc3zjxP3rqmLbvjI+ eJQldQ7ofyXf6fpsdwp4W+B9O1xtbDpgKjnbA/1r+4+e2Lb/3LFMTxcmK3U+XOkBfnbbLNt9ZAr4 3a46iNYYQOs4iABDSAJ5gq2ONKQaphtwLYw8tE7Y8ah11cA17RqIVg2EsYaLBYHf/OB0d+jxEAZb Qk/DyCRBCI6aEPwx917GvfLBIAHxc7lq/ulu4kECe5ZAXyZQgrBGXvXnjH/YopxRYkrJH6z9QjK+ 0EfIBzC/CfGOGdwWmiRB6rqiVoP3gQYOUBI/HjBdOWlPzwyxk70ROUgAcQzYfMPavez0d29tbt37 2MSuh7eEv4PfcaBtU7sbw7CAq+/2tbV6s55UmjQKrUouMxm17QfPHtz/1OGe7n1/O6o98lBtfqoR +mbf/IfYvYDzW5HJkwwNgxUuSLEIEZ6lFNlZhNDPIiiTBR5cE632nZ1/mdXAvkGftNCQMfsL0awz T2c5mo9BTxw6H7/ExyPx84uWJSopoVytXOABflECu5cAZkzq7UGLL+FUvkDJJCKN6gWYNBsBWd/F 5w93ebJ7cp5OL1zWVGkNSpFEJjHGh5q38ZZ6+e0S6eJ63jzHNn9ubVChkmstUI98wPM1AxSmkNuR 3XPV1XpvBMYmSemmGXiS45Ben9wO2VKGdLcnpXtnNhGim4H5sLqtubVpeyGXqW0udGcTeW+Wzu+v DGU5EEoR7fk4F5XEL8b4Mm3FMk1FSCsWfzyADIJLWyEEFjcDw4MhcE8VpYEGqSYJiVgSj9YZ2lfV qp/iGfOpxXhWr7t3zNwUDxqUOEqqnWb4vWAu2xvY9oV1Vd9nYMjc1tET6Jrtbh9tWi5kJp7DcYC5 KTHcuKIQtozduyZIkCQppaRy6XXia05K1G2iOxAN8hjyyNxDD00/BqVzenZ8PLd+Al5Na6dTIRl0 c5KcMzcNHrMgv7ayjvp77559LPto4f70zMRs4d7sZ/I78+uzPfmUTBoiokrIhM39IvDyZBSkRiMF U4YTn8CHvBxjfMU/LkQqnKtLcs/88iAvz0Xoo2UpLcpU9B9b8K4VdQDWYytcpZ78SUk+/i4upTF/ 1ADlaQHyZJQEV9EH4qzixAkyoDinID2ZAKmFORKnIFKgIAxQEM3TwOAIterpkoIUdy9WFW/25kxN p14KbE+qoPTOKnOuFX1lkfgw99axe9bywpYsEfa2svpI+EKFhHieV5/6ocaJpeqzVJXWwN+ukhDA oLVOG7D+7TPrBH4jngU6sxUZnstk3CNeyFu1cgYqiWO1W+PWIMl4LVXYkBnJDhZSaQ8TKSSzwbw1 L+dITBA8ZLLz8fNQ8HFuOUKw3gXQP5XEXAu3iWchiA4AYtsLvG2+8DGhf8gH7oa69CDWwUW000pB MD4xiFsX7gl4isWAKfcgm+fi8Ua4HPbB3Aa7vQua3ck94UbwcqY/0zWlNdEwiNTflBtPBwojmcau Qn+2LR/OmoQsYIEbYQJwIc6X7SG8Goitb+VE7RMzpJADisU8jjqSKadpHKyflBhB8rf+UN5lukZy 9knZkM/7BOQpFmjyw8jn5j7/+YmHJiHjzYyMtPevg75q4uGJBMd87fL2CfCYCcFajM1xcP/MQ9kH C3enJ9fNFA5md+XH8v1ZgzmZ9+WjQEBPmnPqdKYgKhEeLD+uRHdLyW4xt10/yf5PIzkXVlyG0zIP 5NbP9rkoDV/kMdb2RtsPdQMZws5lzvGFGz8Vrz1EGJfjsRtIzwGhSSWfktCgD/wQPwO0QIusQbpO 9CDnsFsQKeIAtrdmyAnlr2+I1gxl+wutGWdNoUElasj68ybO4F65QBdKUr0Y+82lVy6+tHQFEr8B UVxVRdLDXhL8jIQJ2G0Bg1RqCNjsAUaiuQaumZ3dTI3XIhUTGABXbfZZe5ox0mwifmr1w9/gt1p9 JonE5Puo7loI8Q6FkkhltFHttJIUCWjOYuTjuQ9FlziUZpG9c6tWhW+H2MzVjNXsBgHB9BlpDXgk HZCyZjeFOV/Q1Za8PasSibr2FyYym7Kjhd502JksdGXj+RKAZV8ACOpCCcZS3eIlzjo0lUHdNTG9 BrzEMq5hKeaiSxJDJeYGDnNOz4s3X0+rHSWlDpo4j5EGIgl7gEhEmFRBakx+S08LEIn5hkWykgIr lviS5STGsZvoIvAr08jMXHd3pD37Y5Darkb0mB8RI17Ab5GbI+RZbPcZdQQ8VnvOYsOs1bR5dHVT YTKTXV3YnB3It2er82Kv3J6X9yLpUv9AOREpUxlHZJdiF8s0ttzmEf0yhadP4HfwIYg9rAgZ3Saj m4EVoafQGbmU0nJ1J5W4eE9JQhhFyqL1Ueb63qc+IHgf0V549/K/LFMJkixbcvr4bkjwPFZgTY8g X3sKuQfbffqB8fGWm1uh/8mGQoyPy5Vadrd87RyQ1jFEBr0QcwfTAh5ZKRSUDxnOZ4/JRF/ovTPt KNyauTm7ozCabo1kC8PZznx93pdVl4OCspGlUkJgsOCBgNCu9kErtRB9Yi+zvO1VeLhFakJZKa3b vCBIzvyAIOURXpA37GYcV3sZ3rXVBxgVXnJt6GpYVgRKpJcqlUCJpuWy5cuKnyhyvspOgQosdnHL 6hivG/jjwG5XIe1zDocnLYWcusrkgZyqS8YjfWltIZXx8EG1KSsqEWnZD70iWKHvU4d3+OOfwpK4 OM70KcM1gcf+HdjKAWSKlYyMRCMOh4xD4/SWSKR1DxclHxiPQnhsabb1VgDP9sx4dmMhn456Wgvp bEO+AqcFYyiDxYfIADK15mPB9sl1XvTvJcXGecXWf0rFBrBXVcRspv9EzV0myeS9y7vE97n6zvoT bA4GxvIpjwdJTE3J06NxBPIXQ8sHzqIEqx/vZ7PxbHMzEy5YMzlEXmCyYq44CkUBME+leG8CpHEe CkNTag6+JsCVZa8SxNctiqO7lpS5MntyvrRdTuK4mBJROlgViztV6CMUXHgCEe8bcG+HRvVmQ5bx WfUk+J8ICW0PRpjMJGvDa1cohPEgVtbNflHaVPYLodYtHSvVum1uWikR+/r2DWDwjIL64tfw+/Cf IO3IADKOvMzqNeEMrFBnKDl4ctJaNJ+Jp87Ovw/LhymhNg1eXz8Dv5UiB8Elq1Bp0PyghVBF8ThJ wsorzdUan2UV4CIcJy0WMh4mYH2STcAC5Sj8iFEnDX5stNrHysCrTxUl8abcv8lH3tLrtzThv2/N Vjs7f9WU2/gr56DQJp3iVuYLv+ALcqH4BViYNABHAvcbqcFN+kII/BcqPfE5vqcUD/gDYhCHMQYu F1kI8hrhOkdDY2m1gzGA+AxN+MvL9nCXgz8QUOLCO/w+reqwxxobu3ugccKiMXQ0vN01M1ybuPk7 e/cc31ZDu+qcdZGYz+FNbDqcD2YcKK1WF4tTY9FMxDC1sS4bMYyMD/3eGTRKjn2mb6rdgu/3OLzr IgO3j9TYGE2t3VOLSTFX2/qW9pk1dT52fcLV3hQ3mfI1bVv8vrHO/oOrwxLKVby0aYezqbdq/XZH Y/bK5uYURpnCwSp9R5ct2s6tRQDJPoq/iLQBds+djNlXwRgaUSqRNKyEK6psyHBTb6x9lZ3wdMDT YMO5PvBy2pM3vi3iAefrZ+p4HI1cPM/ZycKa3tVNafVXtaJjhrKJLF1XaNz97d11EyMNOgrHCDFM 6Xp3drNbO53BXCYTKC01BDM9mWCp4rlkscG35/iWGplGr1DROjkseWlNWnPbVH4qmPSq+o/+YNu+ p49m1L6W4B4J3zYmKf6VW35I9RyZbNUEu+oAqxwHvu8x0V4khtwxl0qg1VqhNq4tFc21QtFcK1TT tZB5DHZ+Cz63GZ/bh88tScjg96T87nt7NVc8eTKc86bL5RKgveXd3XxTRPLqLeiLU+3FWTn+2FVp 8Ww3zxlastQSkXmwd8O1yxiVfRClygSG3DP/ITokiiB6xIXc/2TKM+iZ9uCM0FPDCBhw77XcK2fc jMAEjAAacw7bi1gRPY+UXvgpvfBdfQlSPYDpjNTBgp+Ex0PPmeheDp9fFELCSouwarX8/nwt9HTQ WIGVou2LAdDWtDSH4L8yBPix0k53NNpcHUyCf4gg+Vkg+QTyMCtPNaDBOrSO1aD9dWfnX+aGWScs JtXBZg4598otJtWdwwKIG5ELs1n57AagDGYmHEbgRHmlYNwyUVWvNV0Olbnw+DxQgwjNrbDEXi/N e+zG2uqFbfKzCyHsscWIoKspYS1booBr2bcolg86FxRj+UCRxwxtB5jpEZY7h2GaO4dh+YMOStJG 4J/PktJpbsaCfJc/d2GJLE1LhyaMQvQy4LRVyB9YiwaeUcCdheLndi8GuK2LM8NousJyyyYNtVYr aK1WaNLhLNpuZ+BeaXuM36/P7dznNu1zhg0j4idXwT23q9qXHk/C/9olx5icQ98HtEKj4pN9OS+s oyo6cu3pcFNvOG+qkH/l1uuksOcfhIbCzlnID9zhuNciiZVYQy/0GgrKInqZJw8tpavprk3u42qm MCZkarpqk/vLXALb6BkbTeYf6G1a3x2lw0N9Ge+6z/Q6FljFk1zEKkvv4McA4+I44N4DawbNkY6q uu5qLaCbfIl1gQRjyEOsipcgfBIIeLGUBN5dLE3YpmaX0XSJh7njUSpORkHff1KgYq6KLQ3nqk3e 3hL0MI5YOGmDvgrtGyBk/fUIuQzi1/uvQ8hXAQUA2gL5GPahvQYQgjsRvsdaU0G0SoMG1ahfgfrl qJ9C/SRaze1+XWbf/+vL7vuHDt8ekaLSigMFnFcfKPA0JoU7xp9UIf0zQEwmeCK8KgdSH0xYDYW9 aQJkkfIxAWOlr+tthcBfa973j7dO/90tDcl9398HXhufsLTvGgSu32VJ7RrM7up2or+75al7+zrv nLsVvObA62zvkW3JxPiR/tyRrcnE5iOwq7H4EP5zgA3sarwbdjW6GpY5k4Rnn4XDSaDb1vMNjVxr I7dvnu9tXLajsZceXLGjcbmGxmV0ZOWGxq9ururuYL0VyqLTWzRkMN8/FIars0/o41xDYzrQfbCr fX2jGf39Z350NEO7E55ie4kLid+XAps7qtuD+vyxH9zWc3iyVQsim+I3RkZbJ2cFtsS+y3XYTszN 1KN+lQCRSkBGVYJKJWCoglBphOOEAOUhEDPEDBD0sZJQzq/SO3v1eUQgL859hcqxTGVzwHJmw0Ei xr6LiSUUZbB59aZofbNnsdH4OpqTNoXLa5MTOIpvY+xqiURC6WrzjVd+uNRsjjZ0B1Q4JZVKlNz6 1tB8AXsJzLgXeYmVR/pSfYN9d/X9oE9UccDCX4SDFTiL6YBtntpFBy9wBy6gr7IO/pQF7nwFSC7C IQuwfQJakOVp9C/coS5S6OTlLOf4wVs/+H0p+Q/kmLz2N43St9Wr1FvUM2qcP0zh1/AkhRzzFq9a 5WMUhEMUxuAZTBWHKCzEQh/3EAXspfjmIwPRdT1RRkrAQxJCqbVN1d0xS4BdtWaIDQSHDw17s81B PUhFcVIqlrgbeiPVbFBfxQ6vGWEDqLJnN5C3waTzOrRmmrQ4LRpPg8+fqHK4Q+1rW+u39tbINXpa rmJouDmXMTFaT9QaqK9yuqtbVwuyEO0RTSNfRb76DNKEvgrS900AsQ5kBn19zhvUHroHllGaVSbV no6pDq1Kpe2YIvoPI/2Hso7CbemmTbvSfW8PrxreMjwzjNcO1w6vi7/g35Vb91a6/x5VwZS9D+T7 XPdsIXVVQxsNk8QkV3QBKT6fHWr4pX76NbgxSmh3F6/cuoYthlN/TfgrmhRXKAqI9mAEKXdUcYm8 /ZBKA89vOGiq7QxWdUXNHhuFw8047vpcpQyuLcHwqpvbTSENY4huOrp6eHZ19RvwNIhS7UBHiikx sVHNqGUyVSndr2xtq0sH2ZzVaV9GeM3XFn3z1h6/WGzM+junh67qpyvXGBBuj8u72B7iH5FmZNNc EFF7woLFhQVLDAuWGBZ8WFjgpDBX3jEowgVP1qYoGLJ1UMwkL+YLkHTiQl/bhfOxio38S6o2K0gC 20PRzmCtIT3J2u7k5fDZUtD5Jiw2AgQbMwavVUeJJCJiY2W5hMdv5dqKMG/iI9HtyCSy/vRwR0ds Mg4nZBqw+mNIzA0eitGByezmzeK4f6Awmm2ERStptr8mb80yBXFGcDiwXAWLVWC254Xq+QWhbwEu eVxdmBJS7BXKhtfu1ixBhTd7snt63V2wBYurTYWisGFL9QJfkHqxRNPFUAU4KyOJP7nQocUVpjSy Ffq5KitTLvWKUM/PQ2Txd0URzI9+Dx45jPmwbyIC4virQNM6kLaTkQ4a5hwhuz2kguwix+tDHVk6 VGipz+pgq6SvX8K3Sl4AnIFGuAVAWNjgFpIqz4S6ceS+Z2dKvcfFyA2iYzFf/vrHxkDQrp8R/wqo dAuYqxL+3bnQwCi3AqroVFjBA6kPrUYGsh3ZlhZnNprFsqPKUKE+q4F/9sfXv6nCmKCOnR+DFVHg yGEhtNwBzMGxYFmLoFjKmyUoFjbtq5czPeJnlJqvZabsxY4KpDCcVNmrlscKfaZUROW6gzXKNxsy 5droRpuLVkoFuCpQVOvUCoViJRxRtHRWTnF+iQlzGJNbgAV/Gbn75Lb9XRDjzYcDsHjWeVsnbYZg +/1H/EOd9X6G8dd3DomQmzYfuuXQLTdJC5/PHM7uz3YFzJsLN8E9D8TJURBjosTp1v5yXyWPfIyv CQHMoY3zXoqHv0IG1+23XF5Lb1h3KwRWXjggtxAiiZjU22DHpkNV7tjUuPiFgpoK/Em1K7CMPCna dV1poq/Ank9fh1tx/Z7PFezjBs2mUtwcKymVsBuKZxTxCMcoczyjiLASo4g7gJXtQnaddLQPckSy K7ZLuWtsbJcStwzAVaDOOljdOOmz/H/SvgQ8jupKt25t3VXV3VXVS3X1vqoXtXrR0t1qbd3Wvtmy vEu2bMsrXiVhG7PFQMCAQyDYYAhJGELgQSAJIC+4DWEg35AwecGZgRCT5JG8eJKX5CPjLJPJEBa1 3r3Vi+SNwIwlq1Qlu3TvOefe859zz7IU7eDmTQt7B9t6a3sjEXdjohFvHMJs56t6SbTcTCWIUlps 2aIOQzuPwnWF3XHlAOLTM+0TbFlg83zOiK4r7ElznME7HGblyAiV3IjP4/bc6iViVzhQ+DjaX3nP m38iAbD7UQw98W2sDjuSc2UbABdECDyIEHhQjbwuil8mKCgOGPD+80VLxVXCFa4SroDXvym2DfoG AQtX2dhxlTC+S4m3MkT7ghxl6fNDg28ukH5+6coKJL9sIP1FOcOp9FxI/VdUeofJ7BDphQ8ojgBU qwQR2BzvTbTd0KUyutCZD1PxD+xfvqhl66ENuLds3cz859C6jqpVy/F95SdIOr2zHxA3QPrUYL86 jflmoW2L3F4upZJXlQs4i984gVSap6l0Nc45w5SrvnQV4c9zafhNWgQBEQQFEKKANwQftHqB3ws8 6NusB/g9wK08dQO/GwR5cI0HeFAAOSOaej1uaPXAu9/lGAjmPCh6H90hTnjQ+zWonGioz8NZ+7jB cpqsQlUsMqb4ESLFT4C8CUW6o1piEaWudaXI5bwjBoM5XUoSJm4AOIEXzijpwc6QRUcWfkhSqByj 2eEzMGSBJD7EWYPHZnaKKuIRkmE1qo+eQunApFrHEis1eoaAYorDL8yMVaPBf4Pqa+FqDlE7OfsB dRukdhf2i9NYDzTvWuHUGtHhWLgRpNG1KgYCHhBwg4ALBJwg4ABBOwiRIEyApmbQ3ASao6ClBghu E1golNzn6JpjobgKbvgGgS89RtecBhni6DG/oE/5d4iYWWFImBBuEkghp5d6hfq+qr6me2tADfpZ DbI6BYPUu7Vmfw3eBZ+aBxWU82NEybFXs9kzkJJFeseL9iSm+Gwq3psioekKnYmgal5S9mVIPu9b 6jaSKrxHaM0hp6vaoiFewvFnCa017HQF4V3hfbhvQHRk90LY81Mcfw1n9FDsXXo1/jYOzuKMwWOV HYgtKiM/xxT8boaZ2TPHIt6oYjjIIZUWcohhIIe00HBFhV3l8h2uVqq+eAv3EzdCfvmxJacxG5S8 JJJsGwjbgKy4imUQ0KV0eJABVmSyN1mBpRFemy3A1WdhDX3sADmEDZRctKi2XaQolEg4PURx1acN qIZtoKGSf29QzEDJqMLrr6Vr66xuEadvZASi8LJa8DudXiNDAUD8jRa9brtfpAsnBZHSGHUgQ+pZ Yo1J1lGEmtfOxPCzBo5CeyKcyQiG4W8Tp7AI1nwaE+BMJFTjMqBUuozDnzcwnQzOVIl5gB+39PJB xVU3UEntHjszhmrufpK8bmgVvU2rdeqZsyYboje4u3CTYCAZLYOTnKhRoWeFfeAJaGDS3SiV2+7x 6iTJIuDbPVWo7AKtk0S3TjZbhZkHVIKSk9GJfxfPUTYsCi3AgWMqUxNqzI6hU/s8GMk5+KqjbrfN dNgdA4lYLobHYqztaGgqfR+7l9hTymVSClOLSj2TueNHUDwCukLa9ZwZPj/rGs/ZnB5r1VhTzUDK FRrY2bFM66oPVLVEnWqtXte8qbVzLGO9fUmoOaCvq6nJ+vFfaTScNlEVlmqy1bGuqOSzVdu1epPo sxuMTtmRWhi/WSO5pWDQH0Rz3Qnn+jBtwAJYGms4xroSL4KVyH0LPpcTMYOL1dU8552y7NLtqZ+m 9pZdiplMqUxL5oI8kou1SlHEVCVvtKnoR8QfRvlu9rpYVLZ5BUlH0YLVaLQKVN1IfW600XqP1lXn r+qOh3rCvjqXQLzXPbU4wko+uUWjRWeuhJ1CBUDgl8L3o1Xxxds7qzqT7nDqpVjU1dCBqgnAGcmU BUtgoWMyVpWHM+FZ04MO7xf5KeKhmtBXVHvnV9N/69VSscAKA+Y5pOgiF5R54DJOqryjzbd/LjJw VZsxEgqYORoanKxKxYaynp7Bgf7IggCnUkGboEGr17Ky54G7h/YM+GlOFFmdXscZ9SzpMa8fX7/a 4WNEGVK/F471elqEKz6J1R1jLMkXwSoI46LgUE4QXbssDBF6Tpqq+7JmnmRlirU/KgL1STPjoCxd b/GIEk/Hx1vaV2es7gXrsrVLQipeoT99Z6gn5IeoWeOsC/j7Yvivi/ReEK+ND21r6d4zFAkEQIxS kwTc2KjC0ljM3dDh83cnPZEkkqQeOJfdcNVUYTGsfToG8eMdJ2yiaAvkwcqcGbMZ7tfpmNhhN0pd k8NH3FPMUXlvuTbfVKVFhH5+xbtKlppkuoBFczlq+G6roXBYH26vDWTrPCyr1nkjtWn30aPB/h2d 3RDv3UF2dfoa/AacxKyWYGu1xEHD3mq36DQMdeRo99Si6lD32pTYPWAONTjRLuzHfwBeoO1YCouf 0OsxnZQHq3JidcCrfiCx2/ug9GD1hH2PbkKxh84XA3L+XPfqXPRtxaMhXS58LDUXmgNewEmaoCNm hFb3aXRabj+tsxlNkBeLOLiKF5lr++vMtSaGwqkf6fQsrtXYqh2Nst0hF7KQMyRiD/iO7LDLqfSS pFXNqLVGVEezGryHb4YroAUbxFZjh17GhkEnFsL0YAnckLvA0lO1EfhRZWtFjZdV2EK05G3YMrAi F6oi789MhIbvz5kWm3BT72E+piJSblR23507nJpyrwQrD+fcwI3KAKi5Xvc1WDYydn6qyENoFJw/ O3Y+U0qDf+sdlEldTK0+p1QU+bsBLalL4lngX9Wl8Sw0XbrDN2uZAb3O07Yi6WrUs9qA+77YYIPd 1zcx0LtlgbMmaHf7rJLF27ay3h43Pc9xLzWlbWGbtqnBHrFpY8n4HT55oDPS5OPJ/2ORDBE51ltn 1WpYs6CXcRo3BRq9oY4GB7SV3aEFTm3c6ms2S5lIvLfeRlPyI4m06AgaEw2Cw1/Y7nTipC0o+dy8 7EYVFfEf4AfgzprA4tMhPaKxHeOgKPGYXQyZddORKe8u8x5qTznEInNh6aviVhr4+MAK/ABUWUYD 3D3Tjb7eMFXcSunylhobTTQN10n4ryvS0tjbE48Wjpbv52+m1SF/29IMWsnjcAXg1IdKVIXvZUwC P4NDx+AEULi/9YRFmFRG/YtyLTHDJeNLzwt2+CvFW03lUZmsPKX1JmIebyzhmRsXLtNqGsfhl1PV Tme42qWsRETBcUjBBqx5AYfVgrtQlT84DAnzgZNQO7Mgj2r9oeiESfsusUzLEimL1f7mKSjiMnRM z0UkqAyShI+r9HZJsosM9ebFxDxBsnqrct7F6B7/AaeeR9Vo4UeXoaj3pzRLE2hSaqP+ucLv9Xxx Tthf4JyK1RvByhOssEsZt1K98VJK/uXiYcz92rlfVXwv8S7cfbux3HTKh7qtx1pEpE3sWDfcf42s bnrBlHs6M9WSCtdNhveY51GrdJYfP5eBnx8rfhffI/4WD5WlSizsu3CkBjTihqS7I0TzVoPJxqvq kt72inxafD5z3dravuWyrT4el5sW1RqvLKMX3+OyBv5pr4+l4/aAhfO3LmksycoNcP41WHTaL86t Nh1m1z0XnPKb3ZPlKRfP0NFa+/jJzk0OrbQbEAMMcCapRl9PqDxHi89jqVtf37yk9oJV1odGfP8l I1bGimNdUFM+CsdqgLrS+23MCA6hen1Q5zOs5QF+yvfFItL6ZKX6Uvij4aGre4cm+7zBwX2L+nf3 Vd3NV7XGqltDRnRdtJx4r2NySTQ4uKunY2K4Jjywqy/Uk3TaG3pqqrsbHGsVFAj+hj8MR4RQYPqY K8EiApoUFGjETAgCsom4i6Rsk8K+ChBEAXbnLwMEL1pmFRpeCgSza1utNdUhc1kuKJ0keK314y1z QLA3GuoO+esREOyZGoowBoexMEOhanc01Ivn0TKApK1NxId2KEAw0vBSNIaAYFEmwBsKjg8c91ox HgERjZV9NTjl5U3OSdOeudPgP7+qz1zos7xUEorFr8EbEAZSao43iTxULtJ8mZarAz6DziOpIMZ5 U5R1KoqmODnkKHz9QlHocYXMalJN68xwlO34d8F5OMos1nsay4BlJ9017hqNJQ+W5xyYpvrwL2v/ VIvXpo5YMlTVFHv4FfFfRVyUjlB759feG7tc8b15R34paGeQFx69lPAtnNF5f3Yk6W6OuTQ0QalI 1hFKVUXbqtv6smF3ZrjOWR+0chT8CUVL/rirLhLJ9merif2R9qjM8bzGbNIaNJSg571Bu8dsDuWS wZaIxGi0LPyJqKG0gjZsdfpkqaoNccUH5/ss9ShWh9Ucx3yuIOKKYOA510TwQQv3oGEi8pCqKP9n lODzV//83R/Pw+gXw6gLoBYC6+gZeJZmJaeHX79sEcdxmoV0CePeBe+4u9zV1gBN0hROCJLMqWly zVoQQDDqM5SaIkn45TMKyPpDbR1PcnpFkr6LH6CMENlGpxlfEaQ70O4i+hgiPGmedD9XgeiVsjKX AejzPG7SBQ43/IDFpzdrqcTm+ubhWomGWt1oEeh0xtMbLm88FURep2wkYJAuLgO68M89ffEo2Fm+ R1R24a9DDGjEglj9Mb3HlQd3njB41B6oGUZznMrt8Witk9o92GRxQwSWuFVG2LtUpw8lJkGVWHak QDviQj8K7jLaeDVBvkCwRq/d7jOxxIsUxQh2o2TX08QRnLgTVws2yogaIvHagk6N4sbVnBr8h0bU qClcGfY6gwE8qlLTBBxvDf468U9wvB3Y8lNuT60UjxujcNA5zmPUNxvVqtZWYxZZ36LKmJqMtxoJ W2jStqc8g2Ix2krJPqVMX7lmX7Ge/cUzCl55cvO+JQ5AqVER5OOE2uCx2jwmBt8N8M0EY0R3Rpb4 GkmoRKvRbBdV+HU4fg1QCRaTyaKjiZtx/GqgFos04HjdPBps1mgKX56jiE7gKhTRaMCjRTaq6cIY V7pD/ISYfgukjwdrQ7jh+eNqNWvOg0MnPZKbkYx5cFdOw0r2SRPDTzJXE9eUFN2FBRiVvaHkBkoT c0X90pWifmAREak2O3hALnxHBXROqwyxEHk/fjtOiw5ZdvKAwnktR6q17DQu8UYNias0XGEfDu5W sVAgOIOAKXvaG+A/KR2UvsRpTAA/ed5phB+YNw9+muMYj/iQZYL3fYm6Gm5hr8DP+cX8wAVOH4Ov 4vSBOzBioLK8/xMVkS58joe0ZVXnf8XpFLW7ThBZ/t33lVqoat6oVUkmmeV5gQODVpsO3uvNFoPd WDhBITsJh6bSKSV6mMM0mBFVt546QTMEyr7/xRkQP1dx2BRjdsFwOUa38Cx5phSSW5hG7yHdYIA6 OPee/cp7Nl3hPQM1mcbqSKYxUjhJVaUj4XQjfM+rGA7Y2f8C71BroeINYzr4M9tCASUT/nx+siwR qMQTX4gKwEsq1IrQrleJQG3y2W0+k1rHWEIuV1hmGDnscoUsDNhXjsIiXtDoNRQNV+OHGU/ExnG2 iMcTtXCcJQpndH72PHiWXKeMxP1tTMI3YW7MhGee54RqOK5tGByU8OpF+CRINFxpbEdVvM0k2QQa iLTBb7d5DSqGkfwOe8DMMOaA3eGXGJBE9Y8I+AWf1QgsRUFD/SO3IyhznBx0OEIWlrWEoGxVF34B 9mC/hBYre4wz2zHhrTPFyH5Vqah82lD5vXugihUPUVqDxSCaWUAe5GS/1eI3c19wNcSilh8imUWu WGC42eZGGNuN5OLF2ffA3cRRJYrRNo0Z8/gNp1inzzJI8VA2zmTPKIdglwIz8eJp343o7w4h+ofc iP4X3xNudw2ifY3bG0XX6EzIU3wAmWHVaKxRtJoehOPZDWfMYeZp1MTlledRsxaGGMTQUCLfKRao rgjY7nhbSwz93dUTj3XBv+gdoPBbgqX+EXJUPS1QGArFMJfIVYrKVn2d1BodJotHT9L4GKk1OE0W t56k/qzl1aRKa9DSN2h5BlLLiCq2uWYb8OPkjz/ufa8QHHyf7BZJAvwJ7gx2+G6RoJ5GlVppBAyG lJqtUA7h+7rACTyGt2I8pjuBqbjzJKb0ayj5gYpzU7y9Mb1YWKuHf8DX1FqGAu8Hna5AwEmL1tlZ iKw74VvO4Criaqih74XvPVh4EvyFugvzYd6ciUAHbwQKgCMUVzRhcnEHsSw6xi62+4EWv1FvrrQ+ iRHKJlScD/jjurF1qymgc1j0VoOGSC1ptLsyS+oBVHuS2S7g1IbvF0bOvl0Y/YFG5Ci461Nb3vjJ z6em3vnpm1tJmiZoVtkbr4cj+i0ckQerP43pi+db+lKEEbqeRCPTK62OOCWCsTjCSF2lI1GlH0tK n2zAg6UdwSzpwW/tjcMpQmOw6q0OLaDWrF27lsQFu9lkF9X41n24ZernP3ljCwVtbYoTNf8bPPn2 WfDk9xkB2qk0TZ4pDMHx3TbLg++RJyDFPC/DvfurGI1Z4Ve4W+LEMUgwDB37//nsubPn5ghmvCzB vjPYP9hHap2y3mLgiJr2qCTH2qshsraaoIohyXseK3z92enCN/4XK7KQXipq2TefPb5m7MRz31gG YShBsTqFXnA8Lyjj8Z2GavAzx0w89iKux/QYBW94K6sMCA5HOHvuY+njJMAL5pr2GpzTQw46tYDs 7+sdJAneYYZaXo1Xt8dkcG7N8We/CX89pBAc1eNgxfSzYNVjjI6lCAj7l33juRPo9P3gLAml6nc4 TRzAxuD99fD+t8r9TdgYRmDYrJa+lopBcIK6Tm8/PnWrXJUHu3K1MY0cbcRukJfLy7HujXvPuUKu 2gN/EEf/sHjxgEpza2zKT4ku+LG29Q87bxse+ONauAyybxWDLSDGQUFU54XzKM4Cro7vKPFV3xHe OCtmMueU4vugdHYeVNYiWS7kak6XTDCCRrYXWTp1uExxO7/ieqOV0zHFe0yWPG1pQF8rBtpG9y8M d6eqVKGB3i5PpL3eL7M6d+PSqwfdzak6q0jaA3qLjsJHhERHuL3OK7Hxq1++95r85zd1VUuq+gNv Pdp3zcoUi2w3QKo0mfHPLnqxMPNYL+dqHLnpW//37sf/+JXBmW8HFtdXd9b5JCaZlesas4EPPyJA 5z237x+tN/gzVaGMXxA9iZbe6sjENVMjad6d8KzS6VBnm0LDyqXh7rGtO+tWPry/p2Fk762HbpoM TuRv7xcNooo3izo9r2GNRt2qx39zT8MdDz3yxTs2Nw3d+y+v5DrDC5asGHb1LxZ9mSCxBPGwMEMf pnzYWmwDthG76eSGnu6167E8uDGn7R7v7Vu2fv3SFq83QeXBvxxrSfS9CH6ILcVEcCbnSmz40bqe HlkYASObgn91OORF2F8XbJLfi2xi/5reuAGDDBWUT5TFeV54dQxyNYOM0F+cUzArSrCFuBVh2Dhk q1JyGhSjNvEiR5zk5bgGH5KSvlI/4JLGTbjSuAlQsdRgQsod/NfDd3z/8FhaMtcvvf7xHV37RjKI L6hBh9A2/pmOfyy8/3ifo3v/yQ+ffByA6bXh1Ye3+0KSmswWbs8StOixOj1anAJBQiuH3f6IVUPc iN8LQh/+E9C0bbih7dYfHV3csfehb55a0X9o/3hXlWAQVDpZ1Op1Ws5o0G145k/3bPnp6ycPDY08 U5j5+qpn7loJtQz76FM0C20zjYHHz0P1QJKMjllXuJ7oh6sMm70WrqqH4Cr7MrYD6ul1s+fJJFk/ 1/egW+l70K30PZCO8WugtSNNU+s+Vd+DZMsNLx747Klr0uh6S/6a9DH/4LVLF+4ZCvkH9y9duHco hBt2vfbF0SX3vbZvJ7oeee2mlQ9O5lp2HFm58oEpeL1PsXJnP8BpMgR3ede0mcvj1uOYqOHyoP24 fTWEeNnszBmlv8T8PGoVTRcd3+mqkjMNwluT2yy5TdwHKMwI1c4G1aRGhDuqS6+yMMiGUHEsMXI/ h/ZZ0SJq6JdxuLYQjIKj2AB37UOQQm1Y+2mI4rY9X18FP7BMHr/tBOd2Z2x5kMkxjaJE0LE1QiYP mqbpMeUYFvnyoVhepsx2KfEUDvGiktF0SR4hEFOq4B+iWJ6ZyWglnZpkeC0w9cD1K9cO1Ldt6k9w NKeGW7xabF55dfvy21bHrZ17Vv0er1XzLNWrt+kZleiUTW6LgXm3Zf3iLk8wF7O6g24a6lqdJGgF v1cODk50N2zYdk33y0yxQtRwoUBcB2c7iq04jdXjfTnt4uWhxe2hxYtD7QTqaLDtFKYztBpa5cY8 kHPswPLYrNdLDayR88AyTY0Xw9rj5zNCMRxbcakUA52gZXzuCvmjSvuGynnu3DK9lCwmJ0Fc13z1 0xNde1Y2alRQo0CrhWtYMtHVvrHTW7P0usHrNTxDUmqem2zf1he0Jhcnmzf018FlqSJxUm1qXr4r O3rnaNTdtropu3tp/MDwXVe1SC4XpzU5JYOFpz0Bt7dtRX1qVdarEqwmg0WgfdmRVLgv5fKFfZRg k3hJ1BmrfObYsn3drduWNGpwqm7JboR6vbMsWUcGsGoshmWOxTxCHqdPBEkSi+Zx6pQUETyrY7Zg HphPCmPsenIMKxUJQMmhUEgQJC63Sqkc6CQr4lJO/RMRQvUBD1ln0L+O+hHIHoNqJs/ptTQ0Sxjw N8roibp8tU7d67xUuAovRMGPe7xVZ1EpbNQB9yyUALPRZbcLxAIGwUc1z3z0eR9R9VFBidvHlG4j bah7Rxq8fTJUF6rT2PJ4zzFM484D7HhTE5XKg+ZjNaPSHNMrnUfKDrSqy8fMV07q59p4oC4QRd1K bO/6zLe2ZrYMJ40shYLeq9o392d3DEW9A9eucMWDfoNddjlwJ6PjKKOh0OLp9U98bVv9yR2PTTTy JtkY9AgWgZHtZnfntr7sWJuToEhrFS643WqD3eAPFY6SRGr8TsipA7PniZ9RbqwO68aapsOtebzz hMZq1dTn8a5TmCY229hI+eFkjxlG2vPAVN4B5yYZn3/MVAYJF5QKUF2UBFROhfpZcveTU0tuHMsG REN86LondgcHF8RFNaA1DBvILKpfe/uKCGFtX7Qqsf3I6uBzcuNoe9VgT9bqya3LLVjf5gRfXf7w tX2h/p2fe3zt0qf/4a6tLYxOLzogXhXUOkG38Oavr+GdMp/ZfNf61nXtPq3Zpb/5me3R2sWblXgm ljgAuevCwqhPwFXHados5vH+45iZEvOg5bh1lFtfatJRcXdUYrAUPViUxyLziAMExdCFWlon+2ye gABo8LuZowzPUEY9/kediaOJs3qH1ar78AxaliqdQUv2swa7PlhF6+0QIWyEfHiT8kDtk8S6sL5v YzHcghmxEG7JsU7ep/g82NSLeCdUSzm8M6dh65upyIxlpGOmwpJ5FaiVHkrCRToqXYTUlT0EbiHK QQXSV+ZUCvUwLGf3p4g3W69+YvvGR6Zawwt3dbeM5Ty1mx/asuELYzHPgrXNPZMDoZ/t2b5jjy2z snXz7oiva2tXdn3WdcfBm24Hg8tvHY2Gh68dat2yYsDr6lq8JtUB4VZ8eFdbat2yXpevf/k6fHzZ +IblwY7WjLP+5plHYwO5No+7tb2vZnz7dhTLAKnx2nxt3KVo4y5FG5uL2tj8KbUx8Vrtzm8duOWp TeHErm8duPmpzeHn5NZtw/1XLXDILcrViet3lrTxru8hbfzPB1Y9OJFt2n7fqtIVaYZnoB58hAzD nS1xGgvj1hwvOkUOfmCyQe9bHYbSYyxrvp9DxVxOXLhY69V7LqOklYBx4hGa1apm1qg0HE3DjQno LtDYelkvu/X0u2odQ3WizBTUGVBvFRn894rqNouyyNGvlFX3RzcyohWOG1qxxFcgTZuwDNLfO56P ++AHlszj153gpDhtgfr7ePUaITlPc5eE6uPUduCSRg9zWvsrFFwBM0mdiVcRLK8Bcv9orTC+sXXj QJ2W4hiKlbKje7IjB0dqLJ17R8/jDVBbXayxs+OLu/0LR90hD+rnavVIfp8lNLCzPb15+5y23gq1 9RE4t1VIW9fi/TntoqWBRbnAokWBHKGDe/Z2qK2bxWZRSinaum9pzazbTfWtkT61tk79N5X1kba9 T+9YMLWqiVfThE7LJJdOdLZv6vRGll638AY4b9S4jZlSVHXDcLJpfLCORS19CEqla1q2p2P0ztVQ VY82d0wsjt626t6taZPTyeuMDpPf5gq4vG3L61Mjc4ramxtJh3tTLi9U1LxNEs16jc7vt80palXD MEK9brgL/ltJTzcW9bS5pKfBX6GeZj2rg7YYXGsnSKSo4X5Y/99X08S/GfVH1AaPUjh75nUO4kuU 7gXOk0Z31OVJuPgjglT4Kii0gO9epKadZqPTKmuJQfgMhUKqPzpUVNOQ95uhnn5A0dNdc3oaIbTe kxChGeTUi6AZq8GaAHYSArSa0YsAmlCEppfo60uBmZe+orp+oPvm6Z0tO5clBXQSpOZUbHXPtt6O yeFYcPjGFa2rAoq6bkWA1KgvOHx9iYknJjLHrnp0oklvkbVa0SrqbaLa4rS42q/qb1uXdWkuVNcU nhz/HEJWO+DO+BLU1w1YL/bQaax/9pWcmccXru8HkX1ZsCULOrKgIQv8WZDN4x05o8Zu11yfBNuT YCAJmpIgkgRwxXc8P4kBFFiCAm75YsmCU/A1WEIDNPnZD3IsvNE0zSYSVKCo/DsvUf6RsbcikbGx c0rkrIIDlO/qUKjoRXCA/iRw4KWGnU9MDd+4prVK0MeG9j+xu2owV6ODYBWoOIYLpBbWo1JVhHXB whW12+4dCTxjTkFA0N8FAUF2bTa3ts0BHlv+yHUXAgJez2l5g06BBKJu8OanSpDg0Pqmde1+BAlu eWZbNDG8GUnSRrganlX6y1UwgQligq3HMROlR5hA/gSYoOJdJJ5VIEGM4s1+qzcg4jR4d+Y+gwEC gv+4AiAI+QMKHIB4YAnk8wsKHkhjPeCzp7EUCtsXUXMa+A1y6yXzpSfJ8pOG8pOG8pN65AsUwcL6 kk+wT2l6DsWlDyTK/yZRTgiY/0Qp85HIQ/RhMYYU/2ZISTcofY8azIfyuJyzImwCKYrS59EXhFIa lX/TiELiTQ6wsFH5j6WH6D82voB3QPv7reNI4OYEsNKVvdRv5pVSTY1XlFLu7Sh6nkXvaE/Al7aX B91eHnR7adDtSOxFFsU0s8lWKgohUtcFEKmUxfBWMbj+glbtCmqay25HkoxFSn/+HpAqH4FfiqRe aJl6Ysemf9jdFBrY3dWyBiKpjQqSqkHBqz0TA8GfOBqXJndOQCzVsnlntbdra2d2Xavr4G033woG l906Gqtecu3CEpYaXpPq3L8KYqnd2fq1y/rcCpZaV92ZsCA01ZJxNRyY+VpsYEGrx9WmoCm0y2+F svTOfDSVVtBUWkFTumJPR92n7OlIvJOBxueux3YmmyafnkTXZ0I9G5o6N3d4gz0bmtEVl2/54b2D C277wedv+eEXBnO3vX7/3ofXh5q2P7AGXsPN2x9Aa84y+wF4hwxWfBuG4x7Ft7HguL3Y+W3me2ix XcG3UQ65Au+w0Pwzu0zqXwsmDTSGWfX7nMFs08suUSUrx6NIc6y/hcW1DrNoFjXkl1VM8aAUjWIN XHIRsg5rwbIIG43P+TY+W/ZtNDxfL9GxLcixkZymi63DinnrH+PYSH+8Y0OCv1StVc/cqTNpaYrV a9/sXFVvNEc7YvXLshGGRj08SLWYWjSeXPGZJWHrgr2rnwTv6MVu0apnaKjYTU6LWftG58TooMfb XCPbvFbUrkJrFLWC02GqGdiUadi059DKrwVRHD2UgioFIy1GGKnxEoyUy0llkPQ+BEi/QgBpi/R+ US4+Fh2B/zE6qmra+aXx9Nq+Wh5u+BqOq24fa20aaXFC+7X7agR0SVar3tmwMus1VLfH61d1RVFi N6KOkIbUWbR/OOxMDkZb1rf7QXXvNUuigtmKkm6NbgtUqtZ4e6i6K2ahdRYjcilbE11hdzosW71W Smcx8CZByzvtRl/Hhra65R1RlqCq21HaARaY/Yg4SPohfEhgmWMJD58HsyeCFIXF8+CpHC8FbYn3 yKhHEFjPZrbY9g6aXggjzQdI4O8DJCeuIKSDev5hldEloUy0Qg2EzBRC8OAQbXRFnN6YU/swFGO6 8Ahe+CLYDpo93nPlc85zlOCQ9XbZrMOHOR1bTArZrxIs+OKZX0Luj8/+kZChbmtH3Y4z4IkKSmoq oqTGPBBympq2/we5XrNJnsf1SwDS5dtxBi71Z6CVUGoUQMhde760IrGiI6qlSWXZscHM4vr29TnX 52+3hnwuwWy0WsG/o9x9ktEwhSmt2erQr7l3YxKsWHlwTZwTjSwnWg2CWacSJdHdOBRdP0pQhOwC p+02tWIBGZjCvwMCgMjQJOTd7tk/EFfBNV2HdWKt0+Fm1JK75Nkw5gyYJvWbWMxAuVw5/3uGLbn/ Km1/pZKUn965EbgAzFxVt/ELa/qmljb5BDHSve0L65wLmiKCGqdZNeupba9eNNHjw03pjv7gqpuW BJ8e3+pobW4wOdPDDQ2L6mSwbPC2dWlPdnTy9v6eez47uTSh4njBIqMwHlbDNo0f6Pz/7H13fBzF 3ffO7t7petepnU6rftJZp2I1q9gnN8mWi1xkyTY2Pktn+bAap5OMTYQxJsXBCX7yQkJM3k9Ig1Ad cBxMIEQKJErA5AMECDFPAiQhAV5KCMTd2vc7syvp5IaTJ8/z18Pgr+ZmZ+ZXd2Z2ZmfW5LYbilfG Wq7q0tvdlo7PrsjKql0GOxfLp9l37NUxTIM6hqmnYxg8mVYcSu40br3MGKZ8+hjGQjfBjw+KFnd2 Sma+XUO+d+6E3e6w8fvpuqRwzOFJSTKdfdDIFl9tRiGSl5ND5wYxgmmG/iPQPx3BNHPLnuBKeJ7N aPBxMxrVj/OJ6Izm0g9oGqrn1leU+LQa/8spWxpfVg3Czpz5V6Y1lL4qvjdWbROp3HrH5s1f2VyS Eby6AT1vStFVt1y97uY2f3L5qtogPPLZTZ1li0uSXCXLaze3SSlV6+bObS3Fg8Sa+nlrKxKJseGa xb7cBZvqAi1NwYyUWcHmGdUdi/25c6+q9i+eW+vx1C1cTj6YszQxtzzDWzZjRkrR+nFbXnVpSWp6 VXm5R6r2JXlmVEysOWCMB6VwBU9wiXwxVJHBFz/CGVKPEMMjVvqdB8PDmjVqx/z0m8UX6ZkTL1x2 mHPDT4Y/c3iouv6GJ3YN4+8jhctji9uvW5xZ0DLQ3HZdcya/+/ZPHrh6zb0nvnXHiYNXr7nvxF2m /c/srl269yfXqn8n1x00SeibPY9xmbw9qE+yG01Gz0pNK32V5Dl2fui/YdHBpBcX3mYUTN4kB1t0 wG1N6FEf3MSqA3TEnu7c/PqpnvnGR4326llK5xxgnfMq2jn7Htauju+cLzuD4byChQc6hVE9sfBw uj1SZffgNq3Z1FRsAPsaXqu316zpnb3xSxsC7sabe57ji+ksxmKHx6lPsHndLm9SkpkYrvrKdZv9 /qU1WVn5mTp7eqIlyW6x5eakVly1c8Hsz+x/6NpX9I405bQYYQfkVWcyyi/opdfFzWQY2UzGx7Sj XuXGT9VV/pv76h2zrr3/2ob+tll2nUYwW4zlLb0LJxYddkzMZPRNLjqEFs80q321s6Ktr2H93qlF B3LNii921bq8ksXs8rqz0zLOX3OwJmQF26vomkNWQSZ989Kc5LA6MnPSilfHGusjK2YZeU3ZanXN 4bQoalxsLqNOmcswT8xlnDnkZvMYUJjoZ931SkPrZbvrCz/HfOGyg+hyPKNzsfkM3bm/TC47PKNx ZQa82aUZlmecTrrssJ7cQ3b7MsZfn/iqEMnU2tKTnBmeNDv/D3R5ysrD7zL5V841qz5wjcaCvnoe 7aufPlxYXsi+ol022VfPCOoDsz/OytIEViRPN/wVdteXWn9Qu2u2/jDnmuXFFvryBO5Fg29euPEy KxD2DCk3ma5BkO9s+07fLFtSktHk9LhsKTZdkic5a941i2dvrM8Q2TKENVPSO9i8xld5npCKzV+g 70GoKxG8Vhjh1B3Hwg3QgjpD36rO0FfQGXo8jRcdSl1hbP13ztCLTzvS01IsZ35tstGXiugDud7p cebl4ZEc/Kkz9ODvZxw3MUeNO9XJ+bl3gynnHU6XO3E4XRHdlZxLn7mLSNyxc/SsRRfdy++ij8Su ZBp7nC9CzZJyEJCkPrJL6hmNkrqhH3/fpu9s5dCdU3xRUG+QMDgNcgI98C2op1/MMyw38BzbkW5l xzeyx+wRNqeDRz5D0Yw0pXfJjetd7A6iPAPT7ea2NzfEnwnIHoQvc8KdGNf7iMJYcc8Pdu+8Z4u/ pPsHN16Pvz+wpPnrlpa0XlPv9jaEm6pb633Jev6Ltx9/ONR274m7bjvB/j4QOjDUWpXSsu+J7v94 9saanHkbo5+dmG1HHxTg3grm5HhJTjrJ8ZDsNJKTSnJSCN3GnEQKmO4dko3OWdDTlqm6SwhHVcsV qCcrFagKLVBPSChQFVqgHoxQcAQ9nMWbTAslGyka7ersBP6y2Qq7OjsRlz5Cq2BHB+hR4i47sTvh nHMOZa8ssB0hCROdEV2hV7fzP0c/IseOOvX/XJ1imNqBvuG/eYlAePV2g7JEYKMdrSgS+i32M7fS JYKJNQLW294WNBdUEr+XFKTT3fzBIxMTjUHipl7sZvM5bqomN9xwsltWdD3rx/wuzqgox0j37hvp yZRX3F3TaRm1x56YhmG79P/Zzvu89YczbZFZDk9FSzn7zDT9mDiv0SXXrt1Wq3Ten+t7jp95+c7b l6VzeBOtbpslMSc7mXXe1996MMo6b7oOgTbhK7T3JprHuHVQmYeqbB0p1UEppfTGL2V6K6V6K0Vj FjTQ7n1ZspMsDdJTI/KQJY8eZjDZ4+tsE+fssZJpEvtsoeKyGA4UHeZ0RvW7zPT+tqiuaVG93UIN 54QZLLX0EN7aINs2X0uY66ourMyr/RODCj87KKFYmUVTZ9DYGIMe3OqYNTV79l8fbPyLyya8Vues ae0Lxi+bkOjaW7dUJaZnWNi6iUfKxWCjtayqPRg32Fhb5aMvOPjYugl9ycsJOwdWD6qDjYSKFjqj VoK+6TfqWONMsIYefVFE8meQnHySk0dyPSQvjWSzBio3meQmkTw3yUskeS6CfgcmztGQHJH40whr rRxKa1XkTkbELdnU06WVU6XfeJSeOu0JBGxH5LPBdOSw0dvPRj3CRg+EsdFOxEZfRrU9ztvxtCUq bZWIDmDiA6BBA/0CqFhSfPlBEO0DqAnVk+X8ZXZ6sjz7APfEHXjef1c6VBJ+Q5d+XMrZaefeNdnM Gvq2PXlR4/TO8GaWem1fsSeOf0sZKvVn5o3/beIwGGLT2rzJTjrPJTjou+YajJfO/iKbf+dcjbL6 877wVYwSZnOjQXN+FcmvZEfDCqzF+pHSYFWprVIVnSs2wtWrfgxN+aB6H1J99L7wWZaX9ZXtKhPK 0ql606l609kNl05vuPQf8zM5DrWofelhdp618wg9KJaekI6HQzomM82o+UTKInSZ6bxh2QZlXOYn tlfUO+bpDS8pN4+iXKrdS4/UPn3lqdL6z6w8kbu2fruvxp6SbDHZUx12uvSUnirN75pcepoaoilL Txj/qCtPGP88wymrJaeFg2x89tvHODvaLoM9kyyx25T+8W21cWFdrV09Agd/TzJfjLEjdmxHJkrZ bMphMKyUTS3FLhvpKT6DNnrjaNUDfDInLJtJ4pYLXmXLBIlqjxx34jqrE3/fOIwybBJk2tBR6ZKZ FfzqiTsTB+9cbG1HPTPkUos7GoNFryzvTI0mrXp1NOnDoNmpV0aT6voOtHmUo6PfJv5p/pjmr3yC qEEffCdSsvlnyaDmz0jRqinN/At8F8uToKY0oNRalqJTU3L5Z/nDmteRoldTFiDPas0xpBjUlPVI OcBKGdWUMpTaxPKYJmk9zd/B8pjVlE38YtKh7UeKQ01pR8pVLMVJU9iYuIA/xi9hKw1sN+ohthv1 Ebob9SnrjuynNJ+JX2TI/ZRFBv5Y/srhNa3Xt+T5VtC/y/P/T2rx/BllCwqdaSXz/WXz/Y4nrrrt mlkVXbdfve72a2oqu24Pr+qbl57ftLUBfz15TVuVeYwSMsgvomsMj3GZ5KEfsmmMI8R5yHOd5nr1 /Uk2laG53BrDoM6RRnf+JdxucRg0vEaf8GPBiKGAK8UsHkmgb7tq9Ql8rCWBN9AX48wGTR8ReULf 9aZcNMuVfBd0U8nNeAya+eRwUWZRJjfzCD83aNAnverbYSp/StjJqd/5UmYsGEva89YTLvnGhZvv MlnGC410Zk5nNny9rD7LEKzNrS2S6DchBa2jsLbJN+fq2RnmQNuia8gyk/XWdK9octttbqfd+NWS ZcHK5OI6l9ultSbZ3GmOlESLVL2sKHtB69b5YbaLvgH2XQsZltE1hCLyYtC8cFHOwuqchQtzqgVL yhHycTCVsywuDLpTmwoPPu99w8t7vZqS0YYd7p+ppmeNoX/Wp79hUXn+SKEybpJ5cphAv6ks8Gv9 ywcWFi+pkug8g8GklcrmFSxZmVzaVNKkM9BnbkPCglXtdfU5c0ozMUTmBY1pRm1T3uwN9enLlvoW lHsSq9vrJJPdnmC0JjncHofLXleVXizZtBYM9Vwm7dzaQKUzyZmcbnaY9aYkl8VT3uhv6rTxQnpp UPlWXwl/mJ8f98YjuX9i9uEmulKQHBhVe93rDNdfaurhyl6lEGbyh03mIZ2NuaN2/EG6eYXXJGhJ OoyQk+LxpZiGjJbxv/Cnzyaler4+sZfz6yI4t6YkugzkUW0C0hLQhPkkcuc4fdJaANuu5uegJ62g 71HsnlghIC8ErZwl60n6tuNvi7Ynj04Z8mLvOV5R76Xu4uZXF60aWJjdUJFnEkX6uXpNQkrBnOL8 hkCyy984M6881WF1uskAhgqixTz+mjOQvHDrgqzS4OZ52TqL3WDAyB4ta4LVYbFmVfqkkgyLzuEm S5NcOkuSJV36IU8yalthnfWQ7QD8NoAH5TkP51cdIT/4oSE52VB8hBwMJuGhuNxWzv+tnJQ/VFio yRqx76j7aZyUG66NXw2Ia7QuXA2Yvjt9ohk7kLO4u2l1bzDN5C1f3t+cVFwomXS0tdCl5JSkVy+f mUykdbULr65LvdUilecVLfU6c6py8yuyrIGqqxt9VR1faCkJh1obcjU6k8mdaE80a3S6hNyGtlJX ek5wbX1WRbYz2bVgXWWSGw9hsGUZvHETbJnB5dM9k39XVgHIJ/SMd8Hx29TtxuuvYA1A7ev4TYKg E8ffEOg2Lo9kFUhg/Etmk6A1aMmH6O80vGhJdDiM576m02vRLJp1fCzDg4ZRpzEncWwloIC/A9rP 4GZwddyGJ7g88iBn4yTyYNCQakxPtSHoih4nD6OzqCIPBz06f5nAZduy+b9lk+wHEndYazJqeLmG 1DwgUKtsuJb+u/j7jrnqLunyymnLAtoEtzv+ZcdpK/T8Hd/88txtzb617blVea6s+V3z53fM8S5Z 1LrhvtlzgrOtmWW5sRRnfr0vtyLLtmjpkkVkWw89T6exo8BeUFydOaO5wptauqBwTiinIETmBWaU FLizJa+tevwnKfnZWU6nlJOfVF5aTC2zafwg6eBfpnvI6I6oG9iOqBvpjihy/6HEDOPN3Jyn47ZE sWNt3OomjOk7ojbV1tRVi8SYnGhNtOr57IpsuyOnPJPozEl2R4pJ4B8dOn3TnjM76EiaFzXi7Bt2 75k//+bdu+bwdGOGzghu2sHNVYybHLof6ga2HwrGofuhbjxkTTUo7NANURP9dcKEj1TS9jh+Q9RV juyKLEFvdVvcyUahdtasWp43JTvtbouWZFXkOH82f8/uG2aDE54O7Heeuvmm00P0DEy0xvycXbtv xn1aLX/Eh/mvKuOHoMPFeQ22FJJy0LorA55wUHMTrA/j434cfWn0019S4MNZC7c1Ldo6NyNz/rZF y7cFU/fZMitzs8szbU7w6puZYSaNS29YWxZoG25Z9Jl15ZXrdy6qbqtJ91Svqp6/viLRW7sKWiqV T5M9/Fcwfkin44eDQQMbQJz17NLsjh89XPYNhT06e1oiPTSOjh5Egub4cVFvTrQlplg1dnqaA0+3 HZ9cliDoXXakG8RewhMCy7HRQx06mVRoppKrpKOHl35ERw9FdPggBm16WxJJOujbZc5AE3ZQuJFq qYypKX7h458YR6SaDeMdJivdSWc0fja3zGuuDGRV5KdinKkRNJb8ioZsaCjNXrCo6mqSbjFXeFIw jnBaEx1W/c7s8sCMlPwym5P2nnaXy+ZymNLK5hdkzpm3tKiFjSOKYGcbpFnBbaTjiENBc9PSnKaa nKamnBqBnlfxclDiTBUVBbYSUnLfvIwCUvD9DKvVlZGhmbcrw0Vc96uuwHrRYtv71+L/iXnvi4wq xMtMQFRO18TU9APGFTZf05bZWXPKc61avV7nKawrzC7NsDryZ8+Ym2BQTuFoaFxcPiu9vCBdK2Lw QQSNIadyXl71yqo0Z/ZMr6++wP1Y0eLydL3FbktJTXNY7RZbSqYdTw1mevKh1WkUZxZlF9ucVtHk tBitJp3BaTen+Otz08sK0nViqo+uFLrk03w9/yU2uqhXRhefmxhd7Ao63PlpGQESuE8dYNxg2D01 wLj2ykYYzrgRhkBHGPUmY7N6IFTC+B/pygURE7TvCZak7GRPfoqh2WB+jx/71ZFUz7V0dYceMnCt iNvd5nbYDOQaMUE5VmU8lkQWjL/I+qSPeCf/ea6aa3iMKyW7DufMyJlhSjsC6ydzJuq592CsaIMN HyoYznAT932TtzvthK/99D0VedOGGu5pIw1nQXMkWNgQ8OAm02i1+qS8mqKM8jx306LArCS71eki q41mk2n8lLPYVrehIeuF8lU1GXqz2ZCUTLcrm6wmc1phelm5zuoiqU57cnp62i2EpJQ0sdmgj/gi eDPt3Roezp1Jh34Gt9sA49wP2QzUie/2+TQ2iUj3oCmrJtX3Xky2C8YX/CXHF3nxw4uirLlX183f VJ/uXbRzvcufl26ii210ZFyQWjqv0EkylhXVr5yZdEtxXUaDx+ot8qT70ywvF62ak+tviS1a+tnN szQJRiMe3V0mMSFB6y1fkOdwZVQsLq2Y5bSWLS5Ockh+5cRd3goLpnN+Oqr4jTqqeCVo4hI1Ngdx PJQ8bKSuB6c7b2QhTOznjt9+beV5neaEYHTS97ptvEg042NGs9lIDrODTFeZXXaHYdxEG0dRb9IR OTXdmywYE+mYIhc6L4POs7lSbh634gmukNzMubgccjN9uyBTebug7HFyP7rWOvJA0GEoqtLY8kn+ 91J2ZTSQhrvjDHDxccQlXjCIH0nQg6qmvV1QyZdJczvnzw0FpcS86mxvSZYjrXbjvIb11alNdQtW fSNQV1NaUefKTbPZbVkzs5J8GXa9p8w3t+IB34Iyj9sfLPSUFObZrBn5gfSsOSXpyf6a7PJl6Rkr iZhdWJCdUZRiSExJG3/G6U1NtZiS0zIcdm+SxY9n8Wr+Oj6sScezOD2O4vNIKeV3kz2aFKQkqil1 /Of5VJbHraYUoZSNpSSpKS5+N1+vcSElWU0pQx6nBjYUU9SUEqQUsVKpakoWSllZnjQ1JRd5ylge D03hiNws/6fQq6mg50A8xjnlkYlvC7L3O506OqtmI0t17AAAUkxP6C0tmb7plB4qkqWxuDwud5pR 0Ak3ayyJaYmJaSZBp9PrE/DM6zRp9DqjVkiwuIwwPPetTw/EGxduUQKf8CnhHhb+frEgtCG8Mj2I ezTeuPDViwetdVp4cyokNH1K+N3lgm7OJcNBfWJcaFPDDy4Szhlik+FFFsanB6OehRaEpxFOTQVT n+m1qWAuuES4kYXTSrDcGBdGlWC1XzR0WN+ZCrbayXCbEuzzLhn+07F1KjjrXBmucdd44u1KcFde JDyWtC/57pRlqcY0S9q3LgyenZcK6U3eNd4/KCHjXqlNCZnzJ8NLEyGrnYUXLheyt7Hw0FTIuTVX mhYeunjIW8DCk0rIv3kq+PaoQVZCwQMFR84PhYHCN/wv+988P8y4q6jkouGvgZ9OheKcybBnWjhV srnkSKm39KbSP5XdPVOY2Yjw8Mzfl28oP1R+tqIL4ceVZZX7Kt+qqq96ruq56pzq7f/j4c7qn/5v +N/wXw+zxGlhpRr2IDw76/0rCzWJNfWTYVNN5KLhkVp+MiyuvY2Fb9R+99ND3efql9e3/cvhe/Vv z7569vicTXN+E1we/FqDF6G74ZdzK+e+OK983v3z187/5oKfL/j5QufCNQt/2bi5cawp2PT4Im7R f1wivLk4e/GdzdXN/3dJ8hJpydYl/Uv6l2YvPbZs5/Lelpktb7f8bcWtK76GcNeKe1c8suLxFU+v eG7FKyteX/H2ZPhoxemVC1Z+YeW7q7avenX1wtVPtmpab5kML65JXRNec0+bpe3udl37YPs7a4vX PoowsvZXa19c+9raP699f+3xtfI6HcLc/+nAVto4yzc4wveYOE7Pf5lzcDWcCdgsfwDs5AycQ2iV T3DJXI38LrBTfgcYk//OJSP9V8B2+XnOwznkt4HN8hvAjfJ7nIfw8h+ANvnPwFT5j0Cv/BrQJ48A /QwDDKsZNjJsZjjMch6gdZIRWj8ZZbWN0bgQld/iakCdYjv4rAP1R4DN8jeBG1lKDPnrGA914OFV YKr8OpDyUAce/gr0MwwwrGbYyLCZ4SBkqSNDDIdZqb0svo/hfkoFHB4DHmYpI/KdwFH5W8Ax+X6u Dnz+gWuG3t4CdkJXzeDqXa6ZHJWPc83g/3lgOzTThjwxYCf03AaeXwLa5JeBqaihDTz/FuiDXdqI n2GAYTXDRobNDIdZzv3gp40cYCljFEGLB7aPnwF2y7cBo/JT3EbQPQHshDU3grePuI2Q4h3gqPwh cAx62IicJ+AHDvkVYI38U2Cz/AvgRkjRieDhOsHzJqBNXg5MlXuAXnkxsEWOAAfl3cAhhsMsfS+L 72O4X+4CHmbxEfm7wFH5PuCY/B3gUTnKdYL/ALBN3glslyuA3fLtwCjoxsDbu8Aa+fvAZhanvMXA 1WNAG3wjBq6OAL3yYWCL/AxwUH4aOMRwGBRj4IrG9zHcLz8KPMziI7BCDPw8y8XAiQ/YLpcBo/L3 CQ9f+gToZxhgWM2wkWEzwwPy+0DUAxyV/w4ck48RK8p+CPQzDDCsZtjIsJnhfvk48IB8AjjC4qMM xxgelf9MbJD0Q+Aw0Is6PwD6GQYYVjNsZNjM8ID8DyCtzctq86K2j4FH5feID7W9CrTJvwGmys8C vfJzQB+76mcYYFjNsJFhM8MW+WngsPwycL/8FnCEMwNHOS1wjDMAGRVo8iZgu3wdMCr/CriLA9+M up9R9zPqfkbdz6j7GXU/o+5n1P2Mup9R9zPqfkbdz6j7GXU/o+5n1P2Mup9R9zPqfkbdz6i3gPox oA1WawH194FeaLWFtHBO4DBs1wLtvUlahFYuCdjNLSLrmA+sYz6wjvnAOuYD65gPrGM+sI75wDrm A+uYD6xjPtANir8H2uTnganyL4Fe+UngsPw4cD9KdaPsceBh+S+kG9weIoOM4iCjOMgoDjKKg4zi IKM4yCgOMoqDjOIgozjEyg6xskOs7BArO8TKDrGyQ6zsECs7xMoOsbLDSDkBHJVPAsfgRcPQ51tk GPp8jexl/ryX+fNe5s97mT/vZf68l/nzXubPe5k/72UeuJd54F7mz3uZP++DTl4B2uQ/AlNZihdU 9sG+ND4svw7cD73tg32dwFHOCKT23QdOWoC4Q4FR+MN+cPU+0M8wwLCaYSPDZoYH5HeAI7DsfsbP fvDzGvAo7pcD4OevQBvDVOQ8AH7eBQ7Dlw6g7J/IAdAaJSPI+UcgzTmCnO8BvQx94HAErTfFAMNq ho0MmxlS6UZQ5/vA/dDPCNpwA3CEMwFHGY4xPApPGIGkIWC73A6Myi+QUVB/B2gDxVFQ/wDoZeiD /4+COsUAw2qGjQybGbawnJT6KO3dgAc4EUipj4K6DjjG4kdhx1Gm51FQhzeA+stkDNTfBNrA2xio vw30Qg9joG4A+hkGGFYzbGTYzLCFlRpmpajPjzHZxxj1MUZ9jNl3jFEfA/VeYLu8AxhFW3GU9vVA G4unyi8CvQx9sOZRWJ9igGE1w0aGzQxbUOdRUKdl98OyR3Gv0fQR6OEo/IGmjMkf4J6v4dzATvl6 YEy+RmiF9V8W2tEHHQPWcE4g+iBgp9wFjMn9Qjt4eBXoZxhgWM2wkWEzwxbU3I7aXgKOyIeAo/IT wDEWP8oZhHZIeitanBr5NYG2GxRtDL0MW+TfC7TdoLhf/p3QLRwffxt4Qp4LPCknAE+NnwCeHkd+ 4YysBZ4d/yvwnDwHOE7ziBpaStTSUmICS9HRUqKelhINtJRopKVEEy0lmpEnSvsdoJ9hgGE1w0aG zQxHGI7J7wk3QF6DcFzoHn8KeFJ+H3hOfkM4DoqIo2Ya942/JYDy+AfAc/KHwgmkU/TJs4WTSP8D 8Lh8AnhGPgk8K38CPCf/Wjgpamg6uEW6aKTpKEvTffJC4RTKjgLPyS8Ip5BO0ScbhNOM1mnhNKcF npHHgedg39OinqagNqQgP03xQfYzyP8X4HGkn4GePwGehHRnhFMsfgY8nAFXZ4G0njPgCjmhW1yF pMgp6ljcQHOCT+Rk9Z+B7P8QzmKcowWe4AjwJGQ/i5rHgWdkGXhOfls4K2rpVdSGq6gNV1EbrqIe etUnFwjnwOd+4HH5j8ATXDbwJHzmHGqD3oXT8LpzTN5z4PZV4DnOBhyHJ58DzygFKigFKigFKigl 6mkpppNz4BylRBMtBX+gpXzjDwrj4J8HnoQVkAueOS6Mc0hBPUgBh0gRzSzFJ2eKGuoJQHiCqKGe AIQniFpqfVFLrS8mUIsDYXEgLA6ExcUEanGggaZTiwNhcVFHrSzqqJVFPbUsEJICYRFRTy0LNNAU qnnRQK0JhDWBsCbwFIvDmkBYE0jLGqg1gVp6lVoTqGNxA81JrQmkdRqpBYGwIBAWBMKCQFhQNFIL AhPoVWpBoIFepRYUTdRqQFgNCKsBYTUgrAakspio1YCwGhBWE03UakAtLUWtBtTRUtRqQCqviVoN aKKlqNVEM7UUEJYCwlKimVoKaKIp1FKiD63KO8AT8ibgSdkDPCUvBZ4e/xB4Rl4APDv+LvCc3Akc lyXRh1YFpaArlEKdKAV+UAqtCkqBH5RCq4JSoIVS4EeiH5jis+jrC3S6Hc8anBonnIX9EtheGYsg qnGBKxEcalyMy6PBc+pcNa6NS0/gTgvr1LiOKxSeV+N6ThJXq3EDf9dkfiO3RoypcRNXKD6jxs38 HeInatzCdSfso8/V7L+yhJNqnHAJukI1znMJ+p1qXOCS9bvVuBiXR8OZ9F9X49q49ARuWP89Na7j EvVvqHE9ZzNkqXEDaZnMb+T8hjI1buISDRvUuJksMUTVuIWrND4JTgh9r1OVlsYVPStxRc9KXNGz Ehfj8ih6VuLauHRFz0pc0bMSV/SsxBU9K3FFz0pc0bMSV/SsxBU938vR0+VKECoRW8pFuA4uyvVx A/i3BU+CEjcPsSjXzzCElAhivVwAVxq4bgSJW4m0Lm4rrg2wX2H8DSP3ELATOeehXDfybEZaBDki LF8I/3pQVyfL24tfA0jrZdeU8hFwIOFfCPkiqGEHfm1HLAZaNM8gaowhPYxflOdBlO7E9V5wQ2vp U2uNIUePSpPmkCBjH6NJqQwwWRYxWbcghco4iPQwKxFlKd2M65gqRweuzGA197CUblZjCDpS0ieo 9KCebqaxfpXLXqT0MKpKnVTOWBwHlGI/k0XR94S2Fd4ppT5oQIL8isYpVz3IGwL9GPtFJY5N2kPR mUJFYrz3qnL1Md1uZjmnOI6XiGrtOlZOkXobfgeYP8RbM5/V1sNq2MH0MKhaPl7f1GKK/GHGP5Vf sUuUeQP9q1CktpZQR/+kNAqPXWqeAfzaqdYegxSKhYYmrRRiPhJCas80uSa8uQOchBj9DpV+gHls F7MVvXLhPVBzgdQ1k3dNBbdG9aKI6m8V9Ow5hIt7fVj1X0WakMp/F7uq8BNWNUZ57GSeS7naxmw2 UebiV7f8U3fwlLcotmnFrwjjgdJfxbw9Ns2OxSoHfXESdKj3XYxJGWa+vAQpHZyP2bgAeTpZ/Y2M K6VsDKEfWixG2M5CgN3j0zkPsNp7kCcG36L8dzEJ+lHDDqRSC25hstA7Z3qtE+m09VAssG2yvrWM Z8VrdzBvG2Acxth9NcDaAaW0xGSg92SYeVSE0VA0tJmVndDeAuhvCVpEpWw07opyP3cynUzdo9sZ rQ52D1+MrvKb5u2AFw0yHXZO+nwnu97PPHZHnJ/3M0l7VU9X6gozpHfu+XLT60oL4UOpAuadPZAr PHnPXshV7wU1X7mOpmqfaKUltZ1VvKdjWnt3oexT/jqdr9o4DVBJFFmUVn/C66OTPUgna0N7WVsa uqSkip5D03QaVr3//HuAapV63iAr2cnaIypNeLIemrObtWmXs9C/676YuieKGTf0HlB6ogCzVT93 3b1SWUlJpbQ00hHtG+jbEpPm9UX7+6KhWKSvNyA1dHdLKyNdW2MD0srwQDg6FO4MzAt1RzZHI1Jk QApJPX2d4WivNBDqHZBwPbJF2hLqiXTvkLZHYlulgcHNse6wFO0b7O2M9HYNSH3IGgv3oGRvp9TR F+0NRwcC0qKYtCUcig1GwwNSNBzqliIx0OgYmCEN9ITAQUeoH3FapGewOxbpR5W9gz3hKHIOhGOs ggGpP9oHvinbqL27u2+7tBWMS5Ge/lBHTIr0SjEqBzhDEak70gtafVukzZEuVrFCKBa+LobCkW3h gKSKmT8g9YR6d0gdgxBe4Tu2FfTD26VoCLJEIxAbBUM90mA/JYMau5AyENmJ7LE+CDRERQpJ20PR HoUWVXPH1lAUjIWjgZXhrsHuUHTSAjUTpGuoaSrWQEUQSqoIlJTEqT4M/YJMCPV3RSgfYTAWDXWG e0LRbVIfvRL3c8vFDczUAmlaeyMxlF8VC8UUGYtRQR8j0AHbxaKR8EBgyWCHLzRQIHWGpcZoH67G Yv01xcXbt28P9ExUHujo6ymO7ejv64qG+rfuKO6IbenrjQ2oWWl8SwgCbKP51vYNQrU7pMGBMJiA SPSyFIIlw9GeSIwytHkHY29B65IGXI2yH7Bz56Bi0e1bIx1b48rib6S3o3uwk+qiT+qMDPR3gwDV eX80ggwdyBXujQWkCdp9vXAIX6RACvdspoWmquqdyHxRjlh26tJQ/wDU06H43SR1ple1rlrGgC8C KnB9qvoovUE6+7b3dveF4omC55DCKRQ/aYG+wVj/YAxqH4p0hGmereHu/vMEuhJbMEsUd4a3hHAT BUID/ddNPg9ycjL3Oe5i/xHkwBMF5+QSZJmz0i8fsacojvg45ZGHXLTcxH8O0WcyEeThrzi/2Uzz C1ec32ql+cUrzm+z0fyaK85vt9P82ivO73Qiv0M4xdGnSpHlp0/VNRx9nk7mzJyHS8XTQT7a5HKk NnB13DJuPrceI4etXDPa5zbuJm4jdyta7G+gpb6X8NyTxMr9iti4V0gq9ybxch9A+6dIC9GSdcRJ NhCJdJMi0kdq6LoFGSIryTBS95KtZB9S9pMbyQFyCzlMvkZGyLfJKHmQjJEnyVHyrLCYvCK0kj8J beT/Ce3kuNBNzgpR3iTcwDuEXXymcCdfIrzHNwrv86uFD/iQ8CHfK/yNv174iP+C8Hf+duFj/tvC J/xB4QT/hHCS/7lwiv81/Q78dPn5165Q/n7IPwz5vwj5vwb5vwv5H4b8v4D8L0D+1yH/u5D/JPER AfLbIb8Xks6A/LMgfyOkbYX8myD/Nsg/BPn3QP4vQ/6vQ/67If/DkP8JyP8c5D8G+d+C/B9D/jNC O68VuiF7lPdA/izIXwb550L+9ZB/K+QfhPw3Qf5bIf83IP+9kP9HkP8pyP885D8G+f/8/3k7G7io 6rTvnzNnmDcGJTOlvVujfUnR3WJbM1ZZm8zMyBfUtGx7mbQ01FxyzahQB0QjUx9QsxREEESF1nyr rC12XBRBXXwBhbglYJCGwYkBl5SKmPv7PzO86OPd52mf+3nm35d5OTPnzPU/1+93XUfyL/E2Xxt/ QEmv+PsQ/23EP5T4I3h1HPE/RvyziP814n+T+N8h/mzi30f8fyf+88TvIP5W4v+BiM3EH0L8g4l/ BPE/RPzTiH8W8b9M1EnEn0L86cSfz6OPib+Q+M8QfzXxu4i/Qz6pCVSiNAOV6Zo7lcc1dxP/KOIf Q/yPEf+TxL+A+JcR/2bi30n8HxJ/IfGfIf4a4v+a+L9X2hSjclUZqLQrdyjfKsPQ7r3Xxm/o7BV/ X6IfJP7NVuKP5NVH+fkk8ccQfyLPUok/j/g/If5i4q8g/hbi75CDiftnxD1I/AZVHk78Y4l/GvHP Jv6XiT+B+FOJP4f49xL/Z8R/gvgriL+e+FuJ/wf5sMYoH9PcRvzDiP8+4n+Y+KOJ/ynin038rxD/ G8S/jviziL+A+P9J/BeI/xLxf6e0EvNlJUT5lzKY+EcQ/0PEP4X4nyb+mGvjN8/tFX8w8YeqKxXe Lf6fBvI+kiuSsdIbxL+JV/YR/0niv0D8buLvkDXyQLmv/Cviv5f4xxD/NOK3Ev/LxJ9A/OuJP4v4 9xN/IfFXEn8D8V+W12g0coqmr7yFeD/UDJPtmgjif4j4nyT+ecT/KvEnE38q8WcQ/w7iP0T8BcR/ lvi/UtxKgPK1covSrPxa8Sj3Ki3E2qpMJ/4XiP8V4l9J/O8Qfxbx/5X4P7k2/uDQXvH/nPhHEv+j xP8ij14j/tXEn0b8h3j1HPFflp6RFel5ub+0WP418Y8h/mjin0X8scSfKH4nzivbif8A8R8l/gri dxH/9/ISTT95qSZUfktzF/HfT/wTif9PxD+f+F8j/hTi30n8R4j/LPFfJP5m4u9QFiiKski5VVmm 3K4sV4YracojxD+P+N8g/jXEv5X49xD/CeK/QPxfE3+nclXbV2nX/ofyrXYwdv97UScNAbJBF5ts 45Yca9DJBkNLchK35BaDli0tNhv/2VrULbzcIbYZZNmgtflvBkUyaEN9N7u6t+SUTHtmSkqywSAb TIWFO7ht3qzu4MiRnJyNG9esUZ/EJam3OPUzLcnJyeJA6kGtKTZLaHCK1RAgGXTt/n0bAiVDYFJo UmiUJcoyhRFqC7XpAmSdvsUQl5ys7kbPN00We9JpZV1ArPh6serrBvEW3qS+Pza53WaLM2j53uGW Fou48SadLi4lxWqLJXDfnvYWi4/4YpX8sYpvZ7OJ+DJTrpkFnUHWmT4qeYubegzfh/2H4ya+Bt80 2RemTpF12lrfB/mmulibPTy4Vq+V9FrfFwpXPyne/d6LugBJF5CcHB0dGqozSjpjsi3ZNp3L918w DD3bLBax14BaHthqe303yaZoJFnhVZ0s6xSbqP82mZtiCwyQjAEGQ3BwqPi4zUY2a7W1Jg2fFU/F zWJRn4oH4mazGY2yIXCQdIc0ybbett2WY0uTLGhDPVVqpGqsPLFmqqet3b+Fw4Raup/EGgz+t4WH R0entAcH+861yLSuLREW9WT6nrSr31KcKN9xxKFitRrJoFjsFotW5CCR1/oeWEhEMkwfMVaEMDbi fySt9d1pLWbgsO0w0W+3bWSIE3JteutlgzFibCI3Di4++3+W3uYfSW9jgGzU23rnt86X3+oGQ3eC iw3WlBaxQSsZSfAbZXjXzm6Q4katbCTF/TlulGVj95T81CQXGtxrvy7JVdlZbpzluh/Jct0Nsrz3 t/vJaR6o4cNdaU56q8+78pyXTSbZYL5dCrVNsqxnbLK8zUEs0mjVMfU9qc6TnlRXt3Sluu+JP9V5 0pPqPOlJdZGo3akutnSnuu84aqoHaCSTmuqWAEUyae28odb/iGHUy0ZD5Bg1kjGR4pmxPUmkX2JS u3qu222+hG9Xt4kNneLHtadXJExAsP9Wa9SxzyRf0icnGU2y0WznlmXJUudjvWUNw2iQjabDWVmp b721cuUK9VnkmARx42uIHbSjq3Z15+JriDqjzodRLxn1nV3HMgbKxiCR+6v92f87m8h+fYCsFzMY R3qYdLLJwG4OHWGHRw6JTb6qlRyrbtJqtYvXsGnNYr1O1ova0mGzxZu0kimgWwIW3qnXx4vptPGG uGv2mZTkmwy/DGymANkkJOKfAJMsm3pmyqY3ynrzAemkqn3fUI/r31XXd0jyHcX/+pFD4pNaWe9X hfpYqNgqpltMftc3DVd3oH6egMQ0iOwn/fUmSR841jLWMtQmxk3STQTYs5msUffZEiwSvcUka0wB 3fqwYZcarchtvSzrCUYoxKb+rWCbLUgnBeq02mtUImsDaoMU2RQQ2ksmoeor4oHvxqZAcfr62pjn 0IdD3wpdH7reslbVyv2S/6z7xaI+84sltN2/TT2kpeeZLz/IHX3IkCHjxyd3GAxdKYxgDP69oBif ZNR3dqhfnG/efbwu0QRqfaLRSoEBtRynxf/IGlxrMsgm4+gHfIE9MFo8NXUkqsmbkNihJkeHkIzY 3KFuFVu86vbr0kHNs+Bu6aifTeqqF0mmQNkUZLfarZncUkNTSfPVoSLd1Z0K9fjkYzLKpsDRXGra et0ewHHU/Qkl+aSkpqZIfmuwmA+TXjIZurUULI7WJym0q5T0kpMvKbXx5FSgTg4Uqd9bT3q/ntRt 2hsLKlDMHie6W1F6ti0TaW6LT0yMv3a310sqMEAOFJLq0lSgLAf2msT/KVGJUOJUn2n5fyGqQFkT 2CWqf1dVfRQ5sJeqhJrUl3pkJTaazZzJvvbwUEvwuJS3UlJSUoM3hK6xWySrdLtNzQl/Cy0mJEBj MoR2a8u/VT10qKWj+2kcp9VvfCHd8lKfxhNCr62RFv9J9D3tFpil+7jqseP0imTW+g9L/2pGWuJd LV2PhbUFGuRA46DnfNFanhsknpvaV/mklriqXc0aITW/1gKNcmBgT1p4e6XI9Smj5mNwj/IC9Rwq sbtqJQYGyYF97SH2kMwhmUNSxqeMFz600rDSkGhQj2K3ZTJSGMm2JEYiI8GmbrpNmn2NFB/g+W2S egC1tvq0qH73uCTiCjeIyQvUS4G9xBisfoFEDvdQsG8MEd8kM9gSbPFfBKFH8tGsl81Gn3JEYT5y 6JoGVt2q4TZynNg6bqT62YixQpNsDWCuI3pEaeFLGnpUmRh/3c4TE3321R2cWSebDb2EmWSWZXPv abYZAmVDn0/sRaFJvYba5nbt8pqeN7Bni6pPte3169Pm72uEe2FeeJnOYmn3ffEIdS++HRKkXjIY 2N3YIUNomnr3x10yDez9DvEPHPn7JzLQ1m6WNWZddwS9lWqQNYYAm69F7JJqH71k1ms0XWL1azUg oLavIpuFVrvEyqNQ9TX1UZdYLbYgcab19pDw0OCHx48vJtmSU5JTU9ZZfXpVE8c3P11TFGgMj07x 50mn+jwuiXOsFZLteY5mNRoSS4jI3L//r8aOTfKiU3W7T7Qadbt47lNtz/47/fEQUPfxx/p+INyg HuHKQbpu4foeC+GajbLZdLsUa7NK9l7Dyiu3S2aTbDZ3SoVcCNl73Q7bCm2dkppxneJ5h/pqp/ru nnd5e3/EbtZwpq55gYzWhXTf3os1G/gmhUUnT1a2VFaeLCoqNPeRzcG1t9Xe1hJ5+jeVCyoXFE84 efLImmNrCs2FZvVgtfYW+2l7JeMko4jxD3uh/bDdHCibg26XXqYgi5rcNaz2l+0EJY7TUVRYWFjk ++JqIJFz7PbauNv66HQn48wGyWz09ny3EHNf2XzTYd1hXeGq2Wtmr5lzcs7JEZXDn4iMCwkPCVfb 7fginW5ZUVHpkiCDHGQSe73wVaG4fXXB17jPUQ81J1LdrnAbNVfdPneU6Kg5fFERczkrMkjHuYm0 Wq3tVv/NLLYvL+IWb1/GJ5Zdf4jCwiCNHKS12yWpe3aD9HKQUTwoYjpbKk+eLPK/p9fNaJaNfS/U OsOLrhlqh9+9a1+/P0d9PCfS3GvbVxfEPkQzVlnbtUdxORB3REykeU2c6AV0PYFEqLvy75awjZLR KC6xZ0tijGCIP4429uE/cYJnh8x97/n3hu+NbAmxhljNN353CCNcUg/bYQ4JCecUdwRpNEG9Mo05 CVBkTQDfwG7DYI0BYqIkMVfCbXl2k17qo9fpzGb2EBLOTbzVLmvlAPoBIRXfC74bD8PVF9VH/pvY 3odsvUlfGxIRHjJ3wQI3+Xqy8uQXlaWxqpgst9vUvPPPZNdkmk0RcZVdWeZVX4gvIjn4NgTT84Iu UserRfGqWvtIg6QBTMCd0hxpnFQkeW06SQz13cvEVMf73y1eGKROSlHPEb3sXeePtfs7zVG/2JxI anqfgNi9alTYRB9drQjP3tL1mJBrfb95MkkLpSOSMvu1RQuk/nMXvTBfCl/w3OKFUiRb5GlTx4RK /dV1KjW+31TxSOax+P2T77EiBUuaqZMnhkohj019NFQK9b+u9d8H+O91kn527F9ipd/Mf2HRQuke 9WeE+nO0+nOs+jNK/Rnd/VsxWb3/sZ8a9f9m9D3jm0gG7u8CE0cewp7Ed9VKiZKkCddES8s1OZoK KVPZqmyVyiV5917xPTVx2u9uNPTh+nDTenNmzwjK9Q2x5frRJ7nfiO5xgXGl35Wbn7r5qYHrxfjZ Z9cPffh/7B9UfPt637gjqWf8IkOMwSE3HOuG5XSNu4/f81TXuO+Kb4xc87+PUbmjciM3/nFezxj9 K98QW64fo4vud3cNy6T/ZjxhOW45/kCbGNduefDOG41RuQ82PtTvoYO+MW5Pz3j4fTHG591wtDzS 1DWiKh/N6BoTdvnGxCU3GpMOTToUbZoS32tUideuH1O10aZo01St+Mxjd4kxPb5r+PY0o2rGxRlX Hg9/fN7jOY9/OaPq8UYxrj/ezDE3GuI7RJtmJs/M8I0nL/YMcaynRoifU7WCp9c829Q1Zo2fndc1 5hh8Y+6Xc798sT+MYcS/mPtiLY9zX8yN0cRMiNmkjsqYKzFX5g2f9wzj+XmJ8w5B4ryCeR3zR4ox L3F+7PzVjPfnfzT/s/lfzf9qgWHBVMbzCxYueM8/Pn3pVy+tf+nQS18tDGeMXPjYwiULNy487x+N Cy//WfrzaMaE2EGxG2OviLHo4F9mibFYWrx98Un/OC/+VyPu29Rnba8MfWXo4pOvbFzyiyWWJbPi QuNCXyt4/YlFB33v5r7N967Xm8X7Xu94Y+QbC97IeOPIG81ixEfGJ6rjYHzV0pClv+D+4NLhjIVL dy3ds7R8WT9G9LItvC9ymX2Zfelwfl4Wj5bZl2uXD1o+YfkSdbTYxqkjzrZ9aQg/42zFtiZbMe8Y lGBIuCtheEIiozjhu+UtvLfYtyXxNltx4pjECSvmrGhPWr8qetWTq55fPXLt2NS89Yu77jdO2jjp veDNjs1taQPSQtOeSbOlrU7bmLY97bO00rSWtO/Sten90kPTR6Rb0ielP5Wem16c/uXWIVtHbB2/ ddnW97ae3erOGJrxRMb6beZto7ct3pa37bNtjm0dmaMz4zI/zRqeNSPLlrUl6/2s81mN2/ttf2r7 pu0t2f2yh2ePy47OXpQdn52RXZvTL+f5nGU57+Wczbm4Y8CO8B2v7zi440quJff13Pdzm3ZKO0fs fGzn9p21u+7ctXjX/l2Nu1dLa6V+3lbpZugPt8AAGAiDYQiEwVAYBiOlgdIoeNTrkibARJgEkyEa psBUmAYzYCY877VKL8AceNFbK8XAPJgPC+AlWAh/hlh4GRbBX7w7pcXevdIrsARehTh43TtPegPi YSksg1TvGWk9bICN8A5sglzYCbtgN+TBJ1SDT+E4j0/ASfgnlMIpOA1n4CyUQTmcg0qo974qXYQG cDIfjeCCJrgEbvgamsEDLdAKl70Z0r+8R6U2+AauwFX41psufQffQwf84E2Xt3hPymmQDhmwDTIh C7ZDNuTADsiFnbALdkMe5MP78FfYAx/AXtgH++EAHPSKvzdXJR/zVsjFUALH4YS3Qpno/UyZLvVV npDMypPeR5U/efcrz3D/LPeLvK1KgXSfVClpvU1SAOhADwYwggkCwQxB0AfEugM3Q3+4BQbAQBgM QyAMhsIwEKsTTICJMAkmQzRMgakwDWbATBBrGDwLVngOZsFsWO69ItkgARIhlSxcDxtgI7wDmyAX dsIu2A15cNzrJCucZIWTrHCSFU6ywklWOMkKJ1nhJCucZIWTrHCSFU6p2tsufQk1UAt14IB6tl2E BrjsrSIDHGSAgwxwkAEOMsAhtbPtW+85suAcWXCOLDhHFpxT/6akAloIAB3owQBGMEEgBEGw96J8 E/SDm6E/3AIDYCCEwK3wM69D/C1E+XYIhTvgF/BL+BX8Gu6EwTDEa5fDYCgMg9/Ab+EuuBvC4Xdw D/wehsO9MALugwj4A4yEURAJf4TRcD9Y4AEYAw/CWHgIxsHDMB4egSh4FCbARJgEk2E6scyAx+EJ mAlL+d7LYDnYIAESYQUkwUpYBW9CMrzNZ7Z4G1FbI2prRG2NqK0RtTWitkbU1ojaGlFbI2prRG2N qK0RtTWitkbU1ojaGlFbI2prRG2NqK0RtTWitkbU1ojaGlFbo1ghQ6yPIf8DCuEIHIVjvF4MJXAc TnhPq2tnrEBhbhTmRmFuFOZGYW4U5kZhbhTmRmFuFOZGYW489jQeexqPPY1vOvHNRnyzEd9sxDcb 8c1G6TVvOd55DO88hncewzuP4Z3HUIsbtbhRixu1uKUV3m+kJFgJq+BNSIa3YDW8DWug3ttGdreR 3W1kt4Psbia7m8nuZrK7mexuJrsdZHcF2V1BdleQ3RVkd4W6TkAYDBV/zx9+A78FsWbA3RAOv4N7 4PcwHO6FEXAfiFUF/gAjYRREwh9hNNwPFngAxsCDMBYegnEg1iIYD49AFIhVCSbARJgEk8XfF4c0 SIcM2AaZkAXbIRtyYAfkwk7YBbshD/Lhffgr7IEPYC/sg/1wAA6Kv3MORd5W8bdtyQI3WeAmC9xk gVuZ7r2I/17Eey9KD0h9ufoazIwOgTAYCsNArAQzCsRaMBNgIkyCyRANU2AqTIMZMBPEijEvwBxI xZfWwwbYCO/AJsj1VuKNlXhjJd5YiTdWUjkHUjkH4pFVeGQVHlmFR1bhkVV4ZBUeWYVHVuGRVXhk FR5ZhUdW4ZFVVEsP1dJDtfRQLT1USw/V0kO19FAtPVRLD9XSQ7X0SOLv0E73XlWepAL9SZqpPMP9 s9JMKQJNONCEA0040IQDTTjQhANNONCEA0040IQDTTikvmLtGarPKBAr4rwAc+AvaEGsjfMKLIFX IQ5e89ahjy/Qxxfo4wv08QX6+AJ9NKGPJvTRhD6a0Mcl9HEJfVxCH5fQxyX0cQl9XEIfl9DHJfRx SfqEmf5U1UCb1EkV8nqvyBLI3itiVR6xJg/n10OECufYQ4SKdIkI1xLhWiJcS4RriXAtEa4lwrVE uJYI1xLhWiJcS4RZ1NZmamsztbWZ2tpMbW2mtjbfOFe8G5iNDT8pV57x1lNj66mx9dTYempsPTW2 ntlqYma+YWa+YWa+YWa+YWZymJkcZiaHmclhZnKYmRxmJoeZyWFmcpiZHCnF20HeFZN3xeRdMXlX TN4Vk3fF0rtsew/SIB22QgZsg0zIgu2QDTmwA3L53E7YBbshD/J5/X3YAx/AXtgH++EAHIQP4SP4 GA7BJ97dnLHd0t94/Bl8DgXwd7DDP6AQjsBRKIJjUAwlcNxbgi5K0EUJuihBFyXoogRdlKCLEnRR gi5K0EUJuiiRzvOZCqjk8RfcV8F/wgWoZu6/hBqohTpwQL23BtetwXVr0JQbTbnRlBtNudGUG025 0ZQbTbnRlBtNudGUG4eux6Ev4tAXceiLOPRFHPoi2VmMQztxaCcO7cShnTi0k4w9RcaeImNPkbGn 6EdK6EdK6EdK6EdK6EdK6EdK6EdK6EdK6EdK6EdK6EdKfkI/4qYfcdCPOOhHHPQjDvoRB/2Ig37E QT/ioB9x0I84qPdu6r2beu+m3rup927ZKt0sPydNlWdJt8qzpTvk56Wb5PmwlH0vg+VggwRIhBWQ BCthFbwJyfA2+xIrlaTCetgAG+Ed2ATveqtR7HAUe7+qVpSqLPD+XQpDgVfwlit4yxW85QrecgVv uYq3XMVbruItV/GWq/iKA19x4CsOfMWBrzg4kx2cyQ7OZAdn5zvOzvecne85O99zdr7n7HzPmfmB M/MDZ+YHzswPnJkfqBn16moX/4BCOAJHoch7mTrioI44qCMO6oiDOoJXMk9m5ukm5snMPJlU18Fx pFtxm2rcphq3qcZtqnGbatymGrepxm2qcZtq3KYat6kmVieqF/2BG5W7UbkblbtRuRuVu1G5G5W7 UbkblYv61SBW/pKD1JW/bob+cAsMgIEwmKu5IRAGQ2EYiPXBJsBEmASTIRqmwFSYBjNgJohVxJ4F KzwHs2A2vEiux8A8mA8L4CVYCH+GWHgZFoFYg+wVWAKvQhykegvwpgK8qQBvKsCbCvCmAnzmc3zm c3zmc3zmc3zmc2pif2pif7RfgPYL0H4B2i9A+wVovwDtF6D9ArRfgPYL0H4B2i9A8wVo/BIav4TG L6HxS2j8Ehq/RGYcJzOOkxnH0fhpNH4ajZ9G46fR+Gk0fhqNn0bjp9H4aTR+Go2fJouO3vAq03eN cZRMOkomHSWTjpJJR3/iNUYlmq5E05VouhJNV6LpSjRdiaYr0XQlmq4UK7j9hGsMJ12gky7QKdZ5 owt00gU6xWpvdIFOukAnXaCTLtBJF+ikC3TSBTrpAp10gU6xHhxdoJMu0EkX6KQLdNIFOukCnXSB TrpAJ12gky7QSRfopAt00gU66QKdYhU5ukAnXaCTLtAp1pOjC3TSBTrpAp10gU48pwbPqcFzavCc GjynRn5Gug09/RI9TUdPP0dPv8R3fi3P8dbiPXeIFenEenTyqxAHr8HrEA8/9frkLT7ztlhHifu1 sA7+F4iVf1JhPWyAjfAObIJ3xVpIXNmnQTpkwDbIhCzYDtmQAzsgF3bCLtgNeZAP78NfYQ98AHth H+yHA3AQPuS7fAQfwyH4BD6Fv8Fn8DkUwN/B7k0T6+7hWlm4VhaulYVrZYlV+HCsfBwrH8fKx7Hy 1TX5jtPx3q+uGncz9IdbYAAMhMHeMzjHGZzjDM5xBuc4Qyd8K53wrThIGQ5ShoOU4SBlOEgZDlKG g5ThIGU4SBkOUoaDlOHd8/DueXj3PFyjHNcoxzXKcY1yXKMc1yjHNcpxjXJcoxzXKMc1yvH5l3CO 1TjHapxjNc6xGudYjc/PxOdn4vMz8fmZ+PxMruRulZJgJayCNyEZ3oLV8DasgVS6gPWwATbCO7AJ cmEn7ILdkAefSFG4ThSucwLXOYHrnMB1TuA6J3CdE7jOCVznBK5zAtc5geucwHVO4DoncJds3CUb d8nGXepxl3rcpR53qcdd6nGXetylHnepx13qcZd63KUed3kLdzmFu5zCXU7hLqdwl1M4yyKcZRHO sghnWYSziHWGXCjbhbJdKNuFsl0o24WyXSjbhbJdKNuFsl0o24WyXSjbhbJdKNuFsl0o24WyXSjb hbJdKNuFsl0o24WyXSjbhbJdKNuFsl0o24WyXSjbhbJdKNuFsl0o24WyXSjbhbJdKNv1/00hdu9+ sv4QWX+IrD9E1h8i6w+R9fvI+n1k/T6yfh9Zv0+ZLt1EZR6l/Mn7EtV5lPIs9/FcJyz1fqwUSCOV eu+7ykUpXGmQ7lGc0jDF5T2jNEka6Y9UcRdV3EUVd1HFXVRxF1XcRRV3UcVdVHEXVdxFFXdRxevV 1S5HgVjv8gWYA74/NWgio5vI6CYyuomMbqLi28nqErK6hKwuIatLyOoSev8qev8qev8qev8qugIP XYGHrsBDV+ChK/DQFXjoCjx0BR66Ag9dgYce202P7aYmuekxPfSYHnpMDz2mhw6mTay7Kf8TSuGU eqV0Wqy/ycw003uZmZlm+i+zdJSoY4g6hqhjiDqGqGOIOoaoY4g6hqhjiDqGqGOIerG6fucoECt4 vgBzQPRrr9HbvM7VyxsQD0thGSxnpmyQAImwwptKhKlEmEqEqUSYSoSpRJhKhKlEmEqEqUR4hAiP UN09VHcP1d1DdfdQ3T1Ud49Uz3XeRWiAn3BVLNYcpVqXU63LqdblVOtyqnU51bqcal1OtS6nWpdT rcvFyqRU63NU63NU63NU63NU63NU63NU63NU63NU63Ni7VKxcinVuoJqXUG1rqBaV1CtK6jWFVTr Cqp1BdW6QqxtKofBUBgGv4Hfwl1wN4TD7+Ae+D0Mh3thBNwHEfAHGAmjIBL+CKPhfrDAAzAGHoSx 8BCMg4dhPDwCUfAoTICJMAkmw3RimQGPwxMwE5byvZfBcrBBAiTCCkiClbAK3oRkeJvPpFCtUmE9 bICN8A5sgndhC8dKg3TIgG2QCVmwHbIhB3ZALuyEXbAb8iAf3oe/wh74APbCPtgPB+CgWFEPiqEE jsMJsn+6VyNWiFWelIJQQ7jyDPfPcr/Au1FdLfYeqmYUlTCMShhGpp8h08+Q6Wf8+m5D323ouw19 t6HvNuk1tPS69yzZf5bsP0v2nyX7z1K1wqhaYVStMKpWGFUrjKoVRtUKo2qFUbXCqFphVKIxVKIx UjuPO8ErhckSyBAtjZKnwFSYBo9BjDRZLpJux+1ilBlSJFEYiMCgLJCSxeqeSoIUqqyQBknxP/In G19T+7+m9n9N7f+a2v81Nd9NzXdT893UfDc1303Nd1Pz3dR8NzXfTc13U/PdXDU0cNXQwFVDA1cN DVw1NHDVINzQzWy5mS03s3WR2WpmtpqZrWZmq5nZar7hdRy5Qt2upW7XUrdrqdu11O1a6nYddbuO ul1H3a6jbtcxWwqzpVC366jbddTtOup2HXW7jrpdR92uo27XUbfrqNt11O066nYddbsOr7iKV1zF K67iFVfxiqt4xVW84ipecRWvuIpXXMUrrlKrL97wz2O/Jbbv4HvogB/UK/AL6P8C+r+A/i+g/wvo /wL6v4D+L6D/C+j/Alo6j5bOo6XzaOk8WjqPls6jpfNo6TxaOo+WzqOl82jpPLXvK2pfDbWvhtpX Q+2rofbVUPtqqH011L4aal8Nta9GeUIySeNw9FYcvRVHb8XRW3H0Vhy9FUdvxdFbcfRWHL0VR2/F 0TvUlZFHiZWPvZc5c5c5c5c5c5fVVZJfgSXwKsTBa95/cfbcnD03Z8/N2XNz9sTVbCeu3omrd+Lq nbh6J67eiat34uqduHonrt5J11RJ11RJ11TJ7J5mdiuZ3Upmt5LZrWR2K6lpVczwp8zwp8zwp8zw p8zwp2K9ZrFaMzPhYSY8zISHmfCItZuZCScz4WQmnMyEkzrnpgO4TJ1z0wFcFis7y4OYGSszY2Vm rMyMlZmxMjNWZsbKzHB9D0HQB/p6Z6grQd8M/eEWGAADYTBXfkMgDIbCMBDrRY8CsWL0BJgIk2Ay RMMUmArTYAbMBLF287NghedgFsxW15q+TXoB5sAKbwQzG8HMRjCzEcxsBDMbwcxGMLMRzGwEMxsh pXgPoKGn0dDTaOhpNPQ0GnoaDT0tvcu29yAN0mErZMA2yIQs2A7ZkAM7IJf4d8Iu2A15kM/r78Me +AD2wj7YDwfgIHwIH8HHcAg+8W6kjm+U/sbjz+BzKIC/gx3+AYVwBI5CERyDYiiB45yLE3AS/gml cApOwxk4C2VQDufgPJ+pgEoef8F9FfwnXIBqMulLqIFaqAMHOL0b8IQNeMIGPGEDnrABT9iAJ2zA EzbgCRvwhA14wgay9iOy9kOy9kOy9kOy9kOy9kOy9iBZW0PW1pC1NWRtDVlbQ3dWTXdWTXdWTXdW LdYPp/+w0n9Y6T+s9B9W+g8r/YeV/sNK/2Gl/7DSf1jFKuP0H5PpPybTf0ym/5hM/zGZ/mMy/cdk +o/J9B+TxTrkYhVy/CcK/4nCf6Lwnyj8Jwr/icJ/ovCfKPwnSqxTLk+BqTANHoPpfH4GPA5PwEx4 RrqTK/QHuEJP5Ap9Glfos7hCf4Qr9ASu0C1ipXOxzjlX6AlcoSdwhZ7AFXoCV+gJYuVzPC4Kj4vC 46LwuCg8LgqPi8LjovC4KDwuCo+LwuOixBrp9AwviVXSuUJP4Ao9gSv0BLFeOj3EXHqIufQQc+kh 5tJDzKWHmEsPMVespM6VcwJXzglcOSdw5ZzAlXMCV84JXDkncOWcwJVzAlfOCWK9dbHaOu6Rh3vk 4R55uEce3XKuWH8dB8nGQbJxkGwcJFusxk4HvYgOehEd9CKxLrsyw7tOrMwu1mWndxjg7x0G+HuH d8Qa7UqBN1ep59qCvlT5iusOl/Qn6ec4TxnOU4bzlOE8ZThPGc5ThvOU4TxlOE8ZzlOG85ThPF/i JpW4SSXqb0X9rai/FfW3ov5W1N+K+ltRfyvqb0X9rb2uBzrU33g9QaUJ4KiZHDWTo2Zy1EyOmslR MzlqJkel24Ig6AN9vQt+pFdwSuLfEQiDoSD+NYGR3r18Q/EnjQ34XQN+14DfNeB3DfhdA37XgN81 4HcN+F0DfteA37Xhd234XRt+14bfteF3bdJfJCORxhFpHJHGEWkckcYRaRyRxhFpHJHGEWmc/7ce GfhcBj6Xgc9l4HMZ+FzGv/lbj6343FZ8bis+txWf2/pv/tbjKGfg6P/Fbz3y8bl8fC4fn8vH5/Lx uXx8Lh+fy8fn8vG5fHwuH5/L7/Vbj/wb/NbjMD53GJ87jM8dxucO43OH8bkKfK4Cn6vA5yrwuQp8 rgKfq8DnKvC5CnyuAp+rIJPK8K5v8a5v8a5v8a5v8a51eNc6vGsd3rUO71qHd63Du9bhXevwrnV4 1zq8ax3etRnv2ox3bca7NuNdm/GuzXjXZrxrM961Ge/ajHftxru24F1b8K4teNcWvGsL3rUF79qC d23Bu7bgXVvwrnS8Kx3vSse70vGudLxrN961G+/ajXftxrt241139/Ku8XjXErzrIbyrFO+6D+8q xbtK8a5SvKsU7yrFu0rxrlLx7yPgXXl4Vx7elYd35eFdeXhXHt6Vh3fl4V15eFce3pWHd5XiXbvx rlK8qxTvKsW7SvGuXLwrF+/Kxbty8a5cvCsX78rFu3LxrlK8qxTvKsW7SvGuUryrFO8qxbtK8a5S vKsU7yrFn6rxp2r8qRp/qsafqvGnPfjTHvxpD/60B9U/iT9txJ8+Rv2/x5vuxZfuxZc24UtpeNFn eNEM2YgrZOMK2bhCNq6QjStk4wrZuEI2rsB1FwRBH+jrXfkjf3rYhCs04QpNuEITrtCk/ssUo0D8 2xQTYCJMgskQDVNgKkyDGTAT/rsuSPSaK7zJuEIyrpCMKyTjCsm4QjKukIwrJOMKybhCMq7gwRUO 4AoHcIUDuMIBXOEArnAAV/DgCh5cwYMreHAFD67gwRU8uIIHV/DgCh5cwYMreHAFD65wAFc4gCsc wBUO4AoHcAUPruDBFTy4ggdX8OAKHlzBgyt4cAXPfzF37/Fx1WX+wCczIZRpK4qKIv7EqgsIcpOi IApeVgUUBZGLwiLVXQu71kVWiFaLFypioRWsVhR+gEgAUVpsG0vpNsMlJW3S0jZtkjbTNuRMLpPJ XCDtnARae/Y9Q/S3i+2u+Me+fn98mjSZc77f5/N8ns/znMmZGa5Q4golrlDiCpXnaf7AFf7AFUpc ocQVSlyhxBVKXKHEFUpcocQVSlyhxBVKXKHEFUpcocQVlnCFJVxhCVdYwhWWcIUlXGEJV1jCFZZw hSVcYQlXWMIVSlyhxBWWcIUSVyhxhRJXKHGFgCsEXCHgCgFXCLhC8Ar//lky/QyafgZNP4Omn0HT zyC3aNvP3z/7OEgfB+njIH2VzynhIMs5yHIOspyDLOcgyznIcg6ynIMs5yDLOcjyyqeZcJDFHGQx B1nMQRZzkMUcZDEHWcxBFnOQxZXPO6l82gkHaeQgjRykkYM0cpBGDtLIQRo5SCMHaax8HgoHaeUg rRyklYO0cpBHOcijHORRDvIoB3mUg7yagxzFQb7KQU7gICdwkGM5SDMHOaryiSqVz1PhIM0cpJmD NHOQZg7S/Dc4SDMHebTyaSwcpJmDNHOQ5srnsnCQZRxkGQdZxkGWcZBlHGQZB1lW+cQWDtLMQZo5 SDMHaeYgzRykmYM0c5BmDtLMQZqrn27RErVxkTYu0sZF2rhIW+UzXrhG5ZNm3s0xXsUxXlX5rJfY faq+RdW3qPoWVd+i6ltUfYuqT6n6lKpPqfqUqq9c87So9hbV3qLaW1R7i2pvUe0tqr1Ftbeo9hbV 3rLfuw1vM0P/BObDT+FnsADuhwfgQfgNPAT/76+FjaqjUXU0qo5G1dGoOhpVR6PqaFQdjaqjUXU0 qo5GVdGoCvKqIK8K8qogrwryqiDvynSNK9M1rkzXqIh1KmKdilinItapiHUqYp2KWKci1qmIdSpi nYpYpyLWqIhNKmKTitikIjapiE2qYa1qWKsa1qqGtaphrWqIVEOkGiLVEFHuZsrdSrlbKXcr5W6l 3K2Uu5Vyt1LuVsrdSrlbKXeUckcpd5RyRyl3lHI3U+5myt1MuZspdzP1dVNfN/V1U1839XVTXzf1 dVNfN/V1U1839XVTXzflba5+yssdcCfcBXfDPfAruBd+DfdBA9wPD8CD8Bt4CH4Lv4OHYSEsgkfg 97AYlsBSaKw+l7/GHL7eHL7eHL7eHL7eHL6eOjuos4M6O6izgzo7qlfwL129L6r5sr51pb51pb51 pb51pb51pb51pb51pb51pb51pb51pb51pb51HgWvpOCVFLySgldS8EoKXknBKyl4JQWvpOCVFLxS 37pV37qVkpsouYmSmyi5iZKbKLmJkpsouYmSmyi5iZKbYpW//X8BroBp8EX4Erz8vtkbXIHPhh/A jfBDuAl+BHPgZrgFblVJt0VXq4KrVcHVquBqVXC1KrhaD0vpYSk9LKWHpfSwlB6W0sNSelhKD0vp YSk9LKWHpfSwlMqpVzn1Kqde5dSrnHo9LKWHpfSwlB6W0sNSelhKD0vpYSk9LKWHpfSwlB6W0sNS etjtetjtelhKD0vpYSk9LKWHpfSwlB6W0sNSelhKD0vpYSk9LKWHpfSwlCqtV6X1qrReldar0npV Wq9K61VpvSqtV6X1qrReldbrYSk9LKVa6/WwlB6W0sNSelhK9d6teu9WvXer3rtV792q927Vu1n1 bla9m1XvRtW7UfVuVL0bVe9G1btR9W5UvRtV70bVu1H1blS9j6nehap3oepdqHoXqt6F+tk9Knij Ct6ogjeq4I0qeKMKXqF4V6jgFSp4hX42Uz+bqZ/N1M9m6mcz9bOZ+tlM/WymfjZTP5upn83Uz6bp Z9P0s2n62TT9bJp+Nk0/m6afTdPPpuln07jCLK4wgyvM4AozuMIMrjCDK8zgCjO4wgyuMIMrzKg5 Onqy5p1wDBwL74Lj4Hg4AU6Ek+DdcDJMhVPgPfBeOBVOg/fB6fB++ACcAWfCB+FD8GH4CPw9fBQ+ Bh+Hs+BsOAc+AZ+Ec+FT8Gk4z9Xz+fAZuAA+CxeK7yK4GCqfqfM5+IfoWT336JovRI/puyfou1/Q d6fquxfou2fqu/fWXMUl/sXvrvX9dVAP34Bvwkz4NsyKpnO/6dxvOvebzv2mc7/p3G8695vO/aZz v+ncbzr3m6733ssBZ+m99+q99+q99+q99+q9c/XeuXrvXL13rt47V++dq/fO1Xvn1tyuX/+Sc94B d8JdcDfcA7+Ce+HXcB80wP3wADwIv4GH4LfwO3gYFsIieAR+D4thCSyFRvv5AyyDR2E5PAYr4N9h JTRBCh6nySfw/iQ8Bc2wCp7Gq5rksCkOm+KwKQ6bchVxp6uIO11F3Okq4k7zQK154DpXEV82E7zW TPAmM8GbXEXcwIVvTgTRLlcSrYls1O9q4rhELirGGjhzmTOXOXOZM5c5c5kzlzlzmTOXOXOZM5c5 c5krD3LlQa48yJUHufIgVx7cz6sYstw4y42z3DjLjbPcOMuNs9w4y42z3DjLjSv3or4Quxaug3r4 BsyEb8G3YRZcD7dFnRy2k8N2cthODtvJYTu5ZSe37OSWndyyk1t2mjNOMWecwsE6OVgnB+vkYJ0c rJODdXKwTg7WycE6OVgnB+vkYJ2cq5Mj7eZIuznSbo6U40g5jpTjSDmOlONIOY6U40g5jpTjSDmO lONIz3KkLEfKcqQsR8pypCw3ynKjLDfKcqMsN8pyn5D7hNwn5D4h9wm5T8h9Qu4Tcp+Q+4TcJ6x+ zttr4BB4LbwOXg+HwhvgjXAYVD5L6y169RHwVpgCb4O3wzvg7+BIOAou9NiL4GKo3KP2Obg89hoV fIwKvkoFv1cFf1QFv0PlVj4rL6M6M6ozozozqjOjOjOqM6M6M6ozozozqjOjOjMqs0jRmyi6m6K7 Kbqborspurv6mWWrYQ20QluUptbjqfX4yqdkxT4m0xmZzsh0RqYzMp2R6YxMD8j0gEwPyPSATA/I 9IkyfaJMZ2U6K9NZmc7KdFamszKdlemsTGdlOivTWZnOynRWT9qrJ+3Vk/bqSXv1pL16UuVvHXdQ wB0UcAcFpCkgTQFpCkhTQJoC0hSQpoA0BaQpIE0BaQpYRAGLKGARBSyigEUUsKhyPzcVzKGCOVQw hwrmUMGcxLmu+C+MTRx/pdF5pqbHEpdFlyb+IVqVuNz/eWriCv+f5v/XRH+MnW4iyZpIsiaSrIkk ayLJmkiyJpKsiSRrIsmaSLIYzGIwi8EsBrMYzGIwi8EcBnMYzGEwh8Hc3/S3uO2O2wE98Cz0QlCt gRwGdmFgFwZ2YWAXBnZV7wF/wUT1IuyGPfBHePl94f8QOzAxDSqvADnlr73TUgRjIhgTwZgIxkQw JoIxEYyJYEwEYyIYE8GYCMZEMCaCSASRCCIRRCKIRBDJfZvct8l9m2jS+7lm3iCaNtG0iaZNNG2i aRNNXjR50eRFU7kDNCOvA3Jaud90IFGZN4+PzXP9c1u0Q352yM8O+dkhPzvkZ8c+87M8diiFHyrK nChzosyJMifKnChzosyJMifKnChzosyJMifKXCwTS8b6oB9GKHss2mrnu+18t53vtvPddr77P73a 4LLEZbGEPEwef9XBZYkr/H9abHLsaPnIyEdGPjLykZGPjHxk5CMjHxn5yMhHJjZP9pZb/bHKDlw9 9UE/vOSQ+3qVzDq72mpXW+1qq11ttaut+MziM4vPLD6zdtk6/qqBLE4HcZrF6WDii1GQ+FIUxM62 wwV2uMAOF9jhAjtcYIcL7HCBHS6wwwV2uMAOH5aDPjnok4M+OeiTgz456JODvBzk5SAvB3k5yP/5 OeJWkbXBWlgHz8B62AAboR02wWbogC2wv7tcR6Lt2OjBRg82erDRg42e6vO3L1Doi7Ab9sAfYW80 go0RbIxgYwQb52DjbHk7SN6OkbcD5W2KvB0kb8fIW6WWpmDnHOycYxJoTqyPHRt7o+grrwncK/q9 ot8r+r2i3yv6iveV5assX+Xx54z2Vc09+3rO6E/VG4v7boLvJlT/CpqWkbSMpGUkLSNpGUnLSFpG 0jKSlpG0Pe3/dYQv3Sv18leQVD5VMm2lA6x0gCgzicrrMs6xYmDFwIqBFQMrBlYMrBhYMbBiYMXK fQsNGGjAQAMGGjDQgIEG+W+Q/wb5b5D/BvlvUIOT1OAk+W+Q/wb5b5D/BvlvkP8G+W+Q/wb5b5D/ BvlvkP8G+W8QVUFUBVEVRFUQVUFUBZ2lV2fp1Vl6dZZenaVXZ+nVWXp1ll6dpVdn6dVZemWiXya6 ZaJbJrplolsmusc7yw6Z2CETO2Rih0zsoIkDaOJImkhi6AyaOIAmjqSJJLbO4K/dsU/GbogdEZsN P4Ab4YdwE/wI5sDNcAvMi30IW89g6xlsPYOtZ7D1DLae2c/09aeenMZWGltpbKWxlcZWGltpbKWx lcZWGltpbKWxlaa/h+jvIfp76BVeD96LobswdBeG7sLQXRi6Czs3Yecm7NyEnZuwc5OeO4GHnKnf XstHjtdvv85LztRvr+Unx+u3X098O1qZmBU1JjbEjk1sjL0lsSn2ThHdQKWz4QdwI/wQboIfwRy4 GW6BeRXflrPHqvW/vynjaZE+LdKn7X7Q7nN2n7P7nN3n7D4nv0//lZ1mo2roHb9LcIKo1o3fKThB ROtUR3+ico9PpTrmiWCeCOaJYJ4I5olgngjmiWCeCOaJYJ4Ivi3nRTkvynlRzotyXpTz4r67FA9/ DFrVaRtUPj98HTwD62EDbIR22ASboQO2wHaesgN64FnoBdcrGCphqIShEoZGMDSGoTEMjWFoDEMV b0hjaCeGdmJoJ4Z2YmgnhjIYymAog6EMhiqfAv9mlXEwhqaqioNUxcEYmqoiDsLQaRg6jUt+X3V0 VbpdbIrqmKI6pqiOKapjiuqYojqmqI4pqmOK6piiOt5D8e+g+Hf8l2czRtTtTi66C8oQwiiMxQ6x 43477rfjfjvut+N+qvxE4iK7+bw8Xhb1yF+v3PUkvqhuvwRfic1OfCd2ROJ7cEPs8NgZctkvl/1y 2S+X/XLZL5f9ctkvl/1y2S+X/fI4LI/D8jgsj8PyOCyPw/I4LI/D8jgsj8PyOCx/w/I3LH/D8jcs f8PyNyx/w/I3LH/D8jcsf8PyNyx/w//NM7ND2BjCxtD466/2dUdWgIkAEwEmAkwEcrdL7nbJ3S65 2yVfB1VnqC/4WpmhzhR5QeQFkRdEXhB5QeQFkRdEXhB5QeQFKh4RfU70OdHnRJ8TfU70OdGXRV8W fVn0ZdGXqXiMisewUMZCGQtlLJSxUMZCGQtlLJSxUMZCGQtlLJSxUP5v6ryAhQIWClh4HgsjWBjB wggWRrAwQsXP7rOjfj7KcakxWshxpzHKHKlGP1/080U/X/TzRT9f9PNFP1/080U/X/TzRf8D0T8u +sdF/7joHxf946J/XPRNom8SfZPom0TfJPrNot8s+lWiXyX6VaJfJfpVol8l+lWiXyX6VaJfJfpV ol8l+lWi3yP6PaLfI/o9ot8j+so9DWclLqLki3nrJb7/fOww+bx4vDN9Wg0eJq8Xj3emT6vDm9Xh zeqwQbS3mFg+mmiPFic2R3sTHbEvxl4j+m2i3yb6baLfJvptot8m+m2i3yb6baLfJvr0n+6usItu q29x9m5n767WzlJnWeosS51lqbMsdZalzrLUWZY6y1JnWeos1+NwOw6343A7DrfjcDsOt+OwG4fd OOzGYTcOu624woor/sZJcTcOd+NwNw5343A3DivT+Rdx2I7DTaL4IA4PxOHZODwYh1fg8EAcno3D g3F4hShvFeWtOJyHwxYcnoPDzfj7XPUacqHIF4p8ocgXinyhyBeKfKHIF4p8ocgXjs/I+7sS38e9 nbrwY/C3vYPEPtWjLipz7sWi7xD9ZtGfMx79qaI/SPTXjEd/qugPEv01ov+F6H9RvR/4pL/6vvzb osUiXSzSxSJdLNLFIl0s0kUiXSTSRSJdJNJF/+ku1mUiXSbSZSJdJtJlIl0m0mUiXSbSZSJdJtJl Il0m0mX7mwZF9FYRHSCi6aJ5q2gqc+10UTwQ+7Ao5opirijmimKuKOaKYq4o5opirijmimKunP3T fl9ZfH/UIpIWkbSIpEUkLXK2Xs7Wi6RVJK0iaRVJq0haRdIqklaRtIqkVSStImkVSatIWkXyokhe FMmLInlRJC+K5MW/cO8LTVYXRc/IX6f8nT4+m54r2sNEO2d8Nj1XxIeJeI78zZG/OdT7I9E/Qr0f pt5W6j0xdjImRjAxgokRTIxgYgQTI5gYwcQIJkYwUXH9Lix0YaELC11Y6MJC137m1QnyOQELXVjo wkIXFrqw0IWFLix0YaELC11Y6MJCFxa6sNDFzUe5+Sg3H+Xmo9x8dF/PdIj4JNGeKtKTRHmqyLbG zqs5GkfvhGPgWHgXHAfHwwlwIpwE74aTYSqcAu+B98KpcBq8D06H98MH4Aw4Ez4IH4IPw0fg7+Gj 8DH4OJwFZ8M58An4JJwLn4JPwy+jQs0dcCfcBXfDPfAruBd+DfdBA9wPD8CD8Bt4CH4Lv4OHYSEs gkfg97AYlsBSqPyV+wnXtU/CU9AMq+Bpv2uJumtWwxpohTYe/nlXfpfz989WPtEdg0UMFiuf647B IgaLlU93x2ARg0UMFjFYxGARg0UMFjFYxGCx8vnvGCxisIjBIgaLGCxisIjBIgaLGCxisIjBIgaL GCxisFj51HgMFjFYxGCx8vnxGCxisIjBIgYrr0UsY7CMwTIGyxgsY7CMwTIGyxgsY7CMwTIGyxgs Y7CMwTIGyxgsY7CMwTIGyxgsY7CMwTIGyxgsY7CMwRCDIQZDDIYYDDEYYrAXgzsxuBODOzG4E4M7 a9a6clgHz8B6HbJy5VB5PfFlGC1htITREkZLGC1htITREkZLGC1htITREkZLGC1htITREkZLGC1h tITREkZLGC1htITREkZLGC1htITREkZLGC1htITREkZLGC1htITREkZLGC1htITREkZLNbeK6jb4 CcyHn8LPYAH8HH4ZjWJ8FOOjGB/F+CjGRzE+ivFRjI9ifBTjoxgfxfgoxkcxPorxUYyPYnwU46MY H8X4KMZHMT6K8VGMj2J89L9hvAvjIcZDjIcYDzEeYrwP430Y78N4X3W2u7xyR1ZNXFQJqIUDoA4O hAlwECRhIkyGWXA9fAe+C9+D74M+V6PP1ehzNfpcjT5XU+lzyZqDY0fUfB6+AjPgX+Fq+BpcA1+H ytX+HPvYYh9b7GOLfWyxjy32scU+ttjHFvvYYh9b7GNLzaujTTWvgUPgtfA6eD0cCm+AN8Jh8Kao reYt0bqaI+CtMAXeBm+Hd8DfwZFwFPz//q4450XNNefDZ+AC+CxcKL6L4GK4BD4Hs6IOOeqQow45 6pCjDjnqkKMOOeqQow456pCjDjnqqLnZMbdG/VTdT9X9VN1P1f1U3U/V/VTdX/N4bHLNE7G6mifh KWiGVdAiw6thDbRCG7y8ti90TXtJ9I3x2XvG+Mw9Qw9aU33N0T2xNyRWxE5JPOHqM4i9PZGJXZDo ix2S6I+9KTHo/9nY6xJDunDOz4Zjp8QuoJRBShmklEFKGaSUQUoZpJRBShmklEFKGaSUQUoZpJRB ShmklEFKGaSUQUoZpJRBShmklEFKGaKUHKXkKCVHKTlKyVFKjlJylJKjlByl5LA+hPUhrA9hfQjr Q1jPYz2P9TzW81jPYz2P9TzW81jPYz2P9TzW81ivvA42wysyvCLDKzK8IsMrMrwiwysyvCLDKzK8 IsMrMrwiwysyvCLDKzK8IsMrMrwiwysyvCLDKzK8IsMrMrwiwysymJ+I+Y9jfiLmP475JzB+aKIp 9rbYxdjsxmY3Nrux2Y3Nbmx2Y7Mbm93Y7MZmNza7X8FfAwvYLGGzhM0SNkvYLGGzhM0SNkvYLGGz VHNe7LU158Nn4AL4LFzo+IvgYrgEPgezdOTr4TvwXfgefB/MZBgewfAIhkcwPILhEQwX/rfuUEpc SMMvvSrwgvFXBV6Q+Ers7FjcTyr3+R8aq/X7CdXrpsurr7k7O/Yq3jiJN07ijZN44yTeOIk3TuKN k3jjJN44iTdOcuRRjvyMI49y5GeqRx7uyMMdebgjD3fk4Y483JGHO/JwRx7uyMMd+TpHftWRr3Pk V6tHTnbkZEdOduRkR0525GRHTnbkZEdOduRkRx5ZnRov99XU+Ip2e2T1Oa6Xjpxa5eCYyt8EYhfR 2nZa205r22ltO61tp7XttLad1rbT2nZa205r22ltA61toLUNtLaB1jbQ2gZa20BrG2htA61toLXV tNZEa0201kRrTbTWRGtNtNZEa0201kRrTXS1mq5W09VqulpNV6vpagVdraCrFXS1gq5W0NUKulpB VyvoagVdraCrFXS1gq5W88sCvyzwywK/LPDLAr8s8MsCv6zoLqS7kO5CugvpLqS7kO5CugvpLqS7 kO5CugvpLqS7kO5CugvpLqS7kO5CugvpLqS7kO5CugvpLqS7sKYxGlDNS2KvMQ+MmgfGzANj5oEx 88CYeWDMPLDFPFA2D5TNA2XzQNk8UObS/Vy6n0v3c+l+Lp2OHaAWk2oxqRaTajGpFpOx82WtU9Y6 Za1T1jplrVPWOmWtU9Y6Za1T1jplrVPWAlkLZC2QtUDWAlkLZC2QtUDWAlkLZK1P1vplrV/W+mWt X9b6Za1f1vplrV/W+mWtX+fr0/n6dL4+na9P5+uTyT6Z7JPJPpnsk8k+meyRyR6Z7JHJHpnskcke meyRyR6Z7JHJHpnskckemez7n955SOd7rc43UeebqPNN1Pkm6nwT99X5cHhe9Y7Yz8feTPOXqoA3 0/2lMtRcvVYomC8K5ouC+aJgviiYLwrmi4L5omC+KJgvCuaLgvmiYL4omC8K5ouC+aJgviiYLwrm i4L5omC+KJgvCuaLgvmiYL4omC8K5ouC+aJgviiYLwrmi4L5omC+KJgvCuaLgvmiYL4omC8K5ouC +aKi2SGaHaLZIZodotkhmh2i2SGaHaLZIZodotkhmh2i2SGaHaLZIZodotkhmh2i2SGaHaLZIZod otkhmh2i2SGaHaLU3v1Mrrl93Z1BqUVKLVJqkVKLJtf+ROVVxBdiNMBogNEAowFGA4wGGA0wGmA0 wGiA0QCjAUYDjAYYDTAaYDTAaIDRAKMBRgOMBhgNMBpgNMBogNEAowFGA4wGGA0wGmA0wGiA0QCj AUYDjAYYDTBaeXfLAKMBRgOMBhgNMBpgNMBogNEAowFGA4wGGA0wGmA0wGiA0QCjAUYDjAYYDTAa YDTAaIDRAKMBFyhhNdjn/S5P+/k+7pHF6gBWB7A6gNUBrG7A6obYz1V7oNoD1R6o9kC1B6o9UO2B ag9Ue6DaA9UevILpqvJK57xqz6v2vGrPq/a8as+r9rxqz6v2vGrP1xytut4Jx8Cx8C44Do6HE+BE OAneDSfDVDgF3gPvhVPhNHgfnA7vhw/AGXAmfBA+BB+Gj8Dfw0fhY/BxOAvOhnPgE/BJOBc+BZ+G fbvRX74/2iw1dT18B74L34Pvww0wG34AN8IP4SZ46X3QRrnRKDca5Uaj3GiUG41yo1FuNFrzS05z B9wJd8HdcA/8Cu6FX8N90AD3wwPwIPwGHoLfwu/gYVgIi+AR+D0shiWwFB7Xy5+AJ+EpaIZV+35X hL9Q0oXRNC54yfjfut4//neu93PBjVV1DVHXEHUNUdcQdQ1R1xB1DVHXEHUNUdcQdQ1RV5668tSV p648deWpK09deerKU1eeuvLj954VqatIXUXqKlJXkbqK1FWkriJ1Famr8vnaddRVR1111FVHXXXU VUddddRVR1111FVHXXXUVUddddRVR1111FVHXXXUVUddddRVR1111FVHXXXUVUddddRVR1111FVH XXXUVUddddRVR1111FVHXXXUVUddddRVR1111FVHXUXqKlJXkbqK1FXc5/1yr1xdxf/5natitdRV S1211FVLXbXUVUtdtdRVS1211FVLXbXUVUtdtdRVS1211FVLXbXUVUtdtdRVS1211FVLXbXUVUtd tdRVO66uCdQ1gbomUNcE6pqwH3WVqKtEXSXqKo332Fn7UFdH7BLqSlNXmrrS1JWmrjR1pakrTV1p 6kpTV5q60tTVTl3t1NVOXe3U1U5d7dTVTl3t1NVOXe3jr7Zopa5W6mqlrlbqaqWuVupqpa5W6mql rtb9vLJijUytkak1MrVGptbI1BqZWiNTa2RqjUytkak1MrWm+sqKW11D3QY/gfnwU/gZLICfV54Z pZQ74E64C+6Ge+BXcC/8Gu6DBrgfHoAH4TfwEPwWfgcPw0JYBI/A72ExLIGl0Fh5P4TYyRg+GcNP Vuu3F8O9GO7FcC+GezHci+FeDPdiuBfDvRjuxfAAhgcwPIDhAQwPYHgAwwMYHsDwAIYHMJzF8CCG BzE8iOFBDA9ieBDDgxgexPAghgfVb1L9JtVvUv0m1W9S/SbVb1L9JtVvUv0m1W9S/SbVb1L9JtVv Uv0m1W9S/SbVb1L9JtVvUv0m1W9S/SbVb1L9JtVvUv0m1W9S/SbVb1L9JtVvUv0m1W9S/SbVb1L9 JtVvUv0m1e+A+h1QvwPqd0D9DlBFliqyVJGliixVZKkiSxVZqshSRZYqslSRpYosVWSpIksVWarI UkWWKrL/81XH/2p32Ff97uvZoJfX71fV7zfH6/eM8fo9o3rv7bWv8D0R/9rnANupq5262qmrnbra qaudutqpq5262qmrnbraTZShiTI0UYYmytBEGZooQxNlaKIMTZShiTI0UYYmytBEGZooQxNlaKIM TZShiTI0UYYmytBEGZooQxNlaKIMTZShiTI0UYYmytBEGZooQxNlaKIMTZShiTI0UYYmytBEGZoo QxNlaKIMqatEXSXqKlFXibpK1NVOXe3U1U5d7dTVTl2bqGsTdW2irk3UtYm6NlHXJuraRF2bqGsT dW2irk3U1U5dOerKUVeOunLUlaOuHHXlqCvHC0JTZnGf737a4uerYQ20Qlv1TqDK1c+bY5Pj74sy 8Y/AWdFl8bOjq+OfiK5OnBs9lbjQNdMl1XdErXzOwaLxzzlYRAuF2MT4iVEuPhXeC2fCWdFGR7c5 ui1+brSZknY4cpujtsVe5dF5j857dGi9HkfkrdkTP9/XS/zsUt//I8yAH0Xp+JwobZ3BWNKRZUeW HdXvqLKj+j2i1yN6xXCcGI7zyLbqGgMeOWCNLo8csKO1drTOjtbFq/FEqyvvoDD+vtKTx99XenJs gnM/6LwP2sVCu1hoFwut8bg1Hq/eDXeIc1/l3Fc5d8a5r3LuUefe5dy7nLuy5y0evSVx4d5diUv2 lsefbTph/NmmE8bvHGqunukKZ7rCmmuc6QrrromfFfs/zvApZ/jU+Gs3bx6/J+KY8XekOHn8HSlO Hn9His/FXu1MX3Omr9nTLmdb7Wxfc7bVzvRlZ/qyM01yptuc6TpnOsRZjnCGI5zhemeojx3oqGZH NDui0xGdHnGIRxzit/NjB2NjJzZ2xq+KHoj/c/TT+L/AV2BGtPNl+vgWfazE57foY6Wjd8nb+TRx CVxFF/9ME/8CX4GvWufC6Nk/a6PG43P2cr7cXiq3/wgzXENeWn1+6ki/bafR8/30kmirs611trXO ttbZ1jrbEy/L66vG8/qq6pl7xHF+tMSxgWNHHbvHsXscu8exPY6d4NiJWE5WX2dwua+V1xq89Pfl p6tH32Bfq+1rdfyq2JvtbbWjvoTZFzAbOnq2o98w/mzcG6p/w/1K9PPKX6er+/6atXf9+QwvHX2q o9ePv6b/Y9UjXzpqvqP0d49e59HrPHqd377eb1/vNz+j1Gvt+7rohXg9fc+OHRCfGxXjP1NDt0eF +C/UZdxvX4zPjsJYjX9fkId61fUNkX8TZkcd8Rud5YfOckuUjS+ww9uj3Y7c7afXONe/wbXOUE/n s6JB5++L/zQqxV3d0O41GP83uNZPv+GR34TvRBvi34Xvwfdhduz18RujRfEfe9yt0bPx2+AnMB9u j5Zba3ms1i53eNQmj+qNL4iet+/Z0Yg9jdrxNdGYVcas8KIVKtH0UmhIoaFHhM4y5ixjdnydXVbi m+XY6+1yNhe40c9+LNsLolLsTc7V5FxNdpz1yNXOmXHOTHym/8+Khhw1IoK8CPIiyIsgb70/Wq/J ek3Wez4+L2oRSZdIukTSJZIunKzF+9P20mEvHbHDrdRvpX4r7bSvJ61WskK3FYatULRC0QpFKxTt c5J9LrZK3ir5uOkf01n7fthKWStlrZS1UtZKBSs9L56VVuuxWk/sIKuFVgur0b90tl3O9ryzPe9M oTPt4tHfkOdvwmxr3IjZmz3yFo+sPsL3C+B2uvjFeHazzpl1VN5RebvO2XXOrnN2nauu86cdO/9f 7PR2j/mFWq7k8rnqM5Z1zpl3zrwo8qLo95i8x+SruSv/1/05483VnYdiDTnCdY6f7Zw3Wvdm399C Bz+mrgWxJPf7EwPXytYsuD52mEfvscPn7PA5jx4T53Oyt8tRx9tBaAe7/qyeigYrGnveDp53ZMuf a2dXLFH93Wy4UWUcbK1Wa7V6dMGjC9aqVFe3nR1gvUHrDVa5/bH//1Rt/IyybvezX+hgiWq9vhTh WGxqfKEcNsYOja+M1seb4AmqfNLenoq+G2+OfhVfBS16UVv07fgz0ex4u8d0+NoJJSw/Bzudoxz9 OB5Gj8VH4QV198fo/yZifKc2yiYO9HUCTPb9oVE58QZ4IxwN74Tjol2JE3Tyk6KmxLvhZJjKc0/V dU+Plib02T9/0tFFsVcnLo5NGn8d0omc/hEOeyKnf4QnZXWu+8S2EJ7E/lPRZlHsEsUuUbwQX+1r m37+DDfbLMoOXzshS8NDslhWfyH1j8KL0fMieNbun7X7ZxOHcdgTooxd7rTLnXa5M2Gas8Mg9sbx VbvxN2bVLqsWrFqw6h6r9ll1i1W7rLrTql1W7bJaaLURq41YacRKI1YascoLVilbpWyVshUKsX+1 wpfjD0XfsspYvDF6JP5oNCu+HFbyhSZ4Ap7kni3R/fE26mn3/82qfUv0T/Gt0b/HuyEN22A77Iim x3t8DTwuEy2L9/m+HwYhG7s2PhTdHc/5fhjy0XXxgq9FKJkSnoPnfT8CO6OL4rs4RSjCUXghOgN3 T8d3+90e+GP0h/heXyMZrIE4JKJmyrgicYDv66J5iaSZYKLvJ5n3J0cdiYOjryVeDa+BQ+B10RTK mUo5UylnqlxclXhT9PXE4X73Zjgi9uXEFF/fBm+PTku8A/7O74/0/6Pg6OjtlPb2xDG+fxccF70t cXz0YUz/GtP1mK7HdD3VfUxO70i8x2PeC6dGtyRO8/V9cHr0WOL9vn4AzjCznGkfH/T9h6JLx+96 7NFD79FD/1kHfqvu+9bEVdX544nYsbLUK0u9stRLH73/SR/baWOANrbIWC9tbKGNLVgewPIAdgfo ZAd2t2N3O3b7MZqhlx0YHKCZHTSzA2tDGHoOQ89h6DkRPyfi50T6nCgDUWZEmRFlRpQlkRVFtF0U vDF2urr6gHraoZZ2xI6is5C+svSVtfMOO++w8412XqmjteNq7rTjjvE66rTrTrp5i51323m3nbfb 7Rq7HbDTbjvsk8d+u2y3y3a7bJe3ifI1IF8DdrzFjrfY8ebxOttqx1vteKsdb67Umd22x462o3V2 tM6O1tjRgB39YbyqM3a0zm4ydpOxm9fazbDdDNtNLx578DiAx4Fxj9qCxy67G8ZjFx67KHBs3Kcy dpmxy4xdTrK7jN1l7G6D3e2wu412t9HuNtrds/jcZoctdpjR2f6DuTMBr6pI+n519wnZiUIIBBAi O7iwyigCUUQGRIigMrigIghCEsKQIIqCCiiKG+6MuMyMiKgE0CgYFkGWC0oSAiRwyTYCCWtIQCHs Od/vdK7zMjP6qTPzvM/78Pz75J7TXd1dVf/qqnDvzTxY7q1sPVzdADbB8s2sIIdIkMcJl891h1sK Sw+QITb1/s4qY75H76fQexV6r2LMGfyqCH8qIy+ah+Y/BovAjz3WuRP+HqM3kWNsdt/24gt2nIcd 55FvzCPD/RiNLMJzFuNtX7CmL3mdCdahgfVoZAPYhPY2czrluKv1VmJfjU1Xs8bVxI9KYsUhYkAl PK3EhluxWQE2K2B9O1nfTmnOTC8x0xPMtPcfotM6TrP1nGMbwCaebXZdZjkeiIPHmeE4Myxihgwi Ti6z+JjFxywP/IMNmrupzJgKqw9jiz3YYg+2KLW6R+ew0HvvSEdW0xFdfo0uN6KRA1Qo4p7Huuex 7nk0/TvOek+X69jhena8ARyQWtjzGPY8hj2P2Vj7JLt5g52sYSevsJNX8LpcvC4X2Rv1ek7MDWCj +z47OovX5bKjfexk4s/E2pmBWLuSWLvmn2Ltk+w844JY+8QFsTYV7029INaOIdbmXhBrhxBrcy6I tat+JtamBmLt+2j3iUCsTQ7E2mRibTKxNplYm4zmr0XzfdF8XzTfl1j7NLF2ErE2mVibjA7vINYm E2uTsUofrNIHq9xNrE0m1iZjnT5Ypw+xNplYm4yVbiDWDoc16Wj5SbT8JFp+EssNINa+QKxNJtYm w6BpxNpkYm0yTHqcWJtMrE0m1g7Dwn2JtclY2fuOxCGBd+mnY+1JxNoGxNoGxNotxNqFMhrrPYD1 JmC9T7FeKtZLxXp5WC/PRrG1MHGjuwHLHcZyeVhuP5ZLw3JZWC4Ly2VhuSwsl4XlXsJyWVhtNVbL wmpZWC0Lqw3Dal9gtSysloXV5mC1LKyWhdWWYrWlWC0Lq2VhtcVY7RvizwksthqL7cViWVgsC2tl Ya0srJWFtbKw1lastRRrZWGtb7HWHKyVhbVWYa3tWCsTa2VirUyslYm1bsRaL2Gtl7DWS1hrNdba iLUysVYm1roHa2VirUysdRfWugtrLcZamVgrE2s9i7WexVqZWCsTa72AtTZgrf1YqwhrFWGtIqz1 OtbajrUysVamzc2u4doNdAc9QE/ytnjWcB0/X+9+gKUSsNQaLOV9/rEr1tkirbDOR1hnIZFiGzHp GFbKwUofYaWPsEwFzFwIM3fAzB1EjDVY6QgR4wvi0hEsdZCo8QVR4wssNg/rbIBTB7FEDhZYj4b9 cGMP3NiDlvfD/Ty0WAn/8+B/Htpcj8bS0UQ6mkhnld4nFgZ7Z7a0xEe24iNb8ZEs/ONLZi7FP7Zi 617YtAibFmHLzczyHbPkMksu9lymvU8xCpW0g56CuYaACOJUJKdaDDqrDxqApnI5uj+JzgvQeQG6 3oWey9BzNnrORs/Z6Dkf3e6CAX50uZ18/QCnj3dOdnHPkfsvsvllIhqag4bmoKG1rPMJtHCadc1n XRmsK4PdHwrkCYtY0yLWtIiKYJ37AiPXM3I9OzzJyBcZtervmXvNiVjyY1bBiEri9FHwA/JOuB/T 00dPH/suofdCei9g3z8wYgEjFpBH76H3CbKUKuxyEpwhwxB2Vss9RK9semVzQu6BCyfcXfQqo1cZ vQ4gz8uDc+l5nJ659MzlBPfjFyWgHFTiE0fBD1Qhp8EZIvl5TmvH3cGoIuz7EfbMxOt24nXe2bTM vpPKexeV530XI+E4Eo4j4XggH/gb8/8NaYdspiJ4jWPn38/8+wOfdGtPvdGJczWfczXfauUQUg4h 5TukFCGlHCnlSPkOKZVIWY4Ub7/LkbIcrVTy9CioyefOevqzOb/DuRXI+7Gun6ee/irpcRTUrPL7 C7KWcva8g5GFjDzLno8xupDRhaLZqfd7uc7Ukn5OtXLknEFymPuD1P77Kb4HhpVbW25FaglSS+hV iMTPiT3HA7r/HImfG+/vw3ojNzDyS0Z+z8jljNz3Y9XiRbIL/YURy9H/IPQ+gprU+wxdKOOPMeYY Yw4z5nCgrqpkpoOMq2Rcpd35CmbxMcOmC7iWx47TGVFluRVmf1v1VMC6u5hljP19nDd6iY0F5VRV lcSJo+AHovpp6xtHmMvTw05Gjw/8rmsLo++w/49Qh9EljF7GDrOJ8zuQspoVL76AS8sCzHgHHXkR xcu732Hl7yB1NVKfQ9oia+VC5i60ue8J+HXaXceoI6yhkBFHGHEE7/GjuT34+wn4W8U5cRKcIR4I J22NVp6m59P42/342/3Y8wQrqkLmScAZT74SS3bYHnTEXp1AZ3CVe5o4EU30j2WuH3O09ui7I/vv BDqDq+xn9Q5430ggYfSuoPcpelfQu4KeJ+l5kp4nA9XtIaLkUWmitLtRGeCAIFALBIMQEArCQDiI ZP4IKtho922i32Gi32Gi32FmWMwMi4mAFUTAg0TAg0TA/cS1fUS6w8xSgSbfR5Pv23f/eu/89Thb jzh63ETDwRh2VR80AG3gTVtwBWiPpI54UifQGXTh3lUSRRz1aucypB+Bx2QN0pGd72TnO4mp0WSP sWSRzfHbFqCl/S3EqX+p7+9kbfe4h9FVBL1j0Fx90AD8T01wyM55Lb3j0Woosivt7wuak6e0AB15 0gl0Blcxh/d3LkPo8X3g9x5beLqFp1sCM77MjC9LME8r/sHCnjV+jELeLDnIOMEsO5ll54U5LHK8 9ZSJYnUnpK6J5Kdo9z3WX8H6K1h/BeOWMm4pOz9xgUWOsJfD7KMCi3ififwEi3yCRepgEe938X65 GEmf/pNtv0LSV0j6AUnHkXQcSaeQ9EPAtqeRtBlJm3+UZC2wm/XvZ/QuRu9idFWg8rvQp8vYxxkk nEBjMWT79UED0Aa0BVdQd9dUAd9ZnRQjrxh5xcirRF4e8rYjbzvytuMTh+x7TJube6W59JGR7p/k ATAKpLp/lsno/VHwGJgCpoK97hwpBWXge/udbbPlDDgLzoHz7mzVxs1VbUE7cBm4HFArqitBe9AB dASdQGfQBVwFuoLfgavBNaAbuBZ0Bz1ATxAPrgPXg17gBtAb3Aj6gN+DvqAfuAn0BzeDAWAgSABj pL5a465WX7vL1FqwDqwHG8BGd5XaBL4B34LNRJgWUsfNkboAL5N6IAbUB61BG9AWtAOXgf7gZjAA DAQJ4BYwCAwGt4Ih4A4w0n0bjb+Nxt9G41MlzX1HJoKHwCTwMJhMJvEoeAxMAVNBK3mZfOAV8Cp4 DbwO3gDzwYdgAfgIfAy+BZtBFsgGOWALyAVbARWbbAd5IB/4wV73M+z8GXb+LPCNm98IebucAFXg JDjtLsb2i7H9Ymy/GNsvlhRx5GIJArVAMAgBoSAMhIMIEAlqg24SI9eCke6j6OFR9PAoepiIHsai h7HoYSx6GIsexsojSJjsJqOLZHSRjC6S0UWyTJcomQGeAk+DmeAZ8CyYBZ4Dz4NMaSLLwV53Mjub zM4ms7PX2NkCdraAnS1gZwvY2QI5xYpPu1PY3RR2N4XdTWF3U9Rbbr6aC94G74L3wJ/BX8Bfwftg HvgAzAcfggXgI/Ax+AQsBOlgEVgMloBPwWcgA3zu5usOnOMdqam7cI0Hfd1HdT8qt/5gEK/HUJOP dZN0IkhykwL/D5wW+H/gNJNGtTSR6ilXgsxWiTbb5VKTT765g8i9l+y0lHhaJm3MPq77vW+V43qY OKTNFnrvxSLeT94nSurLCSwagUUjsGgEFo3AohHoJwJ7RGDRCPsvEtQGddwCmFIAUwpgSgFMKYAp BTClAKYUwJQCmFIAUwqwfl2sX/c3fXf1SHc0njIaTxktD5JTjQFjQSJIAslgHEgB48EfwQSQ6o7B q8bjVePxqvF41Xi8ajwe1RuP6o1H9cajeuNRvfGoMDwqDI8Kw6PC8KgwPCoMjwrDo8LwqDA8yvsb 1EVwsAgOFsHBIjhYBAeL4GARHCyCg0VwsAgOFuF9sXhfLFysgIsVcLECLlbAxQq4WAEXK+BiBVys gIsVcLECLlbARe9v5/4Rj/0jHvvH3/jd0W/i3fPx7vl493y8ez7ePR/PfgTPfgTPfgTPfgTPfoSY 7Sdm+4nZfmK2n5jtJ2b7idl+YrafmO0nZvuJ2X5itp+Y7Sdm+4nZfmK2n5jtJ2b7idl+YrafmO0n ZvuJ2X5itp+Y7Sdm+4nZfmK2n5jtJ2b7idl+YrafmO0nZvuJ2X5itp+Y7Sdm+4nZfmK2X90iMWoQ GAxuBbeB/63vg1zjZnBWrOSsWMlZsZKzYiVnxUrOigzOigzOigzOigzOigyVJWGKmk7lgC3eeyTI cTuCLsB7N0c815p3dDwOowfC6IGW0XdRzYwEY2D4BczWyfYznj1g91jY3QN2jyXveMmkUrGvcNea r6S2+ZoIsIXcZSvZxHapD9MPwXRjdpLL1LA9CLa3sH997xD3DxMN14rj3iZBoBYIBiEgFISBcBAB IkFtEOVeC4OLYHARDC6CwUUwuEi64U3Xgt/EYLlLHgCjQKpcLWkwaSJ4CEwCD3txXi6TR8FjYAqY Cqa7N8oM8BR4GswEz4BnwSzwHHgevOh2//98lv4n/ial+74sB99S/2wGWSAb5IAtIBdsBdvAdpAH 8oEf7JXBUgrKwPfSSX4gPh4HJ0AVOAlOS0s5A86Cc+C8tKR+yKF+yKF+yKF+yKF+yKF+yKF+yKF+ yKF+yKF+yKF+yFEXuX9RF4M6oC6IBvVADKgPGoBY0NB9XzVxP1JNQRy4FDQDzUEL0BK0Aq3BLe4i NQgMBreC2wD1hhoC/gCoO9Qd4B4ZoO6TW9VweVjdLzeqEdJdjZQ/qCnucjUVPA6eAE+CaWA6mAGe Ak+DmeAZ8ByyZrtb1cvgFfAqeA28Dt4Ab1KBd3Bv111AN3e3jud6A9e+MlT3k8t0fzDIHQpL9sKS vXqMDNFjpY1OBEkgmXuB9wWQW/cit77eLHfnm6/cAWaP+w3nWLQpJYvfRzVxgJrsoDQyhzgfD7tV Klac6lMSBGqBYBACQkEYCAcRIBLUBlHV2zjjVnLGreSMW8kZt5IzbiVn3EoYkgFDMmBIBgzJgCEZ MGQqDJkKQzJgSAYMyYAhGTAkA4ZkwJAMGJIBQzJgSAYMyYAhUTAkCoZEwYRImBAJEyJhQiRMiIQJ nE/gKfA0mAmeAc+CWeA58Dx4sXqdzHa3wYZE2JAIGxJhQyJsSIQNifImz+aAueBt8A54F7wH/gz+ Av4K3gfzwAdgPpnYh2AB+Ah8DD7h/kKwCCwGS8Cn4DOQAT4HX4ClYBn4EmS602HddFnBzyvBKvAV WA3WgLVgHVgPNgAf2Ag2gW/At8y7GWSBbJADtoBcsBVsA9tBHsgHOxizE/j5eRfXAlAIikCxu0xK wN/Ad2A32ANOk+mcAWfBOXBeQmBuIsxNhLmJMDcR5ibC3ESYmwhzE2FuIsxNhLmJMDcJ5ibB3CSY mwRzk2BuEsxNgrlJMDcJ5ibB3BSYmwJzU2BuCsxNgbkpMDcF5qbA3BSYmwJzU2BuKsxNhbmpMDcV 5qbC3BSYmwJzU2BuCsxNUcNY6z3SM/A3FbrC3stg72Ww9zo1yt2uxuD5E7k+BCaBh8EjYDJ4DExh XVPB4+AJ8CSYBqaDGeAp8DSYCZ4Bz9r3Qqao57m+AF4EL4HZ7nRYPx3WT4f102H9dFg/HdZPh/XT 1Rf0WQqWgS9BJlgOVoCVYBX4CqwGa9wyzuEyzuEyzuEyzuEyzuEy5SOC/PQndfarbJADtrj7iTDh RJhwIsxyIkw4EWY5ESZKD6o+SWSZRWSZRWQJI5rMIpoMIZoMIZp0I5r0IJpMNCvdFWYV+Kq63Kxx v+Dc3WnWuhvMOvdFoswMIswpU0YNv48xBzijD3LWHnLfJcp4f+FyuhsPa+NhbTysjYe18bA2HtbG w9p4WBsPa+Nh6yrYugq2roKtq2DrKti6CuZlwrxMmJcJ8zJhXiYs2giLNsKGdNiQDhvSYUM6bEiH DemwIR02pMOGdNiQDhvSYUM6LEjH60vx+lK8vhSvL8XrS/H6UpPjzjO5xEgqQ7PNHWG2u5kmj93t cAvJKIo5p6dXn5AZ4CnwNJgJngHPglngOfA8mO362M0gdjOI3QxiN4PYzSB2M4jY4yP2+Ig9PmKP j9jjI/b4iD0+Yo+P2OMj9viIPT5ij4/Y40MDA9HAQDQwEA0MRAMDiT0+Yo+P2OMj9viIPT5ij4/Y 4yP2+Ig9PmKPj9jjI/b4iD0+tDYSrY0k9viIPT5ij4/Y4yP2+Ig9PmKPj9jjI/b4iD0+Yo+P2OMj 9viIPT60nYC2E9B2AtpOQNsJaDsBbSeg7QS0nYC2E9B2AtpOIPb4iD0+tJ5A7PERe3zEHh+xx4cV pmGFaVhhGlaYhhWmYYVp5PxLyfmXkvMvJY//gDw+nTw+nTw+nTw+nTw+PfB9tnnk8nnk8nnk8nnk 8nlS7b4nrvueEqDc97DoHeSHOVj1Taz6qNlWXY1V/4JV+5ErfoFlJ2HZt+QolV4slV4slV4smUss MS+WSi+WjCyWSi+W+i6W8yeWSi+Ws6kLJ2EZJ2EZJ2EZJ2EZJ2EZJ2EZJyHVJWgL2oHLQDdpRLXX iJMwn5Mwn5Mwn5Mwn5Mwn5Mwn5Mwn5Mwn5Mwn5Mwn5Mwn2rveqq966n2rqfaK6baK6baK6baK6ba K6baK6baK6baK6baK6baK6baK6bau55qbzTV3miqvdFUe6Op9kYH/mpsWyq+tlR8ban42lLxtaXi a0zF15iKrzEVX2MqvsZUfI2p+BpT8TWm4mtMxddYXpT2ePRuPHo3Hr0bj96NR+/Go3f/zLdcd6bq 64zH+PEYPx7jx2P8eIwfj/HjMX48xo/H+PEYPx7jx2P8eIofD7gXD7gXD7iXqq+Eqq+Eqq+Eqq+E qq+Eqq+Eqq+Eqq+Eqq+Eqq+Eqq8Eb+mPt4zCW0bhLaPwllF4yyg5RaV92u2Mt3TGWzrjLZ3xls5K Sy1lgAOCQC0QDEJAKAgD4SDS+4wVp8ogMBjcCqgaqMKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKy qcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyqcKyif5TiP5T iP5TiP5TiP5TiP5TiPyTifyTifyTifyTifyTf6IKi6UKu4QqLJbo76cKiyX6+6nC+lGFXUMVdo0e QGU2SOI4CfycBH4qsTFUYglUYglUYgmcCn49Toz+WOrrRaL1l1wzwTr3fr3e/UxvABvdOXqzG6NL 5Cp9guqtirz2JDjvDjPREmXaux+Yju5C0wl0Ble7i8xKiaCKa89p8iks3WhyOTW2STDM/JwqLghm VnO65FHJPRqo5Ezg9zaGU2a/OcgJc4j7h90j1FIOp0IQqAWCQQgIBWEgHESASFAbRLkryE8LyU8L OZ2WcDot4XRawum0hNNpCafTEk6nJZxOSzidlnA6LaG6WvfjN8b9xs+MFZILFZILFZILFZILFZIL FZILFZILFZILFZILFZIHFZIHFZIHFZIHFZIHFZIHFZIHFZIHFZIHFZIHFZIHFZMHFZMHFZMHFZMH FZOzFJOzFJOzFJOzFJOzFJOzFJOzFJOzFJOzFJOzFJOzFJOzFJOb7CI32UVusovcZBe5yS5yk13k JrvITXaRLywhX1hCrrCE6uNLcoICcoICqorbsUg55/05zvolWKGcsz6Bs/6cqao+YE5SgZxyg83p 6pPmTHWhOevWMueq95vzbryp5r7rxjpB1QecWm4vJ9gNdkKqTzqh1YVOmFvLCa/e70S48U4k92u7 1CacwUuI1IdMvlxpvL8/2JcINpcINpcINpcINpcINhdmF8DsAphdALMLYHbB//nv2PI+E+Ozf1mg HAaXw+ByGFwOg8th5RxYOQcGboeB22Hgdj3PPWDfEVHzf+W7YdZuGOWHOXPNFmnK+fYdrHleNJZZ CC9mwbjlco1ZIcPMauli1kgD+i4za6n+1klrkyMDGTfQbIU926Sn2S51TJ50QsbfYF4TCTF7uLtX 2sG3gfCtlTkgfZC7NvD70suY6Wv3E/q/audcwrOxsHKF1ObeN7zaYmPmv3wzhBoj8Vh2i3TEqt2Z 4Wb8px/z1dzpiHed5G4vvGsF3nXIfovPYVHMslca86qn/f1sffq2ZD7vr5/ukyvocSWvtkg8u4nm WRP25X3WZ6ibbdKkG2td6/TgBNTc2cSrzfRe5RaTy1byqphXSRLJqzO82iR1yAbiyQbiyQbiyQbi yQbiyQbiyQbiyQbikRRPNhBPNhBvbpd65k5yiXtAEntaQb6xhvz4a2JFiJW73D3O3WJm3GdWo+E1 MOlrdykZ9GHWmcb6lyNjFb1YGeuMlDoqV5qrrdKBXdzDmm8wd9Kr5vshrrDfD5Hkfu19FsQ85O4x b0hX86b8jnkqsEBLWLrIuUY6Od2kAzu7S5owognzdEHzaRLHTEe8+e1MkcxQxgwbzd2MHkb/+7gO 55qG5XPdXeRN5eRMp61dd0gIozgzGeH1jqFnDD1D6VlBj0o0shemEh84vc95n8qy+qfWIhcrx0JR sHqrlZeHtvMZhUwv0iPzdveA9z5HRrTDQ4Nt73z3OPnWhTLvxu/vA8msPY0TZIt7jNkrWWcF1q+H 7BOM2oDccOSeor0dHQ0FaXh5DhrfQo9cVrMVjW9j7flIqFnFOfz3du4Odavs9/V739U/gSdpEsvI UFZUi5FVjDzHyEjmqvZ2zciz3v+vyO+lFJSB09KaCro1FXRrKujWVNCtkXwHkjuYu2HhMLnX3Md1 ONdk6o4JrOch933zGHZ9Q67Gnt3RWC4zdrO63ea+Y2fLc3fg39FkrmcCNu6EDm5nDUPR6d1gmPdN +lyHc02ThqzbY1cI6w1jrfvNTrnIWn0lI9YyopQRDRlRyoiGjLia3hcx5z5r+W3uWeY9xchSOyrP fod9zaea4gKfaoozE4kWe6QZkaASPoYRMWKJGBcTB1biczX6L6CX4U4lerydn4Za37TfdGRSsfok Yto+1n2AGQ+6FdYfvmNcKePCkB6CZM2TAtY/0j1GdnyM7PgYGe8xep778RsW6R1se+/FyvvQ1H7W dJCc/xBSDrvl+G99a+Vc+/26d7Kue0AqK55InNuDjvdi4VK80+6EeHSA/R90s7zfmdm5zzL3WeY+ G9hZ+Y/vmUaKRko75r8IKSeRUo0U7zvJQpCwmzVo/GSk3CwPgFFgsvSWR8FjYAqYKr2RGoXUywPf Ozoo8H2jg+D8h2jqMzS1Cj/ZiJ/0w09uNh+7L7PuzUTDVjUzEo+9GQ+4BfhIN3ykm9ODvDoEyVUB 2+mA7bTVl7fTg94nG+mxiLnnB3rFBHrFMHcFPTvZSv+g99elTVL1Os76I5zt33GWH+Hs/s5pU12G vZOqK7hbyZ1Kp43bE6lJ1SWmCn2cZfQ5+HXezXGC3JOc+6eccPc4PXPo2ceO/ZqnW7mzlTthdmyF OcN8Z9nZeTefHKLaITtnbDW98skVqukZD7eTqvcxSzVZyHFWVm5Ocz3LrOfwjpqR55i1muzjOCsu d0K4hrGKcO7XSDrHDk7gHUnkLSdFIaUSKdVIcY33DjNv7lqiGF3J6GpGu4w8EFhDW09P1bNZwx5G N2d0IaOrDFWqXf05/O08nlHNuea651nLHqQ1R1oh0qqcUDfP7irc9TsRchGZ0CEkn2dN6d5J4mok nmIdxaZaNKNOMXexE8nPbdxLvR7VW+ixn/k8TRXQYz8yPS0VIIMa95/thfUDdmL0L9jH9rV2oe8v 2IM9/od2IKb9Rv3D9P+y3tnjz+jbPvlJPUttJ1pCnXqsr4GEOQ2R1ogxjTk3L+HnJjxryrNmPGvB 65Y8a8Wz1sQVx4lhhkY8jePaEptEONG8qudWOPWZvyEzNGImT1YT7jfl/qXcb8H9ltxHDlbwensz Nwr08GbyZNVhXZqnZU4Md+qDBtKE9dWhZxkym7A+zfo0o8qcOJ5fCppxvwV9WnKvFT+3Zu+1kVLM Wr0daieWtTaUoIAUb3Qx6/d2qJ3mPGvBs5rRmv1Gg3r4XgxrboDchuylEdZvzFyXePvieVOex/G8 Gc9bcK8lz1vxvDX7YxfYph5yY7hbHzRwd7CGarSzx2mMLS9hz03o05Q+cTy/FDSjT3P6tKBPK/q0 5nTx7BRh9dpAolmHp7FTrCOadYSzjgir22a8bmE1eIo1RLOGcM8qYuzeGwb0XLN6T3vG7rtmRGVg 1Vqi/l2fgLUV6O+f/AK2t5fI3+objOogwT/nHzxtKXX/Wz6CtMvZ9b/pJ4xuIxf/p76ClGu8Hf13 /AVLfGvt+G/5jD0bIn+r39io3oa6+iCR9D4iTmOi2gDq6kqi2o3U1YeIPiOJanFEtW7U1QeJqPcR jRoT1QZQV1cS1W6krj5EZBpJVIsjqnVzoqur0MgVaKQtGmnrNOB1rHs5GqnNqjqilVZopaXThPtN 6RdHn0tBM143p18L+rWkXyv6tcZrQqleIqg74qkyI6ku65JxRpNttiCruJpcYQMZVxQsGEZVdYWI dKNuaifX86+D9JdbpaMMkT9w9w7yoe7yoDwvN8mLslBSZJEs46fl8pXMkTX8e0fWyQ55V/xk2J/J flVP1qhGqpFUqibqCjmqblYDlKgEdZvS6k41TIWoe9VIFaHG8K+OSlLjVF01Uc1RMeot/nVTb/Pv WvUu/7qrj9THqodao7aoeN1Bd1IJuov+nRqsu+luaojuqePVH/QNure6Q/fRfdRduq/ur+7WA/QA dZ8epG9Vw/UQPVSN1Hfpu9Rofa++Vz2oR+oH1Bg9Wo9WiXqMHqeS9AT9kJqgH9Yz1ST9rH5BzdQv 6TfU83qO/pN6Tc/Tn6o3dIbeoObpjXqHWqb9eq/aqA/ow2q7rtRH1U79vT6pdunT+qz6m3aNqD1G G6NKTbCJVPtMlKmjjphoE62OmRjTUH1vmpqm6qS51DRTp0wL01KdMa1NW3XOXG6uUK5pb9prZTqa TlqbLqardkw3c60ONj1MTx1qrjPX6XDTy/TSEaa36a0jzQCToGub28xQfbG504zQ5DsmWceZCWaS bmYeM4/pNmaqmarbmjfMm7qdWWQW6cvN5+ZzfYVZZpbpK02mWafbmxyzU3cze8xh3dtUGVcPdIKc 2nqoE+200fc7PZweehKeokCY6lbrWzEjHpmQJNGjJzyQKOOShqeNk7eoxdWtg3vFUf+I69p319WS RnIp1Xs7PKsLHnWDJMjtyOgnd8lwGR3oF0lF31iaSV25DN+7Sq4l674FH1T43d1yPx7oMKamb23O nEukuUTL5czTFf+8UQbhrRrPHSYjZAznth6cMCBOut82uH+cjLXj6uLvoeT5DaSF1MPnfyc95Drp I4OFmoda8Ga5hxqgpi9Rjp00lVhpKTFypXSWq6Un3Pg9zLiDlbSRAXIv1UJiQLL3TsI4aSitqGLa yzVwqZf0lduEWkHaykC5DxYlSfKITqkj9GzbvmXbebZdZNsvbbt2xPCkNJ1l2zzbFtm21Lbltj0+ YnjqA/qc1xpt2xDb1rZttG0bjhiRPN7E2baVbS+3bSfbXm3bniOTxow2vW17k21vGTkuJdkMse3d tr3ftg/adpxt00ZNGD7CTLbtDNu+aNs5tv2rbRcibLhZatuVtl2bNG5istlk2xzb5tm2wLbf2XZf UsqIJFNu2+9te8ZrHeHhBKeWbSNsW8e2DWzbxLYtUrg47WzbwbZdbdvdtr1s2zdlwshxzkDb3mbb O8d79++z7SjbJtl2gm0ftu3UVHTuzLDtLNu+Yts5tn3XtvNTx4wb5Sy07We2/dK2X9l2vW2/TU0e Md7JtW2Jbctte8Zrg0JsG5M68f7UoBa2bWfbDrbtatvutu2VOnF8alBf2w607W22vdO299l2VBor D0qy7QTbPmzbqbadYdtZ0MnAy/ow4t/5SXufjP0NVwUXfrl1fkXb+F/a8F9sDTEjFE7/Oz8pItg/ txf9ilbb3Wskea9UIHZ6bcivaKN+RdvwX9rav6K92K7L2Ku6oPXWe+G9iF9sg4h90UTTGo/4z17F BF79mnkVkfmX28hfaJsR/QdyxtxDdB4nD8lUeZrM5g1ymflkOUvJcHySQ25TIvukQqqkWtVStclT mqhW6krVVfVUfdTAGruqiwLXhoFrXODaFe/3rt1rXuu4mtd6duB1bs3VNKy5bwL9zS2B+5MD1zcC 15yaK1lpzTXw3Pk4cC2ouQZ1qbkGz7NWVaFFNa/Dugau19XME3ZT4PWswPVczTWiTQ3XIopqrlG1 au5HPRi4fhu45gWugXmjqpgvDIxQr1sG3K9eow1hp3M9DqgTXq0qjrnR/N70Nf08fug6ug7OF61j 7Aj6mtpeXxOJjyqso4g5NdwhL5cIdVQd5eUJZCl1Rp0RrVzlitFBOkgcHa7DJUhfpC+SWrqerifB uqGmStHNdDMJ1W10Gwkz/Zg5HFn12d00b9kqSh5XDdUl8oRqo9rIDDLVu+UpstNkeUalqBSZpf6o 0uQ5NUvNkpfIVv8ks8lIb5FXdJqeKBl6ErnRF3qynixL9RQ9VZbpGXqGZOqZeqYs16/p12SFflO/ KSvJJ3fKKhPJHo+R3XWRH8jlestxVnO51NXvmZtNghllRpuxJtGkmolmknnETDHPmGfNLPOced68 YN7xtKDf1e8SpPqb/mhqoBko2ow0D4gxD5oxEkTuN0GCTZpJkxDzkHmIeuBh8zA7JxuUcLLB6VQH c81cNGts7PgfHTfxrKCv1Z5tgnVH3RHbdNX4jb5GX8OT7ro7uu6te6Prm/RN6PoW9FCL3g3Qbwd9 lb6a0TfofjpB99D9uR/666XoaXoas76qX8UPtHg1WROnqRPnXOo0c5o7LZyWTitbvSuznKpG7Oob XLD6ptZzkrwejlf11vRofEGPuAueae//mOgtjlctKqeN08b6hTdvtFPPiXHqOw2cWKeh08hp7FWF f59Xk0VGOXWcuuTItZxgJ8QJdcKccCfCiXRqO1HORc7F9HHQ9OMswRujyaB7Uo1e71wPAzR5awMz 3ywwC81is95sMD6z0Wwy35hvzWaTZbJNuTliKkylOWqOme/ND+a4OWF/x/WB+QCJH5oPWcsn5hPs Tj7PPrw5HC97/7v0D+j1CU+XmxVmpVllvjKrzRrztVlr1tFvryk1ZWaf2W8OmIPmEOM86fPNfKQv MAuQvtAsRPpisxjp60020stZgyf9SmrJn5L6E/uwOtvDOAmM+4mZf2avnq6z7bhmUlvdrv6g7lBD 1RD1oNqmJ+qp+hn9unnLfGQ+82KOukXdhoFHq9ESpHJVLr6UptPwpSl6ivc9ZvAw1PIwzMwxc+CA p8EI86n5lJNAqyo5JdNlhjzFGTBTnpFnZZY8R9X7AifCSzJbXpZX5FV5TV7nfHiTyvdP1Dpz5W2q 33flvf9XzZXAU7mt77W+b5vJLDKESjJ+2xCVSKSRzBwz2xYRMoYGdkWaVFLRYCMipSRNUpQGojmF ojImKRWS4q7vo3JO59xz//d/zz2/2/5Z715r7f2t6Xmf930WvwAbZIBMkAUOg2wUO46AXJAHjoJ8 pJePo0hyApwEhUgbF4HToBjFlbPgHDiPFHQJuAhKUZS5jFR0ObiCdHQFuIZizg1wE1SCKnALVIMa FIHugLvgHrgPHoCH4BGKR4+R1q4D9aABPAXPUHRqAs/BC/ASNIMWpMHbQDvoAK9AJ3gNusAbFLne gnegB7wHHxDL9KI41o/WOgA+g0HwBXwFQ2CYJGakl60xG8wWs0Oa2QFzxH7BnJBudsFcMTeknD0w T8wLY5DqGfNB6tkXaeflmD8WgK3AArEgLBhbiXRxHVaPNWBPsWdYI9aEPcdeYC+xZqwFa8XasHak mF9hndhrrAvnxd5g3TgfqZ6xHqSeP2AfsV6sD+vHPiEV/RkbxL5gX7EhUkvjkNTSOA3nwDmRnubG eXAr3Bq3QXrXBXfFPXBPfAW+Et+Ab8Tj8QQ8GU/FD+An0bmewouQxj2HtO1t/A5+F7+H38cf4A/x R3gt/pg2i2aAUCM+wv8Uk6+jmJmNL0KM+hBpagtQi9S0M3iCu+HuoJ7iiad4MB4MniGvjgON+C58 F3hJoamZ4tIWyjdbKWS1IVzmgXbKQzsoD32Fn8HPgk7KT7toM2gz0Ulg8BI6w78Gd79G3V+FuWf/ EdT9jLtvyPt97P1AH4m/HwhkUxj876AwlcQPxKA4Yp0JKGcQoxhoEpU5KEM3yASqFBtpkzddQAf6 o1xCF+US0UAfrkbZkSlMhQeBGyyGdwADC0H8tBZLxFLBbiqyZ+P8uAjIIW+NwHFcAlcBBbgargmu 4nSULdygUNeA4tlMFHlFUASUA0oof9BBc8pGL7JEMYF6X0DVSkdrpaj2DL3Iv7JThapo7hpQAx2E PtRHaJwP56OlLoaLAQ3lOPtQZj6SzRWgF8oKoCv0GW05M6bltxmEApVBuGDLqQzCGrNGHuaAOaDY 74Q5oR5XzBXFfibGRLHfH/NHsX8ltpLKIBTJ/5v1VxmEFULFL+hZ3ui8g8nc8f+QS5Ajc1Ejc1Mj 81Aj81Ij81Ej81Mjk7872g3mwwfwIXwEa+Fj+ATWwXrYAJ/CZ7ARNsHn8AV8CZthC2yFbbAddsBX sBO+hl00nEbD+/B+/BM+gH/GB/Ev+Fd8CB/+/7TR0ObTSN04AaELo7JTIVJZIG2BI+0hh7rJHJUD 4Q2tEuHNCXChcyD/wp5EGg/KWgNQPCSzVj4YDiNQxrwGrkERNBEmAkG4BW4FQnAH3AFEyBtXIIoQ WIzQWwbLEZ6vwxtgPKyG1UCKyl0mUDFYhorgBJXBmFIZjBma30w0w39jz0b95m9cGUKOCpUzOCGv +TMFWI1Y8AlivBbEbe8Qj31Bc+dGOlAMzVseKUE1qIW8xxCawkVQBa1DGa1KnbJOyKdI6wpnUNYN zqSsO5xFWQ+kCknrCWdT1gsaUpYBjSjr/d0aU9YHmlLWD5pRNgD5KWmD4DTkiYLImzFUUwPkPbsG 5ZuaqHSDBCrdIR2VHlALlZ5QG5VeELEFGksXld5Ip2KQCfVQ6QPnotIPmqDSH85DZQBiBQyNsgCV wRDpAqSFFqEyBC5BZRrSwBjcD81ReQApKgLogzlgAbAEjsAD+IJgsArEosi2HflYGopYOSg6nULR 6BKKPFXwKFpBGpp1PmVd4THKusHjlHWHBZT1gIWU9YQnKOsFT1KWAU9R1hsWUZYJT1PWBx6i9iKd 2gU2tQsZ1C5kUruQTe1CFrULh6ldyKF24Qi1C7nULuSRa6M4TpmyFihXGAeUgRYwoO6GxiFkSVB7 PZ7aI8nRz9Og1Pd3vuROUjdg/HAPtVdUSSoDKISwD6A4ih+QwjhGIRen/haFH/bAPjiISIAT48eE MQlMGpuETaP08n9S/yImpzTaD8XHTaqg7xrqn+ig7wqKfIYbFvCd88kIQN7RSFC9qEbzAN9u7sDo /df32zBpU2TFRpqlDQiWtD4nj0r8gvh+AciFsVnS01DTFAxCOh/Bw8mhOg7HJnAAwpOTV5UT0iBL D4M0tg1hRaiNaZHJlIuVQYdEvpYCLxAKgkAAYIIw9GNIvgiFMQ+jiQlap0GJJBU3HefFQtlGngb3 IrfJsVniTQQLr0A/6mwckRUmNP+yVErTNmszk/6GFQsE6IcJge9ThRxoUnFbqEnidjROUczJmC5O iJIVblF+B2ZoGDMkUN7EM5hJFyNEyGYuUT7T8BAvz8AIv4AAJl0QPQ218opy2vp6RoYx6bKENNnA Jyo20iBvwgwJ8/PxY3iG+QUF0icSsmQ3Liox2m3rtwKN4rki2C9wmbyJMSE3XoDQpmsROgT1z2m8 AJ2samtp687QneFE2IyZrJ0NfTwhPjL+OHtmiJ+N37JANfmFgQwNuioxbWQgxW8d1FDyNt/GsmGG RPgxmKHkoCyoOHZXIAfAWVAQoHZejAUhyKs6dbi6Rv4E75rEYwnh705b9DSVC15e5lma5S1TXzJQ pZ2/gUh0XLu1wf/Z9EOCl+91rXofmbM2yOBy8gmBC74fA3ZXlVqr5y+Y3Xvmkau7NJb+WdNf7nB/ VlrOhJvYi3VLrJvHeXTNkVl7XqDR6MbppoRS9+jldA08NU40d778bXqogIN6zSod7RSRVJHzjb6a R9uar2zeqnJ1i0KCT+l6R4eg8MsGR5USXKuExA3SN3TalvMGVgxdW/TsPJfwXsXVDYZT78mt6kqn V/a0KUo1VBTNN0mb4M6W29Hi1tu9umdNvhdM6jXna7yraJ+bUlOwKaKg+4LAhxbzOvagL7tAbFZR QnkJhiPgZ8U1EHFPCB1OboRYDg4uiByOUCImf6sTMF7SNywseKamZhAjNFgjAu17KNp3DUbQCgo7 sqIQDtO4CU5kMAgIY7JtIm0moU9MZ+uwteKJ0a8zQgJ+9W3NEayMhYqJsQb6FIVU2Sk0foL32yxw bmIc2ShIjkVDHsCJZojqwjSEzMNSxPhv+MZF+W1tjBHQ9NXp6rrav/EKPC4OLPIf6HS8YipDT4xK Vd1zmXUM1sosqTm52TGwiXtaltvNqmTRdpq1wNv5UzWB/smWymSLtIeKXuL9RnoKS4PpsT1b9BOK Ojr2gqE7dnssJt/Pm2oRXXDW0/iDyu32yjq3ZyWqGw2LDxbXvXAYvnT62treO/yH3u0dUn0wy1pa Wn9qv9Ei5MPDBAtrH/VjgVeq7x4+mbZJUouDxy0tYtNv/fgv8Yyf3ZHQH+uODv/ioJqE+sigSn82 KNnHDPlTlzxlqbzg2QPf6A2Spj7hrmsrzqUzlIZnmxxYLawvNMUutC58qt9Xi/PyLg94B9jSKm/s 7BU8n8g1tFzU9r/x9lmWHnO7dDL/GRs5l9U+uu4cm+cNRVg02cRmxskfLNjkksnd30oMdCvqLZnL e7vp+sSKWrtXcUbF1llqR2H0+8yj23SH0ttcl3Okz/ZvvrynbKjaY2BOOxfb9HWcVWC2yvszm4WU 3yQ95WTHW6bFLOIWIGSrhA75979yLKDlzUk9pdyRJHHMoNkmaPED3YPFQd6yRXvUSma3R71eET0g 0aZ0/MTbVJuzc9RSzkUdHXponT8tbO3crhlymcsl2n4pmez7BMSaCCXE+o+6ZBURd+PfdEn+7y6J EYDQHnFGNUKFUGYrsSfHK/6RM4aFhqozPCn3k6Dcj3zEP/FAzrJ/yQN1fuuB5CknrAqut7CG8s7P oypZRMXX81J7SneCq6U1Ndc/jnsyPGBepu1FCF/rDZN+uKvR/YC8aOHqeZcsa9a3x45ff2Rq8jJR s8Gqc/uM8er9Vs4cW9blBn2QtpSerPHeb1uAYn9JlUTKG/6wMt/IutepXgnloTs+JYZFT8rP2hez t7A/adpKc41w6QXG9e+KBeRtayPZe1kMv688dza/Cy/h2V83IGynlOapdSkaOxkTfynz6hZFtVX3 dCMu7gp1GTjftkScd1J1y/2HOhoL54gbCHpET76e7fN2z53g14btHwXWPr23OitipV/5gaXzCV2F wswTE7wMVOu2H1XhinkiWeQS8/JgdtCQQeJxgkUTQRTweYQCBEE52GJgsEn4nmEfo6tpztgdoyEG CP7m23yiiiZBwVEhfst8w+SVGdPk6TNm6Mmb+zFCgkKDfMLkTYJCgjXocoTMyIfFf90TFDISqxWI iSPHJPmj3zooKEzeODzMNyjELyyKpIcZegSdThB6o/SgRdC1tOmj1b9hRn8ayrHS8uC2We8tpJXT 965yIzoz87ZNcf80lLIk6+zQwUx5w9VWmfszkzy0/O/N9Y7qPhZRaVv//vWBeJmk9A0+Rdf8o70m 1coaNArCXR17Ki6r+6Sl+Sql3p2pdpm/2FGp3Kyd11B/j1qe8ozcroXr5zZvECxJC7DzPMZaneGh HrnkVepp71lpljJ07sli6XntO1Ul22bvY4h5OHIw02X1rBP6j7zdjV2XfnDZbl5RYuzlmV22uy0K vh6JXhFmcUKyeg+PsgJw2OHhp1eyWITLwH7YefCwDy93zv04e4e3Z2a5ScRF0ur7LhXEpgydrFlX e2RCiItB1cV33FmKRBHnxsoi+UjRjU2jvJFLxGUTcZmkX0JaXBoRtzdWyPlu8Fu/kEOTrNaKnTLf PnwrI+S/f36sP8E4xQopHXxl2z7sldR9cw5OfhIp/MHFQyv9EN8tQ46dm5IqZ7YpvH/nkKxWzJ5/ 0+vtl8fVs2Y55U239RuavMKosvpoI8fqZ/Rts9OFgpeXDIkslfQr+3LXpFnYSX5pp1fMiaNSN1X1 pqhfYmaIbJ4iyMjqt5UZUKisFf9gfSzQRIvrK2v8p9ZlAQJWfaU91jdK2yuIL/J0nk2yKdMmmD+S xbJ7Yp/jp50/Fj676dDNXHjD2vbMaVxZZHhH7TvupLXn9l7L11NriW7JjWyOYIO7y43K70/f/NxY JFd3ufTyBt0XD2VoLbnzaDedtPUDzWUEvM7yZm598MjWyKxGxi4nuEFkZkJyePqR+2zECldRcnBi NDFYzpe6tAzI5gvXV2AZPlMvfBMJsn8XJRDTUb6gQ9fT0aHrkAk8onit6d8oIS7n1ymDKCE8Ijd4 HTxDfVEqEIbGEaJCCBIbXNZM7xVBgd7fZsb7RzP7o2VqoUF/WuYkQmFkGRPG9ngzqeSDzEYsKVEg /zOTCJBMwk0xydVq+W0Xm4YNLbujrzycPKUv4rbCcI2KvUXVgbOsU7pR6qAil/sRo/Jsdt+r8vLa wq17Mrk+C55hWae9Zl0vFbqWW9btv2G7jXSJ5WdvmFgu8ZDlC+asMu0V0bcYZFg9/zz7fKteYROD a9KslXN05n/0LzDrnRoqp3hrrpSc1RnrtAdZd0WvSxmt5FzxPkXB1H3um7LKVG/5c+U6XzJN22JO yWqey2n8mNG0X0FwyJFubKe/9oRje0vXL1FT8vtVNIWN9FcZzl13xLdlraLv+LZFuypWmVrPz1i6 ITF5f9mymE6ewXh8TV/qSgPVIz77qpvUX6piEwR1FjB7DURO9CTIyCpZB1Uj7OFZLKiC9kPp9/Jw /H+DXkQ4eUYFuDjiFwzHAY2SqLLjaBI0sSmfVBe73gyxPd7ax1YZLzFYPmATR0h9/4oYRuOX4wU2 IBzJdRNgTPBRiQ+lO8wIwe8JFgeBIzPGLykaYzQ//8Bx7mQnH5/OPRbdMNFr3iPuIwOezJsa+Gf9 BcZ3it9PXf+g+Zq9TW6x1O3qth72gP2ZBbvnT27Nm/g0+mGfRLRIw4cd0l3crkUbd5zf6lgiU53y IGW39sedjcOb9rstXmg5Q2mmvLSt3pc1LuLJV5/KbH/naW3QyvXG521UV9JtBwYzRXIhO7qJebZJ qWDopsiZ65nV1923BH+oashnBXI9ZUqdz+2Lv8Izd1+P0jG/6MJy1SMnfSZmn0jg9t8reu7k9FQ5 jixR/ayyY4ThBYXHRE6Vl4jMCYdtrT3RwhfcDPj1epLLd22yoDlxuNy4U5tX92LNzlVTB08HZidx ajsWuqkICxIsDm1EZdIjNMbraXboFnXdwvzphuJ/hTJ+cN8MHW2d6aRa0kO5EarqklUi7C9Zx2g/ /gf9f5oS1cTt0S9wyXxf3tR4Nz9lW63BwYlbrrrGa7i+KwzpzT+2aXlxfaFiDN/Nm9mLd7opir4a 6J10sPhjYETB2+7DBjcqyn5xMcovCtVWyvGK84zK8PoYuCnlbuCzG+n3D1sJR3heCN7MzNgjkXjE Ne6uqU9rg/2hOVVfnkZM1jAlQGvtmpgU4UeOslkdS/kqNz3NrLVJDahiVKUuT9vltsRcuEPzgbOz m7t1Vqh6dsmGeQJbpcQjbnHXp+UEi3eYd/l9dT3ln/RmmpWe/pbrZgvFd1vuO/nR9/DjRp6Vy8IO RW6V3ei/t7PdfV7187aVAvcYIDmGvm8732nR0qK73T1NCt15Hp7deiazr46kRCy4C+3I9p+0yw8y 6K7zzwu3qVnaLW0hxSmXdSD/zu6vf8B8eWTrJFpcBhF3KPZ3WSQj7PDfwX8/JwuLR4SfKTGXmMM2 ZBvEzxwj/FZ8ew6l/IL9/chWzeCQIO9wRlioJukAJP4R9rUoQbh0jBI1IYwJo+9KFIvXHn1uZGTk 7z2XGfLzA8N+TxPq171N0d/vsk/M1TbQrwm72V40+OCK+XHN/HW2AvVaZz4tbxMYVJgQaZjtG306 Ze1ml/cmFev3M9dssrRazRLrXR/6OPOSSxUWfFspYPxFa7HsxLKzLRnVGeEHd66cLV1mD+yLP21Q qnfTHqydEu2WVp8z+PG98YRjdmbHFzzdqS/qyLOw5wM9YeJF2nZnESb+is/qbgb/5tTSuvLcu9zi UxSKzzgkytxzjtfNrvp6NKErT8/orIl/s3zPvItrC1712J3KWHCReclGp66yg5NB41wVaDm8oGR/ p4lTQsNx3tjeX66ptbSuc17UqhXVrbhxF796kaXz9StzHB3z79c0a5bXdK1I14uis2i3EG3ewCAk 4or/Z8jxVwT/4xqbHddBiH0PqMqQzoVzUH94SobZ0aPnwen8Y2/O0dR/1Pjo44ixveLEpB9fpNGR 39ZmpDdp8i+2WrAyw0eggVeyU8/wCxEy5iv8dG/Ci60fOx2YAz/AACEgiLp89wFhQB6YoXeB1Dt7 wER9oegzZIs80AUagABEhlLs5D/EdlhUcNCyEM9g36jfZpM0FgTrnOotPJYNK7pfvL9ousvg9ZhZ zap2ZsdCDGMs1p1/HJh2zLjC3PBTPUca1lPs+Nm3aMni5E4Rl4OJIvNUxu+VcllsKP450TnkjeQR J86FgaoyqVkzdXdXHtoZ3eS5jrl7a0eHzkKpJO4WojMlKqtQdiqj9aRt/lbXFFdcKtdX485Dy4MT VzvOw81Xx8s7cKzS1ObU3P1imsSJfnFJqcCPkWc+LHEbZPPjteZ9X0/Me5WwYd0tvuCKbbS+DVX7 osc5+kQdjpqw5LNBl9FQ3Cv7ty9nh9G2a2QbMN5NenrupL1Ze8hrD0kGBuzrbLOSyliC4a3BA7a7 9S1vDBZ2PJZ61x72nOXRK5bBQmkRCw7+ODFOOgt2oaYOEt7L/pJLzd+5SuXn5B6ZAIZYhv0LITkW e3w/frUDEfS+93DQBcl4jwK8FnnlQddzQvw7BnoiNCFLrVLVwwrcEYpKn54rLFu1+ncgkFyZ7MzM kzzy6K3jtn38alylMV050m+NpDdaeZ6+OaNpf9Qs2cU7S19ifufjPnQdFpyYVigbsI4vS05oOs9n C1W7IRPlFTWGtP7jASHN1kslolYmC3Tptq/x2G3mJlU2rWD7Z68rO2cU5W9gauc09rkGFHXuP6AU mTmtpmNC3CyY/TrEmsD7HGWrby8aPuj1wt+3RefehQtrZqorvnHwCtE+FRTaIpPhSHS/tGFe37LX 4JbjtrTsx9IVx5IUbs2SLdSeY0kEnWqfZXRcmtG3rr11l8a6gU9hz+ZKw1uNu7x31Z67/s55/Uk3 y6tRcTGbLwR5J7caK/tlL2spcF0Ta+b2UUUFA9HsfwD1AkSADQplbmRzdHJlYW0NCmVuZG9iag0K MTM2NCAwIG9iag0KWyA1MDcgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA1MjkgMCA0ODggMCAwIDYzMSAwIDMzMSAwIDAgODc0IDAgMCA1 MzIgMCAwIDQ3MyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ5NCA1MzcgNDE4IDAgNTAzIDAg MCAwIDI0NiAwIDAgMjQ2IDgxMyA1MzcgNTM4IDUzNyAwIDM1NSAzOTkgMzQ3IDAgNDczIDAgMCA0 NzRdIA0KZW5kb2JqDQoxMzY1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDUw OTE0L0xlbmd0aDEgOTY2NjQ+Pg0Kc3RyZWFtDQp4nOybCXxTVfb4z30v+55uSZumSZMmaZs26V7K 0obSlrIUCiXagkgLLVRHBYGiqEjVEbWCG47jruO4zaCSBtAiiqi4jIgyyug4jsoo7nbEbdwg+Z/7 TloKgjPOz//n9/n9fvPa8773nrufc+9996UpMABIxZsMmutaJk0895W6XcBODgHYWutr62a9++yU PQBXbwZQVdTXTp2g3749CLDuEQDxm4l19Q3glS3E/E6sJWti8/SWZ25x3Q1wwycA96VMbAnXfr5H 2w+sAZOtzuktwZIzrlv+BQD7MyraF5zesSTnkzovgDkCIGxfsGK50/tZ8CSAknsB5F8uXLLo9N98 VHsfQMoSAHXyoo5lS8AKbmwfdWBadNrKhZXvTj8VYNTNAGP2dXd1dL7dtvFdrB/rgIpuVOh3aCox fi3Gc7pPX372t+elvIdtjQIwrvhF19IzVpy0/DaAVTheIe20xQs6ptw2Vwew/Dwc787TO85eYvom bR6WH8DyzjM6Tu9a98jaqwFWtwIYypYsXrY83gwPY3/W8vQlS7uWmJ/4Bsdv/yUa1QXctnKAHSe+ +sA849ivIF0F/Nr28XnPcz5e+4HmoDG2TP2R8lbMqwYB6MJyCogB26k5F9M71B9JNY24xNlcI+uA 9Vj/2SBiSRMEoR1Al4ntCpgqyjzCI5iqkt8gL8Uqs4jiHnhYABUIRqUgymSiILsdhE9D4Dx3qO6m FqcT8Od7GfVBeavgRffeJrW7Q27gI8XaDfCzXLKxMP1fySe+D+v+K+3Idf9eeeFutO6/cCli/7X+ jbxktcevS3wWan6udn6uSzYRND+5zChYI+6C2f9KXvFKWPPTezWirZsPlxdMP14XpluHw6cclXbw 2GUVjbBG9syx02R/gfBP6at46HA9Ms+RdYqLYcIxy5wLtp/SxshLVn78suJu0P6z8uIXMPEntzkF zhfboPHH8igMx06XKWHyT23vf8vFvoZf/Ez1nH8sveJCOJ/75njlZE0/7rMf5B9Rl/DnI+sVi2HS scrI9x6pF54Gyw/q3fhD3bHyyEOUT5n7z/P/K3lGXuIfIO24ac8dP+1Yl/AYVAhfwWyhDkZJ8Wdg 9Mh0ds7hZyRbAbNlp2Heb1G+gipeTioDGB8NY9l3kCnF74L04frv/mlj+5964bwG9vZ/dy/+c/3n +s/1n4su4SZ477hpp8CLx01zw6r/Pz36z/U//BITkpn4VOAljDEpLoMHkTn4fi7Dn2wI4PtCPZ7Z JkMTNEMLLIAuOAWWwHJYASudq+NxzP3DXB1SrtNg6VAuMU/Mj78YfzW+P34g/jUopbeCrfAlb5xN ZtP+1nH05xPSlZS4ZwwpmMCMzMQWsx62gq1il7G17Cp2IyjYJ1LyZz+oheGxhj4TEeDHr0RJ8bjv BmLrP6nhyH5LZygoQKGTWJ10P1G6n/wj3ZBGyD9tScTnSvfhEWOYxgxsh5TyzL/cq/8lV6hh3slz T5ozu601PKtl5ozm6dOapk6ZPKlxYkN93YTa8aGa6nFjx4yuGlVZUR4MFBbkej05bpfDmmI2GfVa jVqlVMhlosCgoN7d0O6MeNsjMq+7sbGQx90dqOgYoWiPOFHVcGSeiLNdyuY8MmcIcy48KmeIcoaG czKTcyyMLSxw1rudkd11bucAmz2jFcPr6txtzsigFG6SwjKvFNFjJDsbSzjrrd11zghrd9ZHGlZ0 99W312F9/VrNBPeELk1hAfRrtBjUYiiS617Sz3KrmRQQcutH9wug0vNmI6KnvqMz0jyjtb7Olp3d JulgglRXRDEhopTqcp7C+wyXO/sLdvStHTDB/Ha/rtPd2XFSa0TswEJ9Yn1f3yURsz+S566L5J2z 34pD7ooUuOvqI343VjZl5nADLCL3mNzOvq8AO+8e/ORITUdCo/CYvgIe5EMcNhOmD4UB+4Y9xPFl Z/O+XD4QgvkYifTOaKW4E+bbohAK+tsiQjtP2TGUkhrmKb1DKcPF293Z3FX17YnfFd3WSO98Z2EB Wl/69eAvpjsjord9/oJuzo6uPnddHdltVmskVIeBUEdirPX9RUHM39GOgziFm2FGayToXhJJcddS BlQ4uQ9OaWmViiSKRVImRKB9QaJUJFhfx/vlrO9rr6MO8rrcM1q3Qml8X3+Z07apFMqgjfcjkjYB neKt72vtXBhxtNs6cX4udLbasiOhNjRfm7u1q417yW2K5O3D5rKlFqVSOLajcg9l5iNXelTOVsEm tnFvocLZgDd37VhMMKG7pCj3aO1YZyuzwVA2bCWRg4eOqAcjomdCI08SedEJjbbstmy6fqRLtkSf 5J6IakRdJlQM94naOW7XKDfvUJ6zvqtuRAePqFSe6GCitmP3U+C2SDSMJVTcnY1DSaIHVy7qBKxG UnEvWp0RaHa2urvcbW6cQ6HmVj42bmvJv1Na3FNmzG6VvJ2YJbOOiFH6KIpFIBuThyLCBJyDDX7b kFul+EQpPhxtPCp50lCys0/lntLSxyt3JyoEJ64gHLTCO6nj8lFJZbg0G3B3czd0uJ0mZ0Nfx0C8 d35ffyjUt6S+vXs0r8M9qbPP3dI61ib1dWbrKts5vKkkmMKmzKotLMC9p7bfzS6d0R9il7bMbt1q AnBeOqs1KjBhQnttW38OprVudeLeLmkFruVKHnHyCK9pJkZUUn7b1hBAr5QqkxRSfMEAA0mnGtIx WDAgkM40pBNQJyNdSNLxC51k7UYT43Zb7+zk7jmvrbuvvY0vLkhDV+IvizB3NUQEd3U/ExS6iMbd VRvRumu5vobra0iv4HolTgyWxtA4fE/qa3fjPoUTqhVsjKaiyKt0DsTjs1qzd9sG27Jxqp2EMrs1 ovbj3i/3TMZ8E7m0o3pipHdBB+8HhFt5WaVn0oI2nLZDFWKWSRE11qBO1IA5GqQyfDpioQXoG3Sg VL4XI5HetkibnzfaekqbNJ1NEWh0j0a3U51yL28o2NaX5C6R1iYuBY3nEg419g1aWkljwyg21kZG Uuqw5wvcmLSg3YnWlsGCFpzqtJdqbKTpwi1R5u2SRGNLJAIflujR6jURdQArxF8e1gb4kpR7lG1t 1HkpdkkiA7ZtimixR94RpkwUQOtg0iTeF/y9BLvKsz7Oq5kxADPdZ+POwjst1aTE5IjeM6kDN38q r0WNe9RQYRXfI7SJOnaSVslHrkO7i55ZA/F73CuzR1yFBW7+cOATE2xbcWJDW9/Risgcf2GB6mit XlL39an0xy5A9lLph4lK6FeLA8K30Sy7Y0D4JprlR3wdzSpA/IPwFeFLSvuCYp8TPiMcIHxK+Dvl HCR8QsqPCR8RPiR8QHif8B7hXcL+aJYa8Q7F3ib8LWpPQuyL2tMRb0XtQcSbhDcIfyW8Tln+QrHX CH8mvEp4hfAnwl7Cy4SXCH8k7CG8SHiBOrGb8DxhF+E5avYPlPNZwjOEpwlPEXYSniQ8QXicsIPw GNW5nfAoKR8hbCM8TNhKGCA8RHiQsIWwmbCJECX0RzNLEBHCxmhmKeIBwv2E+wgbCL+PZhYjfke4 l8rdQ7ibcBfhTsJvCXdQ8d8QbifcRriVcAvhZqr6JsKNVPwGwvWEXxOuI/yKyl1LWE+4hnA14SrC lYQrqOp1VHwt4XJCH+EywqVU4BLCGsLFhF8SLiJcGLWVIS4g9BJWE84nrCKcRziXcA5hJeFswlmE FYQewnLCMsJSwpmEJYTF0YxyxBmE0wmnEX5BOJVwCqGbsIiwkNBF6CQsIMwndBDaCfMIJxPmEk4i zCHMJrRF0ysRrYQTCScQwoRZhBbCTMIMQjNhOmEaoYkwlTCFMJkwidBImEhoINQT6ggTCLWE8YQQ oYZQTRhHGEsYQxhNqIpaqxCjCJWECkI5oYxQSighFBOKCEFCgFBIKCD4CfmEPEIuwUfwEjxRyxhE DsEdtfCZ7IpaRiOySekkOAhZBDshk2AjZBDSCVaChZBGSKUWUqiFZFImEcwEE8FIMBD0BB1BS9AQ 1FSniqAkpYIgJ8gIIkEgMAJIYHFCjHCIcJDwPeE7wreEbwhfS82yf0gjYl+R8kvCF4TPCZ8RDhA+ JfydMEj4hPAx4SPCh4QPCO9Te+9F09yIdwn7o2k4s9g7hLejaaMQfyPsi6ZNQLwVTatDvEl4g/DX aFo94vVoWgPiL4TXCH+mql8lvEKV/Ykq20t4mfASVfZHKreH8CLhBcJuwvOEXVTuOar6D4RnqfPP EJ6m9p6KptUidlKBJ6mhJ6jXj1NlOwiPEbYTHiU8QthGeJiq3kpVD1DVD1HVDxK2EDZTQ5sIUUI/ NRshbCQ8QFXfT7iPsIHwe8Lvoqm44bJ7o6njEfcQ7o6mNiHuiqZOQ9wZTZ2O+G00dSbijmhqCPEb ynI7ZbmNstxKWW6htJsp500Uu5Fy3kC4ngr8mnBdNLUZ8Ssqfi1hPeEa6tLVlPMqynkl4Ypo6gzE Osq5lnA5oS+a0oq4LJrShrg0mnIS4pJoylzEmmjKZMTF0ZQ5iF9S2kWU80LKckFoI/KAsd7xqaHR sU83zfEEyuMoO1Ae057giKL0o0RQNqI8gHI/yn0oG1B+j/I7lHtR7kG5G+UulDtRfotyB8pvUG5H uQ3lVk2340aUG1CuR/k1ynUov0K5FmU9yjUoV6Ncpe52XIlyBco6lLUoA2x1NJmvvvOjSXwmLScs i5r5TFpKOJOwhLCYcAbhdMJphF8QTiWMJYyJmjhGE6oIowiVhApCOaGMUEooiRr5tCwmFBGSCGaC iWAkGAj6KPpggOkIWoKGoCaoCMqonntWEZqD/DvKIMonKB+jfITyIXrvLZQ3Ud5A+SvK6yh/QXkN vfBnlFdRtqM8ivIIyjaUh1FuQcvfrOGW7iVLnxM18xm+koxzNuEswgpCD2ECoZbsMJ4QItQQqgnj aMiphBRCMuFcaraFPDuTWp9BaCZMJ0wjNBGmEqYQJhMmERoJEwkNhHpCHcFFyKYOOgkOQhbBTsgk 2AgZhHSClcZgIaSFbkIeQjmI8j3KdyjfohO/Qfka5R8oX6F8ifIFeu5zlM9Q3kd5D+VdlP0o76C8 jfI39OBulOdRdqE8h/IHlGdRnkF5GuUplJ0oT6IMoDyEXn0QZQvKZpRNKDdJHl5FNj6PcErUHEB0 ExaRPRYSugidhAWE+YQOQjthHuFkwlzCSYQ5hNmENkIr4UTCCYQwYRYhSAiQjQsJBQQ/IZ+QR8gl +AhegoeckkNwE+QEGUEkCARGyw1CdyDjKDGUD9Cir6D8CWUvyssoL6H8EWUPyosoL6CFt6JcLHoc vxQDjotYwHFhY2/4gg294dWNq8Lnb1gV1q4as2rKKlG7yoY4d9WGVa+vUpzXeE743A3nhGXnpJwj aFY2nhU+e8NZYe1ZTLeisSc8q2d/z5c9YkrPrJ7OnuU91/bsRYXyzp7NPTt7xIH4jlBSz6gxDb09 V/UIKZguQA8zcnV2j9bQsLxxaXjZhqVh2dKypcKY/UvZnqVMcC5loaXNSwXMtWlpTm4Dzx1fmpbR AEudS4uWimc2Lg4v2bA4fEbj6eEXT2e/wKGcikM6JbAo3L1hUXhhoDPctaEzvCAwP9wRaA/PC8wN n7xhbvikwOzwnA2zw22B1vCJmP+EwKxweMOscEtgRnjmhhnh6YFp4WmobwpMCU/dMCU8OdAYnrSh MdzcyCYGGsL1YoUDHAyy8HdJVm/WgSyZtt2+xC4sse+zH7CLSzIPZAqrbcyYsTrjygzRiDeBbumO 9CvTb0vfmC43SgFRtySpN0lYYu41C0XmkHmPeZ9ZBubbzYLxSuNtxo1GcbpxnvFTY9wo22hkGw2P GV40hNrF6YZ5hsUG0WjgGtEUMgSKG4x6hz6oF8cG9TX66XrxSj0L6QMlDSF9jq+hRjddN08n3qZj IZ03r+FTTVwjhDSY8Kk6rhbiagYiczIGzIQQVWjlzSzV0SA+wvjfIuXA2FX9s1r8/ikDyvjMKRF1 85wIuzTiaeH30IzZEcWlEQjPntPaz9gVbf1MmDArksI/yJXiF69bB/baKRF7S2tUvP12e23blEgv D4dCUjjOw4BZ2vwnL+tZtmy5f5kfbygnL0PN8h78lcDwjuxZzlOWLwPM4j/OtYxkWc+8HiyLkZOX LeO19vh5jAtv4f/uxf67O/B/9rLOk/7irrwVILZ+xJ+SL8Cfm2EDbIGH4XF4Dl6GL5gG2uFieAze gY/gc/geF6OSpbJMlvfz/QU7dpH8dNCLO0DBv1UZ/y7+Yex38Q9xzRtGaNZjzCLzHtbEk+KDR+ti 62MDsRcUWjBJZU3CLtQeYIPx74QaHo9X8LhwCQ9LJQ4ob41tjN12RHeWwFLogbNhJZwD58IqOB9W w0WwBi6BS+EytMVqDF8Oa2EdXAFXwlVwNVwD6+Fa+BVcB7+G6+EGuBFuQjveArfCbYk0Hr8Vf66T UnnKHXA3/A7uQ/4W7oS74B64F+O/R+vfBw+gjjQUvx81t8NvUHs3ankurtuIPxHohyhsgs3oM4oP xQZgBzwIDyG3oje3wSPwKGxHP+5Azz4h6bhmKH78nHR/EnbCU/A0PAPPwh9wZuyC52E3vAAv/lsp Tw1reGwP/BFewrm2F/4Er8Cr8Bq8Dm/CW7AP3sZZ98kP0v+MOf6Ced5I5Pob5noXPsScg5iT8lGe v0qpH0g17MWy+2A/U8FXTIDvIY4h7r3rJA/dIPmRe497507JztwfGzHOPXTPsG/uRxvfj/7kMR6+ MeGNBzBvP1pwyH7HttoLCe+QvR/BPNwWPGV3whbPJDzB69k+XHaXlBaVyj0xXOthi9II/zTCOn8d YcN34T3JMmQ9Sj1sPZ5jP+bhVuZ1HGnbt7EsWZ+X5fqRZXjaXzD+Ie4On6ClOT+WPPExvD8cfj+R Pgh/h0/hK+l+AD7D/eQL+BLj/0DNAYz9UHu05mv8+Qa+he/Qgwfh0IjYoaNSDkEMfYynBiYwEWKH Q4e1ksiYnClwT1MxNdMwHdMzg/SdKuVRKdrhFPMPUnTHSFNLmiSWzFJwv7QwK8tgNtw37SyLOVg2 c41ISx9OcWKKm+UwTyItTSqZPlzWgTksI/LmsSJ2Ft79LMCCGC5mZaycVbIq1BRivATjozGtSGIt /9+52DLxddwdRVBCFTTBNJj1COjZLbiFjma7NtfVqQqV2zEqgJPtAhWa6pZQskzQ22w17nLFWnGG eVKNcq0wC2oOvfnG03jbnVQV3M2Cbwy+Mmg69LS5Kji4d7C4iJmzzZKkGASlUqFwuwJCuc9bUVpa Ui2Ul3ndLoMg6coqKqvF0pIsQUwZ0lQLPM7E1w9OF+sP5Qgrs8e0FMuZ32NxJKtUoiNL7yl1Gqc0 uStyM+QylUKUq5S+ilp3+KzJrhc0Vl+m3WfVIO2ZyENPyA3ffS43fH+irO77R4QPqlqrcxQr9VpB rlbdkpuVmlOcOW6K3qiXG2yWjEylymzQ5Dd2HLohw2PRaCyejEwPr8tzaAyeQqfHP5bp5G602+X8 gBlujWaCf7vwDBjAyjogG7zxDzZrjWyql7/oJbfI8C3uofIiK1cV8TfBkPoEsNZkNB3y7x2s4TeG 1tpZXGR75N+toLiozZNiIPOWJVVUoOUUqQlLchunpmQJ3OTcojKdqNCk1czpqbv4leuaW2994+KK znCdTaMQZRqD2hiY1NXQtDJcEDzx3KaGhZOCeo1OJduZ7k5PsuRkp8387Zd33MXggdlJdq8tKdOb mZWfoXP73TU9d3cvvee08uxcp8rq598bXAcgrsUZVgARslJ/hm9AuCZkVCc7k52ghgyrHseT8TCe IXC8D+pZk9erSB9IDD0dX2FDav0MnzRqH3+hDSlmSaMe9NcM+nG6+Qf9LBhMqqoKBk2DJWi+B3+O KsmUgjvb5S03l1WUZqPJJFNmm48K4vA0RvWhFdmFhdnCGrVBI5ejAWMl7BK1kYeN6thK9hIPL8Kp qPUVyLoLfJp0XxZOSG1sp9aCU9Rr0cTWa60+yWLx72Sr5SkQhBfJYlshGN+3yciaPAPEnAS1CWoS BORmpFvH/0poydEiQlqw5M/Mkcaas40tgBDo4h+EUnjcqHPoBJ2o0yXZZyaF5WG0QU0NDn/eyXP9 kjFYcO9giWRUOiraQup/u64hg/K5iVvBcDCxwFNRNxSUrdZnlXh9pXZ9LFOXVeLzlmbp9VmlXl9J lo7t19tLfd6SLH2OxqRRKPAmaA99NRSWPT0UinnY60Nh/v+68U8EG1o1F9qGrArCtZvtBvdM9QBb +FCyVRqWlX9uE5KPWFc4t3Bd2aL/LB+Oj9GgFEOblrS7DY9KsGVP7z05a0xxjk6lEESlXqO2ZuXa bHk2g95e5vWWOPSsu3XdgjK1waQ3WFwZrqBNqzfojZ7qYnGlhuaSJjFDFGfimhoLr9FYQlp9UZEl GNQErNaMAaFzc06xTqfBwEOQUzEjXae1bmOF6K1A/MBmk1uYWjwQPxBy8pDFxO96uluCRcUBhSN3 hiM87MKaJEsVdz36sKSkhGaEudTEb+aqccHSUnMpWmfLz9vKEXPFzQwiD/mYe8Ss4c+OLMHCShk+ MCT7Ks7U2os8OUWZOiF2mSzJUeRyFTmSxNh1gjYriHq7tqLwvkBtkVPHrDLm0jvyRnn6bb70wxNJ Zv9+v96sEeVak1aW+f07w/oLSiuM7qr8g4dElj86x2jAUvw703yliuiHTMiD3sTulqPYJqwHM9iF x0NqMHuk2eIZYP5NCoXOPbQHuVGxOZQ6QycNn68PXCp8H9s7mNjDflrBocl3pIVwd5LJywJczaei TKy78NHe0/S0onTFuaw40LL8rFkFscGihqa8JStqwhWZ4sWn37tsbGzB8NjXBoNKS/W81fPrWvO1 sUmucWGcgTXxD3Hb88Ak2Da0msYLv96SU5JTorPxbziALsAnQyVoWOGD5kr8SRs7NIaxA6wwpBtv k+e1pEmjTOOfaA4tJtwqcC8f9JtpQzcNcqNIu/ug9GgM/EzVHl6vsiPWa9nw+j360akQ10698IEF E5a1jsnQynBDN5Q2L55UNLU8s6hpfvf8pqL6ntvaAic1V6co5Xx9a7VFDSdV+kP+1OD0zu7OaUXs lwtvXFSW5nBlFAcc+Rna7NxsS361t6Cm2F80Lrx8xtx1cwMGa1aKweLOsOdm6DKzbameMruf0pfh jNPgjKuWFUAO7mPNW6wWn86rHxBmhDQhi9eJSq0XV/0dW8Drsefjk80UUvMNuSupW94NtB8PmpOq WHrQuncQLZFUlWF6I4NCxUWetDQ6mvl82Uq+5rzeikomncdkFqVbzJb5taq0MZXFozK1svGxhePk enu5v7A4Wall0xTmnOrSvDF5GWbcg4WrmWeeOzdVLiqN+u0DBlxTirR8l3iDKVkjYzKlzqy7KzYV T51r8HRwAN/Zs8APoyDc7y3dJpwGWnAIt2zJ0KamamFA2BNKKdBmrPYx31t7ivcVC4uLWXGx0sP/ pmPqLB1gqn7lIqgZrMFJEpx75uDcKj5h8OSZVEVrCb0s+8FjXJklMmllpHKnJx9eJOIBd80JXUsb YtGsvLwsNqPr6s6K1NyqnGDzGFfs4SRvZVHf+mCZy1yS6q8bc/Om4Oi8NDZh7MmNJdmGHK94jTcn q3Zho6++Kl+n8tWcwM61B5ymg6nuYGy+szQnOfZ5kqsY18/s+Mfi5bIxUA7jolbwbRNeBh2ksfLN Tjuzu6S/ri0UBljSg8HimmKhuGCA/aJfeQqesvfOHZRuiaOih4/t8DFZdrzDnni52l7aOKe859E1 jU2X7Vjub5k4KlMnV+lVupzRM6uq28e7cid1VZc1jfLplHgEvDOvyJ5pNdZd+vwll750xSSDJSuz uMTutWpsTlvx7POnzr6oxZduT1el5fHnEfdiIXqxAMZJp7vVD6nxbJcM6owBZnjQ5GXS8YuZo/pO nJTmfsWwv87EgewePrkd58CVevSBq5B3/NAT3EHCaAzKZHiLXcDqVQa1TKY2qGLb2EWoknfY8NxO blGneTNtORbNfgzYMjxp6lhMbfFIvcc1lYZrKghl/fzk1Esnp1s248GpSzfATg+pc3KOWkQjTkb/ 8qEmTZdV6sGDiy52Fh5qpBDS6+GHmsukEG7KDg0NQcOuj3UPhcX3h0+Va9g5Q+FE31kf9j0Vkvl5 5pbNGlOX1EvGd0vPD/rD+nQOalpv5007DjcofqjWq+VyvMXjYMV618vvFbzwAAAoBK9V+h+g+N/Z fmwtV/rOJbaGp6cuPAkt6Zefwj1KR6UfPwWx/Y6GM2dlVgacOqUMd0mtSp1kcVrSXaka6ahXYtex 6e3nnhhUaA16fYrT4glkqLVajc5RPEq4b6iLiVknfIm9sfLeJHN/KfVdKQOsql+2iHqzW7KBIjGl hl2Cd+HL5KRDsaw8coBDx+rRArKuygBOlu1DjRzcqbHmJqwsfxLn9yho3FyQWuizDghtIbVLH9QU FrrKcMftDpnBVd5ZmKYV7d5Oe7cpMVX4sYamShKelfD5Y+UHp6qqka5xs8Sme6zjTXJpsnS8SUuV P6m1FXm8RZkaIfaybFSNszDTKMZeFVDr9QZtmoB3Y2Eo4NC9JntL7/CP9t3vKzjs2uKDz5mNMpVO JVYcfHFYG80rMLmqcg/tFKryR7uNBXlDq2E8WnUMBPqzk/i3pDJlRYiQHjIrurT5FmenpVtcRAuh 6oh1oHDjI8Mner0+dwo39A9Hk5ZmKQ2Ih30hG+/3/iGvKOmN7FAWEwSmtua7XIXp6oB3T5IjI039 nGeCU2ACY+r0fJfbn64O5xV489nTDVePz2ponJgVE0YORp1sT4mdNP2aRnfzzOYctmPo9Qufm+H4 R7KLZWMhGXzgewxShHtwWmcJ94IG0llV1LjQzecNzWJpbz08j4c/gpBOUiP2VdnFE/t2XXTBU2vq JyHPe/LSxtjntuquSVMX1ths1Z2TJi8KZQrZa16+ZurYi/64/oI9VzdVX/T8jc29c4oq551XH/7l nGDlvF7sG1pcfAhnlx2fgcX9Xjw/9uL5ETsXBTNul/pNcrnOw5naqeOziu+bg8MnxWMe+9IsWaK8 zOvzeoeeag+NOfOuZadK+06pXRfwsoLcqTm13Y2+2GfFgeT89FN7SsfmJgtvzrtyXlFs+0irKpTa sumnnlA5zSiXx7ZkBGog0ef3sc+leNyv3Qoa4febi01+cxn/wqx3jJlvopl+Mz6iN40ZY6nCzm/h 04YWhdR/fEgPlkjnuldGbFQ+X0D84Rl26IFtsaSlsRFP6vd1ztGF/jKnQWwy2D1Bz+Sh4eFze1bX ld2jM8qnlaXne1ymsEYVe9zsHVux4ozSmvzUZKVGLso0Jt07uVXepNjq4eE+6s1xNS6eUjF7YrlJ k1U4zvdapl3YlVnkTon9PcVTxtfHhPhHYj7OpCkwYyvUCudt8ZZ5ywx2/lVfMBRtY/xzNA0+uJOr 8MdaPcC0W+wT5P6FVv7gownGz6HHPN0ec+f8sfNofvXiG+eWz2+uSuZvlCqdRhec2F7tGZ1vya2d 1TprfO6YRWubAyc0lJiUchH3WrU2f1xzUXZpTlLehHBbuDaPjZm26sSgKd2eZEx1pDlyrZpMl83k KMh0Ffuyc0snLqidvLw535CabsIX0vSM7BSVJcNiyvSluYq8Ll/JRP6fqTacC+04F5zg6AcZPjg3 pRllpgFWucnWqZEmbAkL7jy0m49PMdK7w4tLeqi3m01x/lDyFdv1cZWee0SvEgWVTi0THx9VePDJ YS+No0/1+CdyPmpflok7lgvKo2DBvbnqwZDL4tRYUgeE80IarcXelSZPPBaTcMeSDr+Jk6907B16 vcTjbsWIXbcEj8NKYZfc6KouHdfgNcljT2nlqZXFRRV2rexb4WsZvrUXFJYkq7R+U4pGFLWpSeL1 7rwUuag2GQ9+IupNyVqZMjXPjX3Uoo2elM7twa1gEc6I6nUZ/FvCOVY84PbiKd3RZVUkdSmG+hg8 VPXGoOkN6aPTYXsdu4OJRZ2pj+1M1qeMrQxUOvTyZ8TH8HBe6q8YnapLYmtiNwwfKxYJ43NysY8q oy62Ao8DRpUoT8E+CjAR3+lWiK/yNc3yEp9oqi24pOdsBp8PRg8I9SGTWbSwLyzMMqArYwfLWBn/ +oNap2dTy8oC4/MHmDVk2+di4irXOpcQcjW72l2i0eVwCTqZyyWzD8T3hQw6fDWzW02syf5dYPI4 fHsLqTEybn9I1yQDa3DoYzg/fXg0d+68ufydJejnZ/szcdvYWcVPi+g4W8j439wb6XMK/vj2esvL Ex9r8wldWp54ViQ0Mulpp6R1m1ZaUlEprkjx5xfmmSvXnTDxrBOLxq3cfNb/Y+/L45u47n3PjNYZ 7Za1WpbGsi1vsiTvC8bIrMbY4LCHALGwZSxjW0KSsQGz5N6GNv2QlEu3NG0TXl+al7S5vWwlNKGJ Wng4TUnybpr20myXpGlp+gm9LjdNeKljv985M5JlYxO63Pv+6fzQ0ZmZc87v9/v+fud3lhmsDbqC Jt+CztYKrUKnkLK2pVvD80Jf7nB/1DF/fbVl2YKqOz0OtVYm06qXzVuYv7yveWVsRV518YLiTJvT pra6TI687Fy7vmjdoc2vZeRV5NT6qytxrN4/+Z4YSSKoGM1HXxHsyuZUP0N3wLSxhP6Mn0EGtroq RyzxJZfSvrPUCr/K1ZK1VNtaR9bSdfj1ML+kLbmWXoA3Sk11wjCEjXHmL21jaiFOFxhunkHzzwOS g69MZzSSwRdVbvvCXaUrly3JU1iK7Y4iC6vM9uXn+7KVzsWLmws7P7+hcOJPuuJFFRZfRbW9KlBV trg0k3p/6NlDzTpXfVFAoWHFYlajkOSyWoVUqtCyE3qnz6FedejUYF3v6jK1s7pw4vLiZeXt3dB/ myHq54h+Aeu1b6b2+guepeNkr9+BHChP0DoPvwCnbxE/TTWjMvBGhYJqK3MT9d34LTo/05bcMixJ bfpfKBc2/f+6lqbt/idHDCk/YEinrQZzRBKZub5lg2f7I301i4Yf3VbYtqjKyEhEmVqdq7K5fFuP taKtonJFrUvFwDT9uDXXrDHlWLX+fafjh84fbFSb7UaNOddS7wXX++rR5oGWfIfLwWYVIx4ryS8k O9F+NHIaDYVWic7Sm08316xSQ2i+26+omF+xCmgo07XpLB33s0OtH63ecL1lpLn/GdC0C91NLT0V bauA8dJxSj2/2YZfQSxtW3SWsp2QLyXzswUV18phEQzfnwjPTMgASnYltRfBIS/owKkgWibHUYOB pPzoY0yiYEiunWEgck3vtgCWeHboDNMANlLjFlNlz0Pbu47e7fkx3qLN1J/3zMvkzBkyKSsXK3Sc p87eOtDs7NJn4t3bTn1+XX5ubYHBlMdI6Eyt1ulbXDYD7XTb+HvvXaJ1is5YmtxNO9f4vJs+s34l ayrMrvFO7NyyXMbIZIY8m9unUytlrlXD3dT3vTXZhSa2snSJ22gsqMstaczTmLCdrA5rup1y0i16 7w+Ha6U4UrTACHAGRoASVElJeD8/pdfnuPH/ISmphKE96mdzRG69m85ynxfjYGtSUW1IrBXTre3i DjF9THxcTIvFNi8EAfxAAn/7OSjjfdfVYv4QqbVqWidSM2Yl1caYoQDzf/22pBuXvAoB9poQa7fs 3Lql5NrWLXia+CaeMeJwz/z38iaBCVaPc5ofzguqycNLmehMUd4nb2fN29K0sGu5T8PAUosWy1X1 m+ILh04Nz2vc9URv5JFu3weiu+72LfNaaOpjj7tuS5NTb9LLMnIsRodRozabdA17nt439Ny9SxcO HtvK9e7Om7/GC3bZAavx+yUrIVznoCW8XZ5DRvo5ZEMGiOIsclB7v++3aJdLWvGu8C8gugprGFgZ 33xv2u56UhE9dnfoBtXYq/ckY2nyW9+4dt28+evWNjiTzyFEeyB4QtzUsJSvtb52eeu8Ouj7+0HS PTDWGNAC4cmERmWgIHQpWEqFKIUYpjsd3/ez2qW8OJSXyENG1i1Zp5KXZ5XwZqlSwkwFcV4GKQNe 3I6+K+zJL9VD5Dllt5ez+H90tTcW4LGvHGmFSKvF70OvaMk7OxV52/xqf1NL49LS2uWlrZZWXip+ xStMCADgOrLNeK2OwPxXNTZdXxJ0ZLpbXEiGNWE6yA+RBimjtOEtgmyFLrcqv3RzNeCUh3HSOavz PJurkrCx1iIHV2xiW77YXrNxSbmusG3FioI796zgUnjSutKWquyliz75l7mviEaSue3t7aaShvyS xgJ9w/bPtyHeBqJXwAbl6B7BBsV6DLodKcACyK49Ozl2CgY0LYZJKcDmV/hLW4otectTGGXwCAnP RZJA/zk1PwXZ6UAaRK8obWV5+WU2pT6vzuXbdjNkX1tz1742Zwoo6pOmW8ECcASg/zbDDEwMaODd h53J/ptJD5I9iEG8BzH1aNrqZzQtuWbhWY8tfb5EnE7o1bdbI21yNec+hrhhz9m9Q8fjtfP3PLV3 +HisduITQ/maBbVrq7OMZWsb69ZWW6n3ouc+17Jw/9ld0R9+tqVp/9l7FoZXe4pWhZfBd2nRyjCe Z058WYxAy/R5Zk41m5xn3nureeZy7aq/ep75aW2kzzNncYG55pkV245uLWia38ClfMFS5LDDfLNg xco13m14nvmxrmhRuaUMzzM7KsuWuA3UtaHnDjVrHB7HxOZkZBK/lXSMUOH8osy2QyeH6kKryzR4 nvnaouXld3Tz/YZ+hqzBIkK/cWkgYvqVyKphHayXFalELB7gFPipP7XGz/pLWlwaA7fcQPw+GVPu xiPnBaHHsJ9ePg0bXvs58JHSz8CoxsozLfYMQ3EpdJQZHSS3sbbWprJzZoVETItW5HmsrEwu0+U1 uD959eYuEi5vcmlEMoZVGopB++WT79HXQfvl6L2pp4qe1FPFxX4nUoo9lOfdGhhO2Ku6Gj8OBDVc DS0ijwI1DVQDfuacRR4HvosfBbYYtXg9iIyUVmy8nnIK/FYC/zxwC9mJuXtLifbaFvg37WGjn/sv 5vYXPIOkr9f1PLCm/K5mn1EplisZRYl/XbWzqiAzf37bHW3z88u3fnZt8Sq/Wy8Xi0QypZxx1a3w Ocs5ratx1R2rGl2UvTW+skBjMhtK3dm5BpnFblVbC632Es7mdPs3LfDvaC1WZhg0GoPDlOXMlBnM BrU1N9NRzNly3P47eStJvgHz+6PoK8+hWtqDgmgzvRg1oQi96HRekX7vvXieb9BYNP1NwSa9RqNv Corb7kFte/H/DLH5bYNLazf3Li246llxdbUHaEPFu67elg3Xl7bdq8GLHkvzfTDpPwHrGzzbLycT /tR+mQ67LHn+cgH6tNeL3/zhZ/5v4RCh5XcTpXNP7OmZiBpuaQGj6dPWEZJv0FK5xumptrUOLMsN ZRgkCg3Toy+AiX59kdFiY0RyBTZDa7oZbm3EqnV9NZlOjcVcFfp6d+fRDm9ybVHakMlZdGRtscfm NKjUMAeDif9q6ifJif/iUqPBVc2V1lori2ax3/xbW39RqDlfIs5c5PIPrPakrza2LBdWG3h0N02+ Tz8gPoHq0Rf5fvqUTqeaV4RyS/H8yqQqTcbmUryIy23OViUvqLB9Tc1leFHnlwndA8Lzi2Rwq/ik /EK5jp/s/wCV/iWN8OP9zeu6WxmQfkCRkeutsa2AddoOfp3Wq8jm5wHpizoMvEIq2eP26mfAPgpB XiKBID86E67JSYyWeLFkJe2iHsev2dP59FNIQFHsAxSb0IKT3iYtQHe6xG4vgXh/9xlRVUlTs7YE az6vqjkTND2V38a04s3UBS9ew6/h8Ksi8HsAiyo3pj1tyfm0NW4SC9Gvi3OS852JcJqGbEbeHHCI EnnO8cdTk8JXphS1uUsNc6LCayuRi9+GYHEXaKvGjlKyciOOFHrVQpUNCFWVrEUrm5uaN6qx4qeb QfMMbOP8ts04Hsj4eLDgxQvXysvx0uGCtyJt4U+QmLL9DBRuDghJFHI+pXfLFfpcT00WXsRP3JMG EizTtU7P7DBRB6b8R62QGDJIxyWbAjLwH0+mWikglQagLceoUanngvCj5As5H93UI3kfkz5LfOw0 72OSsqSPSb8DqPei4ElH4yoMt7K3vFfdu2VLr1qUtRKbYWEZwl/5WWsAZb+iq625tbG5rHkVysJW qC3JbxZj+A0EfgH8BfgpWQVZmpMgTEzgJbvVt+d7aajn3Ib3Uo+mIa/QO+dwzyncaX+xc8q309An lYk16Q/SvdeXMaf3TkE/t/OnVce4G2H9c0p0EbnROmEmrM1xnKU/c8ZvyOGkObln6S1+pR9xOYXL cxTW5QphMoYfTljNb0I4S3s+kfXUjELCrEGWei9uam5v0ptq9MIb1KcokUQ88YFEV7CoumqRSyeZ +EAqoxS2svyi8myl+KdS6fMilc3ryvdaWdEjErXOqB7/pc6gFEuUBq2oIJNTS0FNsYTRKT/ZabHQ X1DqGImY1RD9Jr4sOg365aEeXr8zFMOokRVmaQvP+POsHGs1n6Vjfo1fbXUst7D65ewK8Sq0Irny 5Z/CpOuJ3xvHUy7lrMVB5RwRv8Feo3e5CihXZdqjEDxMGzNl9D/2Me1thT4zLRtSGSQTL6rMdd6S cpta9oooIdW7a0rqsuQTFyxGmdaso0qkFrWoMjffIBcpLaZPvksHrDq53JhP3uyrps/RQYkdlcIY 13hSZqg/S33vNMrNRZVnqX/26zUcl2U47PWyWV8t3FnzZTYuipHQTB5t6uq8sE57MfmUguI3VuZ4 PDA1t0h/OkAHXSWluTl3zvesrM8pXLVrVRVrLuYK55c62AyjdtEOf/P2JsezVc4yh6rQyZVZ6Ctq lVLjchaaYPwvW1pqyDI4DGyGQecrNlnsRkvV6trDcp0lI9tus4F2m0C7Z6RK5EI1qPIk6/A9Qx3H i1PqB34d0jtYtft7zp2WfnWs4rgkjns9eWibtghL26+Xztiu580iE5baBn4VRT+T4988z17pcxvz fPi9fdbosmXnG+XF6yqaNtVZfsqY8m22ijx7lT0r36wQ/bE5ttqtMOaaq9RasVwhE2mlrFQkgmTi am6Ob/WOpfbqEgtX8tW8PEtxJfhjLf1D2iqxIR+qOmlG+WepM341a3j4Zfw21aOanaJvu89OJp7K MDS7C5+QxfF7VCXT3qMi74iljJE26ZbyFiFK0VaRRO7cWHf/0dL2yCJ9cUG+UcE/dpWruLLs2saG htxql5JhxJSoKsOiUxhsDz7QvqvNBeFCo9CZMtQ2s0ZqzWhrb19hylGZOOxp9WCLz4On5SMPajrh gVB7/HSWTpflOks96TehLLWaEd9/3JVw0S6XueiL3E7ma+b41OtTxNmSUwHe2ab2K42GaWpN7VbS n8/Kmnhck1tbVNRUkcOqGDbLVb209Ngjxe2xlpYdi7lzoorKrEKrmhZ95LBnu+0aRsmacvOy1aDr P32tebC9pHBZoM5UOz/DUWwFLVbR/xs6lILsUHLnYP3zH/hP/FLHn2Id/2HRRiS4e7x104sVKa+p Sd98tDOG/OzsfBMDTgHfBkblafKXehc0ldK/kinwy14KGZ0pZ2WwvmHlT1cVFVZUFpH3dDaBFDbw a/5tKACS1fYT1pR3VraUDfp7ts1lZJP+OMVhyuWElsU6sNJS5D9RnYv/nIqnQYd7jQ0tpf7Fn8mq TzTt5E7U7WyoLiqPFMVMMcKXX2Dzr5R4r/F7hWliuGbsRs08x3Dwe1PG5B6fWMcYXDYboFNQaCl3 JKHKL7KWO5LK5Hp9Tl+gqnm92VLmLbc03FFmmNKL8tZW5zknnpjrnDao4aj1ecqLzU6TIm/+6jpe f/oR0N+NSk/kCYorqBN+NbKpjxfszDNxkaTKEK2vpfbrbqHslHL43fhH8Pt5NpeJKSyxVtkZI4QD ook319dZ3bCm3DRNgxqQ+PGbJCay0qgOetQ5kFUPfcp5DmVS+I922yEiMKzlEc3O3P/Jx7S5XvOR Tdseg4HAvXb3yjVDK/OKVu9ds2rXyoLnFTZPrsNr1yiyPLnzmkR/XBpb7SlsjSxfGr3DXdgabs2d 57aYShpcrnnFplbcxzdRf6SfAYlwvK056fCxGEADibeZyMD6vA6xBIfcrIh2MD3kmmYPudPcOIXh zSF3wd3zLcUuGOAEv5DrHSZfrrdrvv+uWisJuVnVTnsVII1D7vLYHW5GZ9WN4cWlWM5K6asy6AaA rMfnvaNvGY64zqKv5OXzERf3tbfICOk65bQiWLgf9yut7I8Kdjo1BnvEEEOC81PeTy5kpCkwc3+J 9wP+LWPqLVrCymSsSqdSma12XbpHGwvynRnq7EyZiBI/Z82Bb4lYnuEwTvxwuiPMgwqMWCbP4EDK BvAFCUi5AC35Aaqjjn6fc3NupeUs9Z3TSFn8QBn5ExBGS3NZ9RFLnSR/J3tEZzwiIQMEeU8HjxOz vKGTtldQDWN58lQ8bdywi2lJ4ZKOOmdjmUMJ0sqljL24JjfXXdCwZF5hnv/OaketOxsglsol0qzC imxXTvH85vlFor3eZT6LQq1RZtv1ZrVEo1ObbSarwVTUVO1eWGqSK1QKm0NvUomVWqUt02w1GAub QFcbfY66KHkElSP3KZTrKMAW0cJK1REu+LZF8W19uOQ7Mt7zXyQvR1745MKbaUNflRCBpy2WjWQ5 xI+B5L/hXZSrzE6XfnuHX61Sqxfgjorjz041nEatORaHRCKDsJmd7VQxMkmgczynqNgeB0cSiyGJ 24uLcq7k5yklGgtIbKEv0oclmagA1Z3MgPkxdfKMX5/DyWF+TH0P5scyLidHZY2oYijCRxZhepw+ O6ZAqkwp+Ck/Fxa5XNOnwnRRNjiQWHpMrMqucpdU2VWiY7AKMBXY7QUmVtQnFm8XscZ8SSYtY7Rm 44RbqYU5L8z9qVeNZpj30yKpkpn4MsdROxilFP8SgIn6T/p+kDoH+fEoc/2UXM6azlInzvhzjBxj hMX6U34la7RFDIwmwkRFu9CC2V48Iu4kTGlrRFOv9tSkXu2h7pf6G5xFRlrS8jNWpC/JdxaYldKd dCfNGAudzqJMSkrrdCoxCPskTZuytVKaydBNXKCoRayGEUs0WUbyl/1FCfL0UIGUKBO/t/vcaSkj UjajBW+9KAyMaaMvdX/yUd9ETHxJeLI38V3cjthF7ZU8PtXOv5J2uuZoZ++89vb6hvb2uol7JaXL aquXwGfiNLTzm8k/0EjSAwGwCDlgrkCfRRwy0A+cUUjys9q0SwGuN19KBuekWaceU874f6FvU6yl xMEVW1jKqnRUFRZWOlQSVU51UVENp1JxNUVF1Tkq6vHkLrzosCpTJZWp9Ko/rSqqdWo0ztqi4rpc jSa3DmP18uR71GXxAJENz2PobxHZvnVGoS0G6UIIRNNemDlypKTTzZTuWdZUxOUUmxgrY6sqKanI ZpT2igJXhUOlclS4CirsSqqbUeEFpYqhX1XrQTSlXj1emV/OqdVceb6rEn/jeLtv8j+px6hCQJ85 yYha0YIX+VduU4A/1rR2rb9p3Rr/kS3+BRu3+snPGD786USVzUIv3JrowVvQ6zeT6JHbIbFtGl3+ W5HEPyedk+bOQv/wKXQFk0w5g0yEtgr0xSmSM/J4Gv14dmJshL7GE+tMo223pNPppJDeRNfnIuWX VMXTSS1Lo5/9/yRN4W1Q7xRp3dpT6aRzzUHPY8pYxpPeOkWZWQKdTNGzM8lQZXgXaGwmGZ+cnUy2 aXR4DvqTucv8I/OPLHkCbSf0JWumtdd6KisbKJL1G9sCoIcIXf/vp2xjdv3f6e/0N6DPTaOfT6Ox v9PfKZ3IUwxEZ0C6njqIpOgzKAPVIw2yoYzJdyDdOvk+slH05K8h1U5ehdQ++Rak+0j6EC5DJSZ/ CukopPWijZN/QBtQ/eS9aAPUugypdvI1SO2T/w7pPpIemfwdpA8Blw3UKE6hlh1thVo30FZo7T1I Ryd/RdHQ/jVIEyQ/Ovk6pYG6H0L60OQNSBMkPzr5R0oLvD6AdB9cscPd65AmSH4UWhgk7QySdgZJ O7vIlV3kyi5yZR/kP4Z0FNq5j3C5j3C5j7RzH+FyGLj8DFIt1DoMGr0H6b7Jq/g3sUiaQBmQjiKG OgwateJfyoIyR6CFdyEdnXybeghaeB9S7eSvIbVDrYegBXzlocnfUgm4+w6kgDOkdpAwAXdxegRk SwBiLKQJBJpj3KgEcAlTo1DrbUi1k7+BFEs1CrV+B+kRmNOOklqjpNYo1II81PpH0Uaw75uQ1qNc 0Ubg/hKkicmnIR2dfJr8Za5S2omQ8OvhXSQVEW9RkzOcp5FcVIySv+hWLxILeTEyi6xCXgL5RiEv hfx6IS9DH4sGhLwcFYveFfIM4sQ9Qp6lj6V4KdB68eeEvBIVi98S8ir6QYlcyKtRn+xY6lfYyuVK IU8hmbxRyNNIzPwPIS9C2cwDQl6MlMzXhLwE8t8V8lLIPyXkZWgfc17Iy5GBmRDyDNKyfiHPUu0p XgpUwrYLeSUysHuFvIpqZY8IeTWqVryBfwFPzAg483keZz7P48zneZz5PI8zn+dx5vM8znyex5nP 8zjzeR5nPs/jzOd5nPk8jzOf53Hm8zzOT8DSrRz5gKoh14ZCqBNFURjF4NON4nBtEeSiKELSAFwJ QW4AeeBOE+oD4tBquLYd9cC9GDkLwneQ/HJfECTCv+wXgHIhtA2uhaBEiJQLwKcf2uoiZQfgLAbX Bsg9vn4IJODgE4By+LcAd8PZEOTiwAuXGYQW43A9CGdY5kGo3QX3B0Aa3EpYaDUOJfoFnrgEBzqG CU/MJUZ0WU507YYrWMdBuB4kNaLkSh+ROi7o0Ql33KTlfnKlj7QYAIz460ku/dBOH0EsIkg5AFf6 CVe+TaxnPE0CzDFCdOHxTqLNy445hQEBDvTnEcdS9UPZAPCPkzOscTxlDx4zngtHZB8Q9AoTbLeR klMSp2uEURsm9Xitd8C5h/hDujULSGv9pIXdBIdBwfLpeGOL8foHifxYf94uUeIN+JvniG3NQRuR lDa8jNuFMjE42yO0HgcteAvtSlkpQHwkAFf7p+mV9OZOkCRA+HcK/D2zeH39TXpyaCHc64PW6lM9 pgqtFzwoJPhaFbSG70yvW5qqO3tPCAo+zWsYEHTaTu7yMgYFFLHcXcSbsQ47iB2TdWa/2/1n9eop D+LttQ7OQkQGzH8N6QHxabb1ChKE0zToFPpinGgZJP7dClc6USGxexGU6SLtLyNS8XXjQBFA1ws0 RMhD+v10yT2k9X4oEwd/w/JvJxpEoIXdcBVbtZvognvT9FaT13FE4S2wI9XenURm3pN3Ew+MEQnj pK/FSGzga3NEB9xPg8TLQoQHj9A2UjeJ3hLArxWiJF83mnaH7+NdBJOpfjtEeHWSfj0bX/4cl+0E LxokGHal+kEXuY8jDa9B0vcjRNMBwfv5toIkxb15pt74Ph81CqFWEfHOftArmOrHN0s1cFPLt4/R VOvJyM0JsZf3ns5pMfBm3af8dbpc89IQwJrwuvAjQdLro6lRpYvE1QESXwNzasrjHJiGaVDw/pl9 AKOKPW+Q1OwiMSpEfvs22Q4u2Ufi3K0s9LfqF1N9wkukwX2AH508xFYRNPwEV+7zVXNtoc5oOBbu jnOLwtFIOBqIh8IDHq6pr49bHdreE49xq4OxYHRXsMuzKNAX2hYNcaEYF+D6w13B6AAXCwzEOLgf 6ua6A/2hvt3cUCjew8UGt8X7glw0PDjQFRrYHuPCUDQe7IeaA11cZzg6EIzGPNzyONcdDMQHo8EY Fw0G+rhQHHh0xtxcrD8AEnQGIpDHVfoH++KhCDQ5MNgfjELJWDBOGohxkWgY5MZiQ+t9feEhrgcE 50L9kUBnnAsNcHGsB0gGVbi+0ADwCndz20LbScM8o3hwOA6VQzuCHk5QsyDG9QcGdnOdg6A8L3e8 B/gHh7hoAHSJhkBtqBjo5wYjmA20uB2uxEJ7oHg8DArtwioFuKFAtJ/nhWHu7AlEQbBg1JOCvj7J k1sY7uuqx4apWg8AgUpclcfnE+6W4rtpRggC0sAwAJy2h7BEQRAxGugK9geiO7gwvpN22j27qQlA oNe6gVAc6q+JB+K8tl5oIEwYdIIV49FQMOZpHewsDMSKuK4gtywahrvxeKTe6x0aGvL0Jxv3dIb7 vfHdkfD2aCDSs9vbGe8OD8RjQlGc7w6AAjtwuTvDgwDybm4wFgQhQCV8mwuATYPR/lAcC7RtNxFv ybrWJrgbJSdg8a5B3rZDPaHOnrS68B0a6Owb7MJYhLmuUCzSBwww+pFoCAp0QqngQNzDJXmHB8A1 CkNFXLB/G6401dRAsvCsEpHi2LkB/hjA08l7YIo7wVVoax4RoDAEXKATYOijuKt0hYcG+sKBdKYg c4CXFIBPWSA8GI8MxgH2XaHOIC7TE+yLzFDodmxBLOHtCnYHoDt5ArHIsLBWRJNt6Gk020FBCVht wIpfNjkJKS2ssBBVCN/DKPU72HMcGaKNSiUFZahjt1tepcLlafPtltdoSPkjt1teq8XlRfLbLa/T kfIHb7e8Xg/lM8ivf8thvYfL41W2WfiVbxWsGqwQ4QvQYlSJNsBKYCtaT9Gok9KgAUqL9lJ2dIja gv6JCqNHqEH0JLULPUXtQz+m7kMvUofRa9QR9GvqITRGJdA4NUrJRC1UpmgjlUNsMo0v5f4z+I4A 388C36PA9xjw/R7wfQ74vgB8fw583wG+14DvDSpBSfDeBfDNBr74T5qWT+dLb03ji//OqQ34FgPf WuC7CvhuAb47gO8Q8D0EfI8C34eB7z8D33PA92Xg+zrwvQp8P6SO4F0lSg18bcC3EPjWAN+lwLdt Ol/Rd9P4aoCvHfiWAt8G4LsO+HYB3xjwPQB8vwB8vw58/xfwPQN8LwLfXwLfXwPfP1CHKQR8lcDX DHxdwLcc+DYB3zuA78bpfCWiNL5asiqshznJYrQC+HYD313A9xDw/SLwfRT4ngC+zwLfl4DvvwPf D6h9FEXdBzoepuzAtwT41gLfZcB3LfDtAr6DwHdkOl/pgTS+2cDXA3xXAN/NwHc38P088P068H0C +D4DfH8CfP8N+P4WWvuY2kXpgK8D+JYC30bg2wp8NwHfXuB7D/B9GPgeB75P4X4vlyC5NPJ8Ao7n I+TkRiIB/xI35DIkl1+8eHECPhflIiQXd/BHQs4gOfujg78C+ujgzw++efAnQKTu2OXLl8egcrLV sWHzgxGpBEmlY+bhy5eHyfVEAhe7PCYVI6kkgjnzRSKXge8wQyNGlEigBDnkeMslIRxSOZKyH76O D75N3MxloS4cWH7hKgghFSGp+Apfked0JeK7IhNPysQdY1gPH6kJhdsjfE2S9XV0yGlKLiYVQQqa RjRIIJdSctnwBXzxAqhBpeEEd+SXLl0ah88luRhw8vHHFTlDyRU34YQbugFFb9wCJ0aKGBluHLd5 Ix0oKZLKhi+NJxIj04ESzpJIsUiq+NPBS4kkkXqktUtCE3AMy1NXbwggjc3ECysk6fgUwBiaYnjA 0hBjZBQjb9hGrm5rYKQUIxtP8JiN43vMxaRzMWLESHxJ1BgFxaiuwPGHK//a8TrQCx0vAeEG5ElZ E4wEmgPgrkRqATmZFMlkw4eVI5cujbBSipUnobt0QyahZLx/Pw/FKJkcNB8HE7I0xYpT6CWE0+Qh YymZMh2/SwlSmW/0UrIhjCE7dR0LJhNTMgFFkpcSGEErCejY0XGD9KBamQwEvnixr6+vtpZNy5t9 PiyJJJEGJkWDYKwMtGrY/w6++s7+BqLkOMB5A3iOj7NyimXPwzE5iVNWjNgUnmNXWCXFqq9ExuD4 5XFML/te9l0Ewo0y49gEE9gypNHh8QuJGyPKw+PDvMLjAOr4iEJGKRjM+w1S+g2MqmyYuD9fbngc UB0fmYGqgqYUaagSWFWvH5xMh1VGyRjS6sWLJD9COIywqesTb+Ca2Iw4PqRgHUt0gG4YVinAinEd rpXJkUx+/nx3d0ODmU3LA6xYlCSsabgq5KBY44G3yeW3DzRiReUTExhUuDAxoWAoBXRhniaBfpQi hQQppGbhePBGRKGiFJortVdqx4bHhnEMevHBFx98+cFR86iZwDcFdEIhBS4Y6SvDNgw1CSHD44fB f8f7lDJKOYU1qM+HHiiduABFZZQcYzSR+PHEiIBvEu6EkqaU6Xgn5EpKrn7jyuTYVWJwnkgTb0z8 hmCebI+AruDvXEyiTuLc5RtX+LYkWIwbOFbdGGMliE3iDsDL5TBWYLAx2or0E4BeSdNKaUokAXuw hZKhlKwDHTjYcRCupqjj4IGDDkRQwIZIWkLJUkrllGaTQFOHUoKUKVtgYyjVlFJ3xXbFNtYw1nC5 73If7p+jh0cPn1eeVyrlwHh8YvT8+VHeHoRZw/4fgz0a1NJD48MkPo1MHJLuByR2qeSUiuUtchW6 19WJN0gwqh15F669O1LLyCmGbdh/9fwkdiFsBEmaURIqmlJJEukHo6QYzUyzXPSRdt6a/NV5cqRa BY77G5T4LMU/IUTApG0SRCDwEXAo8CeFhFLIktYB8zAMYhjss50IUzWQDUg522UlkBlIRdOqKaul mU2YLbNomGKRqHN3tA9lbo8Gd6DyvkB8APnhDrVm9UIOZSL8P7bw2kIq5CgkI7Nm/gyGdphX0atX tXHIunb1Cg7lCXfw6oTPQSQTchL8Pl5nJBZBLSRtJ+l6km4m6TaS9uwIRgfQAEnjJN1D0oMkPUTS w6kZ/6el1KekNOimFs60RCMK5msUSC3Bf7mYaCBG/wCzZx/djg7Qj9L/ho6Jvin6JnoVUY9/A6NB D4s/no1kPpmPPao8NkWqx3jCd2aS+nMZ1Sl6A+jDjA/1m/WbTUcxWc/NJJkv66T9ecdRnnI+M0XO hzEVmGelB0oeTZL3hfLNSar5kKf6wzfTvMfmPdbwpfm9U9SYxxO+M5MaLy54P0n+lXPQRv8L/hea PsA0/c4i12w077FFv12SseQ0T0tPTtGy45iavzcrfbD890lqeWPFt5LU+iRPbXtmo5XnVp5rV99x MI3ewtdm0mp5u7pdvVqO66w5imntlSTxLa1vXN+8ftP6L61/aYN8w8L1jRtaMc3kt/Gx2QjL0K7e +P6dNE+bmqcI87rrIZyuluPP5rG7VyYp8OS2x5IUFPPU/Vr3a9u18GkEGt7+re1vQP5bQBM9zT1H Cb3ac73nesgX2gTUEdofOg2f/aGnQzd6qzGF9vf29R4Cerz3ZO/Z3nd639kh3rESqGNH744vCXSm j+t7oO903zv9bqDq/vb+aP+R/lcEerf/9/3jA/VAzWFr+Ej4Oqadx6NbCY3HHo49L9Ar0XE4fz42 Rs7G4q64K/Z8/MigfbBhcOuQbcg2/PTutTuP86Xhe4wvtft3uNzuG3uq9/TseWhPYs/vMO2t3buf 0PG9vxjJHLHD9/ERH1DvyKMj3xn5P/vUQK37vgLlaved23duxAfp73Fu37n9aL91f/P+KKH3Dywk FD/w8IELkMYPvHRg7MBLUMJ6UH2w8mD9wc8BvXQP2v8+lH3p/5F29+FR12e+x3/Z2Xa3bl2ube26 tD1uW7ut2tp27fZR21Jb++ADEbpaFVa0Fbql7soRaNHVdlFUrBSRqPGCiAkiGlBMg4EyJQZryAOY GDI1yUAmQybDDKE/HibACKb6O6+x7DmeLvSq3T/eF6iVme/9vT/v+/4lE/u7fzL3Az/pvPyLc79x 23duO3T7wjsuvuPyO665+9MLxi1aed+M//q14sKKCyvf/tDAQweWvGPJe5dcteSWJXcuWbRk2ZJf LNmyJFxSXBos/eul7116ztLzll649Iqly5c2L91e9cGqc6q+WnVz1f1VnVW7H/7Qw//88MJlf7ns Y8uuW7Zk2ZPLOpftfuSsR657ZGX1+6rPr76++s7qh6p/Vf3r6tdqvlFzW01/zWvL37f8nOXnLb96 +b8u/+nyF5a/9uilj05/dN6jzz7ateLPVrx3xbQV1Ssyj330sWmPPfRYz2Phyg+sHLdy4coXHn/H 49c8vuzxXz/xw+BnwTui3cE7cQrehb/FqfhwlA/OwJk4Cx/B502lc3FRlA0uxiUYj3JcigmYiG/h clyJ66JrgqmYhn+NUsH3MR0/wPX4N/w7bsAM/G/ciJlRZTArqgtm44f4Eebg5ujK4D9wC27Fj3Ff 1BcsRgXuxwN4ECvxOJ5ALVZhQ3BmEMcWv9+KF9CBTryILmxDNxL4NV5CH4aim4MsdiGvHrsxjD34 DULsxT7sxwEUMBLVBAejDcEhHEYRL+NodFfwCkbxW7wa3VW2JHqubCmqsAyPoBo1WI5HsQKPYSUe xxOoxSqsxpN4CmvwNOrwc9RjLZ7BpqizrDV6vqwN7diCrdHzsUuiJ2OXBWNjVwRjYldFk2KTouWx q/06xa83RvnYs2rXF/y5U70Fb8Vf4C/xNpyEv8LbcTL+GqVPTb0Tp+Bd+Fucig/jDJyJs/ARXOTm L8YlGI9yXIoJmIhv4XJcidLnsKbgGlyL7+C7+ElUDP4Tc3Eb7otGdMeI7hjRHSO6Y0R3jOiOEd0x ojtGdMeI7hjRFQVdUdAVBV1R0BUFXVHQFQVdUdAVBV1R0BUFXVHQFYUgFY0GA0hjJwaRwZB/lsUu jHi/B53vEA6jiJdxxD876tdXMIrf4tUoU/p0WVkMf4634K34C/wl3oaT8Fc4GaXPRv0N3oF34hS8 C3+LU/F3GIt3+3NPiwbK/h7vw/vxAZyOD+If8CF8GGdE7WVn4ix8BB/F2fgYPo5P4B9xDj6Jf8Kn 8Gl8Bp/F5/B5nIvz8AV8EV/COHwZ5+Mr+CouwNfwdXwD38SFuAgX4xKMRzkuc5bL8W1cgStxq/f9 Y/wE/4m5uA23Yx7uwJ24C/Nxj39nCZaiCsvwCKpRg+V4FCvwGFbicTyBWqzCajyJp7AGT6MOP0c9 1uKZ0ifYoq1lz0V9Zb/C82jGZrT6+21oxxZsjbZKWV9wu4SFEhZKWChhoYSFEhZKWChhoYSFEhZK WMixCY5NcGyCN1O8meHNDG9meDPDm5ngpqiTO+PcGefOOHfGuTMuLaG0hNISSksY3C4F83AH7sRd mI+78VPcgwUYQha7MOLPP6iTD+EwingZR/z9o1Gv7u7V3b26u1d39+quUHeFuivUXaHuCnVXqLtC 3RXqrlB3hbor1F2h7gp1V6i7Qt0V6q5Qd4W6K9Rdoe4KdVeou0LdFequUHeFuivUXaHuCnVXqLtC 3RXqrlB3hbor1F2h7gp1V6i7Qt0V6opQV4S6ItQVoa4IdUWoK0JdEeqKUFeEuiLUFaGuCHVFqCtC XRHqilBXhLoi1BWhrgh1RagrQl0R6opQV4S6IixrkcxWv7ahHVuwNQpjl3HtVbiaQb8cjPEM92EV PQNn4ix8BKXPpZ6Li/z+YlyC8SjHpZiAifgWLseVuM4z0VRMw326ZTEqcD8ewIM4/uQ8zeQ8jSNT HJniyBRHpjgyxZEpjkxxZIojUxyZ4sgUR6Y4MmVaFk3LomlZNC2LpmXRtCyalkXTsmhaFk3LomlZ 1DVFpz8au8oEmhR8MXa1X6cEXww+KxNdMtElE10y0SUTXTLRJRNdMtElE10y0SUTXcEY7/jz9phz cV00JB9D8jEkHxn5COUjlI9QPkL5COWjQz7a5aNdPtrlo10+2uUjLx95+cjLR14+dsrHTvnYKR87 5WOnfOyUj53ysVM+dsrHzmBDtC+I40h0IHgtetmj88tlAcqil50uEbsCV0UHnfAkd3zQCU8KfuOE C5xwgRMucMIFTrjACRc44QInXOCEC5xwgRMucMJKs7VgthbM1oLZWjBbC2Zr4fi9Et2vGve/qV65 Otplxu4yY3eZsbvM2F1m7C7VyqvMiMqMqMyIyoyoTLXKVKtMtcpUq0y1ylSrTLXKVKtMtcpUB4te n8ld+q5L33Xpuy5916XvuoJK/+whLEUVHsYyPIJq1GA5HsUKPIaV0Yt69UW9+qJefVGvvhis9vef xBo8jTr8HPVYi2fQgHVYj19gQ7TGja0Jfun3G9GIZ9GETfgVnkczNqMFrWhDO7ZE3XLRLRfdctEt F91y0S0X3XLRLRfdctEtF91y0R30+Hd60ef3Sb9uxw70I6VrBpDGTgwigyGdmsUu5LEbw9iD3yDE XuzDfhxAASM6/6AkHMJhFPEyjqj5Uff8CkbxW7yK1/z9KOrSsV06tss+0mYfabOPtNlH2uwjbfaR NvtIm32kzT7SZh9ps4+0vYl9JLSPZOwjGftIxj6SsY9k7CMZ+0jGPpKxj2TsIxnzPjTvQ/M+NO9D 8z4suyY4veza4LKy7/j1u8EZZdcFp5X9AKXPn/8YkmsPyNsD8vaAvD0gbw/I2wPy9oC8PSBvD8jb A8LXP61+HxajAvfjATyISha+LJogsVNeT6ukxq5nhjMl8DC3FLmlyC1FbilyyxFuOcItR7jlCLcc 4ZUMr2R4JcMrGV7JuMlDbvKQmzzkdva5nYNu56DbOeh2Drqdg27mZTfzspt52c287GZeNjN22ST2 2CT22CT22CT22CT2mCOhOZIxRzLmSMYcyZgjmeCt6jRGnU5TpzHqdBLrFBmnGIxlmwTbJNgmwTYJ tkmwTYJtEmyTYJsE2yTYJuGsKakv7QfDUj4s5cNSPizlw1I+LOXDUj4s5cNSPqxiYeknH8pO5qgG jmrgqAaOauCoBo5q4Kg6jqrjqDqOquOoOm5ayU0ruWklN63kppXctJKbVnLTSm5ayU0ruWklNxW4 qcBNBW4qcFOBmwqeMnOeMnOeMnOeMnOeMnOeMnOeMnOeMnOeMnOeMnOeMnNua9htDbutYbc17LaG uamFm1q4qYWbWriphZtaeKaZZ5p5pplnmnmm2Uw8xUw8RfZbZL9F9ltkv0X2W2S/RfZbZL9F9ltk v0X2W2S/ReZbZHxYxodlfFjGh2V8WMaHdcbzOuN5nfG8jCdkPCHjCRlPyHhCxhMynpDxhIwnZDwh 4wld1KqLWnVRqy5q1UWtuqj12DNGq05q1UmtOqlVJ5V+RiIn0zmZzsl0TqZzMp2T6ZxM52Q6J9M5 mc7JdK9M98p0r0z3ynSvTPfKdK9M98p0r0z3yvQOmd4h0ztkeodM75DpHTK9Q6Z3yPQOmd4h0zts gSlbYMoWmLIFpmyBKVtgyhaYsgWmbIEpW2DKFpiyBaZsgSlbYMoWmLIFpmyBKVtgyhaYsgWmbIEp W2DKFpiyBaZsgSlbYMoWmLIFpmyBKVtgyhaYsgWmbIEpW2DKFpiyBaZsgSlbYMoWmLIFpjhnB+fs 4JwdnLODc3aUXR28W57Olqcp8vRxeTqbd84pmyaBP+Cg2X79IX6EObgJN+MW3BqleSnNS2leSvNS mpfSvJTmpTQvpXkpzUtpXkqX3e3fucdrLvDrz7AQ92KRVN2HxajA/XgAD6ISS6IO22uH7bXD9tph e+2wvXbYXjtsrx221w7ba4fttcP22mF77bC9dtheO2yvHbbXDttrh+21w/baYXvtsL122F47bK8d ttcO22tHWYP3sg7r8QtsQBy/xEY04lk0YVP0OGutZq3VrLWatVaz1mrGWsNYaxhrDWOtYaw1rz// bLHTnsMceebIM0eeOfLMkWeOPHP0MUcfc/QxRx9z2PWC99uE388g/QzSzyD9DNLPIP0M0s8g/QzS zyD9DNLPIP3cPZ27p3P3dNboZI1O1uhkjU7W6GSNTtboZI1O1uhkjU7W6OT5a5hjIXMsZI6FzLGQ ORby/MU8fzHPX8zzF/P8xZ7kxgTzcAfuxF2Yj7vxU9wDuxzrJFgnwToJ1kmwToJ1EqyTYJ0E6yRY J8E6Cdb5Eut8iXV6WaeXdXpZp5d1elmnl3V6WaeXdXpZp5d1elmnl3V62eVhdnmYXR5mlyF2GWKX IXYZYpchdhlilyF2GWKXIXYZYpchdrmbXZrYpYldmtiliV2amGUys0xmlsnMMplZJkt2VrKzkp2V 7KxkZyU7K9lZyc5Kdlays5KdleysZGclOyvZWcnOSnZWsrOSnZXsrGRnJTsr2VnJzkp2VrKzkp2V 7KxkZyU7K9lZyc5Kdlays5KdleysZGclOyvZWcnOSkhSQpISkpSQpIQkJSQpIUkJSUpIUkKSEpKU kKSEJCUkKSFJCUlKSFJCkhKSlJCkhCQlJCkhSQlJSkhSQpK6vl7Xb9D1G3T9Bl2/Qddv0PVP6fqn dP1Tuv4pXf9U7LLgNJP5/Nik6HrT+fzYFL/eEj0XuzV6JPZs8MnYUFQTywZnx3YF58Ty/rfDUV9s T/CW4AumeNYUz5riWVM8a4pnTfGsKZ41xbOmeNYUz5riWVM84Tkg9BxwvK8a5HV0XkfndXReR+dN /LiubtLVTbq6SVc36eomu3/a7p+2+6ft/mlbQcZWkLEVZGwFGVtBxlaQsRVkbAUZW0HGVpCxY4d2 7NBMCu2YRTtm0Y5ZtGMWbTAjZS/4tQOdePH158DSk1JGZQp2rzEqU7B/jQk2O/Vsp57t1LOderZT z3bq2U4926lnO/Vsp57t1LOdetbrP395Lq6LXnHqV5z6ldf3tZuc/ma71n/gFtyKH+MnqvWfmIvb cHu0yAkXOeEiJ1zkhIuccJETLnLCRU64yAkXOWGzEzab7kXTvWi6F033ouleNN2LwVDwF4F7Cnbh TTwVl35y1LTuM637TOs+07rPtO4zrftM6z7Tus+07jOt+0o/X2pabzett5vW203r7ab1dtN6u2m9 3bTeblpvN63zpZ9CNa3TpnXatE6b1mnTOm1ap03rtGmdNq3TZWfYHm28ZWfhI/gozsbH8HF8Av+I c/BJ/BM+hU/jM/gsPofP41ychy/gi/gSxuHLOB9fwVdxAb6Gr+Mb+CYuxEW4OCj934+PKRuPclzm LJfj27gCV+LNTtx7/DuLTKv7sBgVuB8P4EFUYonXWooqLMMjqEYNluNRrMBjWInH8QRqsQqr8SSe who8jTr8HPVYi2dKP5mKNrTDNCzbqvsvi/6+9HPBsauCU6Th7NjVfp3i1+uj1aZmwsQcE3zq/07C 60zFqZiG3+W7IN8F+S7Id0G+C8FNwZ/r/s26f7Pu36z7N+v+zabWWFNrrKk11tQaa2qNNbXGmlpj Ta2xptZYU2usSXSGSXRGcMTvX0MUjC0LUIZLg8+WTcBEfAv/jO8H5WUtwalsNyV2eXCeU7zdCd4e uz7499hPWG1ucHrs9uC04JY/8JWNA2b/AbP/gNl/wOw/YOaHZn5o5odmfmjmh2Z+aOaHZn5o5odm fmjmhyf8rsF1mIppmMl8x6vWzdF2ldquUttVartKbf8DX0EbMLcHzO0Bc3vA3B5QrZNU6yRzO21u p83ttLmdNrfT5nba3E6b22lzO21up83ttLmdNrfTXHGUK45yxVGuOMoVR7niKFcc5YqjXHGUK45y xVGzevdxvx571NlewSh+i1ffxBP4rVG/LPXLUr8s9ctSvyz1y1K/LPXLUr8s9ctSvyz1m337jvuc 2oo2tGMLtkZ7Yleoydfe1PeUSk/epZ+NPxf//8395vh9Hu11e0m3l3R7SbeXdHtJVh9l9VFWH2X1 UVYfZfVRVh9l9VFWH2X10vdy+mxNfbamPtVNqG6f6vapbp/q9qlun5mWUuG4CsdVOK7CcRWOl356 XyX2qsReldirEntVYu/rP8/fhnZswdZoyJwLbQChORfaAEKpPlJ2mspMUZkpKjNFZaaozBSVmaIy U1RGfnAy/hpjostlJyE7CdlJyE5CdhKyk5CdNtlpk5022WmTnTZVXK+K62WoXYbaZahdhtplqF2G 2mWoXYbaZahdhtplqD0offVgCq7BtfgOvovrGGAqpuH2aJzKjlPZcSo7TmXHqew4lR2nsuNUdpzK jgsWRVtk6EYZulGGbpShG2XoRhm6Maj0zx7CUlThYSzDI6hGDZbjUazAY1hpl38cT6AWq7Da338S a/A06vBz1GMtnkED1mE9foENUaU5Xhn80u83ohHPogmb8Cs8j2ZsRgta0YZ2bIlmyPgMGZ8h4zNk fIaMz5DxGTI+Q8ZnyPgMGZ8h4zOCHv9OL/r8PunX7diBfqTsEwNIYycGkUE+queEek6o54R6Tqjn hHpOqOeEek6o54R6Tqg/1rXdurZb13br2m5d261rXzyeF2xnedtZ3naWt53l7R9T7R9T7R9T7R9T 7R9T7R9T7R9T7R9T7R9T7R9T7R9T7R/j7R/j7R/j7R/j7R/j7R/j7R/j7R/j7R/j7R/j7R/X8085 /5TzTzn/lPNPOf+U8085/5TzTzn/lJddGv1b2QRMxLfwz7jMv385vo0rcCWuDk73hH6RJ/TbPKFf 5Ql9iif0Sz2hV3pC/4Yn9EpP6JWe0Cs9oVd6Qq/0hF7pCb2S48o5rpzjyjmunOPKOa6c48o5rpzj yjmunOPKOa7cE3qlneF6T+iVntArPaFXekKvtEPMsUPMsUPMsUPMsUPMsUPMsUPMsUPM8eRc6cm5 0pNzpSfnSk/OlZ6cKz05V3pyrvTkXOnJudKTcyV7bGKPZvZoZo9m9mhmj2bbcgODbGKQTQyyiUE2 McgmG/QDNugHbNAP2KAfsDOcH7vcfvDtaJXd4TK7w1hT9x/sDmNN3n+wO8xnmVmxZ6MlsSHPFruC k2K5qCk2HFwU/C/maWeeduZpZ5525mlnnnbmaWeeduZpZ5525mk/9h2XnWyyU/rz0p+X/rz056U/ L/156c9Lf17689Kff8PzQPH173hdUfpalFet8KoVXrXCq1Z41QqvWuFVK7xqhVet8KoVXrXCq97A d2m+S/Ndmu/SfJfmuzTfpfguxXcpvkvxXco7rPMOS19p7OO7Pr7r47s+vuvjuz6+6+O7Pr7r47s+ vuvjuwN8d4DvDvDdAb47wHcHgpnB25x0ppPOdNKZTjrTSWc66UwnnemkM510ppPOPPZdjxqeq+G5 Gp6r4bkanqv5E7/rUc1z1TxXzXPVPFf9J37Xo8ENNPwPvutRy3O1PFfLc7U8V8tztTxXy3O1PFfL c7U8V8tztW/4rkftcb7r0cJzLTzXwnMtPNfCcy08l+a5NM+leS7Nc2meS/NcmufSPJfmuTTPpV+f wq/pqMhuE6AMfxbdy133cte93HUvd93LXfdy173cdS933ctd93LXvdxVwV0V3FXBXRXcVcFdFdxV wV0V3FXBXRXctYK7KrmrkrsquauSuyq5q5K7KrmrkrsquauSu6q4q4q7qririruquGsFd63grhXc tYK7VnDXeW9w1xTumsldl3FXC3d9mbtauKuFu1q4q4W7WrirhbtauKuGu2q4q4a7arirhrtquKuG u2q4q4a7arirhrtquKuFu1ZwVwt3tXBXC3e1cNcq7lrFXau4axV3reKuVdy1irtWcVcLd7VwVwt3 tXBXC3e1cFcLd7VwVwt3tXBXy/E2HH6q56d6fqrnp3qp/84xPzVL/xe46YO89EFequal1cdcdGnZ 21ihmhWqWaGaFapZoZoVqlmhmhWqWaGaFapZwfNYdDsr5Fghxwo5VsixQo4Vcsf/ZFu0mhVWs0Ke FfKskGeFPCvkWSHPCnlWyLNCnhXyrJA/4RZ0k33z9mg+K8xnhfmsMJ8V5rPCfFaYzwrzWWE+K8w/ ZoU4K8RZIc4KcVaIs0L8T7RCnBXirBBnhTgrxP9EK9SxQt3/wApxVoizQpwV4qwQZ4U4K8RZIc4K cVaIs0KcFeJvsEL8OFbIsEKGFTKskGGFDCtk3uT3P4sn+IRK3wm+//n72886BlnHIOsYZB2DrGOQ dQyyjkHWMcg6BlnHIOsYpJ5B6hmknkHqGaSeQeoZpJ5B6hmknkHqGWQjg6xnkPUMsp5B1jPIegZZ zyDrGWQ9g6xnkPUM0sogrQzSyiCtDNLKIBsZZCODbGSQjQyykUFOYpDPMMi/M8h5DHLese9PtDHI ZxikjUHaGKSNQdoYpI1B2hikjUHqGKSOQeoYpI5B6hikjkHqGKSOQeoYpI5B6hikjkHaGGQjg7Qx SBuDtDFIG4NsZJCNDLKRQTYyyEYG2cggGxlkI4O0MUgbg7QxSBuDtDFIG4O0MUgbg7QxSBuDtNl+ Sp+O6WeRfhbpZ5F+FulnjW+xxn2McSljnMwYJ7NFU7BC6uNSH5f6uNTHpT4u9XGpb5D6BqlvkPoG qW+Q9ri0x6U9Lu1xaY9Le1za49Iel/a4tMelPX7Crxvc51UXowL34wE8iJV4HE+gFqvw/75b2CQd TdLRJB1N0tEkHU3S0SQdTdLRJB1N0tEkHU1S0SQFoRSEUhBKQSgFoRSEnkybPJk2eTJtkogtErFF IrZIxBaJ2CIRWyRii0RskYgtErFFIrZIxHMS0S4R7RLRLhHtEtEuDQ3S0CANDdLQIA0N0vCqNLwq Da9Kw6s6t1vnJnVuUucmdW5S5yZ1blLnJnVuUucmdW5S5x7VuUd17lGde1TnHtW53Tq3W+d269xu ndut+5K6L6n7krovqfuSui+p+5K6L6n7krovqfuSui+p87rLlmApqrAMj6AaNViOR7ECj2ElHscT qMUqrMaTeApr8DTq8HPUYy2eQUOU0onr7eFN9vAme3iTPbzJHt6kO5t0Z5PubNKdTbqz6fUn+N89 vTeVTTO3JphbE8ytCebWBHNrgrk1wdyaYG5NMLcmmFsTzK0J5tZXdXCdDq7TwXU6uE4H1+nguuN+ v/zz0c/MrZ/p5LU6ea1OXquT1+rktTp5rU5eq5PX6uS1OnmtTl6rkzM6OaOTMzo5o5MzOjnz3z43 e3t0gRl2gRl2gRl2gRl2gRl2gRl2gRl2gRl2gRl2gRnWKAXTpGCaFEyTgmlSME0KpplhjWZYoxnW aIY1mmGNZlijGdZohjWaYY1mWKMZ1miGNZphjSd4gm80wxrNsEYzrNEMazTDGs2wRjOs0QxrNMMa zbBGM6zRDGs0w24zw24zwxrNsEYzrNEMazTDGs2wRjOs0QxrNMMazbBGM6zRDGs0wxrNsEYpnS6l 06V0upROl9LpUjpdSqdL6XQpnS6l06V0upRON8MazbBGaZ1uhjWaYY1mWKMZ1ii9i6V3sfQult7F 0rtYehdLb6f0dkpvp/Q2S2+z9DZLb7P0Nktvs/Q2S2+z9DZLb7P0NktvXHqflt6npfdp6X1aep82 zx6V4D4J7pPgPgnuk+A+CV4rwWsleK0ErzXPZplns8yzWebZLPNslnk2yzybZZ7NMs9mmWezzLNZ 5tlE82yieTbRPJtonk00zyaaZxPNs4nm2UTzbCIr3MAKk1lhMitMZoXJrDCZFSazwmRWmMwKk1mh 9B3CprIzcRY+go/ibHwMH8cn8I84B5/EP+FT+DQ+g8/ic/g8zsV5+AK+iC9hHL6M8/EVfBUX4Gv4 Or6Bb+JCXISLcQnGoxyXRt9jre+x1vdY63us9T3WuoG1bmCtG8pK/5XJK/Ev0aCZe0bZlChu7p5n 7n7f3L3I3L3K3P2auVtV9n0G+YF/Ntvvf4gfYQ5uws24BbdGk9hvEvtNYr9J7DeJ/Sax3yT2m8R+ k9hvEvtNYr9JZm8VA95g9laZvVVmb5XZW2X2zjV755q9c83euWbvXLN3rtk71+ydW/ZQ1FD6L1uy ZidrdrJmJ2t2smYna3ayZidrdrJmJ2t2smYna3ayZidrdrJmJ2t2smYna3ayZidrdrJmJ2t2smYn a3ayZidrVpnzVeZ8lTlfZc5XmfNV5nyVOV9lzleZ81XmfBW7/pJdN7HrJnbdxK6b2HVTWYsnjlbv uQ3t2IKteCFa5ClikaeIRZ4iFtkH3mEfuMlTxEw7wbvtBKXvjJziKeImFl4cy0QFTxLNsd1Rn6eJ 02N77HiPMfMIM48w8wgzjzDzCDOPMPMIM48w8wgzjzDzCCsPsPIAKw+w8gArD7DywAl+iiHDxhk2 zrBxho0zbJxh4wwbZ9g4w8YZNi59FvVQMBs/xI8wB8f7fuSb+3zA774rs8Xvt+IFdKATL6IL29CN BH6Nl9CHN/7Uwpv7GZfj/4TD8X+6ocg+RfYpsk+RfYrsU2SfIvsU2afIPkX2KbJPgX0K7FNgnwL7 FNinwD4F9imwT4F9CuxTYJ9B9hlkn0H2GWSfQfYZZJ9B9hlkn0H2GZTkgiQXJLlQVvqM2pW4Ojj5 DZ/sOVuCzzn2icIzpDMnnTnpzElnTjpz0pmTzpx05qQzJ5056cxJZ04yCzr6JR2d1NFJHZ3U0Ukd ndTNKd2c0s0p3ZzSzSnd+j7d+r5Y6eeevuamB9z0gJsecNMDbnrATQ+46bSbTrvptJtOu+m0mz7b TZ/tpjNB6dN+L6ADnXgRXdiGbiTwa7yEPpz451YW6oCFOmChDtimA7bpgG06YJsO2KYDtumAbTpg mw7YpgO26YBtOmCNDlijA9bogDU6YI0OWFP62p4umKML5uiCObpgji6YE7skejh2WfBXx37SaIqt 6cnY5Ghq7F+ihtjV/nqKv77GX1/rr28MTgrO/aM/ZXAfFqMC9+MBPIiV+vRxPIFarMKWaFDlBlVu UOUGVW5Q5QZVblDlBlVuUOUGVW5Q5QZVblDl8iqXV7m8yuVVLq9ypQzkT/CUWfreW1EFiipQVIGi ChR//xMQsX9hrGtxY5QMPuW0odOGThs6bei0odOGThs6bei0odOGTjDqBKNOMOoEo04w6gSjTjDq BKNOMOoEo04w6gSjTjDqBK85wWtO8JoTvOYErznBa+6+y913ufsup+l1mkGnGXSaQacZdJpBp3nJ aTY7zWan2ew0m51m8+9/1Y2Tc+71gDstfd70QKz0dZKPBQs9/5z45/X++/1sCN6lw9/llHmnzDtl 3inzTpl3yrxT5p0y75R5p8w7Zd4p806ZD4Z0TRa7MBK94p0PeucHvfOD3vlB7/ygd37QO33l2E8b fD02OTjJPXzo2E8dfD12jb++NvgQm94unfNwB+7EXZiPu/FT3IMFWOj2NkS77Z671XObem5Tz1I+ +tVzWD2H1XNYPYfVc9i72updbfWutnpXW72rrd7VVvXMqGdGPTPqmXnDTw2Ualo4VtNCzP4eK+3v 3/yjP4G/MNrgDobcwZA7GHIHQ+5gyB0MuYPQHYTuIHQHoTsInabdadrdwW53sNsd7HYHu93Bbnew 2x3sdge73cFud7DbHex2B7vdwe4TPrf+LiuhaoSqEapGqBrhse+ijqrGqGqMqsaoaowep7tK/0Xx W93be9zbme7tlGP39h73dqZ7K2XpQ6pzrepcaxPoi70YfCD4O6cvfc1t1OlHnX7U6UedftTpS+47 7L4Ou6/Dxz6VPeIdjniHI97hiHc44h3u9g53eYe7vMNd3uEu73CXV3+nV3xn8Gd+d6rfnRq81430 uJEeN9LjRnrcSI8b6XEjPW6kx430uJEe72nghD4+zmelnL7D6Xd6pTFeaYxT7oqVfi7jQq+4zyvu 84r7vOI+r7jPK+7zivu84j6vuM8r7lOBZ1TgGRV4RgWeUYFnVOAZ99/g/hvcf4P7b3D/DTI4RgbH uP917n+d+1/n/te5/3Xuf537X+f+17n/de5/nftf5/7Xuf91TrXPqfY51T6n2udU+5xqn8mSNVmy JkvWZMmaLFmTJWuyZE2WrMmSNVmyJkvWTex1E3k3kXcTeTeRdxP5Y5Nl2E0Mu4lhNzHsJoaPZfl0 PXGaCo07luXT9cRpqjWOXzuC0iczTw3m4Q7cibswH3fjp7gHC7Aw+Kxq9ahWj2r1qFaPavWoVo9q 9ahWj2r1qFaPavW8YSa/+U95DEXL9N8y/bdMhXpUqEeFelSoR4V6VKhHhXpUqEeFelSoR4V6VKhK hapVqFqFqlWoWoWqVWe26sxWndmqM1t1Zpu5b+WQ8ebtXB4537y9i0vGm7dz+eR88/au2C1m863R Q7Gu4P2xbcE7YolgbPAJvZXWW2m9ldZbab2V1ltpvZXWW2m9ldZbad1c+s7ebzjjN39gy9jqpFud dKt3P3CC+33uj5w0JTMOHvuU4FucKnXsk4JvcaKUdISx0tfqLvyjP8W3MLrbnRfcecGdF9x5wZ0X 3HnBne935/vd+X53vt+d73farU671Z0X3XnRnRfdedGdF9150Z0X3XnRnRfdedGdF9156evdpa9v H1ahwyp0WIUOq9BhFTr8ez9hOaJCR1ToiAodUaEjKnTk2Czer0L7VWi/Cu1Xof0qtEuFdqnQLhXa pUKfU6GvSMapKnSuVLxHKk5VoXMl4j0qdKEKXciSc0o/5V2adub0PNyBO3EX5uNu/BT3YAEW6vQN wbt1/Lu94wHveMA7Hjj2PHDYOz7sHR/2jg97x4eDIzxy1IR8BaP4LV6Nkrryy7HLgzPc4V73V/oE zF53F8a+E3w09l1cH1x37BNifx8rvbcv/dH70X3RHve4xz3ucY973OMe97jHPe5xj3vc4x73uMc9 7nF/w+5v2P0Nu79h9zdc+n9oc3/D7m/Y/Q27v2H3N+z+ht3fsPvb7/72u7/97m+/+9vv/varxl7V 2Ksae1Ujd4JPZP23pyN3d8TdHXF3R9zdEfe21529+/U9aopfS3tU6fQ5p885fc7pc06fc/qc0+ec Puf0OafP6eRSBfaqwF4V2KsCe1VgrwrsVYFDKnBIBQ6pwCEVOKSTR3XyqEocUolDKnFIJQ6pxCGV OKQSh1TikEocUolDKnFIJQ6pxKE/kPU39kVp7u9RiT0qsUcl9qjEHp28QzVeUo2XVOMl1XhJNV7S DzmmGtUPOYYa1Z3h66ef5/TznH6e089z+nlOP8/p5zn9PKef5/TznH6x0z/n9M85/XNO/5zTP+f0 zx3/53miLU5f+vROq9O3On2r07c6favTtzp9q9O3On2r07c6favTtzp964k+8St782OXRwOxb0dL 3eV8GXy/+7zk2HQql8P3u9dLjk2nclm8WxbvlkXPPdFKW8s5sW6/t7/HXgouCv7G6RNOn3D6hNMn nD7h9AmnTzh9wukTTp9w+t7/+oSFd5Hy6n3+9JQ/PRV80Z9S60+p9afU+lNq/Sm1/pRaf0qtP6XW n1LrT6n1p/z4D3z1YZsablPDbWq4TQ23ecWNXnHjn/Rf2EjJxADS2IlBlL52c1l0kxom/w9zdx5f VX3nf/zkXkgkSFM1onRmaltc0NYNcalLFa1bxQoqttIZx5lRZ1xaBldwxo3gLoiKW6GKihsg4kIj AYIIxISLrAEugTSEi4GEJDdX4FJwOb/nuVwt4wNnfs7j9+jj98eLG5Lz/X4/y/vzOd+T3HuOGEZe XCWG+4nh2WLYQwwvF8P9xPBsMewhhpfz8nFePp5/d8tHYnikGC4Sv3Ny15GTeT6Z55N5Ppnnk3k+ meeTeT6Z55N5Ppnnr/B8Dc/X8HwNz9fwfA3P1/C8jud1PK/jeR3P67567/f/5sz/Te8X/3Pu+uQO 3q/nfQPvr8t73yfv/TV57/vkvb+G93/g/R9y7wk+lrdZ3mZ5m+VtlrdZ3mZ5m+VtlrdZ3kZ74uk8 nc7T6TydztPpPJ3O03KelvO0nKflPC3f7Z2sM3k6k6czeTqTpzN5OpOnM3k6k6czeTqTpzN5OpOn M3m6maebebqZp5t5upmnm3l0EI9KeDSINwfxJtrbDuLFxOBMXgzjxTBeDOPFMF4M48UwXgzjxTBe DOPFMDn7DU9m8WQWT2bxZBZPZvEk+svCezx5jyfv8eQ9nrwnZ+/L2fs8qeRJJU8qeVLJk0qeVPKk kieVPKnkSSVPKnlSyZPKb/w9wBd6axi26eBtOnib/F0of4vkL9qnnJnfn57B2568vSW/Pz2Dxz15 fIv8jZC/EdT7CO9foN5e1DuPen8SHPctznvftGfd028MO8tnZ1FYIQorRGGFKKwQhRWisEIUVojC ClFYIQorRGGFKKwQhRW6eVo3T+vmad08rZundfIWnbxFJ2/RyVt08hYeH8HbPjw9gpd9cp28f0Gv cFvB4TgCP8ZPcCSOwtE4BseiN45DHxyPE3AiTsJPcTJOwak4DT/D6TgDfXEmzsLPcTbOwbk4D+fj F7gA/XAhfomLED0VayzG4Tk8j/F4AS/iJUzAy3gFr+I1vI6JmITJeANT8Cam4i28jXfwbvREqzBV MCfsKPgAczEP81GVe6fwmoJq1GABEuEa58X18egveZeKYEYEMyKYEcGMCGZEMCOCGRHMiGBGBDMi mBHBjAhmRDAjghkRzIhgRgQzIpgRwYwIZkQwI4IZEcyIYEYEMyKYEcGMCGZEMCOCGRHMiGBGBDMi mBHBjAhmRDAjghkRzOSePTYW4/Acnsd4vIAX8RIm4GW8glfxGl7HREzCZLyBKXgTU/EW3sY7eBfR U8nm4APMxTzMz32uaF3umWfVqMECJLDQ1cNHWITFzpCDcr9TyQR///+9JqNnsT2Gx/EExuBJPIWn ET2lbSzG4Tk8j/F4AS/iJUzAy3gFr+I1vI6JmITJeANT8Cam4i28jXfwLr454mtyT4erRg0WIIGF 4UYR3yjiG0X8L/c3OSD3rLo4OqEzClGEvdAFxeiKboieaHcn7sLduAfD4TxX4DxX4DxX4DxX4DxX EJ3nigtKgqMLBuEG/BaD8e8YghtxMx4Kjg7+mR0N7GhgRwM7GtjRwI4GdjSwo4EdDexoYEdDwXfD +oJ9sC/2Qyn2R3ccgAPRA7s+E7224CD8AD/Ej9ATB+MQHIrD0D9MFgzAxbgEl2JPn0O+I2wUg0Yx aBSDRjFoFINGMWgUg0YxaBSDRjFoFIPG3OeIR9P5Y3gcT2AMnsRTeDq6G01QWjAnKCr4AHMxD/MR PSGvGjVYgAS+XjsDw3HObI87s/XU5wc5o/XU56Nz9/LcVdt4zNDz52C9XUoqOCe+wVnv46A0vtH/ N3ltDk6Nt/jeZlefl+SeChhHJ3RGIYqwF7qgGF3RDdGzA/fBvtgPpdgf3XEADkQPfC9szj1h8CD8 AD/Ej9ATB+MQHIrDMNCxl+FX+DUuR/RcwjtxF+7GPRgOZ2RRbxX1VlFvFfVWUW8V9ebcUwzHYhye w/MYjxfwIl7CBLyMV/AqXsPrmIhJmIw3MAVvYirewtt4B++Gm0R+b5E/UeSjT1SdKPKLRLx7vDLo kXvuZL1o1otmvWjWi2a9aNaLZr1o1otmvWjWi2b9t/iLWxTNFtFsEc0W0WwRzRbRbBHNFtFsEc0W 0Wwp6B/sUzAAF+MSXIr/dxHOiHBGhDMinBHhjAhnRDgjwhkRzohwRoQzIpwR4YwIZ0Q4I8IZEc6I cEaEMyKcEeGMCGdEOCPCGRHOiHBm1yd0g31F+RxR3leUz4nfEJwaxHwnei99j6BTPgv981noH3xH 7ynRe0r0nhK9p0TvKdF7SvSeEr2nRO8p0XtKjDzRyIFGnmjkwNzIXkb2MrKXkb2M7GVkLyN7GdnL yF5G9sp/GvB3+U8D/i43stTIUiNLjSw1stTIUiNLjSw1stTIUiN7G9nXyN5G9v1W1kYjL8iPvCAX gyOjzyJGz7xQPXF0QmcUogh7oQuK0RXd8N1wOa0tp7XltLac1pbT2nJaW05ry2ltOa0tz7/jrJrW qmmtmtaqaa2a1qpprZrWqmmtmtaqv+HdZVV0VUVXVXRVRVdVdFVFV1V0VUVXVXRVRVdVdFWVe3fZ 6DCtX6b1y7R+mdYv0/plWr9M65dpusvSXZbusnSXpbss3WXpLkt3WbrL0l2W7rJ0l6W7LN1l6S5L d1m6y9Jdlu6ydJeluyzdZekuS3dZusvSXbZgmrPkjWGFiomexzon/Mz59jPn28+cbz9zvv3M+XZV 7imt1ajBAiSwMNysS2/WpTfr0pt16fVBZ7XYRS12UYtd1GIXtdglGJB7jmscndAZhSjCXuiCYnRF N0RPe90H+2I/lGJ/dMcBOBA9sOvzxc2y1ixrzbLWLGvNstYsa82y1ixrzbLW7My3yZlvkzPfJme+ Tc58m77hM73f9u4+G/+nu/vknlI7J9jbmW9vZ769nfn2dubbO/fc2mrUYAESQRcxvC56km3+czQX 5D9Hc0HurhXRXjxt55i2c0zbOabtHNN2jmk7x7SdY9rOMW3nmLZzTNs5pu0c03aOaTvHtJ1j2s4x beeYtnNM2zmm7RzTdo5pO8e0nWPazjFt55i2c0zbOabtHNN2jmk7x7SdY9rOMW3nmLZzTNs5pu0c 03aOaTvHtJ1jOvf03bEYh+fwPMbjBbyIlzABL+MVvIrX8DomYhIm4w1MwZuYirfwNt7Bu4ie77vn nWFL7qm/1ajBAiSwUI/9CIuwWK8dtOszkMFAEU2JaEpEUyKaEtGUiKZENCWiKRFNiWhKRFMimhLR lIimRDQloikRTYloSkRTIpoS0ZSIpkQ0JaIpEU2JaEpEUyKaEtGUiKZENCWiKRFNiWhKRFMimhLR lIimRDQloqm/2h0kp4VbRHW9qNaLar2o1otqvajWi+p6UV0pqitFdaWorhTVlXu4wlkuqsuDp3NP VY6jEzqjEEXYC11QjK7ohm93P6821d6m2ttUe5tqb1Ptbaq9TbW3qfY21d5W0Mu55nAcgR/jJzgS R+FoHINj0RvHoQ+Oxwk4ESfhpzgZp+BUnIaf4XScgeh8dibOws9xNs7BuTgP5+MXuAD9cCF+iYvQ n4YH4GJcgkuxp3uQRc+ivhN34W7cg+Eowwjci/twPx7ArnuN7dSNdupGO3WjnbrRTt1op260Uzfa mXs69ViMw3N4HuPxAl7ES5iAl/EKXsVreB0TMQmT8Qam4E1MxVt4G+/g3ei52c7lc/AB5mIe5u/5 zgOU1E5J7ZTUTkntuuD90ZO2813w1HwXPFUXXJVTVwt1tVBXC3W1UFcLdbVQVwt1tVBXC3W1UFcL dbVRVxt1tVFXG3W1UVcbdbVRVxt1tVFXW/79XR3U1UFdHdTVQV0d1NVBXR3U1UFdHdTVQV1F1FVE XUXUVURdRdRVRF1F1FVEXUXUVURdRdRVRF1F1FVEXUXUVURdRdRVRF1F1FVEXUXUVURdRdRVRF1F 1FVEXUXUVURdRdRVRF1F1FVEXUXUVURdRdRVRF1F1FVEXUXUVURdHdTVQV0d1NVBXR17fE/aHTr2 nbgLd+MeDEcZRuBe3If78QCi951FTzh/DI/jCYzBk3gKT+P3QSF1FVJXIXUVUlchdRVSVyF1FVJX IXUVUlchdRVSVyF1FVJXIXUVUlchdRVSVyF1FVJXIXUVUlchdRVSVyF1FebVtadz6p7UtZW6tlLX Vuramj/HPrgHda0PfkZd66hrHXWto6511LWOutZR1zrqWkdd66hrHXWto66l1LWUupZS11LqWkpd S6lrKXUtpa6l1LWUulZT12LqWkxdi6lrMXUtpq7F1LWYuhZT12LqWixTq2VqtUytlqnVMrVappbK 1FKZWipTS2VqqUwtlamlMrVUppbK1FKZWipTS2Vq9f94H69p0b0ActfRPXOfbXk691T7ODqhMwpR hL3QBcXoim74btjE8yaeN/G8iedNPG/ieRPPm3jexPOm/FXc/90erZeucTiOwI/xExyJo3A0jsGx 6I3j0AfH4wSciJPwU5yMU3AqTsPPcDrOQF+cibPwc5yNc3AuzsP5+AUuQD9ciF/ioug587rrAFyM S3Ap9nyV2SJbLbLVIlststUiWy2y1SJbLbLVIlststUiWy25q8z/ua7+ml17T3W1p9/SfL2uRqir snxd9c3XVd/c+05v+Zb3A1xDXWuoaw11raGuNdS1hrrWUNca6lpDXWuoq4666qirjrrqqKuOuuqo q4666qirjrrqqKvOTi9rp5e108va6WXt9LJ2elk7vaydXtZOL2unl7XTy9rpZe30snZ6WTu9rJ1e 1k4va6eXtdPL2ull7fSydnpZO72snV7WTi9rp5e108va6WXt9LJ2elk7vaydXtZOL2unl7XTy9rp Ze30snZ6WTu9rJ1elrq2Udc26tpGXduoaxt11VFXHXXVUVcdddVRVz111VNXPXXVU1c9ddVTVz11 1VNXPXXVU1c9ddVTVx11tVNXO3W1U1c7dbVTVzt1tVNXu16QtfvL2P2l7f7Sdn9pu7+03V/azi9j 55ex88vY+WXs/DJf/UaiW+zkcFnsLJwXXhY7P7wmdkF4TfzC8P34wKA4uu9K/h7/4/L3+B+X00LX 2DFhU6wPTgw3xk73el5Ya/R8o+fHLgyXUFIy95f5K8Km4DuObnV0q6Oz1qs3otWa9TG1GPu17/0m XBu7Cr/Fg77/UFifW6fYyK1GbjUqadRWo5KOaHRE427vip6fW6POkXXWWOXIOhYlWVTNoupYzp9w Rv7dkdty7/6/wus/BqXBXuaeZN5JrJjBihmsmGGNGmvURL8lC/Y1963mvtXcTea+1dw7zZ0xd8bc dY5e7+j18YFfbLdGyR7uvzQsd/0XzXSlma605mIzXWndxbHzgu+Z4XIzXM7Ko+KXhS/k3wtwXL4S j85X4tH5v1dfGXzXTNeb6Xo2Zcw2w2zXmy2yfKCZBprpcDPdaaY7zLR/7q+n0V9Nb7AruzH8TVBk 1FtGvGXEEiOW5O6f9o+I/p5aIhpp0UjHrg3Hxq4LR8Suxw34bZj+mj4eoI+3xPMB+njL6E/kbYBI uSI3utbo+UbPN3p+7Hfhitw7Db7URkHu3URFjt9qxdVWXG2F1Wzpypauuah189PVZltrtqTZqsxW ZbYqs83YLa9b83ndmstrNPNafgwIJxj7sbE7jc0amzU2a2ydsccYe6ooFxvbS5Sju/f2EqOROf1F o4ex6yN2fRS7NujOto+MulpkW0U2ZfRIo/8297fLK7xGf7u8IRxl9NSc3ddbO2OGmWaYafRMo08y epnR7+bvGHyUUUcZVRa9myModHSNo2scXeOn+/vp/n7yJqXewodbReq2sDk2QhWONPeTauiZsCP2 bNgRxPx0Ryz6W36Bf7fLw23h9thQ3xuW+/7i2H1Bl9j9ZnkkbIs9RUXP+P6z4Q5z32ium3CL79wm e/aW5t8Y02liT5trX0csccQSR2w0Z8acmdhdOsfduAfDMSL4u9h9YWXsUceNVsmP4XE8gWdU4rNh ddCJlY2OWueo5lj0rtoY21rYFFl8I/9uwl+sXkGh7RTa7oh2s2w1y1YW3xo2sDTL0tbYnWwZEZSa db1Z18ei9+F9z1xzzDWHxU2OXGTOJnM2xW7nvXO8Ua086OBBBw86eNBhlkLrJayXsF46NkrmR4cp nqR4kuJJSkxqxb2GLSvYsiL4Gyu1WqnVSlvZNcNqW62w1gppK2SskLFCxgqRnQewc7pVWq3SGrMr F+k2dk+xUpuV2qzUZqU2K3VYaQt/llttk9U2yeCNvL4JkfcjqPQ+MzzoqIcw0vce5X1X3u7k7U4R 3CDvxbGHHflIbi1H+PopPOPnz4Y7c9ldZ851RrUaFcVlI6s3snojqzfm1vnS4kdZNVqUH8PjeALP iOuzKjrKZZrKG8Xxy6iM4ckunbY6pjWXu7bd7GvlwVZxiCzP8jWrI9zKgxHsuc+6D/v6EZp5NOjB 6n3p9kZKuAlRRdyBOx01wuuD4v0QHjHfyFz2MkYdnlOxvTMLPmHBJzkNRpWRZkHayMRXtZMJ4rka G4Hojl8l1lpprZVfHX1nuM1P17Ksq/U2WW9TLraPsnqMSD1JWc9Q9rNhc26u7Y7ebK4/B31iU/g6 jRezqKcSc/TED9g2N7w5Ni98NjYfH4YvxRI67SJnmmWOWeF1JdKi3IEtzjjbwodi2fCV2HbsCJfG Pg+fiwf6TidnoSKve6Gbr10lx10lx10lx3vhcBwZbo4fHb4WPzZ8I94bx6FPuC5+UlgbPyWcFD/d MV8+5eey4HvxXzkn7PoMTnT30efydx99Lne19XexCbyPvPpA9OeqsXk8n48PZbJaJBK+XsSLWpFb 4XUlNgX7x5opcptxWeO3YyergrCB9Q2sb4j3CLOs3MjKzazczMrN8ePDDhamggPzqzaK36dWXWXV eqvWW/Vzq6616karrrLqJ1ZdZdVVVmu3WqvVWq3UaqVWK7VaZbtVMlbJWCVjhXQw2ApXxiaG11rl 09i0cHLsvXBwbDpmOe9UYg4+CD+z4pRYgkXL/L+WVUnHrFatdViDtajHn8IbYw1e1zuHpXTHDb7+ GBuxKbg71iyTLb7ejNbwtlib13akw5tk/aZYxtefYAubtoYVPNnIk42yP0js6mOf+tln+BxfIHRO LEAMcbuxTuFN8c6+LrSzKA5vi3f19d7O2ZFKSsLH4t/FPtgXpeHRlDOAcgZQzgC5eC7+vfCZ+N/4 2d/ioOC6+A+9/gg9w5PjB+OQ8P74of5/GHqFZ1Pa2fEjfP0THEkxR4X/ItIfiPR4kR4v0uOprp+c zoif4JgTcVJYHv+p15NxSrgofqrX0/Cz8CWqHBA/w9d9w6vyZ+D6/D2rrsv9VTn6i/K14WyqnBH8 WJZWytJKWVpJHyt308dC2vg4p8hlvv+lItN6ZAe2YBsVZx23HTvU2+fhGnpZJIIbaGYRzSwStVYR 2iJCW0RoC4+38ngrT7fwciUvF/NyMS8X8zLDs2YeLebFFnV1irrqq56SaikZHEZnWfpqpq/m3Sxf xvIdLK7Jq3l9zuJax67w9UpsCnqzvIHlDSxP5jtBB0sbWLhJHttYuYqVq1i5St7+Vr465KuDxXUs rmPxShY3sbiBxQ0sbmDxCtY2sXZV0ItFC1m0MKf4uTr/h+HUfFU3sWgha5pY08Sa41jTwpoW1jSK 41px7BDHDpZFytwojqtY1yKOq8RxFQV+ytJGVm5g5QZWbmDlQaxLsS6Vty7JugWsW8C6BaxrEM81 LFzIwg36yAS9Za7qnuf8Nx/V+m1C/17EylrdeoXXlbpxjI0Hm7+bTj2BxRMd+55x01Ed/jn3ibRf Oz9189NmP92h+psdsd0R261wjRWetsLTjl5hhblRxcvjTHmcab8xwXcmhguMWhV7k03T5OU9/5+O uUbMw3xUU1gi/IJ9C2NLnZV25XQhGxfqHym9YqMe0KJOW+RwqZytlLOV7FvBvhVBTyuNstLdVmqy ylSr3GGVO6yy3SrbrLLNKqt0plKr7LDCVivssMIOK0yywjQdZ5lVPrDKB1YZKgftctAuB+1WLLNi maqOtN0uF+1ykRb7VjFvV4XRbwvOZ835Yjknp4pIj+fI8Bey+4XsfiHSZznXT+DhXH13Hlvn53TS bfd+m+u1t/DmXp5U8KSMJ2VUt4zqlpl7YWyenfd8fKgPJ1zrLfP9Xb325m/otffne+1yvXbF13rt PTx/e7dee/NuvbaMest267VD9drlu/Xaa7/Wa2u/odeW5Xvtm6J7c77X3kXp6/TaMXrtGL12jF47 RuT7ivwgkR8k8oP02sl67Xi9doxeO0YM/0GvHaPXjpGVC2XlQlm5U68do9eOkZ1fy86v9doxeu0Y WbpYr71Z1XwkyhNFeaIoT5S5/npthV47Rq8do4Le0WvH6LVjVNIEvXaMXjtGrx0lw4P02jGyfLcs X6PXNuq10SfKbtdrv6/Xfl+vXZy7XvlX2ft72fs32XtH9q6Wvatl7yPZ+0j2apwlG2RuFsXvlLmP ZG6NzF0tc7UyVytztTJXK3O1MvegzNXKWrWs1cparazVytpNsjZJ1mplrVbWRslarazVytpUWZsq a7WyVitrk2Vtjv6zVcbKZWyDjNXKWJStWtmqla1a2aqVragfTZWtWtmaJ1ujZKtWtqbK1jLZKpet ctkql61y2TpftkbL1mjZGi1bM2VrgWyVy1a5bF0tW+WyVS5b/WWrv2y9JFvlslUuW4/I1iOyVS5b 5bL1sGy9I1uNsrVOttbJ1jrZeli2ErJVLlvlstUgW+WyVS5T5TJVLlOVMjVapsplamz+To5/lKk/ 5n53cGO4ODhUdl6RnVd0imo9abMsJWTpJVl6SWaiynxPZc5VmXN1jNfzfXOOvrRJpjboGnN0jTky 9rrszFdTTTKxKOocIrxRbWxQGxtE+U9qv14Us+q/Xv3X5zvLqyLxuki8zsptrBwcfS4zOGS3ndRs +njZyuncLmpTcJGcLpfTqALnW6XeKsusskw+31Z1DVZaIm/LrbTESkvkK5Orru5ydwAOxEFBb7Hf IearxXx1/lyyRJxniPMMcZ4hzovFdqkKqBbLWvv1Tc4+0Xmyj6uiElHbKkJXitCTIvSkCH3Izgmi sJ1dr3y1B98pEp/ri4H9cxH2CicFext531ex/VBHTlDwtvDNr0btOiNuNmKzEZuNSDsTdWCL+baF zznyj478I7+Tjn7F0b/nd7sRvzfi964F14vatnC1Ixsc2cCSJkctkIeNjlrgqAXOkOud6Xadj1c7 arWjon3NFkdGXSrjyOXx6Ok++8nzOHkeJ7/jdsvCYhYsNipj1LZc5AutUxyOk88XqW4V1a2S1z/k 3rt+Re63SIlgHzNkzZA1Qza//lrrrzVbNNPHOcV02k0xuz7ldaTrjZ7Oq43Oq425qGw0y0azNJhl w5e7eLM0mCWb351t/HJ3JippV44d2KLXbAv/HMXPUZ84ap2jPolHd/Io4esmkWl39A5H73D0J/lr ki+tbOXzEiMbjdzB5zajG41uDGI8PYGnJ7iWTLKp1RXtTmfH4rDNGerLs/h6K7Tmcllr1jqz1uVn rNB7MvnYV5ixIh7dxzoaOc3I6UZuNrLCyI6v/N0p7rvpxYiK/N/ChgUFsejzY12M35yvy10+7Mxp bL2VPjZuvXHrc56/apUKK8zYLcuLeFxhRHsuw8W53649kc/u2lz3v1GNRKP/YHS50VVGp4xOGf2n aLdsZMpaURyqcrZdpsJ+heg9MTeGVcG+RieNnsvDRfp8k1mqWTybxRUsjtZ/K18Z74pR1FEivb/L 8nfNWm3WF8xWkcvyEmsvsXaNGdLWf9+oyPolRrQb0U49SRFcb8+/LXzcGpOtMdkayxxZZu5mR5Y5 sozehtLbUPncVdnTHDmNJe8Hhfr8Dr1jh97RrHc06x3N+vOfg67620d++rEeV6/H1eevJne/Zv2T mVvM3BIUO3pb7sq2p9o7GMfSYm8ch+N9/xQj+rr+/H5BLEwUxNEJnVGIIuyFLihGV3RzltjbmqVq sbvRB+BA9LT3OBiHUNhfdnCb9bVNOl20SvRX+tdE8rXcJ86iT5lFV/T766OZeKn/dbffOwAHopeM Ho4jc9fLKXavZ/d6dq/P7QmPD7roo5+wf43Z0+r4bHUcPbGkmufVwd7sS/F8Pbsa2NWQs+tou/9j 2dEbxyG6vh8kslfYqxfzqokN69iwjg3r2FDPhno2RGs2WmuntdZZuVTketi/91SfB+NY/++N43C8 2Jyi2qN6PZmXJwd7OTbyovK/XKUdb/1Bri+vCB8Livw087XfCbR/1Y+i9aLfT7RZb4P1Nnwt35sc 3RYUsHNrsF+8WxB3/Mv/5WqxpzP0wTiEbb1E63AcKXrRlWJ0hdiXZwPDaXIzjdU/YPUPcr8n38dM b5up2UzNZmo203tmes9MW82UMVMmdw26a5/ebKZPzDTHTHPMdJiZDsvlopH9fzJ6rdFrjY5+19Ly NXWv48f2aKcvYt15fAAOxF/ysNY6Ses05GKyyXybzLcpZ83RjjhWP+6N40AdwTnBVXaMV+Ma3BS+ Ftwejg7+A/+JO3AnUuHLwQZ8jE8csyN8NNiJT/EZPg8fLegVLi84HEfgx/gJjsRROBrH4Fj0xnHo g+NxAk7ESfgpTsYpOBWn4Wc4HWegL87EWfg5zsY5OBfn4Xz8AhegHy7EL3ERrlXB74c1e7wz94eo Rg0WIBHOCw4O9nXe2g+l2B/dcQAOQy8cjiPwY1yAfrgQv8RF6I8BuBiX4DJcjqvCySI+WcQni/hD wc3hm8EtuBW3YShuD6fIwhRZmCILU2RhSnDot7qj1P/uTlLT5HmaPE/L331+eeBqK9iGLLZjRzhb 7mfL/Wy5ny33s4PBQafg+0FnFKIIe6ELitEVe6MbvoOTgyODU3BVOFYcxorDWHEYKw7jxWG8OIwX h/HiMD4YFuwrFiPEYoRYjBCLEWIx4ls87aR3UIFU+BTPnuLZUzybxLNKnlXyrJJnlTyrDP4c7MO7 UbwbxbtRvBvFu1F/rfcLxo4JesSODY6M9fF6Os4Lx8bOD5+KXYABwYGxa8OJsevC4bHrcUM4XPf7 Xfw34QM64O/i/+j1ZruCW1T/Enu9pUFpfDlWqPmVun4qnB3f4P8fB73iTblPcPSMt3jdHJTow4t9 lRKt6Kvokx7fD7bJaImMlshoiYyWyGiJjJbIaImMlshoiYyWyGiJSqlXKfUqpV6l1KuUepVSv+e7 uQc9Zb/nt7pv81XhzZRyM6XcHPybPdW1uA7X4wb8Fr+Lfm+Bf8cQ3Iib7ML2pKrbw3Mp6lyKOpei zqWocymqmKKKKaqYooopqpiiiimqmKKKKaqYoqLnLzepwSY12KQGm9RgkxpsUoNNarBJDTapwSY1 2ER9Pamv5//qGfUpZ70N+Bjf7r7Jb1P3dOqeTt3TqXs6dU+n7DLKLqPsMsouo+wyPTupZyf17KSe ndSzk3p2Us9O6tlJPTupZyf17KSendSzk3p2Us9O6tlJPTupZyf17KSendSzk3p2Us9O6tlJPTup Zyf17KSendSzk3p2Us9O6tlJPTupZyf17KSendSzk3p2Us9O6tnJgv5Bj4IBuBiX4FL8te6F+H5Y 8Q13j61wrqhwrqhwrqhwrqgoWBgUF3yERVgcvUfCjvxYVw59vDqfqeaSmHOWip6uoq9S0VflKvo3 riCuwrXh07tXduy3uXf+nqu6r1Pd56ru66K/N8dvcuU+QyVXBt3ic8L744vDqSq9RKUXq/SNKr04 vspeLOV6d9dntb6fe/JctM/drJo/CDqFfx90RiGKsBe6oBhdsTe64TsoCc/c470STw4nBqfgW1Vw cEFwNa7BTcFRwc36xi24FbdhKG53hvsP/CfuwJ0oC08LRuBe3If78QAexEN4GI9gVHjOf/MZ8lkq c5bKnKUyZ6nM6E6z44MKLAhrVGaNyqxRmTUqs0Zl1qjMGpVZozJrVGaNyqxRmTUqsyZIOZ9swMf4 JDgo2KJXbkXUM7PYjh3BAcFOfIrP8HnuE5NVrh+qXD9UuX6ocv1Q5fqhyvVDleuHKtcPVa4fqlw/ VBV8N5xUsA/2xX4oxf7ojgNwIHrge+HUgu/jIPwAP8SP0BMH4xAcisPQP6wsGICLcQkuxUDfvwy/ wq9xOa4IBhVciX8Khhb8c/BPBf8S9C+4Kriq4A5KvxN34W7cg+Eowwjci/twPx7Aw+YarYofw+N4 AmPwJJ7C0646jwn/IdYHJ7vyPN3rWV7PC86MnR8cGrsAA8J/VSXLVcny2LXBqbHrgh/ErscN+K3v PRjOiz0UzrOjvsyOekC8wvV3ZXhVfL2r5ZSz2obcXURfiG+y32127mtxftwcZguiJyl3UwndVEI3 ldBNJXRTCd1UQjeV0E0ldFMJ3VSCs9wX0d1EZzvHzXaOm+0cN9s5brZz3GwVUqFCKlRIhQqpUCEV KmSUChn1re5WvvuTmG4PSlVCqUooVQmlKqFUJXRXCd1VQneV0F0ldFcJ3VVCd5XQXSV0Vwndg1Ff bApGhxv+myc0bQiewViMwx/wHJ7HeLyAF/ESJuBlvBIOVkGDVdBgFTRYBQ0OJvn+ZEzBm5iKt/A2 3sG7mIY/ohzvYXr4jKp7Jpjh65mYhUrMxvv4AHMxD/NRhQ9RjRosCIeo1iGqdYhqHaJah6jWIap1 iGodolqHqNYhqnWIah0SrDRmFZK+Xu21DmuwFvXhnOBPaMA6NGJ9dPcqfXInPsVn+DzorHKHq9zh Kne4yh2ucoer3OEqd7jKHa5yh6vc4Sp3uModrHIHq9zBKnewyh2scger3MEqd7DKHaxyB6vcYSp3 qModqnKHqtyhKneoyh2qcoeq3KEqd6jKHapyy1RumcotU7llKrdM5Q5TucNU7jCVO0zlDiv4B7Ze EZyWf55Af9XbV/X2zd/XuL7gWsq/xeutuA1DMQy34z9xB7vuxF24G/dgOMowAvfiPtyPB/Bg7r2Q wwoe8ToSo/AoRocjVf1IVT9S1Y9U9SNV/UhVP1LVj8zdnf2PKMd7mI4KzMBMzEIlZufu4t7qPNzq PNzqPNzqPNzqPNxaUKWD7OHp6QULjfkIi7A4rNdhztJhzsp3mLPyHaaHzrK3zjJSZxmpsxTrJiN1 k2t1k2t1k9N0k3N1k9HxmeGC+CxUhsXx973OCVPxD3SRueHzuswLOsyn8Y9zXeYiXWZcPPo9SUs4 Lb4593THsrCfqu2navup2n6qtp+q7adq+6nafqq2n6rtp1rnqdZ5qnWeap2nWuep1nkqb7rKm67y pqu86SpvuiqqUEUV3/qJHdGTOr7h/ifxRTxZoke6Mowv00ud8+K1vrfSbmIVT24Nyr7YGYzAvbgP 9+MBPIiH8DAewegwwZvLeXM5by7nzeW8uZw3l+s9Cb0nofck9J6E3pPQexJ6T0LvSeg9Cb0nofck 9J6E3pMQgQEiMEAEBojAABEYoPck9J6E3pPQexJ6T0LvSeg9Cb0nofck9J6E3pPQexJ6T0LUrhe1 6/WehN6T0HsSek9C70noPQm9J6H3JPSehN6T0HsSek9C70noPdF94gaK9kDRHijaA0V7oGgPFO2B oj1QtAeK9kDRHijaA/WehN6TEPWBek9C70noPQm9JyELD8rC/6HuO8CqOra218xselOaSBMBEQt6 wIaK3aixizXGAiIIioAUW9QosWFi9MZYkyixYI0m9hJbNCpGjwVjbEcNKKhgQQVF9Jzv3XOOXtM+ k9x7v/v/nmfWnD176pq11rzvFjYZ2IUM7EIGdiEDu5ABzJ8DzJ8DzK/+bfhjwPEngeNPAsefBI4/ CRx/kp4arv3euyxJb9hOBsN2RkjMsB07GgF8qMWufoldnYlddcGurseu9gFW3I+dnYSd/YAeAK34 Ic75gen5gen5gen5gen5gev4gen5gen5gen5AaH5ges1wklYhJOwCCdhEU7CIpyERTgJi3ASFuEk LMJJWISTsAgnYRHYXiDYXuBfer/2UOxwNFIMUizsMw5pONIIpHikkUgJSIlISUijkNRncSmon2qY AbY3A2xvBtjeDLC9GTQOsx5vqAfGVw+Mrx4YXz0wvnpgfP5gfP5gfP5gfP5gfP5gfP5gfP5gfP5g fP5gfP7yfXl//D62B7DOB7DOB7DOB7DOB2B9oWB9oX/v/beG92EB78MC3gfrKwTrKwTrKwTrKwTr KwTrKwTrKwTrKwTrKwTrKwTrK4S1jIK1TIO1TIO1TIO1TIO1TKOn5AtraQpraQpraQpraQpraco4 2TCBpCCZIZkjWSBZIlkhWSPZIAELgYXZgoXZgoXZgoXZgoXZgoXpwMJ0YGE6sDAdWJgOLEwHFqYD C9OBhenAwnRgYTqwMB1YmA4sTAcWpgML04GF6cDCdGBhOrAwHViYDixMBxamAwvTgYXpwMLU6J+J 6J+J6J+J6J+J6J+J6J+JyL8QkX8hIv9CRP6FiPwLf4eF+YKF1QYL80X0LwAL80X0LwALiwML6wwW 1pl3UX+imPxwEhTgJFB/OvojMLFoMLFoMLFonAoFPAF9raOqfCNZ8J1Uhe9COmRI44cN2/j3SEcN X/IfDO34VWrKS8DeSoFJnyC9MEwUzlRZ1IU3Bht2ihCkekih8Mpvwc72kQanyTF46W5xGqfGWfm8 RgsW5wDPLMfpch1MbqaJyVmbnttY45QpFrdxwsg3bxjug0sphixg2Sxg2Sxg2Sxg2Sxg2Sxg2Sxg 2Sxg2Sxg2Sxg2SywuvXAp1rgUy1OpwycThk4nTJwOmXgdMrA6ZSB0ykDp1MGTqcMnE4ZYFcHED+3 In5uBRbSAgtpgYW0wEJaYCEtsJAWWEgLLKQFFtICC2mBhbTAQlpgIS2wkBZYSAsspAUW0gILaYGF tMBCWmAhLXCQFjhICxykBQ7SAgdpgYO0wEFa4CAtcJAWOEgLHJQDHJQDHJQDHJQDHJQDzJIDzJID zJIDzJIDzJIDzJIDzJIDzJIDzJIDzJIDzJIDzJIDbJINbJINbJINbJINbJINbJINbJINbJINvJAB vJABrJABjPAlMIEWmECL8z8cO1KE874UZ/3X2IUi4/tPcF2q/048MTiLp3qdKNPniGf6daJcf0E8 1+8SLww2Qo9yg75IMdN/p5gbnBULvU6x1OcoVvp1irX+gmKj36XYGmwUO5Tb64tIQbT+GpG6QPwI zqL+la0OiGDrEcHWI4KtRwRbjwi2Hp6thWdr4dlaeLYWnq39f/7dUurvxByBZx8FhjuGlI10HOkH QxG8chW8chU8UAcP1MEDdXylIRfelgXPugXPugvPuit/CvWgYbU4BQ84bdDBa7KIY2ey4BezUbab 6ok9FCX2k784QO6oe0J8Ry7iEFUXWuqEdp3kc5Oz1ErkID9HIeijSH1SSpYiF6V5FAR/6ySfk6o/ Q3UbJ6bxeWkIRjpo2IX6u+SYX+PeJBIYLxBlOWpNMkfMtEbMtEbMtEbMtEbMtGZxaKtgbG/saph8 nw7sB+MZS7yFisPy1OezOKVvqT3he6GhGKPkIYrcplby+axaNwTjqX/5Mx+zU9+9I4xvnFTjh/oc Xv6uTz/DGZEKPRw0aJVm8ilvP8NZXF1B7b3AsAcMJbjKxVU82h0wlOHqLDkCDYQADYQADYQADYQA DYQADYQADYQADYQADYQADYQADYSI3lRR9DccFYOQ4qGxPYbz6OkaejqNdan97kas2oN17TX8LIDm cfci7u4Bgr6HeaZSLexVRdwtVvcI83QmR3aavNgZqmb6f/Ro0R+1jO9tqCXf2xAvf6b0BzEa2HQB 1RALkXYbbmMHfOGlm5XGVFNpQtWwsnfJHi3sMU5daD4V2tpruIeRfpAj2WGEQoygle9mH4jIqr6b PRJ5KkY5bbgC3FQEzPRc7ut5MkMrazJHC7W2+t7GyqhZGTWLUaMEGsmDpyI+4PQuVX9bRY4IrgUs VoQdMoNXX0B/j+HZJWhRrPapRnr02Rtr6YdaqdCiFqVqbfVJsMMv+hyA9hFII4nJvtU3cp1G+Rn0 dxZ6zMEu/ogT5TzZyH5tTP3morYDZlGOFrloUYQWxWhhbnpqaCZjjD1qF6N2qXwbs/oW5mS5R36Y kYVQ30ZgHKsULW0wVjlaq+ygGDaXB1x4A+kmUhkFgEEHgEEHgEEHgEEHoOcIyagGwKYHUm8RgTwS +Uig02T0PNpwSEzATiyAVS2Ed2ih8VPwXlW3Zw2b5WjnDD/Bvp2BXJ9jj0OwxyHy7R7qX2EIQm9B mKuzSXuIoLBAVcc/Yc/Und6P8fdjZQXybzZEIFf/bkMqxjuFXk4jqpwxPMJYxRjrqaoX2Uor7aM/ xlB/r3eQfJ+vn0hDhMilSsazAPZSAO2qP0N523AIIxt1rkMta5SUYB4vfzPL9Dt+IgV7OAa+cgv7 dRv6Mze967UAbRAHsIJ8pNsGHVUAGi4AGi4AGlYRboFcb3/MaRBSGlag1s7DiBId4N5tRA/5vNdQ BHv1lruaI98j21++Y1snUjDbNKwiFzrNM9zBKsqMqzA8wYzK0UO2+oxMjl2MsYsxdvErCzX9jDR6 MUMvQRjfGr0USB5sRCjqzK9jDur/Bw6ldhSNFIM0Hjj6PaQJSBORJqF1b0MV9FoDPm5v+v1We/n7 rfGGhdDSNmjpMOxiN+wiDHbRTqyDveRi9DzMX46I+FsAnd8y6GATjWATjZRmhguqzqWeSuXbxY37 Zib1lS93pRiyNzTVD2eGsVZlU63KGLsYNUNk/+oemIt4/Wrx1HAfZ7lOsTDcx1mtUwL1xzBuvP46 SktRUqoEGmqj13j9T6IUGi1H6+fo6YUhVzEzlCnWhnLFxlCMmrmoGSzbbsTdCyi5gN5KZFuteAZf U9u+wK4Z0MaKLGRbW0OOYo880OBNjqh5DKOUA3UUY2ZFogx5OUZ9bniGlmfQshSjlgNtFGPGRYol cmvMwsbwDD2dQU+Yr/5naDseOMXYSwl6KUcvenXOcmxj6xK0LkdrvZy7cQ5m5IqW8ZhDrngCnT1F Xgb9AY2YVn5BvIBf6Q030VMZ5pKrmFNl9JaL3koVIEWTRrB+slLsDDfRcxnmNFs9OfS56FHVQYHQ I+5ayPUXKHb4HmggWWOT3JFnspZxV6xkLXVnzkK7v9ovnH+mfULrN+yPrCv3BXXfsB9U4V/dB7L9 q/qHFf+b9Q4b/wN9yzu/q2eyV5zJUnFBr25krbgjeaCNJ9p74TuQlFIF93zx3R+pGu4F4F51xGNF cUUfHrjrg7yaqgPFGVcuWG8l1HGXd4tlX94or4LvVfHdX9YuVvshc1nbTY5aImv4ylFKyBHzMsPd IsUVJZWQ3Mgb83NAzSL06Y35oV+kKrj2wf2qSL4o90edaigLwPfqGMMevRRgruoKzZTKGN2dhKkX tXUB5q+u0Ezxwz1/3DO2NqMKmIM1Wt+VK3VDv+6o5QHteaLcOL41ergrNeCL+/4oq4b7AShXx8Yq 0L8L7roaHiiV1LXC4uQcsJeeGNcLZd6oUwVlPqhTVdUB6si5oE4A6lRHpFP3yUHq1Y2cTftUjnk4 Yx72mIeD1K0vro37VI45OGMO9uquSO2ZmVo9/sXs1XUbWzx+NWuHv2sT8Npz+PYru4C3VyG7v2ob aOUHL/0D+8BdTk7/LhtBby4o+Zt2gta2VPFftRX04qqu6N9jL9iJlXIf/5bNyBXZ/VW7wZhPgQhL 9WcQC4MQcRREtWDw6H2Iah7g0YcQfRqDR5cjqlUAjz6D2BiEaKQgqgWDR+9DVPMAjz6EyNQYPLoc UQ0+qL8IjbhDI3bQiJ3ipj8Gjbgo7vp8zMofWlGgFa54o14V1PNBnapIvqjnh3r+qFcN9QJQrzqs xgpsxQE8ox1YpTPYpIqMnYE0vYEqQtRnMkBclYnTQLCoICJqQi2oJnhbK9JQJ+pJwdSH+qL0HeCh MIqlj6gjfUwbKJE20g582037aBEdwOcLOkTnaSldAKLeTAXMhQ4wD+ZB95k3C6IHrDPrwoh1Y70Y Z/3ZQGbJBrOhzJbF4ePI4lkCc2JpbBFzZUvwacI+x6cpW4pPGFvL1rFm7AA7xVpwDQ9h3Xh93oiF 8ya8CevDm/MWrC9vw9uyd3g73o69yzvwTmwA78K7sAjeg/dkkbwP78eG8nf5u2wYH8wHs1g+lEez OD6MD2MjeBxPYPE8mY9myXwsn8HG8Aw+m83gc/gC9hFfxBezT/lK/g1bwLfw79lKfpSfZzv4BZ7H jvJbvJDl8Pv8AfuJP+RP2EVexsvZNW4QxHIFF4LdEBbCjuULB+HI7gpn4cyKhatwZw9FFVGFPRFV hS97KvxFNfZMVBc12HNRWwQxg6gr6nImgkUI56K+aMgV0UQ05RaimWjOrURL0ZLbiNaiNbcVbUVb bie6iG7cXvQS/Tg4rojiwDtiJPcRyWIM9xUTxAQeKCaJSbyGWCAW8ppio9jIa4utYisPEjvEDl5H 7BKHeF2hFT/xJiJXFPK2olQYeFfFTLHn/RRnJZAPUZopzfgYYrAVa9bE/DiJqHHJ4M3DkqNHUEJ8 ZGoCLcF5yXqGt/YB2yGDgSqCgZuTB1UFV68Ju6oPe2pD3ag3+nib3qVIGmaqZwf+7km+5ES1YHkN qCm1pe6wQAarG0BDYH8K2hjr2oPne5EfWHFtjNMQ1vkW9YCtctjtQIqiOLABHt6tiw+F9Qrv5EPD ZTsn+TNh3uRG/uQCi29EzaglkH449SNB1akzDQIDMNZ1Rg/WVAX+UY1cqQ7Vo1BqDs9oD794BzMJ pC40GFxhhKnnimRDPuQO/lgJ7L0xPKk1daBe1B+nTA3qShHwoXgaGRWSEsXnSrlEypVSbpRyp5Tf RUXGp/ITUp6T8oqUN6QskvJxVGRKNH+uSsGltJTSXkpnKd2jokYmCR8pA6SsLWWIlKFSNh8aHzdM tJWyo5TdhyYkjhR9pBwg5RApY6VMkDI1JjkySoyXcqqUH0u5SMrlUm5AZ5Fiu5TfSvldfELaSHFM Sq2U56S8JOV1KfPjE6PiRZGUD6V8pkqFcDNZMZfSVkpHKd2k9JbSPxGZUlNKjZQNpQyTsrWUHRKT hyYoXaXsJWX/JLU8QsoYKeOlTJZyrJSTUqBzZaqUs6T8RMpFUi6VMislLiFG2SDlZil3SrlPysNS Hk8ZGZWknJbyqpRFUj5TpZmllK4paUNSzPylrCmlRsqGUoZJ2TolLSnFrIOUXaXsJWV/KSOkjEnF zM3ipUyWcqyUk6ScKuUsuJOAX1aCR/ydbxyebfEXcgZfeLNU/oT0/I20eaMUiBlW8Om/840hgv1a VvgTksvVc/SkXjEpSUrLPyEd/oR0/420/xOyopyXkDl7Tarzfb3M9o3SDLHPGdHUaBH/2pWr6erP jMsQmd8s7d4gfRH9u+KMGYTonECjaRJNB65ZACSTBYyzHfjmCGmBbK5SPt2jUtIzc2YPlOLNAlgd 1pA1Z+1YV+O+sgqm3N2U+5jyhrB+NQ8zXnMf4zWfa7o+bcyFu7FcmOqL7qby8aZ8gSnXGnNgUmNu uq+sM+WXjLlZfWNusVLuKrO6Yry2bmjKWxrHse5oup5lyp8bc9tAo6/ZXjHmDubGcodYU37clJ8z 5aZxHUoxnjVSFJsvPWAI+xTSEiv9TPUBVoIre1LEW6K96CDeVv2DO3JHGJ8zd5UtUFfYq3XV331B PgjJ0eQ7Xrhvyx6wB7gsQV+MPWPPiDMDM5DgZtyMFG7DbciMV+AVyJy7cBey4O7cnSy5L/clKx7I A8lavI2RbdBXJawuXZ02c6D3mTvzoskskAXSVODUATQN2HQkzWSJLJFmsVEslT5ks9gsmgOsupjm Ao92p094Kk+jLXwMkNE2Pp6Pp+18Ip9EO/hUPpV28Rl8Bu3mn/JPaQ9fyBfSt0CTP9FeYYc1FgPb 1adHQHJt6TFmU5uc+DLRWXQTMWKYGC5GiBSRJsaIcWKimCkyxCzxofhIzBZfqFrgS/lSBKlOohM0 1VV0JS6GimgSIlbEkRmQXzJZiFSRSpZitBgNNjBWjMXKgQXJBljwA7IVn4nPoFkhY8c/deyt7gJv ytW9seDBPBh705DDbnhj3hh3wngYdN2Wt4WuO/KO0HV36MEctd2gXw1vwEPRug1/m3fjzXgnlFv9 +V54Ok/HqPP4PNgBJ5WReStVFB+lquKr+Cn+SjUlAByMY827wWlIzt7ttdlXkZYTr9ZQVM5rrOH5 Wg2f1+5x9X+UUJsUlSsyJVAJlHahjuusuCiuSiXFTamsuCseiqfi9dq4nFRu7ag4ASGbKxaKpWKl WCs2iq1ip9grDkoFpSLqKND0+5iC2oYDPzcnW6WV0goewIFb3USWWCM2iE3isPheHBFHxTGRLY6L H8QJcVIUibvinrgvHohi8VA8Eo+F6jvmYpVYhR5Xi9WYy3qxHvsONI91qGMoKnZ/1fsq1FqPu7vF HvGt2Cv2if3igDgovhOHUC9P3BA3Rb4oELfEbXEH7dTes0QWel8j1qD3DWIDet8kNqH3w+Ikei8S JbL3Our/lv1Or7+zDqmzXLQjU7vfGfkP1qrq+qRs50v2rDfry95h/VgfFsvO8jQ+ic/k88USsVZs VmMO6856YYOHsWFkxk6z07ClVJ4KW5rIJ8L7VT+0kn5oLRaJRfABVYO24hvxDU4CzkrpKX1AU2ka zoAZNJMyaBZ9CM47GyfCHJpL/6BPaB59SvNxPiwE710MrvMZfQ7uu5SWUSZ9SctpBa2kVTg7VtMa WkvraD3Y8lc4STbR1/QNmPEW2krbcK7soJ20C/x5D31Le3HK7AeHPkjfgUUfpu9x5hylY5RNx+kH OkEncQKdotN0hs5SDp2jH3Ee/QSmfZEu0WW6QjqcTtfoOv1MuZRHN8DA86mAbtFtukOFVER3cXLd pwdUTA/pEaJMCc6xJ1hrGT2jcnpOL0hPBjUwgy2H8568F+8NxtyX9+Pv8P5gzQP4QD4IvDmCR/Ih PErlzjwG3DkWzHk4H8Hj+UiewBN5Eh8FVnyRX+KX+RWu41f5NX6d/8xzeR6/wW/yfF4Avnyb3+GF vEhY87v8nrBRuTMvBnd+xB/zEl7Kn/Cn4NDPeDl/zl9wvcqkBVOZtFCEmTAHm7YUVqKHCBc9wXYH iIEiQkSKkWKUmCqmielihpgnFovPxdfY181iCxjuTjBbrTglTosz4qzIEefEj+K8+ElpqoTBalyM 8V9G8vdlZM4UHRFRz4FRd6Xz4NLv0gUxSAymSzJOXBFJIol08OopdFV8Ij6hXGlNeTKW3pC+eVNa Vj7sci0VSA+9JT30ttgudtAd6adFSmOlCXaCs33Yw/+M3f3S6v5TNqf7t1jdb+3upeX9vu390/pU +/unBWZKG/y/scLFqv0wzlwQddyBGZxlBPKTyCGQDWLRVEtGo3rqcy6qz0YASzQAlhhPoWwC0FFb tph9QYPYNnaKongy4tMknsEX06fyZF8lbIUjZanPjOgr4Spq0kZRW9SlQyIYaOGotLrLOM+a4OR1 xAnoTQHAD/Uxp1X4qBJngvy+UV7tNV3txZUOH8R6VovVwtzrsDrYiFAWCmtsz9pjqZ1YJ1KAcRYB mRvR3EZ8gArYQBZjKtn+WsmvEURViSAG8OESQYTzcHhYX94XZ39/3h93BvKBOPujeTTO/hF8BM7+ UXyURBC+6ptYf4EgesAq3kFfQ7HfSSp2/AtYQh3ZQo5sKUe2kiNby5Ft5Mi2cmTEf3hYe5bDzrEf 2Xn2E7vALrJL7DK7wnTsKrvGrrOfWS7LYzfYTZbPCtgtdpvdYYWsSBGKIkrFE/FUlIlnolw8Fy+E Xhj+lTIFyldU3ugO6+ISnVZQmQW4hQD38MZtFaOawd6wSthbf7LAPgwkS2lpVkCt8TgPVdRqw9LY aCDmiWwiTtAMlkEO7EP2EVVgc9lcclSft5ITLHAbrPcAOwh7PsKOUiV2gp2gyhK7uMsz2FOe4BqJ YNpKBNMO82uCGf4NnZn85r+4MlhOTYkZ+sNr3sQATyAKXkDEu4HY9gBx7Dnmbgke6Ix5+4AJ1mYh 8J7mrC3ryGpiHYFYVZDM+8On1HwgayzzQayJzAezpjKPACtU80jWTOZDWHOZR7EWMh/6Km8l8xjW VuZxrJ3M4+Gnap7IasATHeDNHFe1SX3KXkf6Zl3IQUwDOZgFQ0awEMhIVg9yCEO0wFgNIIeCp3IW zRpBxrDWkHGsDeQI9hZkPKICxygdIJMYeAG4UEfIZNYZcgk4MGefsS6Qn4NRaSiUWlIH6k79KIJi KYnG0mScbB/Dx5bgxMrC6bQZp9E+nDzH2TqsYAlmvV7mA9kGmQ9iX8l8MNso8wj2jcwj2SaZD2Ff yzyKbZb5ULZF5tFsq8xj2FKpi2VSC5lSC19KLSyXWlgltbBCamGl1EKW1MJqqYU1Ugtr1bXJGBco 867ACvYUSCEUJp8N2cOyXKWuK0kduZnqK6zyq2+xqiblEzBbtkDqSkqVGbAKsH1iLjg/mLRxLi1X 4J43ahezUlaOIGDObXlF7so9uB+vIfnyv5P/IpJLjvZPxmepsqBXHOp/4UGvGJTaxyAe/yrmqyeA +ozGVd7FlRJBL5/cken516unYR5tkTsbiz3CNOkeoeZWNad3mP7EjlnwzHSPGiiqxhkLttFYmZvV shfc3Yw0kebWtcyZwtIbcaZk9tT00NR+rcRzufdkT2yS+ulGQyiFEimeoikVqbn60VR9rTPF+Vm+ V97CjeMP9/7oaYvKHUpS0pas7pyZ7nJNky4OIwVlCgQrXqH9/srzr80Ob9fmyeWRHeyCV2rsXk2V mWFSUz6UkxS9FXMn3r9VsIvGSb2wdLLtG52SGp2c4NMmMik62FnjqBZbONm0TUseEpkwOi4+PjrY Ab2h1NrJvFds5JjU6GAvjYdaYOPkbCzwaROdnBoXExcVmRqXmBBcReOl3hZOrqbbveJGYpTIkUlx CcN82rTSeFey09QLDtHU18h//SvZBauX9ULqNWjcoHF/Tc/XJtu7Z3AljYtxfPs+0clxPeOGJdT2 eTshqk5wLU0N40C+L2/IoXx6vhyrZ3Ty6Lio6BR10HTm+7pWmBmJdOZAKLfm6YzR2uObV5446bPJ emLGhhlpD7Z2Lb520GH/sMi9K4Z6XtpTdrze+qmajH6TPro8QtdwqcP+M0VjH47JmpQYtn/eJrvd sY/jPz2+NzxofYdmJdt/HDjYgy97VneE98onK5ZkuR/jP7/fOTzPPqKopeekXXZXWxzdem3G3sHj hwfXEYunOK1p76MNTrHrG3RybP168x0XO+66Glt3XX7ed7M+qnnow6ozYvZ+0K9vYtr+sHUBMwYe r+AStmzqnV4HrRMO67/vqNtlUXGh74TLzauf8R5btCw4uzjft/Llw1vat1niPjjTe+6NQSX3JhRP XD+EzSnpYnP1tG+fNfNPbpw5euO93XaPbnS5mFkem7nRuemWGQf3cAHDXzHlsmbKBU19c0tYrJmZ BYPDaQI0/i+vNWy6W2xqalKTunUTo1KS6oyG3lOg9zpRiSOl7Xg5MWZQLDXmyDgjTSu1rIrSRBOq aZhZPzNkusbUPCo5/het6xpt5XVTadOqDmpJS/WqpthqrF/OQlhq7NVCB3UsBR5gjhniuqICy1xZ WVPppX0LJ9tePVvB0EKDgoMa1PuVV4gpU6jjiLI7/b5r6xmcMW5xrQX70zew856dT349q1/CNcsa KwYdOz7PqUAJt7vfvnpdCv36Rva8rkvO+Q5xedKiUdVuScGTiz8MnbHl1q2FpD/Ve0FX/7Nrq3cd v3FHZKtHNbUF2RcH6fbUmtZ82xfbLv7c17Bv6/eTSk7ZLn2wUF8rp2m4h0do9SctOsKHDZp0XmDy Y7vbtR6cu1BjpluImdWgJaNn/tqP/yOe8Vt31IS+7o59/+SgdTVBxkED3jSoei86+Y0uubl7YAdd Tuz4qW5tY9IGTjq8c1lUgKFZm88nVAytUK13ysW06nEvuu7yGZBjXZbpUfNu7z5VIy94X77xbb0R R+/rVjSK/thjnu32nt4DJsQ0GGw26y396K7Xek5ePsXni40zByy3fHJTU3bPt1Hn1tbaa0eqHD7f +/aUFtvCV9Rex8Y/XL5udgP9svyBw82WNRuRt3/BAf2JiLKWBRaZbQun9EhYVfPh9lkVAu/OuWKe Ob37kvc6WtppvI5XWDriye1+G5W1LRdvDrw1x3VDWF7PxE45Db7YljjUa8uC2nuaFYwrHDm+zDU/ 4KtN9xf33NGy9vyd49bpz4Wvr5E6qXVRY+/lw13z39njH3uBJrepMGPyCJNLHtdMOfo3XdL2lUty DWnqGZ2xtqamJjAzINN/uu8fOWNqSkpQVKR0P1fpfmoX/4sHmh/4Ux5Y/9ceqO7yjLFJl7qGM593 r4/LTtccfrGr8oK9/6BDe0+ePPLY/oKhrMuBekM0Fb8vSfU498nVwZ/7OH0z4a193U9+UDC50ger q88b5tSu/PjORa3Eic96vGv24ftrEh95dPfwr/Mwbna875M9x13n37VNPRA75mLh4iEzDqbMfZqR Ot5v/YpF7y385smcGqO61Enz6NDq0oNtdj69zo/JXJgeFffC6tSsB2l7rD67WFaxd8CSyJB94/nX 703ft/zQh761x55pMPrbT1IGlO3K7+xi7Xfixtlz9eu83dIlzCFivP+RVTH3F5xKKmxe8Nhu0pUz E1aMHhV38PNu7TUNqn6zfJP7kLBaFz9eV9PivQtuWwa8l/vFqkR9WMZXmnTFESHgmTEEONBB+jAs bGbFM81Lo4qutXxdYwoiQNJL37Zx8m2TmDQuOW5YbKpPYFQNn+DGjRv5dImLSk5MSYxJ9WmTmJxU J9hb42ms7PLLO4nJxrO6qqaKcZvc/nk/PDEx1adVWmpsYnJc6jg1PDRupAkO1mgamcJDiCY4pF6w 6fK/MKM3HuV878Gk/KYPu3oELls4dpDmzvK1s6sNfqqf33nFDv0Xy32aT+ix/LPlcyJCRpxpPXTc vQ2js3tdelj4+XTPOcumxmz5fsT4IX7nvcKuOrBPbi04vD8oZsmS2IDFp5vU3m+7rV/AwXYF1s1D F9ReG9h4TdHbH7TOm+qwZ0l878gN6RO+jAga0/n24q1Dmy7p7hls6e+8bG3BP2q55TdbFOUc0c8s eplXo/AZT1bf/5Qf8cjZ3/utLRmT9zcp6vVp140vVo8fmdp1k9uJBVaBVanv3Ii4Rns6OVqE9TG8 W74yxtoy6+yUPn3vb286yHXKGOVS6b6Nk+frvz75/vnV7skDwo5/+8Byha9mi/m07C0+Y5ymXTPF jTWaKas0U5arfsmUKUs0UxZOrvDu6aT7cclL/XpMct7c5WPDD18m/9/vX/obbFxGhfm3bA7MfrTQ rcHdncz/wpiKjwZEhCxbavNDc7N/zJyT3SS/6sMHfefV3pbZ/tiQ+89/OtG0af+1DXvF6f1Htsg+ se6q2QRd8OxmyyokDd+jd+zmFnfg+ek2eRX7+3S7M+S9TesqH6vVqFrQvugvHWdVc4ha8aSXZ1nV 7PMuj8I3JLQJsXiRXunpzWHxdj1K9xaHH91bcFjz3CfYaqbX/BruXX704quKJ18XW999/I3uWN97 0W8fDe+1fasIdDTMPf/Acs6knQu/X9+o9o3xN9aMyRudSaeHtzh4tuGs660c1zQY7jH8coOfz3kq N9a8pRzrXy80oYun3ZAd1ss/yvmxV4t2Jz17ZyVddmwyY17astVnMxEVDgEcbDIBg+E2i7sdIK/1 FS8d5l/GVN/9kiR4/bdCgqYh8EL94Eb16wfXVwE8QnxIw5chYUrWLyGDk6aikW5Y941MiQUUSMU4 FeQRArJhER49dGRiwtCXM7P+o5n90TJDMOhvlumnqWpchvvrd4ZGS/ChopHukhT4/DaS2KmRxFJG kkMnfGZ/e83QvPu98d+d869WOlpb1XCyZp+uxz/fkb65wbggOrzG8seo7B2rSm8fPHj+m48WLLd4 5rA9PXxJYfqRvRW+X3Pg3oipH/f02NP92VCWcdD1XHostRzbtsQxtGt5VI/rz5rtutnom2tRFn5N R7Ws3/7xiI3tSqqnePv+0Lqyd4/t4UtyVpx2OlK5xSjzkQ/nV207uPXdA9mLh/rsPFj/+fK2+e9t 9qq7M+vq4y+vfVbVQd8vuFXv0Emb+hXcKHpnXLX1T2rWrdgidGzz1u+vjr0xyTe2Un7HTw6PbRve /stuUzPmfXZg2Ht3rMqni4mli0eF1Vods+jEtaDcWtzdoX6H6JIwx03FMzy9AsITT8D2xIp0VhP6 CPg9HC7+/wgvjuZWJgLugvjChSBFUlQve8VVca72tFangceSe311szSzZiXX8oNlPadoKr9q4swV W29r6klpoOttqJXGRgIfyTvaaRxeASwzjUD2ml/KMBaVd/2R2c6v79jY1D+THtw8Y8hbP1quLouM PlZHPAvt0OrUtofVP8jJ+75PzzXbKmtP5BdnlvXZ3uHT9v4311a5Mv5cqet4x8uP5noUWQ7cMm3u ro/67fE8MT9n/qf1Hv/jqmHmZ4M6vd29cUATH49ejZ5PHOAy79AVz48fRIaH3bS4G3N/XNEcbd+o 6Plub2eOvxa941rARv0xx+1Hlp84MvjDpEfHL69PT7C4Ev0/k9y54lvbIU6nGR/V1mRWbTyovXxD mvzS9e0c2dOFd2wwmynHuljYYvGBNQZ2uxSvGyw7lSQksz689+nHKsFdcTY85h8nH5zU4ccSxRpz /Py1lTcf1k6sUP+9JW9pP5txxMY4LUF+gyZWY2BRJg0pxrgS3eadBg+3pGKMUAyVIgNR9lmaGJuY gXpL5sC2EZBrCuIalNDEH1B5ZhzyBJtEZxunWayLWfTp4P17F1ZP7b1mM1e++3Bsm17sh41FX1ev 6cjaemujUjX3iRNLvSfGKQm//PlVee7WL3ll696/W2Jz/MiByBj71ZuLjdWWJTUmVi5M+pLXMfVC 3t3j8y8tCRQsS9xV0JW6cJpY5/LYxgsuaU9vh81zOPXnTpmKnosBw9NrtdVTBa9GyC5+4c99suPO omvBM3NOJZ+amTVrUpyPr+AL/cvR0XHxQYuLdZfubnHl7ZEULTvNcWvWsgLRF75vMv/Gbsruf6sZ aG7RfczNU3RKwIwNXzKWXL/HWZheMq+8R7Y1e/qr5/GuZx48K+S9mMwwudpwRh/3FuG9my+8+3hf 8d3KhMR35s62hyFNoibGScAQ6cPouyAKg3c3s1eWBp/1fyftJ8kmt3jO6vNT/uIo+VaCRJVZGhca NM5rwFqKLCxZMhDlH2ZjwRvS8XMxcDJwWGC3wKbNCqnjlwszB9zzK8jOBInqFxTlp5QmlxTrgzIA KP0D074RuEPoj9QTdTZwNLCH90SZ2oyh5paXl2MzN7UI08ASbH1Ci5vvp1rMjpkhEhuSl3mf6cTz zb8vH/Jdq7+6PoT3ltG2H1nPeH8rSpXbLc2o2jK1rivmk/OR5tmptR0BgTVNIl+bi68v2hdziqng nFqO+J4gkaWdB7Y/WXhmYenciYW20gfCGMK2/mhRuxVn/PuaalXcrFvLfn/55Ci1JtRtrcediRbC EZyeHz8btsvvYemLFkplfskdeGEhT9fMvTcPrrjAIaqquHVbeKfMxeg206Wn/q5qf7PS3H67c/Zj hY+ue+rWvfwYummhx57UfcEmN0++YEtmYavIC/jvsXv2K+eo9ttruRq+Rh7VefK0PtrrqVHlO6XW STy6mwOijx1yiIhYfensY/2DZ9/kzjevNGxiOQ0sNo8zMTIaNG4dMoUjSgGPGMZe0PjCQAReoWow GrIzs4IXnoKqWWjUczIb8iCPnAOdjuBxG/IZIMuKGigjNLIYAvPt1tLCI7uyLzWtdoif/Mux1fjw x8sdBkVIWngMUwySFlg0mDH4MmQyJDMUMeSDB9/TGEoYFBjcgKw8MCuMIRUoVwxUAxJRYDBl0GMw YDBYqNaggjNtl1QW5KcXJRZkVKK3JlmaGBm8j2XP/pv0ffdnjRdv7pYVHGIMXt2aLb/0bU5N2MR1 kWerPENXHHxmeynNW2LCg2lm887pZkZ7bIpVfzZjwusPW/6pNkdMMWfdPvX878uCiwTXv7O9edd5 feC6Zf7Jaj+qOW+53U/O2Xxu9+eQi+yv5n0L/sI5+UN505sXbsFrYzwN7xpoXqtK3/jKr2rDx+fP Vy5iSHHQPf/CTKFTRO1PLNe3rV1SypcELpwP0paPWrX2/q1tSncObj/16GWG5lI+S5bLL6V+eN36 uKExtHJFFbfolpIIzUON/3TqIjbFM7D21KuuW/Z62ZPlM/nbN0Ys2aobz7vS64fcGRf7le+f7rh2 vtW002T9w8muNuuXbFvYBGwWNTH+RsQYm2ET4xug0AtQ8k6nyaAmlqFUHjYOiAOYgKXMgkgDCeS0 x42Y2mEEJj24DKshP6i+B1bwRqAhD0NgBS+PnPSEWATOzHgiFRQwNc+0Osq1bFrhTSxJoPFbclsR W9Cv7AWJaZNZn/eff1DmZdHqGvTq+Tr+hZEX5+q4iYtHPghzlfyn80Qg3PoUs0jEi0kbZ06bYPGw c49G/G6Zxgf6M5dWCN6xvPiNoezzhAjO2dtu2p9wO/VgYyO3fK5VwrF1WW99lD7J/HMqPPO95I9F 8rV3hrmSl830RaMunpJ6WqB3yGd+UdSsuWLfGPbPvCmRJXf71n2Vh6cnbN+ZO3nJxO3W5co+Gk7T 18ZHPpf/94/LOnHTicNhm5UeH2R5mGPqzsd4tnHhng75trjOrNZHQQu2tJq+EKi4ZnCxb5PG11nP VqS6lUTsmnqF2bCurG2P1HTb6HOaPH6f/hiyFhrfWG98QXzKBwBwyhcnDQplbmRzdHJlYW0NCmVu ZG9iag0KMTM2NiAwIG9iag0KWyAzMDYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgNTE0IDAgNDE2IDUxNCA0NzggMCAwIDUxNCAyMzAgMCAwIDIzMCA3OTEgNTE0 IDUxMyA1MTQgMCAzNDMgMzg5IDMzNSAwIDAgNzE1IDAgNDQ3XSANCmVuZG9iag0KMTM2NyAwIG9i ag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0OTIxMi9MZW5ndGgxIDkwNTY4Pj4NCnN0 cmVhbQ0KeJzsmwd8HNW18M/M7O5s71Wr3Z3Vatfq3WpWWatZVrNkaW3JVbKKZeOGKzYYTDfCmE4o AQOhxgmslybTIQYeAdPCc0ISCIQkpIkWwgvGlr4zc3ZlyZh8JO99L+99P0Y6+7/33HPvnNvvXdnA AIANP2TQXtc5d85jZ8uKgGnYAODurq+p62LbojkAewQA+Zf1NS21tocv/BBg9ygANzynrr4BQrIh tG/HUrxz2ud1bjjT3ARwVTLATb+b0xmpMVwb/CUwOTIAZ8u8ztyCNadtvACA+Rna9/av7dtQ+8Nm B4DpNwDsjf1bNwsP3vjKQYCca/B9+qENK9fe9seaHwBYdwGoLCv7Nm2AZAjg++/B/MaVa7YPuVOv WQJQeAdAxY+HB/sGft14/++wfNRB8TAqDI0mTGOwPEgdXrv5jLeetR/Dd5UCGH5w2uDGdbOvbXgY YHsR2ljXrO/v+/jtiQqADVh/5aG1fWds0D9n+hLTsL4grOtbO/hs8ayXAHY0AujDG9Zv2jxhhIvQ n91i+oaNgxsGPz2UCuDB9xmPg9i2coBb//hc03JDxV/BpQTxeexPZ70s8pma32uO5Y9vUj3M3wIs qFDowXwKGAfmkLrtWP7x91QPK4G5EaY83BbRRtYHt2H5mcBhTiPkQi+20h/wvSymcjI5cwWmKuU3 yAuxSC+Rew0uYkEJrEHOsqxMzcpuBfajMAhnJspu7RQEzC98KSMf+FvYEHb/Pum9T8hNYk2xdD18 +3z7SA/32cQj/1S+/bDqVHrZILRMs9sFrf9M+ZPlbYU5iTDz5xPhUz2Ybvq6NPbdU/uhUECDbDs0 nPLdN4iz8ps/3LMn/OM+mO4rVz25QkzP0wO7/pF3nPwovHDXKcs9W1zb/v4j80DHP/NOrmt6Hyce voH08k+IJ5fPvfGfGwv/2x6sf3UizBw5Ef7PPF9XjqILqqe+7yu+uKHtH3mPzDPxt0SYfXJ6uZwH 97tTPPI7p+vZ++D0r5S75au6U5ZlITvFW9/M/h995KNw+an03DVg+0fKYX8G35c4G+4Sw+xtcM9k 2s9hH7MCbk/EmWVwq6wFbmV/gXIEbX8KWyX9xxjPg/OZ9+GxST8+glekMi46tZ//Pz7MK/9qD759 vn2+fb596GFvOrEefyWtF2767/TllD5sgkaUoX+1H98+/08fLi7J0ncSAPdhjJHiMrgKmQRG1KjB D9nQB4N4L9sAm2EbbIcfCkbhnIkJtKG0fhiGNbBxahqXztXDbYlXMU1MG/vc+yve64u/C8AKTnxD ylSHGCOTxHiZRcxSZj2zhdnK7GQuYfYwVzA3ggLvYOLzyWT+yUx4/6Eb0CnvQdMsqdpNX9McG/8v +f+LHoZN1FSKYW0lTtYYw1RnUfsMygv/PX79z3nCDcuXLV2yeFFPd6Src35H+7y21pbmprmNcxrq 62prZoerqyorZpWXlZYUz8zNyc5KCwVTAyk+p9VkNOg0apWSV8hlHMtAVn2goVeIhnqjslCgsTFb jAf6UNE3RdEbFVDVMN0mKvRKZsJ0yzBaDp1kGSbL8KQlYxQqoCI7S6gPCNHDdQFhlFnU0Y3hy+oC PUJ0TAq3SmFZSIroMOL3Yw6h3jlcJ0SZXqE+2rB1eKS+tw7LO6BR1wZqB9XZWXBArcGgBkPRtMCG A0xaFSMF2LT68gMsKHXia6NcsL5vINre0V1f5/b7eyQd1EplRRW1UV4qS1gl+gyXCgeynh7ZM2qE Fb2Z2oHAQN+S7ijXh5lGuPqRkYujpsxoeqAumr7jN06s8mA0K1BXH80MYGHN8ydfwETlQWNAGPkr oPOBsT9P1/TFNYqg8a8gBsUqTjYTpifCgL6hh1g/v1/05dLRMKzASHRXRzfFBVjhjkE4N7MnyvaK KU8nUmwRMWVXImUye2/AL3ZVfW/8d+uwM7prhZCdha0v/QbxF9OFKBfqXdE/LLJvcCRQV0ft1tUd DddhINwXr2v9gbxctO/rxUqsEpuhozuaG9gQtQZqyAAVgtgHqzq7pSzxbFFrbRR6++O5orn1daJf Qv1Ibx05KJYV6Og+CIUT7x4oEtwPFEIR9Ih+RO212Cmh+pHugaGor9c9gONzSOh2+6PhHmy+nkD3 YI/YSwFjNP1dfJ1feqOUC+t2knXCWKw5H1QK3ayb6xF7CxVCA34EaiowwYjdJUXFHq2pELoZNyTM 8C1xCzE0rRyMcMHaRjGJE7PWNrr9PX56/o5L7rhP8mBUOaUsIyomfaL3fK1rZC06lC7UD9ZNcXBa ofK4g/HSTu0nK7ZF/MWYQyl2Z2MiiQvizEUdi8VIKrEXnUIU2oXuwGCgJ4BjKNzeLdZNbGupf5s7 A80di7ql3o6Pkq5pMUovpVgU/JiciLC1OAYbMt2JbpXic6T4ZLTxpOS5iWRhRBlo7hwRCw/ECwQB ZxBWWhGa23dpqbkIp2YDrm6Bhr4A7t0NI32jE7tWjBwIh0c21PcOl4tlBOYOjAQ6uyvckq/zu3e6 d4ivMkMz09xVk52Fa0/NgQCzu+NAmNnduaj7oBFA2N3VHWMZtra3pudAKqZ1HxRwbZe0rKgVlWJE ECNiSfMxopTs3QfDALukVJmkkOL9owxIOmVCx0D/KEs6Y0LHok5GurCkEx/sJOcwNjEut/XCgNg9 Z/UMj/T2iJML7NiV+MtEmUAVRNlA1QGGVWij6sBgTVQTqBH11aK+mvQKUc/jwGDsDDaOuCaN9AZw ncIB1Q1uhoYiJxYpjE5MdHX7D7vHevw41JagLOqOqjJx7ZcHm9Bujii9qJ4T3dXfJ/oBkW4xLx+c 29+DwzZRIJrMjaqwBFW8BLRokPKIwxEz9WPfYAdK+XdhJLqrJ9qTKb60e1WPNJyNUWgMlGO3U5ny kPii3J4Rc6BAmps4FdTBi0Wo0Dfo7CaNG6P4sh5qJF6LnvcHMKm/V8DWlkF/Jw51WkvVbtIM4pIo Cw1KonbHE0GsFhfU6NRRVQ4WiL9iWJMjTkl5kO/pIeel2MVxA3y3MapBj0JTmjKeAVsHk+aKvuDv xeiqaPqMWEzHKMwPnIEri+i0VBKPyVFdcG4fLv6UX4OaQGkis1JcIzTxMg6RlhdrrsV254JdoxN3 B7b7pzzZWQFxcxAHJrgP4sCGnpGTFdHFmdlZypO1Okk9MqLUnToDtZdSN0lUwgEVN8ruiHmrfKPs dsIZMa8GsY2wNeYtR2whbCaTTTHvLMTGmLcCcTphA2F9zFuJWEdYSxnWEE6LeWYjVhNWxTw1iOGY pxaxkjBEGCQMEPopwwrK0EfopbTlhGWx5HrEUsISwmLCIkIPoZuwkLCAECF0EeYTOgjthHmEtlhy HaKVYi2EZkITYS6hkTCH0ECoJ9TF3HMRtTF3E6KGMJsQjrmbEdWEqpi7BVFJqCDMIpQTOgllVGYp oYQKKybMJBRRmYWEAsqXT8gj5BJyCNlUWBZlz6R8GZSWTkgjzCDLECFIGVIJAcqXQpZ+gkDwEbwE TyypDZFMcMeS5iGSCC6Ck9IcBDspbQQrwUJpZoKJlEaKGQh6UuoIWoKGoCaoYq52hDLm6kDwBAVB TpCRCUcxlsAQQAIzQRgnHJcyMMco9iXhKOELwt8I/0H4PObsRPyV8FnM2YX4C+FTwieEj8nkI8KH pBwj/JnwJ8IfyeQPhN8TPqC03xF+S/gN4X0y+TXhPVK+S/gV4R3C2zHHAsQvCb+IORYifk54i5Q/ I/yUlEcI/054k/ATMnmDYq9T7DXCq6R8hXCY8DLhJcKPyfJFwr+R8gXC84TnCIdidlyXmB/F7NWI ZwnPxOyLEU8TniI8SXiC8DjhMcKjlO8gYZSUjxAeJjxEeJDwACFGOED5ouTL/RS7j/BDMvkBYT/h +4R7CfdQvrspw12kvJNwB+F7hNsJtxFuJewj3BKzrUDcTPhuzNaPuClmG0DcGLMNIm6I2YYQ1xO+ Q7iOcC3hGsLVhKtitj7ElVTmFVTm5VTmXsJlVPQeynApYYQsLyGT3TFbBHExFXYRFXYh4QKyPJ9K OY+yn0vYRTiHcDZhJ+EswpmEHTEbrsnMdnrDGVT0NsJWesMW8mUzYRO9byNlP52wgbCesI6wlrCG cBpVZTW9bxVhOGYrRqwkDMWs5yEGY1Zx7A7ErOcg+mNWMd8KUvbFrGFELymXk3JZzHo2YmnMej5i Scx6IWJxzIKbMLMoZvEiegjdMYsasZCwIGbBbZ6JxCy4vzNdhE7C/JgFt3mmI2bBjZ1pJ8yLmUWv 22LmBkQroYWUzYQmUs4lNBLmxMy4bzINZFJPyjpCbcw0B1ETM4mTcnbM1I0Ix0w9iOqYaRGiilAZ M4mjtYIwi1BOKIuZMhGlMVMWoiRmKkMUE2bGTOKLiuhFhYSCmElswXxCXswkNmQuIYd8ySZkkUuZ 5FIGIZ1cSiPMICdChCAhlRCgDClk6SeXBHLCR+/zEjxkmUxwU/YkgovgJEsHwU4O2ghW8tNCLzIT TJTPSDAQ9AQdmWgppokZlyLUMeMyhCpmXI5QEniCgiAnSxlZcqRkCQwBwhPICbQbRx5HOYbyJcpR 1H2BGf+G4f9A+RzlryifGVb4/oLyqaHf94lhwPcxykcoH6KMof7PKH/CtD9i/A8ov0f5AOV3qP8t ym8w/D7y1yjvod27GP8Vyjsob6P8EuUXKD/Xr/S9pR/2/QzlpyhHUP4ddW8if4LyBsrrGH8N+SrK KyiHUV5GeQnlxygvovyb7jTfC7o1vud1Gb7nkId0Wb4foe5ZDD+jW+sLTzytW+17SrfK96Ru2PcE pjyuy/c9hvIoykHt6b5R7UbfI9pNvoe1m30PoTyI8gDGY8gDaBNFuR/lPpQfovwAZT/K91Hu1Zzt u0ezw3e3ZrvvLuSdmrN8d2h2+r6H+ttRbkO5FWUfyi0oN6N8F+UmlBs12b4bUK5X3+37jvpO33XI a1GuQbka5Sr1sO9K9Xm+K9Q3+S5X3+zbq97nuwz1e1Au5IK+C7hS3/lMqe+8yK7Iuft3Rc6J7Iyc vX9nRLOT0ex072zeeebO/Tt/sTPcqlCfFdkROXP/jsj2yLbIGfu3Rbbu3xKRbbFu2byF+2wLs38L U7eFydvCsLDFuEXYwmk3RzZGNu3fGIGN7Rt3bYxulM2Kbnx3IwsbGfXoxNMPbHR7G5DhszbqjA2n R9ZHNuxfH1k3tDayGt1aVboyMrx/ZWSodCAyuH8g0l+6ItJX2htZXro0smz/0siS0kWRxfsXRXpK uyML0X5BaVcksr8r0lnaEZm/vyMyr7Qt0ob61tLmSMv+5khTaWNk7v7GyJzShkg9VhmSjclCMmcU HWhLRk/wxluT5w6733V/7JaBO+p+2s2ZDUm+JDbd4GJq57mY9a5zXJe7OIPzVScbdqZnNRgcrzp+ 5fjIIbOEHek5DWA32gU7ZxPrZm/tapBYXUfMnynVtdUeCDUYbIzB5rOx9T4bA6Z3TR+bONtTxleN rMHAGAwTBjZsQHOD3qdnxY8JPRfW55c0GHQ+HSt+TOg4e1iHGrHEGdr2rgaDxqdhI9WaeRo2rKmu bQhrsvMagGMEhhH/kiAwnBJtH2RsvgbucUb8O4ccGOaKA12dmZnNo/zE/Oaoqn1xlNkdDXaKn+GO RVHFbrxsL1rcfYBh9vYcYNjarqhV/JJIil942WXgqWmOejq7Y9ytt3pqepqju8RwOCyFJ8QwoElP 5rJNWzZlZm5ehh/LNm3OlH4xxmwRY5miUvzdtBnj4s8WKQ6Zf/chM8TyTfhsjus2//1M/2sf5l/t wP/wx7l8mfRXIf4WgPGrp/2hqB1WwybYhT8XwWVwNTwFv4AVcD6GboBb4S64F6LwDLwIP/2v/OvU +Hb5WtByj4ACLAATRyfGxu9CGZXrp2iuxphFJpzQTBgnPjxJ9+H41RPG8VGFGdRSXh37Bmr/whyf OMpWi/GJYjHOXoxhg5TjE/6W8fvH757mThO0QBdEYAEshB6YB20o7dABrbAUlkt/mx2AQRiClTAM q7C9ToM1sBbWoQzBetgAp8NGbMPNsAW2YnhzXEPxM2A77ICdcZ4JZ2F4O37ukEJnwznY8udO8rxJ ntCcDxeiXICfF8HFsBsuQYqf03XTYyNwKezB/twLl0+GLz+lVgxfAdeiXAlXYa9fg+Hrse9vhJvg u5L2argOviPF9sHtmH7dNFsx7YT9zXALWt0Kt6Hl93D03H2SrWi5Dx6HJ3BMPQ9P4mh7CkPPwkEM Pwu/gnfhN/AB/B7+wGQyxcwc+BQ+g1ex9Yew1cU23yB9rsLPlZMtvg3bNtGyZ2OLTW+HrfE0as/z pHZKpG1Dy4uxN86bkmdE6qdEWaJ1oqyp7SXWSazRCR3V8OpJzYl6T89FdlPbbHoL3ihppqee3LJT w7d9bcr34E6UO/BT7IeTY4nQPTjDRfk+7IcfYIg+T8QToR/CfXA/rgUH4AF4CB6GR2B0Mv4gxk6k xyRNwubU+kfhMWkUPAVPS/3/Izgk6Z7C0MF46lPxlEel8LPwAq5CL8HLcBiew7HzgiQvwSs4Pl6H N3DV+iW8Ex9BR6QRFGAy4TV4XRaCn8n1jJx7Gp5l2+AMjP+UvUH61xlyXIk2cT/HlYMDHmZJK8C8 h7Lt2XZlxWw1MwZzgWcGgAWB2QNKPA8MhM0yNlii4DrcOtOGDqajjme7oPrtd95e+s7bh5GHmdy3 x46MGY8fGTOXleXm5ucxJr9JEque5XmFIpCSw5aUFBcXFhZUsTOLcthAih4lNLOoii2p4goLvKxk SpaSFo1FLffzY4u5eccV7Jm++nVtqazPrbdq5Ywg9zmUlfNyLAb/zLS0cK6PVytYuVKhTC+vS6lb Vp40/hDHa3i1YLcn6eUyXqtUCS6LSy8bb5Drj34q139ZK1vz5TVcftHK+cXy69VKVqZQPO52BGc1 +F2ZgsVgMWr1covdrOAtZk2osun4pUpHkoNXq3mtUa1yOu1KlVqhNR4vBXbikYmj3B5s4RQIQSSs SwGnI6jVhTTqQKruMZYHB6jZyrAZHKHgJ5qAR6s1ewbNw/LhtEfZM9mzoDszs7q62lyWay47dPxZ JvfNMeOYK7cQm1L6NZfl5wXtYnPlsDNm+Hk9hw0XKi5hqN0cfIDxc5dwnDnk96UY5UzGeHiXXOcM JnsDWl7LpikMSWm+QJZLzVzOjv+JGa7AFpHJeI1y7E8qLS+T65Nt3HMaPc9xSr1217ha/PcuqyY+ 5p6U5eHomPeAIIBllK0Lq3IsaTPTZ33EB/E6/7CHxx+nVrxRzhxyihf19FVT6jNWPWYShwIYsTIm c2YZkzt2qEwcGVa9TKwJDgCZzeplxQFRWGC3WfWJrpdhrWTck5xModbxWqGwvbJm7YKaTJtQsaC4 sqc6w6BRytU6y8y23qLuS1fMFMK9535vRbCuqjRFz40qrElumz45kFzYuX77juLq3tkpbiFZp1MH gn5LcpI5v+/K5W133DyyqkKFUav4b39aAGRW3F3tEITCg6jBrnJ4vHqdQ69Tej41DXg/Va6cXjXs F6zQ4cKCN8fiNfKLA9wiDXAvy4sDPIC9UyWTWZMq+y57Yu/4UY1VL5cf5NOSPzn/znWlUaFhTe+e W/YMndtfn21lb2/67nUXDc5S6F0m7g6/p3DF3tVlfQ2hYx/mzFu1eYfYI63i/9NCL7OgMSyorDal zaYMBbVOrROCqo9D6UGrVVB+kj5g+0T4irO5OIbGmNxDYocYDxcUGndefOhQwnHOX2CbHkhUxV9g 57awcl6tV433VjErbTjBNHrl+A31zN1WMaxTHv+j1qKTyw7yM1ysUaOScbzNabdqxl/2Kq1Ou1kz fqdbYXM5LVre4DSKNTOKdZkzcVTWiPMlF1aE7QGtLgV/nI5UjTqYC0G1I2MwNYDjKmzX5AZTnDIP qHUO2ddOGkeZ2YHz5lA1ThzsEbFqjNOIoXgtg+J8EWvk5xIhmjg857cUiYNPDJ7Fam0pLqfXrGAX jwuLWY0txekUzHLmx4zG5heDPNPJvNulsqU6nX6zgnHg6iLOIp55frw8Eeb+oqCQYnwFc0siTDVm nsQa2yAUNoBNo9bY1CCTGwen1wdrwuQ+X1CYn1dykq+fsmp7itMlmOTsFI8cX30xTEyACc+BavmF bAh3IQAFGzLFRxC7F31IhuywzunSg86p13FKy6BL/OrnpCEueXL4+cICbMATg2Ky4Qrs7F5GptQa NeMBjTgCnmE0dgGdsiiYGLNeq1ors7iSbHqp219O+HbsXBP60TBxVH4ER3I59Idngrpco83X5eXn 5ThzHa5gUmow1enQqIsHHLqkVDXk5rmcWk1OfrDc6Esb8A1/ZQSInmLXS4+pkH5OhKZ0f4Ch0Awu MDkQ4vPVYSkUF1Nchni5llHZsCI+k4I5wB7/Jaexeu02t1nJPMgeYFVWv9PlxT54VpGZtCppRrJZ cb2Med4oBLN9wy6f8kR/bDt2gVzF4xqmVHBnHbtkUv9CiqB2pvuOz2Rf84ScaiEFqEVkzdgzlVAf DkBlYbbe6sviQzovXzrotfKQnaXzhQorNa6UAdewbOX0GUDVP1RgKsTeOpQr9Rhuo7hHzOByuBkB PcdPr6/dYfFyjsIq7kR/7lalJw0meTX3al0Op5pV6A16fjOjtHjtTo9Rxv4Ia7vT6Vddr3W5HBqW NxiMykFGZfY57MnYGDUpgieV1QTbOztCobZ5rSnHn5xaX58wnhrq6OgIzeiYPz+DGZ8cqbj29k58 KOuQFeAOmQt5T0n/acUJqfipBQ+jjFmG0sVvJ/mTdhbcSyYX3hN7Bi27J7YVmawjqWzp7oe39l07 UJhUjqHN/df1FzyYVL549vwzF1emGt3lS2rmbV9cGTSxT9Tu23ftpobcpZcsarzj9qtPry3oHRku WTI7taL3zJ3bMksXz04pX37G2dvQZ5zL3D4cvz7IhjniflEddguWNKVqBv5YLWkfWh0WlVKpn/GR Y0A/bbBKSzGtxc/H1ydcqiarEji5n7wcXxSaEQrRXsJy+6xZc4YuWXjdXFZj97scgkXOPqPIED5P qfHktJR4YgV5lhzLle2724ar3Jw/q3fJ/MrU8SvFvuB4rdQXCl6dVtURzqvTyuXja/NblsXrcz3W Jx+qYHnYXObxluJPukNp12rlkKYsGMUaukBepnSo7N40LR9Iz/J4AqVZA4Fh0/TJeFg6xOCQPCzu 97kYLhNn4fOTi7F0yLPbHQ67uOPHjzQ53PSq+6dtoSx3vb+mrzqr2JjGypSOkCfJZ+SZoMKRVpkz uJBV2+It8SNFhoth27d2ZMQs6dV519afN2dFpYerLF8ZmW3V981/3+zG8yA2hUqn+UtGXW7S+LzJ lnnJ7/GURTqSsgTz+H2hqjbx3wZPfMgZcWTOheWPg4lNwsYpwZOBK6kKfyBkKqn1Nb6VFubbeZbX flo7lIqL6ENpedlMdoH4Fbpv6pA9/iYszRyLw2QWzw60F+PZaNqJiMWhq4g3jCwxrONHZjHOSkcj I6tQqDQKTWrxnLzspiJPoHhOU0NJSvXpNyyeuXRugYXHPRtPdtr06kWVxQtm+cojAwvKSoYuXxho rM63yLiXlXan3aSxu+3unFn+lPyMUFpuRVvhvHOXFplcbovJoLA5nVZtsj/ZV1QXzK4uKqhbWl+7 rbtIa3VZDdg2u3DE7McRkwIzwxpQKq0qi9NqUVqxCR6xqPS+k4Y9Vvj4ISb3yGFxLBgPTx48Jjdm 6R4gk84b+zkFj+eK8fce4NS0BSvYB8bf16o4XqXRKtgP8JCBo8DpsmiPnTe5ypxt0uvdTpteaUTv 7po4qliMq2kFLA0X6FK1QdxSgs4KqCjID/hxedM4SwYzBkHt0OUF8lM12gpnQTDXbzzl8QIXV+lc IZ4n3sSN2STdb6btLLifTO4sITpO2CyJw3kiZLcreNlauSEpwyek40m8hB2/S27ypHsCWU4VM8DK zKmCJ8Uoa2OZC+Qae8jr9hjk1SxzuUxjCyR7/Vq52otHL47j9Rr2s+M6rV7Jisd17kWbSyvjlDr1 sXtZboFKp+TwrqM6djfLRdQYkevddnGHuQh77F1sk1QoDic5AbSMRqvxDWoYLTh1qY4klcI8qDj5 KCLuK2JVxQsIM9lbHN49iqfsmlLdWGUzK/aXS5yJLa/zjDk9BTdKnr2FYVrlOnsw2Z+mVxmZa8cn O405m50n3kRwAirH85lXlaLe4LLjitQxMca9x/0Yb1Oz4LJH2XPYXeiT+FVzpPsBlUfpHWXufxDX xVnKUea+R8AQYtCp/FHWG3ZYQDVrhiek4PxzM75Iair+W1jfyrWkZTqrq5NaxxLnmrE3ly9b+vaY OBrFW0p+njts/wYZ8/N6gomrLLUGTVG7I35Z5Xlcq6fca0q4LFlqhjXJiMXq6pZunNW+qsphy21e vaen55wCiyyUZnUbZcxPctfWFS+szfcZNL7izJL1vU1ml0mPbaT6vtASzihdsrmydO81e9bXNlYv Nuo5pZb/c319YddpG9dlBerLApVrruoW+7gFW20B9yLMhItParPkZDCJzeNJK/qPNJ+ckas/z20S Pk8Dl9HFqjmX9Wg42CrWNakV1yhsm8nFKnFrc4eT/9Gs2FpMfImnNrFPu+qFJm96C3i9Rav35jeX h/vn5nl1i3pmL52dYVSqZCqds2Lekvzb9tkK2jZe15fWNHumh+fa8KJr96R6Z0bWrFsZWrlaSBcM eq0/4HWleix33F555dUjp4V1dn+SOd4qirfkZ8AeuAE3MYblFBmZWXuy9pTsrK4vyeov3mDxmL3d YusYN5SUv7/H7LV4irP4/AvmDI8yprA/zdgr9LK9i2uOtrR0LD66tjW/RZ6pdrZ0vLNtW+gLdVNa oq3xZFKYOyYudtXi3Td3zEirPg6csQJxzBUcLjC+9nzhkSNv4kKI+6H+ED04ufCMFl8vrIqpp7XE NyUndNIAQzM77aCyUzYvS98RJEZnKNHWLGbiZS/K9QaD3Fi7ZP2s8KKyJF65AaeugHcfPPKulyu1 yZm+met6m03trFo87vrwhPe5VlB3rsWVA6c6p8BLoErnzZlTeqK/wpnYX3KlTmWsaJM6LL9lzeWL XNlmjdqUXrdyz7IZjSVBmYxluUeTimfmmQPN1RnB2YuKUusCx19RapS4pmuUbFbSbKcnL2CtWntN ZPz0hFr2BsvmNXanZdfZeaMW136HReMJeL7S/UoT9f8VV+1eVc3zluzklPb2prKAXKmWy9V8fCzw 8vWwF649CA3Mq2FBY9p7wflwfldvX2dfJ/SdX5ddvtuUnW3azZ1fvn59d4o4LoLl0HvB+3vtGfaM oPsd/eyuvY2iqax15d+2tyreb20IHi1pnToMpEs3Lp+H3iygL0GM4vYnzSTjIUeZeFExS+ci6VBk nHIKFHt8egefev6c3MHxgDh6eLIQT5MKxSkyxb9ds8S/fCsslG2Wc3NrqiIznU6bQsHrrFqdJ/sb 9G2OyWoOVS7cNHfv9Qq56XcGFatQqQ2qDwY4PjM/aYbXphJzaXmlkJHrKJ1f6mZlcm5om1Yt11p0 Z8jwmm9qCuc1doWya228QWsKCbZv0Kuphakd8xpL/LvOchR5uux6lc1uN6nH1bYivPap1CqNQefz OnncJhXOwtZirUcQ9MxRnUUfFOI7i6xMvhayoPrkVTKs9mdXp2CCKqVE7PYkW0oWN6MBlSolKPR5 XyQ3lZ+8K4i9LB3nxL4Vv3vQi9PZHXZ946xf2VMmj32OxO2MSWwqdtpTsrnUDFuSUc4K0p4ya+Gs oI235zWvvrQ7s6WqyDbEqK04nX1mOTt+BLeWmZG6fMFYM3fqxnKPv7k63VdUP7fJV37FlZeeVmPx 57iYcV7Hy+X4cXxFfWP+/NWnr8vpW1mx+qqF2HKtuLvcjHtyDp6rTmq5hzMKShQyUI2y+rAqYNJ6 Oas1kDvK6sI2CCieLCnJ8JpM2oLXM5q0vwp747uF9AWhOBFyx8RvPKUvcnA3dki7seUb5ErsL4Gv H+bxW6E0o3jpKnFzePeb16zm5f3rw0PNeSqVSqbUKbWVXQMFPRf1ZLmKF2z77oquLc0p97Y3zR5o LTENrbosEmB/W7+uLcNf5R5YbbFbdFp1sidJpXVYtGmdZ3XNvvaqi4aqMmo6Sgqrs1sGS5OyK3Cl qcbzVlR+OsyGnSeNskCOK3W2BtQBjVMzu0gmt3wRLmsKuNSQmqPwpjd4/w97XwLeVnUlfN/Te3qb 9t2SLD/Jm2zZkuJ9i6M4TuKYhJjsCySWbTkx8aLIsuMwBFyaUgMZmo2lKS0QKFtbOm1pCwPDkCGE +Smk0J8BvpbSDmmhpaWkG4SWxP+59z3ZlmNImM7/z/f9X3Nyrs67975z71nucu57lpazipOQDRgI TDYsJLx/AYf2HpiEL/Y+7FufsJZQmeg/e/WZp6wGMO3DasDpPLAaDG3NWg0okRYg6oIqDNWBFxOt qVVdTHgu5wKzOVvH6zAFm76+2UsBPhEAzVHvsRFkRSXoymzdPVKSZ/OhR+mumCTm+Xy2vBKmIMf4 KLX0e2ysYFmOOrjeWAEhFlbaKy+/q2zUPd+/QF3sSqpS1GcRs07fqF+zZm+pL7fIQrNaiweoQit9 7oNplXwHxpxfURrzvLfIKYrOIq+3MEcQcgr/Oi8ju2Yvp8jOIcVHqN+Dj9jR0lk+YrIjKSYi0S4x rGmJalgik1t1Aun8QhCidpZl35rbZjnn20LtD/s2jPDN6P5Z/alvLS8P1zsdAf+lgc1oMzQOO26x LiCtbjcHP4wta68L+50icpRLgc2XttYbKpuXVS73Tnmk6pLkiBZcGTaJ5soKGMPH4eMEUNhEMf+n 5TXbu4uyN0pzZKlaUZ3dOe3z7DZKxEeqeWYtDT4/b37Fjs527PEk0wTbIo6taKq8UsnMqPS7lGDN tdk9RoYKGBdfPlDftK7WrbEtuby/btGmOlfWUMitcseWz99xaN25welMX0PO/GXZmZrPgYdo8Bb/ 6wHY+vvrV0byly8oLWrZUJXfWoAyMwtYqQH9wywrFc1zuz1FjEGDjJRNYzQU2j+M1bQXegyM2ziv iJdDy+TlQvYkQUWOY3MoZ4eKHRwXvovMvNpPoWrNP/HcTvC/zLTCsVXzZ08qWdps3bJzPtYh/QpI PXODmNfgmH/JJ6qsZNEGmEUuhdXqJdASPlfckK0nfGKXFxOQy+SirRpXAV7rJV3un63tJadi3PQ6 o4aJ72KliOcXK8vPJ54/al7y1m/YddsVnTdsKPU0rCfUxtKH7fNW1jV1ragvtDjmXVo3P44perj9 yBeu2VIb3jB+WfuRm6/dUhvZML6poqPWF1rWNTRSV9FR5wu1dyXTiJ48c+6w5kWQrRT2MAdn+YDe X12j01frq116pwth0bwhp66m2s9w0Q+L2p16l8xYPMssK+vPzBCGGFZZaV5+N6LuTGErY6aIS7gv nsEMrRTPPNKb4QxcZh3iHA6ipReVvUt5e3OVYy0+Ys9xwt6FOkuTbQ64g2ERbHOWb4t5v2H0VxfX JCE28Uf6W6shZPYb6b0NBw7f1L/QIofc5zoy8xnzDgTK4Bdf81+ysLRq/a6VobYqb1P/ofVfXbK4 Ys2VqaQykug/gB4rUf/snWDQbM61eFGuV/co5YqZYuXtFq85mFusdQaWOadmXGUERY5nHjV4HkO6 C1SfoZ9PnJsc0DOQQ8/zVqfPFti4bql5ZfZqo44Vv3NB+2XF5nyfU6vV3ME4fbLHwolc4/abV58b On+I3FuyvD7AcoJWi+cSYfJd+jeggSXoG9kaeAKmkLOoEVXBji7kaARA+caqmGfxD4MyG2VjrIYV fxhrlz8MolJTKa3TlEbeiHnmPgc477zTEyv4W3hlnyvgE1Nm6ih5OtKddWiKNfobrWQUdP7oonBZ a9hV3XHFyurabQc3RVYviup5jtaSZ/uB2lXza1dW5VStvHxlddXWz11WtLSpTJI0/aJfdlhdtpxQ rS9YXVrSuHrBkt3r5xkcHh1v1uEDVYvkyfN4ypv8pdWh0vrVsZadq8M6i0MSVU2zj0PkeRd6OGa6 diQ9nl582arWVavSreM29CTougwV0gbEoXrqxdiCm2rKuJtv2p/e3VnG3bR/d2fn7v03cWXaZbbL Rk6tSl/ZOt68+Nq2DWeuXHH9qeYlNz992x3HUKGust38oUd+QzczFD37MjmQwB8YjiuvFOBoVIlD 1VCU/MfGAcA7zam4FB/VXki900cM9H81BK3NjntnnGvQVPPFGMpdtmD5uoilzCJIVYnDnTfdxrKm X5KIVDLyb/cwbEkFjkh5QYlI/SUQka6u82hwRDomSRCRGsaMWk37wqa1tTkmE6eBISJp9bLqK/S3 Ls7k4ctaqwqtLGcJOVvHu5r+KzHqahIWh5euLSquNWkdWpvdYZYUv8N+tHPyPfoZ5htoMbpx1pxV UlMWqg218MJCYWGtEApFa521ThRtaatd2MSXnRJC/po245mYf2rOBkd4t+KFenzK+wIenLOOJEgY dhF3Z2a0i7Z1ZqaDWvQztFaUDMJbCUYbinqCuQ5+9pkBy2oSeySdVmfVXxOiJBvZpbFU6C2jqDn0 aRT7CqcTGEbQca/gcwDQI7MPoox2tAXVPIY2UUtjto4GXfSUPlK4JLiwoc16pnAF7DmnhxIMH/RC 6DgZPqbX3816r+BTSu6vcHDWrHhDs5dM7i4ZNqBfORf5VOrArwSE6EU+s3YNBCklPl+hGaqZc4NA WeipPajG/mn15HFT7bNCGcUD2RLmNbQLLYnlx+NBeTA6SA9uLi/jLzvVEQoLzJL09m2b26rOLFlh POOffS52/PhxWAnPwofpOEzoUy8EXcB7Pr2Kpx5tQ322RKOFtVR4u4dlS+d5inOVoykJ9BqKOOrW 1CoTwbmFn94NqX+tJOEy2bFUvmUULtYpP60xKAr6w7L4WcmkAykerP09ePDVaD+65Htjbf1tO9r2 QXwby71u67yoTlp7KrJGX8G0pxJb2+rOtK+Yy6HfXfBCxhzYp2GHf/Fu/TeY5Hz/Z3+tEUisZWHB /8P/t+1EL8o1s+poyQrpP8Vo+VsMOPfI+gLE3/+meQJdgvbOjljKqYce8QWslujj1EcQ+TVSn3vE 0mAJtDxOGxFCZdTZmCUWWLqselm4yarJKV6Ws1w/I2SDGR6mbHzGRhZ5c73pp2QbZvr4O9QQD/bQ qlE1VIbILPX4hNI+9RIikM2ajDX/jdUUbR64po2zewJ2d75dWHTuJdbkLvZ6gzm6raAJq9/txm/Y LGGotYxo8TnBLjzVzoYvX7dCxm9iuSHsZjVflZz8wM9++h/dko6jGd4g0ofPDsEmjsG0Zr1g1upg xGk4vXDWJQj0r3g9fkKq4896eL7tm8eeiwt6TqNhBbxy2iFquge0G0XbZz0dy7dZSx6nTaDIAHX2 Oy4XPsjMjxli1vCyfN6Wu8x2iWGlqhqyWoIuj+PHO5lHh7o5601rkMq8sGnN0l2lqi+H5h6G9V+6 /abOc2e1FndhjiffQkt/uoWmOXBfT56Zo0bo5p41S/NoyV7gKfdp7pWc4uZnXn3nM+fu5MG9WJ3N QNVrhnQ2TiLqMIhnA+sfeexf4tiRdTBXPEQ/ozGzHvy8Hi3+fiAfcdWe/NCj1N2xHLMWcaHqfI83 IGjykkX3uHZG79OlNcMwUXyGvm56olCem0YqI5Uk1KHwmXXRnI9BHepTUHrqKSh9VJMbCDg1Zj7U 2FZctbjEYvDNW7y5oXa1LFIBv9+pud/TXBJuKbVxlrwcX6wxItGndDq9tNVWVugK1C4rzl+/cXWs uKS4QtLrpS8XljWuixdbC3ItBbGN1fiJP32CvpvNQTWoXnnWSd0Vs5SYo0U5bA5rE++J7rTdV5Se IVLm7VTY9s54L/UinrWQQOJuRjQIos1XHihqKPWa+drqYE0wR+JYjVbgxKJ5jXkDA3q5qr1noWde SJYE5iVdnsdqtptzw01NdfaaGqvTYhD5HI+DE+1GMdFduH7DqgVFvMEqiKq1WrVmVIRq0dqYjosg T3GtFxV5ayPYZB4wmbeI0fgHIDvCsbpSMFrFXEYjjxiI3Y5nHk6YLVT9x1lvan6eesaoWo/2BcBG FiHU1FZctyRoMObNW7ypvqYjp5HizR6rzW1gqZ+4YyVlLSF7cam8qLFcoE9hS221lhXmFDct9Rds wAIW+6hihmdhRPLMue7Csoa18ZKKqmDL+ghI/QBsBn8BPloOYeeWmKQzC1ZrAGlrwsLj1G7w3DC1 KyYhs1k370slNV8MavHfuOm9gTatNrdkp+4rudnmtdRHUChExmgE+y02t5m8nFSvmnrmY4MLPDWg fxHaeNMViyh6/uKSRRUBTkdzoiCU1LUEmjY3y+ZA7cptLQ2rq10T0bLCplCe0NS0ap6d+XzJ0iqf 4DbUVEkGyaC1u5y8iJeIiuWVwU0bO5oLckprAp48V0ldntEdAC++k/4B/XutFeS/DHy91O5wBp1B 2YnEvEYpKOeLKM8hNYY51nx/5c78Aad7mM0y+LEFxOIk2q6MHK+oPFGRechMnjDPPqvLvJU/dTyT 9RiAvo/iLR6bFdt2Ic36CryxxrBYRsklVvzOxp2UXGxzGxkqTPO8yEqh+taCUFOxRcvQp1hByzBa gaWWGgr1efkFCzdWvSrpcY7GK4o0y2l/KeXJeZK1JN/hLK6V7RE72P8o/QPqBfavyIqKUV3MZPMV 5YHkPvypnNzrvssWJHOyRH5DPemPvPyCcgKTfYqfdbji4KjnWL0DNgQ+I80wBrvsdOUZNfeAC7tt thwQZYCQwRyKfcTmsfBEfI+ZBxc/683IROdoeS0t6vCKchf0+DmwlxWVxsxWCYkQ6otWiWENA9mW Ufqo9lCdZqbUTgWhAUXPd2WUSr+JXxvV4MQrSjBcWLU9pgtGyHq0MRaNlZfXO/1IjNS1OxyB9dLK nebg/Yt3RpDo9NeVOwLS+lh7vaGyKVk57J3lKMoST07jYTqHPUzl8YrjFZGZCqye6SdzuE6WEI45 TtQZh6JX8JUWDZPndzfDpF6mThd6lmph6Nz8nOaGqFiGxcd5dD+Vm++3U1aprHFJQXFtgVVjKGtY XFA2v8jMsDPdSuc3BAoDzZvqXp3OM+cZ/YGsPNot6XRSp6OswGUNhD2O8gKnK1idZw85FF3SfwRd 1qGFMX8INIhEl79OMt8f3elCot8h1YUCpaK3OHme8shJJ9HcLJ3NrSDF9WYNLEUzMLBYjRzIXYgH VsYJQAu80WlR9NC0tKh8frFZy047BNVmlsVAYeHCDVWvZfJoD6ZUWV3BWp+9zK6uIwzIaEZ+NO8J 8KC7kQW5qaMxvWhxc/a7jTtzj3KzVkXlYfb0y7WZYx2uauaaoGFMhfWX9sau3V287vNbr9n9jzUL a5ZHHTWxmuXzHEx72eb1K+oCg4mFN+xsG9xR01h1Wby8trG6I47jllHqjIaFXpWi+WhTTO+vrNLp K/WVynk1dC435NRVVYaQX8uF7yvaqR44Jy0jtV+d1dlPPLWeOoXmPu4UuijrEJo15EVhUfNEi/36 eZRg9sKcoGeo2+i8gMmuYykrXv2KKhaFbDcXluW2gMl0nvkleRVFXivPrC7csGF1rEgyuwxnwP3A KOB+v5N02DhkD5NXs6wqUlMY21AZKyhxh+sXNKs+uIOseM2xvAKj0WNGbjHodLf9TKTEx0t2mt3G Ag9r9yXts2eTBe9C7ExFjldGMnMKNtUcQzMjrwN2LTtoRsuLnAib7drKEmGmx+XmKzIaSyIVOY4i CIEmGYvTbTPogrE1ZVkjCou0OadctvI8AzJ8Flbt7SDDAvyWrJ4aRlUQq+yOGW1VAEgu1+fUNx8J snixdjg9bax4pH6n78vBpwpfLKQLS7+UM9Oi02/JhuZ+S1bdn2mzj3wzO+rKippZB77bNRA7Ci45 5K2oC9Q0VQcKWrsX+BvCeRzP4JKc/Kqihligoqky4G++vNEdCebyHPMmh18u1etKAo5cF65S1l6T JxhMHG/g3G6ryWIMFzl9UFJRHFxSlasV9Tz+C4/HQRMr2btRE1ofK7ZYilF9OfQvUK/l6gDCgeL6 obpwZbk2/ygXcJcP6e91z96x4IMl5TzueKQi692gF8xTO9Spg5IadduS+Yu5mvNjbjs5Y1vJCkbx xmoNm5OX55f0YEBWPz9Q2FhkZ9m6S3geF7fnULzJY7e5jEzOjSLHfCB43dZzfzQ4Ba/PaOadDitr MBj98/zGQivllIy8J8e6B5YlhoFkD1kNT9LPMx2sDS1FiW+VluAvu3HX1T5KbfmOwWgoe5Qai4k1 sBeqMbg1KPg4tQv5UDN1Z8yMFiXnJUvrjBp7Pvi5cP5cu4Bs3yzkuJrEru9WwH+sDS2nnRJfo5l6 BbdqZnhqnSM8ZTo0msjnNonlAZfXxJU8zEh2f45btnJUM80YvC6HG8ZCSPMswxtdeGfAUmHGXVVR bqEEi8duh2mBpTkT/9lzf0kbJXAxnrry3O0CecAC9GlBx5ILraA9t0WrpY5qBWWaPreV54t7+lO1 JIMlT2C+QH1AvwdaK0eXfJuHwJN65hGz32Iuepy6B+JRGYaS2eFAZl4XSvrxLJjSjWZrCL9EhMeJ Go/iRNEN7OaIcnDgWZsVeGbiTvo9hrVXLFxbf7cQKnH6wJdu76VprRlkxItTe35DNGiGqdDnKPCy lNYs1I5ee+MlL8FWjjdAiMxxRo7XcRqak7hzV0Z7tvXV4LlPwt+mzcjUh+znYGdkQ/4nkEhvx392 Sq38jtHWM+Md4zfwM1borTojKxZkqXLW4i3xegqsNMtaPCVeb4GFPvcqW+AudImiq9DtLnRKkrPw HbyaPD75Pn01uwXZUQQ1xmx2yZEvefIdQSbkk+xIZEwshLmrHvGtMC2ZefR19qTZWa/uHbPX8EwM NPcfoz6IH7zZHbBHo7+u0bkK3J6AldH8TCsZJUNZvjvfyrGiSTSV+nMLwJ1GMk8jNf+st0gsq7Po /jpgKC7OF40G8C2jvihYKJkkweQCSb40+S4dYLYSSeoeA9/4l++IYr79cXo+khDM3t/Ox6JsfsTX Z+qd+Z722ZNkwcbPby5ajFFasMJo94AYN1CiI+B2B6ws9X1W0guG0rwc2cJpeQMPpEO2iVQtJxHf 5sCjdALLijr+owWSLOfxBoNgtut1gXwfkDyIAR7dRj1C10On7cj5XSRZTvHTesdvek29/T/9zj9d T2l5ySyeu0Kvo1leZ5SoewwS7dXanE6bzmJhrU6XVbJMTqJeupVeT78AcqVg/thPvsXggb8DeoAy fwJ8fgb8WAE6dgF4jMDpWfDXmaBZMAP+nVk8A+6cG1iOwEEFtPIMGLoAfDgNXMd58JuPB350GoSr havFPeIeya3Ct/5nQHcpgacvDHppBrxh2JkFP5sbjJ/FYGJUeGwazD9VwPKZDFh9c8Cb1jdtP7h4 sF81A87MDY7tAD90tjt/gMHV7rqHwE9yPpPzR3ez+2n3055Cz0PeUgLPeJ/Jjf6PQOLv8Hf4b4Dn ZoIv/DfD5b7E3+H/V0Dk92Uo/JeLIfQUYlELZaLoyT9Capr8Hf69F0L7SLpn8j3KRx2Z/DOkxyb/ BOmzkL8Jcn4L6TGSPjv5E2qE5IyQnBGSM0pyRknOKMnZA/T7kD4LfG6g9gN9A9T5ANJjhH4W0n3U MSRC+iySqH2a1OSr+PdlJn8NKW59P+FzBHr7C0hNkH8Eeotp3+Q7kO6ZfBvSI9DnI3DvMeoYdQTR kB5DGkifhfRZyBEhPUboZxGtSQFP/Is95TT+hR8N2eP1kFRDNGUgV5imkU5TijK/RtSsYVSaQV6N W6VZ5NK0qLQW8jepNIf+ohlVaR6Van6r0gKSmaRKi/RdU21JaB2zX6V1qJR5S6X19O2sSaUNqJ97 YOpXhip4m0pTiOOXqDSNtMKDKq1BecKtKs0gg3C3SrNIJ3xXpbWQf0ylObRH+KFK88guiiotIJO4 XKVFqmOqLQmFxMtVWgf1P6/Semq5eIdKG1CN9Cv8602MoOpZoRU9K7SiZ4VW9KzQip4VWtGzQit6 VmhFzwqt6FmhFT0rtKJnhVb0rNCKnhVa0bNCK3p+EMmoAkUBaoBagfpQN0qhITQM2IvSkLcIqBRK kjQOOX1ADaIwlCxE/QAyWgV5+NvN0nAXvkrAZwJqj0LaAzUXwX39UKcL8vqgRh+pFwccAF49pO4g XA1D3iApU+7vgx7IgHH1W7t2w9UuoNLQFq4zAhzTkJ+AK9znEbi7B8oHyfd7yaSfMvmmrwRwUNrE NWSQcYi0mSDfvYZlWUZk7YWcOPlmsBSRQiafcSIlbleRoxtKygjnAZLTTzjGQUdKfqaVAeDTTzSW VHs5CDkDpFWFJ5YzPaMHuMUkkUXRd0bbSt9xS0OgAZl8k9w2ooU+8r1m+Fvm0uQKS5yesoeiM6UV mfR9UJVriOi2i9Sc7vFMibDWxsh9itQ74DpM/GGmNYsJtwHCYTfRw4hq+Zn6xhZT5E+Q/mP5Fbuk iDfgT6VFbGsZeCSnpFH6uE2tMwxXV6nc0yCFYqHRKSvFiY/EIXcgS66MN+NfSouT9rvV9sNzeH3D eXIq9snYv2Fq1FSjdaoX9an+Vg0ccUn2/eVZ9889IhKqbyuSxlXZtpFSpa8JVZu4/z3Eq7EsO4g9 M/fMXdr7qUb3tCcpdlsLV32kD7j91USSdJaNI2oPhmZI0K2OyTSRMkH8fDnkdKMgsX8J1Okh/JeS Xin3psl3IDYAxwhYEkOYjP/snocJ9wGokwa/w/3fRiRIAofdkIut20tkwaMqm2smH88sigV2TPHb SPqsePRu4onDpIdpMuaGyRyh3C0TGfB4TRBv6yNtKBrqIvdmtLcY9LccZkvl3tSMEmWs9xCdTI/f XaStbjK+52pXucZ1u8GLRogOe6bGQw8pxzOOIkFmDCSJpIPqKFB4JUiKR/VsuXG5MnsE4a4S4p0D IFdiajyf36vB8zhfvI6muWdmcFmdgxXv6c6aC8+Xfdpfs/vVOEMDWBJFFmVFyHh9amp16SHz6yCZ Z+MfK6mi53iWThOq988eA1ir2PNGyJ09ZK7C0iSm+OCa/WS++yQL/XeNi+kxEVG/lzSurlJhYqsk GntQrohGa+QVfd2poeGh3rS8aCiVHErF031Dg2F5YX+/vKpv2/b0sLwqMZxIjSZ6wovi/X1dqT65 b1iOywNDPYnUoDwcHxyWobyvV+6ND/T175Z39aW3y8MjXen+hJwaGhns6RvcNiwPQdV0YgDuHOyR u4dSg4nUcFhelpZ7E/H0SCoxLKcS8X65Lw1tdA+XycMDcehBdzwJNL5lYKQ/3ZcEloMjA4kU1BxO pAmDYTmZGoJ+424D9/7+oV3ydui43DeQjHen5b5BOY3lgJ7BLXJ/3yC0NdQrd/VtI4yVhtKJsTTc 3LcjEZZVMYuH5YH44G65ewSEV/qd3g7tJ3bJqTjIkuoDseHG+IA8ksTNAMdtkDPcdxVUTw+BQKNY pLi8K54aUNrCau7eHk9BxxKp8JTqGzJtgjxY/gZsmup1oCIQSq4OR6NqeblSPsMQCdA2NBqH1rb1 4V4loJupeE9iIJ7aIQ/hkhmXvXObmygJZFs72JeG+1en42lF4ggwGCINdIMl06m+xHB4+Uh3MD5c Ivck5KWpIShNp5MNkciuXbvCAxnm4e6hgUh6d3JoWyqe3L470p3uHRpMD6tVMd0bBwF24Hobh0ZA 0bvlkeEEdAJEwsVyHOyaSA30pXGHunaT7i1eu3whlKbIBVi9Z0Sx767tfd3bZ9wLn32D3f0jPVgX Q3JP33CyHxrAFkim+qBCN9RKDKbDcqbtoUFwj2BfiZwY6MI3TbMazFSes0ekOnZwUP8wqKdb8cKp 1oleVV6NpAPBPmgFBgJWfQoPl56hXYP9Q/GZjUKf40pPQfFTFhgaSSdH0qD20b7uBK6zPdGfnCXQ xdiCWCLSk+iNw5AKx4eTYzgem/wzoAtdj+b6R0ENiDyQFXGTk8io/gIsfiQXhM9ONPWbrx/z77Oa YZ2OgjrUxMXW1+tJ/V9dbH2jEden2y62vslE6j9wsfXNZlxfw19sfauVoiia/NYtjxhSH0fcFuVX aZFEuZGD8qF8ahMKU1egRmoItVEjaC01inqpPWgndQO6mtqHbqD2o8MQ9d8JMf/XIOJ/QtOO/hdw fQV4vT6L/8/n4F8A/CPAfz7wbwf+G4B/H/BPA/9rgf8+4H8b8D8K/L8J/J8C/i8A158Ar//M5o9/ I3eKvw74u4B/MfCvBP4twL8D+G8F/ingfw3wvxH4fxH4fxX4fwvu/lfg/yPg/5/A9TTwej+bP/39 OfgHgX8V8G8F/quBfzfwHwX+1wH/m4H/l4H/g8D/u8D/aeD/CvD/JXAFb0Z/zeav+fYM/nrgj38Z OAT864D/MuC/EfhfCfyvBf77gP8Xgf+DwP97wP9p4P8j4P828P9Ak6Lwn4AbsvkzT83gbwD+XuDf CPyXAf/NwH8A+F8L/G8F/vcC/28D/6eB/0vA/2fA/z3qWUqraafygX81cGnE40zLUlptXdvE/v1J TLLRtvHx/Z08S/Fanp/O10bbTo+PJ0l+LJZsa9u/fz9PU7wmhmKx2Pj4uHIRUy60AqUVN6Oe8dbx GxAGwkK5S+U2MUFaIbkT+38O9zCUlkkqt7NwQ11MNpl+zjEUx8RO4+xOzFWYGP8i+Tro59EE4rVQ r7WtraNDjkEHaJ5R2kfjlIZimJ9rtZSWa2rdO3H79hmyCVpK4BiGmS5QhSMFwGBDT+vExESWdAJN CYp0c4uHG1JuI2Rd6969E0lezd07cfrjxOMZCnc6S76J8Vtgo9+LWol8WixfFOQTaFpQ5ZsSkNNS HN+EG7t9O8dSnBZLCCKKHCWCPphMEVTDfTozPj4maqFIlrGQuLuKYEjlK2ooUQOF6iUnUpxu43hv rBUAd2xinLSo3ktoLCrIKnKI48sqAoGW1jG4FXeG3dCpcNEiTlvXGovyE0mBoQRWlk8T/p2Yv7Q3 ti+2b/zwuCIy5sO1tLS2BqPQD9IhqE96hMbHKYZi2NNZUiuiQTMTSYmjJJA6S2xeFVvSQpk8LTdm zMhyRnBJQ0mMPENyieL0lz/VLbcA7I1h+H8sOe5RRvJp0XmO4oXmlpbrrtu7Lw3+xYPsMSK8jqd0 Al4SpkqhKt/U0vLR+PjeMR0HpZjb5V0tLS3Qb1VglBFYp6F0Uwog41mi+CkNZHRAms+wIBdNpLW9 Y9J0yfFH8e14osBqILw4xHNNLaAHZu+YyFKiVpbPKO0kcTu6vfJeGXQRWzO+arwbtSCJRzy/cGFL oCAYxL6v09A67VTvFG2w7GmBpwRxQXf3008/feLkqMBRAu/t6nwK/h0f0wuUXqTGMWjQAohmutHT BE6gkxA74cqCt7f3xEekMg+Vo9Fo5+BwN/w7ceKEnqH0TDQKizH5ByzVnGjnVI6gpwTjYHL49m6X AieiGEivphiRK5/SxxNjuhllb72OeeA5pz+Z4chBx5q6OpN1Xt0+4rPaaPQjtb0kbs9wwnXCdTJ6 MvqTzs2dw0/tfCo+rhOQIMTH4+NYxiKEv2mxDiAK+4inkJ6l9FqXyxVVeo6eeopiKVZ7RtlhiGiM EpGme3eqH9m2pRI7UEV/PD2IYlBCrV7VIiMbwt9gjPdjWpWiEEd2GsoVDauTCdGrVq6QkXvNqktk VKCW4B2dQjHATaFYJCFdd3I4idpJ2kHSdSS9nKRdJN2+A0I/NEjSNEmvIuk4Sa8n6b6pXdKFUuoC KY3P9dUrE5GIgiiWgl6zEOt3EAkYdB3sIKJ0B7qWvpd+Fd2l+bLmy+hlRN0+iLVBb2Nemws4A2cQ X9e9Mw360wrgktlgeM7yegas1wHcYb3DRttoVysG98nZwBk8x33X5dUp4C+dhoANQ9HgnPCL0j9k IGKa92QGajsUqP/D+dDIA7zf9Pw0zL9KAVIyC5q9C1qm4N6PgYdjckxe2I4hu6Tl6rmgkV/U3Nqz WKvAEjQD3sew9PW5oC2wjJmCH7ePZeCS6xRY3rG8Y8XRlbYZ8CbOmw0duhVHVxzt0K0KA7xIAFPh NeE1dWva1+xd8+SaM2sr1oTXNmFQyqZh3dG5ALe84ui6XymwvmEaMP/1v8UptAi44eimDRnY/PAV 3gxsSSmwNQ3wEOBrW1/rNHSWdW7Zmoa0rHO887m4jcCqeBLg4fhrAG/EP+qqiH8EaV1XquufMAD9 Fp4+un3dwe5wdwfAYPcjACe6X+x+RYUzPV09L/a8nzAlNgH0JK5J3JV4MvG6Cr9LnOnV9sYALt0W 3HZk258w9J28cgLDjtIdL/bTKujgqhQ+S8lVaX8bAN3/8MCagdTA4aHBocGd0Z0n+k4qteFTqduW GsP1UtenjqfeHw4OXzo8RuBEWkegOd2TPpr+Onw2p58EODNSMRIb6R35OsAfRpuGTwyfGO0a7Uo/ CentmAJ4aPS1XTSAbpePQNuuh3e9uOvHu348ZhurGbONvjb62tiasdTY1WPXA6wZu2vsJIANl+wu ACyFEtvutt2rruq/6tw/3L5n1Z7L9/SO7/3sWxPeibcynzdO3Dhxs/sLj3zhxP62/atgB/zt/U/s P7H/5f0/3v/bA4YDrgOBA9EDzQfWHNhyoP/AVQeOH3jrwEcHlxxcc7D34NUHrz/4wMHvHXzt4F8O eQ81H1pzaPDQxKGbD91x6KFD/37oncP84cDhssM1h9sOrzqcPnzN4bsOv3mL7ZYtt4zNlXfLwVue v+WNW023lt6avvXhW0/f1nBbeq682+67vQ39I7JMvoisgDZAO6AD0AlYDBgELAEsBQwBNiAnagS8 ZPIEWg64AvBSwJWAHYCXAa4CXA24DnAjYM/kBpQA7AXcPvkM6gO8EnAHYD/gAOAg4BBgEnAnYApw eBLWhMnPoxHAUcBdgGOAV012oH8AvBpwD+A1gAcmX0IHAQ8BHga8BfBWwPsmn0P3Az4A+CDgQ4CP oRL0z4DPTf4I/QDwecAXAE8C/hDwRcCXAH8E+L8BXwb8D8DXAE9NjqFfAP4S8O3JN9CvAH8N+A7g bwB/C/gu4O8A3wM8Dfh7wD9M3oL+OPkN9CfAPwO+D/gB4Icg418A/wr4EeDZyUHqyOSz1JcA7wD8 CuCdgHcB3g14FPAewHsBvwp4H+D9gA8APgj4EODXAL8O+A3AhwG/+X84u/fwuOsy7+O/OJSTHHZ1 H1YfdtcDiooioOBaWHA9oJVdXbddlIOclLpb6j5L1xaxhYKiSEUQa6F7xTSV0vRAaFNCYktLIc10 26QTStJOMpkmzSTM/DrJzGTG0lPY9urveaVbr8t1wUv443OlAZv53ff383nf9zeZIK2hp6mRnqEm aomerdoaNVe1UTtto0TUHPtS9GDs6uDM2DXBabHros/Gro9+FrvRx5t8/Pdoa+z54BPBvuCEqBBM oBPpJDqZTqFT6a10Gp1OZ9DbokEOG+SwQQ4b5LBBDhvksD0ctofD9nDYHg7bw1kZzspwVoazMpyV 4awMZ2U4K8NZGc7KcFYmuDEqBTfRzXQLfYO+SfdEB4N76fv0A/p5NMQdQ9wxxB1D3DHEHUPckeaO NHekuSPNHWmuyHBFhisyXJHhigxXZLgiwxUZrshwRYYrMlyR4YpMsNtrDFCGBmmIXqZslOWWLLdk OSDNAUMcMMQBQxwwxAFDwViU5IIkFyS5IMkFSS5IVr0l6quK0Qk0gU6kk+hkOoVOpbfS6dHuqjPo T6Khqj+lt9Hb6c/o/9BZ9Of0Dnon/V9/52z6C/qraFfVu+jd9B56L51D76P307n0AfpgFK/6EJ1H H6aP0Pn0UbqALqSL6GP0cbqYLqFP0F/TJ2kiXUqX0d/Q5XQFfYr+lj5Nn6HP0ufoSvo8fYEm0Rfp Kvo7+nv6En2Z/oG+opZ/pMk0hf6JvhVVqmbRHfRdupO+R7PpLrpbXXPpHrqXvk8/oPvoh/Qjup9+ TA/QPH/nQV/3pz4+RA/Tz8bfYROF0hpKayitobSG0hpKayitobSG0hpKayitobSG0hpKayitobSG 0hpKayitobSG0hpKayitobSG0hpWNXutX9NaWkfP0nraQM/RRnqeXqCWqKtqU7SzqpXitJn+k7b6 523UTtsoEXVJ9Ehw3xtK863Ri3j+Ip6/iNG9GD2I0YMYPYjRgxg9GHwvegmnN+P0ZpzejNObcXqz ZBYksyCZBcksBPdFB4If0o/ofvoxPUDz6Cf0IP2UslKdo5BekZp90W5J2i1JuyVptyTtlqQuSUpJ UkqSUpKUkqQU9+a4N8e9Oe7NcW+Oe3Pcm+PeHPfmuDfHvTnuzXFvjntz3Jvj3hz35rg3x7057s1x b457c9yb494c9+a4N8e9Oe7NcW+Oe3Pcm+PeHPfmuDfHvTnuzXFvjntz3Jvj3hwH5Tgox0E5Dspx UI6DchyU46AcB+U4KMdBOQ7KcVCOg3IclOOgHAflOCjHQTkOynFQjoNyHJTjoBwH5TgoxxWFqi2c tNWf26idtlEiysWujrJY34fzfcGngzPdBj8QlbG5jM1lbC5jc9n0P930Px2jSxhdwugSRpcwuoTR JYwuYXQJo0sYXcLoUnCr29VU+ha9/pR+CYdfwuGXcPglHH7JlH6HKf0OPO7C4y487sLjLjzuwuMu PO7C4y487sLjLjzuwuMuPO4ymfMmc95kzpvMeZM5bzLnTea8yZw3mfMmc95kznNNRfWHYteZdtcH 18Zu9PGm4Foz7gQ+nkAn0kl0Mp1Cp9Jb6TQ6nc6gM6PR4FLT6zK6VSam0rfoOz6fqXOz6A76Lt1J 34t2ykevfPTKR6989MpHr3xU5KMiHxX5qMhHRT4q8lGRj4p8VOSjIh8V+ajIR0U+KsGz0b5gPY3R 0WjMJXysKqCqaEx1m2LXRG3Ot+J8K1XuuNEClS1Q2QKVLVDZApUtUNkClS1Q2QKVLVDZApU9bn6X ze+y+V02v8vmd9n8Lr+2R6KFurCQR8o8UuaRMo+UeaTMI2UeKfNImUfKPFLmkbI5njPHc+Z4zhzP meM5czynSwUdOaAjB3TkgI4c0JGlOrJUR5bqyFIdWaojS3VkqY4s1ZGlOrI0eCQ6wm/t/NbOb+38 1s5v7fzWHiz07/6Dfkk1tIhqaTH9ih6nJfQELaU6WubvLacVtJKepHr//ClaTQ20hp6mRnqGmqiZ fk1raR09G610UiuDDf78HG2k5+kFaqFWitNm+k/aQlupjdppmw02QR30Im2nl6iTumgH7aQkdVOP v5OiXn9O+7iL+qifdkdFe0vR3lK0txTtLUV7SxFtM2ibQduMLJVkqSRLJVkqyVJJlkqyVJKlkiyV ZKkkS+NkfhmZs8icReYsMmeROcuV7ci8B5n3IPMeZN6DzHs4tZNTOzm1k1M7j72fNUYn0AQ6kU6i k+kUOpXeSqdHCTtPws6TtfNk7TxZO0/WzpO182TtPFk7T9bOk7XzZI+9N/Zs+gv6KzvQu+jd9B56 L51D76P307n0AfqK/+0/0mSaQv9ENwdvr7ol+GLVN4K/rPpm8N6qW4PT7Rlh1fTgbXaN0K4R2jVC u0Zo1wjtGqFdI7RrDNk1huwaQ3aNIbvGkF1jyK4xZNcYsmsM2TWG7BpDdo0hu0Zo18jZNUK7RmjX CO0aYdUjUX/Vz2k+/YIW0KP0GC2kZv+bX9NaWkfP0nraQM/RRnqeXohCVLgUFT4X+3b0a3ehM6ND uHUQtw7i1kHcOoBbh3DrEG4dwq1DuHUIs4YwawizhjBrCLOGuOUItxzhliMc8F8ccJgDDnPAYQ44 zAGHnf4Rp3/E6R9x+kec/hHzKLSlFG0pRVtK0ZZStKUUzaj9rzWjghP1/zT9f7v+n6b/p/2WaME7 Ea0f0foRrR/R+hGtH9H6Ea0f0foRrR/R+hGtX60jyFJCkhKSlJCkhCQlJCkhSQlJSkhSQpISkpR0 KtSpctWf4GAjDjbiYCMONuJgIw424uAaHFyDg2twcA0OrsG/xfi3GP8W499i/FuMf4vxbzH+Lca/ xfi3GP8W418Z/8rj/69c+FfGvzL+ld2WB92WB92WB92WB92WB92WB92WB92WB92WB92WB92WB53W bqe122ntdlq7ndZu/GvGv2b8a8a/Zvxrxr9mLGvEskYsa8SyRixrNG/PMm/PwpdmfGnGl2Z8acaX ZnxpxpdmfGnGl2Z8acaXZnxpxpXmP8CR7ZyxnTO240gHjnTgSAeOdOBIB4504EgHjnTgSAeOdOBI Bxdt4aItXLSFi7Zw0RYu2oIjeU5q46Q2TmrjpDZOasONnbixEzd24sZO3NiJGztxYydu7MSNnbix Ezf6caMfN1K4kcKNFG6kcCOFGyncSOFGCjdSuJHCjZ24sRM3duJGN25040Y3bnTjRjdudONGN250 40Y3bnTbNou2zaJts2jbLNo2i7bNom2zaNss2jaLts2ibbNo2yzaNou2zaJts2jbLNo2i7bNom2z aNss2jaLts2ibbNo2yzaNou2zaJts2jbLNo2i7bNom2zaNss2jaLts2ibbNo2yzaNou2zaJts2jb LOLaTlzbiWs7cW0nru2sujF4j2y9T7aulq33yta52Pa+Y3eo6T7/w/eoXmzrxbZebOvFtl5s68W2 XmzrxbZebOvFtl5s6z1+j9r5v+5Rj0jYz2k+/YIW0KP0GC2kanewX1IN1dJi+hU9TkvoCVpKdbSM ltMKWklPUj09RatoNTXQGnqaGukZaqI3ds+qQbDHEexxBHscwR5HsMfR60n0ehK9nkSvJ9HrSfes gWCJzfqzKPICiryAIi+gyAso8gKKvIAiG1FkI4psRJGNKLLRxv1OG/c70WQjmmxEk41oshFNNqLJ RjTZiCYb0WQjmmxEk404fguO34LjtyDIcgRZjiDLEWQ5gixHkOUIshxBliPIcgRZjiDLj3+/7V4U uRdF7kWRe1HkXsy/HvOvx/zrMf96zL/ejfHs4If0I7qffkwP0Dz6CT1IP6Wf2zrm0y9oAT1Kj9Ey yV1OK2glPUnPBlch0FUI1IpArQjUikCtCNSKQK0I1IpArQjUikCtCNSKQK0I1Io0S5BmCdIsQZok 0iSRJok0SaRJIk0SaZJIk0SaJNIkkSaJNA8gTR3S1CFNHdLUIU0dysxBmTkoMwdl5qDMHA5Mc2Ca A9McmObANAemOTDNgWkOTHNgmgPTHJjmwDQHpjkwzYFpDkxzYJoD0xyY5sA0B6Y5MM2BaQ5Mc2Ca q1Zy1RquWsNVa7hqDVet4ao1XLWGq9Zw1RquWhO7OvhTU/Cy2PXR/zMJL4vd5ONd0SOxu6MbYs8H E2PZ6LFYLrgwFgYfieWD82IjUW+sELwluNzEHDExR0zMERNzxMQcMTFHTMwRE3PExBwxMUdMzBET M2+vD+31IXdt465t3LXt+O2mwDEFjilwTIFjCqZrnGsSXJPgmgTXJLgmYZfvs8v32eX77PJ9JvBe E3ivCbzXBN5rAu81gfeawHtN4L0m8F4TeK+duWRnLuF/zs5YsTNW7IwVO2PFtnCwqoNepO30UnTQ xN5hYg/pTNmd7jSdKbvTnRY0qHququeqeq6q56p6rqrnqnququeqeq6q56p6rqrvVPV3Vf1dVb+q 6ldV/aqqD6pwQIUHVHhAhQdUeECFB1SYVWFWhVkVZlU4X4XzVThfhfNVOF+F81U4X4XzVThfhfNV uEWFW4JsEAtyFAaxN/AdwJSplnoDU+13vwOYMtVSplrKVEuZailTLWWqpUy1lKmWMtVSVR+06X6I zqMP00fofPooXUAX0kX0Mfo4XUyX0Cfor+mTNJEupcvob+hyuoI+RX9Ln6bP0Gfpc3QlfZ6+QJPo i3QV/d34b1LRl+jL9A/0Wt8BvNtzz6V76F76Pv2A7qMf0o/ofvoxPUDj392r9rV+STVUS4vpV/Q4 LaEnaCnV0TJaTitoJT1J9fQUraLV1EBr6GlqpGeoibZSG7XTNkoEp3PtO7n2xNh1wRlce2HsRh9v 8vHb0YPjvwEYnG96fP7Y+7kvG38vdrSDI3dw5A6OzMhhSQ5LcliSw5IcloLvBSdyaTuXtnNpO5e2 c2k7ek9E74noPRG9J6L3RPSeiN4T0Xsiek9E74mIfCUiXxmMBR8MjgbvDqLg3VXj/3WUKpoW/GPV luBsBJoW+2qAQMFJnvak2LeDB2L3BO+KfZ/uC/4yuOsNfffgjX3XILQ1h7bm0NYc2ppDW/M4obbr zHad2a4z23Um1JlQZ0KdCXUm1JUeXenRlR5d6dGVHrMqZValzKqUWZUyq1JmVcqsSplVKbMqZVal zKqUzkzQmQlm1aBZNWhWDZpVg2bVoFk1aFYNmlWDZtWgWTVoVg2aVYNm1aD5VDafyuZT2Xwqm09l 86lsPpXNp7L5VDafyuZT2XzKmk9l86lsPpXNp7L5VDafSuZTyXwqmU8l86kky/2y3C/L/bLcL8v9 stwvy/2y3C/L/bLcLxc9ctEjFz1y0SMXPXLRIxc9ctEjFz1y0SMXPXLRYx7tMY8y5lHGPMqYRxnz KGMeZcyjjHmUMY8y5lEmdk1wKoeegIQT6EQ6iU6mU+hUeiudRqfTGXSpLl5Gt0avOLVXnNorTm3I qY06tVGnNurURp3aKOrud3KhkwudXOjkQicXmv4p0z9l+qd0rFPHUjqW0rGUjqV0LGV29Ovac7r2 nK49p2vP6dpzx6v7jep+o7rfqO43qvuN6vKqy6sur7q86vLmScmkfcU8KZm0r1SdpdJpKp2m0mkq nabSaSqdptJpKp2m0mkqnabSaebJv8pCnyz0yUKfLPTJQp8s9MlChyx0yEKHLHTIQofZs9Xs2SoT HTLRIRMdMtEhEx0y0SETHTLRIRMdMtEhEx3BrRI3lb5F90WTzJ5JZs8ks2eS2TPJ7Jlk9kwyeyaZ PZPMnknBI9EzvH8D79/A+zfw/g28fwPv3xAs9O/+g35JNbSIamkx/YoepyX0BC2lOloWXSMv18jL NfJyjbxcE9T750/RamqgNfQ0NdIz1ETN9GtaS+vo2ehRM/HRYIM/P0cb6Xl6gVqoleK0mf6TttBW aqN22hZNlc2psjlVNqfK5lTZnCqbU2VzqmxOlc2psjlVNqcGPf5Oinr9Oe3jLuqjftodrXfDXe+G u94Nd70b7no33PWyXC3L1bJcLcvVslwty9WyXC3L1bJcLcvVslzNmWs5cy1nruXMtZy5ljPXcmYT Zw5w5gBnDnDmAGcO2HT6bTr9Np1+m06/fWCyfWCyfWCyfWCyfWCyfWCyfWCyfWCyfWCyfWCyfeCf 7QP/bB+41j5wrX3gWvvAtfaBa+0D19oHrrUPXGsfuNY+cK19YLJ9YLJ9YDKGTMGQKRgyBUOmYMgU DJmCIVMwZAqGTMGQKebtZPN2snk72bydbN5Odov8qFvkP7lF3u8WebVb5K1ukV90i6x1i7zKLbLW LbLWLbLWLbLWLbLWLbLWLbIWk6Zg0hRMmoJJUzBpCiZNwaQpmDQFk6Zg0hRMmoJJU9wia83ryW6R tW6RtW6RtW6RtW6Rt7lF3uYWeZtb5G1ukbe5Rd7mFnmbW+Rtbne1bne1bne1bne1bne1bne1bne1 bne1bne1bne1bne1x/fwOmSoQ4Y6ZKhDhjob51PosAwdlqHDMnRYhg7LbKEzbaEzbaEzbaEzzfNL Yl+NHo59LZptrn/CXD/LlLzAXD/LpLzAXH/UXL859ny0LJYNLrKjx2J70GUkuF56TzDXJ9CJdBKd TKfQqfRWOo1OpzPoTG651BS47Nh3tf7Ynxj8dqc+4kn7POHuqphXXeFVV3jVFV51hVdd4VVXeNUV XnWFV7Xt0Bl0ZvTtPzDb83iWxzO3DvrwsRvEGk84/p2xEM9CPAvxLMSzEM9CPAvxLMSzEM9CPAvN +P1m/H4zfr8Zv9+M32/G7w++E5ys0tkqna3S2SqdrdLZKp2t0tkqna3S2SqdffwnAbX4VotvtfhW i2+1+Fb7Jn8SUItvtfhWi2+1+Fb7Jn8S8N87/5v/SUA9vtXjWz2+1eNbPb7V41s9vtXjWz2+1eNb Pb7V/85PAupf4ycBm/BtE75twrdN+LYJ3zbhWwrfUviWwrcUvqXwLYVvKXxL4VsK31L4ljr2Toaj 0WHMOoxZhzHrMGbVYFYNZtVgVg1m1WBWDWbVYFYNZtVgVg1m/QyzfoZZCzFrIWYtxKyFmLUQsxZi 1kLMWohZCzFrIWbVYFYNZtVgVjVmVWNWNWZVY1Y1ZlVjVjVmVWNWNWZVY1YNZtVgVg1m1WBWDWZd iFmfwqzbMetzmPVNzLoMs+KY9QnMimNWHLPimBXHrDhmxTErjlkrMWslZq3ErJWYtRKzVmLWSsxa iVkrMWslZq3ErJWYFcesGsyKY1Ycs+KYFcesFZi1ArNWYNYKzFqBWSswawVmrcCsOGbFMSuOWXHM imNWHLPimBXHrDhmxTErjkshLoW4FOJSiEshLjXgUgMuNeBSg7Rfh0sLcGntMS5dH1yMRxcf59F8 DHoOg66uOgkNlqLBUjRYigZL0WApGixFg6VosBQN3IXoDDozuhsNimhQRIMiGhTRoIgGRTQooUEJ DUpoUEKDEho0okHjG/pZ8o3RITQ4hAaH0OAQGhxCg0P2woNoMA8N5qHBPDSYhwbz0GAeGsxDg3lo MA8N5qFBBQ2a0KAJDZrQoAkNmtCgCQ0qaFBBgwoaVNCgggYVNKigQQUNKmhQQYMKGlTQoIIGTWjQ hAZNaNCEBk1oUEGDChpU0KCCBhU0qKBBBQ0qaFBBgwoaVNCgggbjPF6PBuvRoIIGFTSooEEFDSpo UEGDChpU0KCCBhU0qKBBBQ0qaFBBgyY0aEKDJjRoQoMmNGhCgyY0aEKDJjRoQoMmNGhCgwoaVNCg CQ0qaFBBgwoaVNAgiwZZNMiiQRYNsmiQfYM/C6zYdvbYdvbYdvbYdvbYdvagRMfr/CwwixxZ5Mgi RxY5GpCjATkakKMBORqQowE5GpCjATkakKMBOdYgxxrkWIUcq5BjFXKsQo5VyLEKOVYhxyrkWIUc q5CjATkakKMBOVYjx2rkWI0cq5FjNXKsRo7VyLEaOVYjx2rkaECOBuRoQI4G5GhAjrOR40PI8W3k +DhyfAw5PoIc7cjxQeRoR4525GhHjnbkaEeOduRoR4565KhHjnrkqEeOeuSoR4565KhHjnrkqEeO euSoR4525GhAjnbkaEeOduRoR45tyLENObYhxzbk2IYc25BjG3JsQ4525GhHjnbkaEeOduRoR452 5GhHjnbkaEeOdtvOAHp0oEcHenSgRwd6dKDFVLRIIMXHkeJMpDgTJVYE9dLeKu2t0t4q7a3S3irt rdK+Sdo3Sfsmad8k7ZukPC7lcSmPS3lcyuNSHpfyuJTHpTwu5XEpj7/uu/p+jhbz6Re0gB6lx+i1 f5p1vvv5+VLRKBWNUtEoFY1S0SgVjVLRKBWNUtEoFY1S0SgVjdLQyP0l7i9xf4n7S9xf4v6SW2a7 W2a7W2a7JGyWhM2SsFkSNkvCZknYLAmbJWGzJGyWhM2SsFkSXpSEbknoloRuSeiWhG4p6JSCTino lIJOKeiUgkgKIimIpCCSgm4p6JaCbinoloJuKeiWgm4p6JaCbino5upuru7m6m6uTnN1mqvTXJ3m 6jRXp7k6zdVprk5zdZqru7m6m6u7ubqbq7s5M82Zac5Mc2aaM9OcmebMNGemOTPNmWnOTHNmmiu7 q6qjoapfUg3V0mL6FT1OS+gJWkp1tIyW0wpaSU9SPT1Fq2g1NdAaepoa6RlqouYow6XtdvJOO3mn nbzTTt5pJ+/k3G7O7ebcbs7t5tzuYzd1t3Ru/YVknhBNN8umm2XTzbLpZtl0s2y6WTbdLJtulk03 y6abZdPNsn/h7q3cvZW7t3L3Vu7eyt1bubuNu9u4u42727i7zSx7wix7gssTXJ7g8gSXJ7g8weUJ Lk9weYLLE1ye4PIEl+/l8r1cvpfL93L5Xi7f+7/eu3pfdIu5dou55l5FP6YHaB79hB6kn9IjUYuE zJCQGRIyQ0JmSMgMCZlhrrWYay3mWou51mKutZhrLeZai7nWYq61mGst5lqLudZirrVI1Z1SdadU 3SlVd0rVneZai7nWYq61mGst5lqLudZirrWYay3mWou51mKutZhrLeZai7lWba5Vm2st5lqLudZi rrWYay3mWou51mKutZhrLeZai7nWYq61mGst5lqLBM+R4DkSPEeC50jwHAmeI8FzJHiOBM+R4DkS PEeC55hrLeZaiyTPMddazLUWc63FXGuR7MWSvViyF0v2YsleLNmLJTsp2UnJTkp2p2R3SnanZHdK dqdkd0p2p2R3SnanZHdKdqdkt0p2k2Q3SXaTZDdJdpMZ9yvp3iHdO6R7h3TvkO4d0r1esNdL93rp Xi/ds6R7lnTPku5Z0j1LumdJ9yzpniXds6R7lhk324ybbcbNNONmmnEzzbiZZtxMM26mGTfTjJtp xs0042aiwSw0mIUGs9DgdjS4HQ1uR4Pb0eB2NLgdDW5Hg9vR4HY0uL3qg1Gi6kN0Hn2YPkLn00fp ArqQLqKP0cfpYrqEPkF/TZ+kiXQpXUZ/Q5fTFfQp+lv6NH2GPkufoyvp8/QFmkRfpKtIjqrkqEqO quSoSo7QahZazUKrWWg1C61mVd0QDR/7rsNNUZ9ZfKFZ/B2z+BKzeLLEX24WL6qahhrT/btZ/nwH fZfupO/RbLqL7o5moN4M1JuBejNQbwbqzUC9Gag3A/VmoN4M1JuBejPM40XIN8s8XmQeLzKPF5nH i8zjh8zjh8zjh8zjh8zjh8zjh8zjh8zjh6pkEC2TaJlEyyRaJtEyiZZJtEyiZRItk2iZRMskWibR MomWSbRMomUSLZNomUTLJFom0TKJlkm0TKJlEi2TaJlEy0Vm/yKzf5HZv8jsX2T2LzL7F5n9i8z+ RWb/IrN/EaquR9VWVG1F1VZUbUXV1qot0Vpk3YSsm5B1E7JuQtZNbhRL3CiWuFEscaNYYke4wo5w vxvF/faES+wJZ9sTznaj+AH6Phh7OTriVrE/NhwddLP4aKwQHQ1WvKHvEr8tGkbjYTQeRuNhNB5G 42E0LqBxAY0LaFxA4wIK51E4j8J5FM6jcB6F8yicR+E8CudROI/C+WCm++osuoO+S3fS7Oi/gjl0 F91Nc+nnUQ+y9iBrD7L2IGsPsvagZA9K9qBkD0r2oGSP3eNiu8fFyNWDXD3I1YNcPcjVg1w9yNWD XD3I1YNcPcjVg1w9iNWDRIeR6DASHUaiAhIVkKiARAUkKiBRAYkKSFRAogISFZCogEQZJBpGomEk GkaiYSQaRqFhFBpGoWEUGkahYdQZRZ1R1BlFnVHUGUWdUdQZRZ1R1BlFnVHU2Y86+1GnhDol1Cmh Tgl1SqhTQp0S6pRQp4Q6JdQZRZ1R1BlFnRHUGUGdEdQZQZ0R1BlBnRHUGUGdEdQZkepRqR6V6lGp HpXqUYl+uzR/RJpvk+aLpPnT0vx+Kf6QpGYlNSupWUnNSmpWUrOSmpXUrKRmJTUrqVlJzUrpKHcn uTvN3WnuTnN3mrvTnL2Ls3dx9i7O3sXZuzj3fM49n2uTwZVOPe/U804979TzTj3v1PNOPe/U8049 79TzTj3v1N/t1N/t1PNOPe/U804979TzTj3v1PNOPe/U804979TzTj3v1PPm0lFz6ai5dNRcOmou HTWXjnLDHdxwBzfcwQ07uGEHN+zghh3csIMbdnDDDm7YwQ07uGEHN+zghpXc8BQ3PMUNT3HDU9zw FDfcxQ13ccNd3HAXN9wV+1K0LHZ1cHrsGrou+pqt6fnY16O/i90Q1cVu9PlNPr/Z57f4/N+j/cFl NpKCjaRgIynYSAo2koKNpGAjKdhICjaSgo2koHsv697Luvey7r2sey/r3su6t0v3duneLt3bpXu7 3tTP0XZ7jQHK0CAN0cvHslBQfUn1JdWXVF9S/fh3Oks6UNaBsg6UdaCsA2VT+YCpfMBUPmAqH4jd 4IZzy7FbTjm4RLVl1ZZVW1ZtWbVl1ZZVW1ZtWbVl1ZZVMKaCMRWMqWBMBWMqGFPBmArGVDCmgjEV jKlgTAVjKnhVBa+q4FUVvKqCV1XwqnPvcu5dzr1LNT2qGVTNoGoGVTOomkHVvKiaDarZoJoNqtmg mg2qyakmp5qcanLH3r14XdTvTHPOsz82/h7rDwcPB3/mfAacz4DzGXA+A85nwPkMOJ8B5zPgfAac z4DzGeDu07j7NFUOqHJAlQOqHFDlgCoHVDmgygFVDqhyQJUDqhxQ5fjvvh30tGlPu8/T7vO0+zzt Pk+773+88/7rQUzvz/3tO/BjN/v8luDc4IPOIHQGoTMInUHoDEJnEDqD0BmEziB0BmHwcDRi36zY Nyt6uFUPt+rhVk8wqIdFPSzqYVEPi3pY9FQbPVWvp+r1VL2eqtdT9erhsB4O6+GwHg57ym3mWqc+ btfHhD5u18dE7BvRYOybvvYXPWHcE8Y9YdwTxj1h3BPGPWHcE8Y9YdwTxj3hSn0f1vdhfR/W92F9 H9b3YX0f1vdhfR/W92F9H1bN06p5Wt+H9X1Y34f1fVjfh/V9WN+H9X1Y34f1fVjfh/V9WN+HuWuU u0a5a5S7RrlrlLtGdWO3bmR0I6MbGd3I6EbmeD7GdGNMN8Z0Y0w3xn7/HTe6cadu/LNzO8W5nefc Jji39zi3U5zbec5tgnN7j+58VXe+aguIx14Kzgveofrx38U7qvqjqj+q+qOqP6r6cdZVnFfFeVU8 4X5PuM8T7vOE+zzhPk84/tsNA55wyBMOecIhTzjkCYe8+kle8aTgLf50sj+dHPyFE8k4kYwTyTiR jBPJOJGME8k4kYwTyTiRjGcq6NSYTo3p1JhOjenUmE6NHevIUc8cRQdVf1D1B3/7bmCvNF7lBFW+ rMqXg6u84pBXHPKKQ15xyCsOecUhrzjkFYe84pBXHNKBeh2o14F6HajXgXodqHf+9c6/3vnXO/96 51//O7mrc/51zr/O+dc5/zrnX+f865x/nfOvc/51zr/O+dc5/7rXPf981GeS9JkkfSZJn0nSZ5L0 mSR9JkmfSdJnkvSZJH1OInyd37WqOIndTmK3k9jtJHY7id08MYEnzuWJU3Xocp6YwBPn8sSpunU5 pvYHfx/cF3wo+CH9iO6nH9MDNI9+Qg/ST+nh4NN/IC1dutWlW1261aVbXbo1UbcmvqnfGcpG9/Df Pfx3jw516VCXDnXpUJcOdelQlw516VCXDnXpUJcOjfP5Th2ap0PzdGieDs3ToXm6c6Pu3Kg7N+rO jbpz47Hfqr3Ornx9NAtHLjBj/w1LrjBjZ+HJBWbsv8XuiubE7o6ujnUGH4h1Be+K7cS/C//on+qN u/nZaA9m7PkDW8U2lW5T6TZPn3/NvfG/v0ubUEFCBQkVJFSQkIY+aeiThj5p6JOGpDRkj7/T7kRV bT/+brsTVbRdOsLY+HtyxgnZpIImFTSpoEkFTSpoUkGTCppU0KSCJhXMc+YVZ15x5hVnXnHmFWc+ /r32ojMvOvOiMy8686Jq16p27Zucv6/3e7sHdeigDh3UobHX/I2GseglHaroUEWHKjpU0aHK7//U Xoe+rEMXS8ZbdOgiqThBKt6iQxdJxAk6dKUOXYmSNeOTLjhHMs6RjHMk4xzJOEcyzpGMcyTjHMk4 RzLOkYwruP393P5+T9vpaTs9befx9wu9Vl4jT9vvafs9bb+n7fe0ni74VuyrwSedX6+zG3B2vc5t IPYNmf0mfTv4Yeye4H2x7+P5fbbbK5xj3jnmnWPeOeadY9455p1j3jnmnWPeOeadYegMQ2cYOsPQ GYbOMHSGoTMMnWHoDENnGDq70NmFzi50dqGzC51d6OxCZxc6u9DZhc4udHahswudXejsQmcXOrvQ 2YXOLvy937l+vXdPZXQioxMZncjoRMa5FZxbwbkVnFvBWZ1yzM03+cjJweUq36fyfSrfp/J9Kt+n 8n0q36fyfSrfp/J9b+zWEB3h3vGf5RZ0oKADBR0o6EBBBwo6UNCBgg4UdKCgAwUdKOhA4Q/ke0QH RnRgRAeGdWBEB0Z0YEQHRnRg5Pisz+tCXhfyupDXhfF3OLkDRUf5YBcqHcXSP/b37R6OHlF5WuVp ladVnlZ5WuXp1/6vMJjl62mb3iaog16k7fQSdVIX7aCdlKRu6nUmV0dPxL4atcW+FnXJ1vdl68+P /RTz687qhuAr8vXnx36iebPPb/H5N6LHZOwxGWs2gZ63jVwZ2xHtjyVV2h18M/hTVaZVmVZlWpVp VaZVmVZlWpVpVaZVmVblkCcve/Kyp8h59Zyv3uer9wWf9FXW+SrrfJV1vso6X2Wdr7LOV1nnq6zz Vdb5Kut8lWV69YpevaJXr+jVK3r1il69olcFvSroVUGvCno1TvRhrzj8ZlziKW/Tqw69ava0P9Cr k/TqC3p1pl7drFfj79v8gl6N33puVs0jqnlErx4e/50FvbpKrw7q03XHbkNtKmxTYZsK21TYpsI2 FbapsE2FbSpsU2GjCgsqLKiwoMKCCgsqLLxOhXtVuPdN7bljx7ay+arsVeVOVf7r8SrPOu6I7xyv 8qzjjviOKmtUWaPCl4IPeNK4J4170rgnjXvSuCeNe9INnnSDJ93gSTd40g2/887PhCdNeNKEJ014 0oQnTXjShCdNeNKEJ0140oQnTXjSxOv9ZOlY4v57i/6X8dQd36D/xdOtDD6j56v0fJWer9LzVXq+ Ss9X6fkqPV+l56v0fJWe/0IlHSrpUEmHSjpU0qGSDpUkVJJQSUIlCZUk9Pywnh9WSb9K+lXSr5J+ lfSrpF8l/SrpV0m/SvpV0q+SfpX0q+SwSg6r5LBKDqvksEoOo+gRFD3y/5m79/CoyzP/4998B4LF AUUtFmlt66HVegbxWGsrtWDVbtVqXXDt2rW91GpbpUR0qyjFAyiora2lUlHBEyoRhFFDJhhCkEM4 BEMgB8MhCYGBBBGYgKdnXzOkXXe33f25f+z1u7zezpD5Pqf7c9/389yZyXxl0Q9l0dwni8bl3z38 Yf6cMKnrfHiE1faz2vFd58MjrLifFY+ny4N0eTBfM9wi0ldE5+UjdXV0UjSQJbIskWWJLEtkWSLL ElmWyLJEliWyLJGrMVpYoYUVWlihhRVaWKGFFVpYoYUVWlihhRVa6LkfPfdjhZYo91eGVViG5ViB lajGKryNGqzGWvztv3TcK6vulVX3yqp7ZdW9+U99/VN0ev5TX9d4vCWsin5QcEz4uOBYfA3H4Xic gBNxEk7GKRiAgTgVg3AaTscZOBNn4Wx8HefgGzgX38S3cB4G49s4H9/BEAzFBfguLsRFuBjfwz8g d7ebxzEZT2AKnsRTeBpTMQ3P4Fk8h+fxAqbjRbyElzEDxXgFMzELr2I23gw783e1mY8KLEAlFoba /F12FmExlmApqsKWgmVYjhVhiz1rtf1qdXQViwYWDSwaWDSwaGDRwKKBRQOLBhYNLBpYNLBoYNHA ooFFA4sGFg0sGlg0sGhg0cCigUUDiwYWDSwaWDSwaGDRwKKBRQOLBhYNLBpYNLBoYNHAooFFQ/5e P4/gt/gdHsXv8Qc8htxdgB7HZDyBKXgST+FpTMU0PINn8RyexwuYjhfxEl7GDBTjFczELLyK2XjT WLl7Dc1HBRagEgvDmvzdhxZhMZZgaf7va5pZvJnFm1k8d9ovZ/HyaGD+fkkJdEN3FKIH9sNn0BP7 5+6gFDoK+uAgHIxD8Fn0xaH4HPohd8+l/vg8cnde+iK+hC/jCByJo3A0voKv4vu4BJfiMvwAufs1 3YnRuAt3YwzUUQXqqAJ1VIE6qkAdVXB//i8Sd0Y9Cw6IDi8YhhtxE36BX+Jm3IJfYXx0eHS/dbdZ d5t1t1l3m3W3WXebdbdZd5t1t1l3W0GvsKqgNw4M66x/nfWvs/511r/O+tdZ/zrrX2f966x/nfW3 WX+b9bdZ/3rrX2/9661/vfWvt/711r/e+tdb/3rrX19wTNS94Fh8DcfheJyAE3ESTsYpGICBOBWD cBpOxxk4E2fhbHwd5+AbOBffxLdwHgbj2zgf38EQDMUF+C4uxEW4GN/L3XoW37eWS3ApLsMPkLtD 1Z0YjbtwN8ZAdUGfNvq00aeNPm30aaNPm+jZI3r2iJ49omeP6NkjevaInj2iZ0/Bm1GyoDzqUTAf FViASrzl54uwGEuwFFU0X4blWJH/ndYU+9Mf7U/9ZOtf2pf6yda/lKk35f+a5cnomMRcJ8pybIwO SjRHlyVaokMSrdFhibbo6MRmz7fYqzLRgYmt0anRMfm7fj2OyXgCU/AknsLTmIppeAbP4jk8jxcw HS/iJbyMGSjGK5iJWXgVs/GmOjN3b7H5qMACVGIhi+XuErYIi7EES51Uh4USsVsS/fBTfNtCHR+u y99nrA8OwsE4BJ9FXxyKz6Ef/uO3LWT4cIYPZ/hwhg9n+HCGD2f4cIYPZ/hw5m9+28Kn95GW/D3P HsdkPIEpeBJP4WlMxTQ8g2fxHJ7HC5iOF/ESXsYMFOMVzMQsvIrZ+b86/Kiroh/SVc0Pyd1pjY/0 TZRFR+RfyX3Ku68Kf9/vSS/o+v3oBVFveSYpzyTlmaQ8k5RnkvJMUp5JyjNJeSYpzyS1PEbLS7U8 RstL8y37a9lfy/5a9teyv5b9teyvZX8t+2vZX8svafkzLb+k5c/yLXtr2VvL3lr21rK3lr217K1l by17a9lby69oeayWX9Hy2E/dclBXy0F5Gxzv2fHRP/K1Mr5WxtfK+FoZXyvja2V8rYyvlfG1Mr5W xtca+FoDXyvna+V8rZyvlfO1cr5WztfK+Vo5Xyvna+V8rYyvlfG1Mr5WytdK+VopXyvla6V8rZSv lfK1Ur5WytdK+VoZXyvja2V8rYyvlfG1Er5WwtdK+FoJXyvhayV8rYSvlfC1Er5WwtdK+FoJXyuT j9rlo3b5qF0+apeP2uWjdvmoXT5q54tZvpjli1m+mOWLWb6Y5YtZvpjli1m+mOWLWb6Y5YtZvpjl i1m+mOWLWb6Y5YtZvpjli1m+mOWLWb6Y5YtZvpgtmKPmuSXMjvrIBZ1/Z1+vzd9tcBEWYwmWoiq0 yoKtsmCrLJj7TpCG6BAaVNGgSj49OH8XwvmowAJU5u4aGO0vn+4vn+4vn+4vn+6v5U/lzyu7/sZh eNffOAzP/93i8fk7Fz6OyXgCU/AknsLTmIppeAbP4jk8jxcwHS/iJbyMGSjGK5iJWXgVs5H7hqu/ fZLc8rdyofV3WH+H9XdYf0f+fbKrVTcnmHHGjDNmnDHjjBlnzDhjxhkzzphxxowzZpwx44wZZ8w4 Y8YZM86YccaMM2acMeOMGWfMOGPGGTPOmHHGjDP5bxt4M2z4m+9PL3TaesuJbBEWYwmWoirsMOsd Zr3DrHeY9UqzXhndRLkNlNvgRJB0Ikg6ESSdCJJOBEkngqQTQdKJIOlEkHQiSDoRJJ0Ikk4ESSeC pBNB0okg6USQdCJIOhEknQiSTgRJJ4KkE0HSiSDpRJB0Ikg6ESSdCJJOBEkngqQTQdKJIOlEkHQi SDoRJJ0Ikk4ESSeCpBNB0okgKdo6RVunaOsUbZ2irVO0dYq2TtHWKdo6RVunaOsUbZ0irVOkdYq0 TpHWKdI6RVqnSOsUaZ35e1k+jsl4AlPwJJ7C05iKaXgGz+I5PI8XMB0v4iW8jBkoxiuYiVl4FbOx 74SRFBFJEZEUEUkRkfw7J4xNVNpEpU1U2iRCxoiQO7p+M3F2128kzo4up1qGahmqxVSLqRZTLaZa TLWYajHVYqrFVIupFlMtplpMtZhqMdViqsVUi6kW5+74QLWYajHVYqrFVIupFlMtplpMtZhqMdVi qsVUi6kWUy2mWky1mGox1WKqxfl7iD6OyXgCU/AknsLTmIppeAbP4jk8jxcwHS/iJbyMGSjGK5iJ WXgVs/Fm7i6lmI8KLEBl7j6lWITFWIKlUYJV72fVp/+LVYfbcartONV2nGo7TrUdp9qOU23Hqbbj VNtxqu041azfzvrtdpxqO061HafajlNtx6m241TbcartONV2nGo7TrUdp9qOU23Hqbbj1Npxau04 tXacWjtOrR2n1o5Ta8eptePU2nFq7TjVdpxqO061HafajlP9v/jr9GpxsFsc7BYHu8XBbnGwWxzs Fge7xcFuChVSqJBChRQqpFAhhQopVEihQgoVUqiQQoUUKqRQIYUKKVRIoUIKFVKokEKFFCqkUCGF CilUSKFCChVSqFDW2sbaA1h6gAy/LO/DzazY/P995vm/yxR/z4djPhzz4ZgPx3w4zv+O7Mrw5y4f PqfLh8+JvvkpvgGihfVb+PBGPryRD2/kwxv58EY+vJEPb+TDG/nwRj688T99A0QzH27mw818uJkP N/PhZj7czIeb+XAzH27+O9+w8Om+1yz3DQsPh618eCsf3sqHt/LhrXx4Kx/eyoe38q3cO4lfYIEv RL3is8KmeDCGhuviC8L18YXh+sTF4dXE5eqtfd9PfGFiuH9f7fFHHm9Rx+8fnxwy8ak4PWyLz/U4 NFRrvVTrpfHFYTWL574bpDWR+waBXq7ucHWHsda5usN46+JLwvb4ypCNh3t+LW7CuNAQj1dB3RK2 RT1cvdmVm/202U+bP/HJseooqc8t+txiBlv1ucUMlppBoxk0msFSM8i9c7H+L39REe2nvyn6m2LE KUacYsQp+l6r77X5d80P0ucYfY7RZ4M+x+hztz536XOXPpf/dX6XhxP0/dmu37We3PU71tz3SIzL n8dyPf1YTz825hI9/di4S+Kh0Rf18H09fF8P5yeuCA8kfhgm6um7Xae6gV2nuoF6ek5Pv4kO0NN4 PY3XU25O4/XUoJf79HJf1zsPk/TyJ71coYfDtT5c6/FaT8rbsFKLSi1qtah1xUGuOMirj+p7eGhj ibb4+nB3fEMYFf8MN+Km0MYHSrp84JAuH3ilywde0XpH1JOCWyjYovWbWqe1Tmudjn8e1nR9JmqB FguiAtdnzOUS1hweWo3YaoTW/Hu1ufdoc3r26uqtTm9L9LZMb8v0tkxviz7xHniTVt312qRl93zP xVFvbV/TtkHb7dq+p+172r6nba22Q7ss3H1f27xW3dnoTyxwSXjOnJaY05L4+ujz5rVEiwdZtZpV t2j5XNd7XwO73vPKaTPLuM/m5/yccT/UQ5MemrRu0voBrVdoXav1A/lKT5Wn1UKtNkSFri5zdZmr y7ya6/PQRO7boXrEReHj+FaMjbrHEzz+Xnz80eOk8HEUe7Ujzn0qsMD/9/DnW8Mez2rie6Nu8X2u etDq/2BNfwwfaPGB/m4RGyNwa1gf3yHGJ4QNsRoqfizsivp4db5X58ejWO42jA4r47twN8ZgbNQ3 vtfjQ1b2cFgTP4Lf4nf4I5+aFCqNXOTVe8PbrqqLc58giM3pvTj3HkFuntvMsyhsNIOsGbwX35lb Q/QlLZq1WJ9vcZiZzDOTefFI2eRWPY/yeBtuF/25ed+p5WjruAt3YwzGhsCr5/HqeUbbFU80q4fl kEfwW/wOj4ZVbFhrto1m2xj1N1KrkVqNtMu85hotN8IqI6wxQocROozQYYTcPD9jnjONss4o6+IH 2DdnwYfCVCOtN9J6I6030nojvWOkzdYz32i1RqvV+harHoHc6sey+L1GHUe18ZjgZw/RodBK2mnY K36Adg/mfuqRjrLILXocgb/YY7RMexfuxhiMdeU4thgPfZnVZrPabFabzWqzmWTMJJPXZEe+9izU Z4c+O8x4mxm3uqbDNR15nXYb6SMjfZRTLj/bB/zsIXP6gyv4J78ca6x7jbtvtq1m29ds++S9bd9q 74iOie+k6kSrfCg60Si7836yR+8des958Vt5f86NsytKeLbXs71G/FA0y8X6aXR11tXZnM8bsbuV dlhph5F76bePFTTru8MKdljBjnw/77u6Qz97otPiGTxnjphOyyJlKA8L4/lioyLcGi8IT8eVeCs8 Hy8Nw+LlYXS8yjWrPdZiuzHfxU7a7g6/jbPitRN7xcNHThJReCzRLWQSPTzuh6TnvdS2B4StiUPQ F4ficzgGx+IEnBJmJgZgIOyfiTPkm7PD2MS5Xrs4vJT//NIV0YGJH9p59+2+Q2Xeu2W8oTLv3fmd 8fPxNGucQZ35ol49azWdVtNpNe3xIsqpvK1oZVxDvdUea7GZQlv41G6enkUn3jeDSLbugf3QL2TN cJMZbjLDTYlB4T2zW07haSJwhp4rwmqjtRut3WidXaPVGG1512jLjbbcKO1GyRglN8K7RnjXCO/q fafed+p9p56boyKnlUlOK5OcViY5rUxyWpnktDLJaWWS08okI98QTw8/N/qeeE4ojV8P/xq/gbSM XYbyUG4mz5jJx2ayh4pLzGR7vDb8JK6TS+rRgEa8gybqr/O4Ec1hTtzisQ2bozviLeHJOOP5Vmxz XbvHDmx3LnoXOzx/DzvDP8e7wrNWuNYK1/KK89lyYfyB1z7ER/ajjz2GUJkoQIwEujlbdfdYGH6f 6BluTezveTJcxHNqec6xiQNDcaIPDlLFHuLffcM5vOgcXnQObW5LHBYmJPp77fP4YvSLxJc9HoEj nUeOwtFheOIr/v1VHKP9sfia58fjBM9PtA+e5PkpPG4ABuLUMIDOjyZO8/PTcYYxzvR4Fs4O0xNf 93gOvhFG89JzEt/0/FvhR7LJ7+xzzfa53DdbTLNLHmGHPCLhNJB/V/1ECm2j0DYK5fxmM7/Zym+2 UquZUu18ppla2/hMM59pZuXtrLyddbfznzbWXce661i3lUWb+VETC27nS018qYnltrNcB8t1sFYH a3WwVgdrdSS+GD5kgQ4W6LDyDiveYsVbrHiLFXdY5Xara7CiDjF3tpg7R6zViLMa2Wu6rPO6mb2B tDgpQ7kYqhBzb4UVXR5fa/Zr+FrWCmqtoJYPHWEV9VZRbxWrzHyxmbeadb3ZrjbbDWa7xmzXmO1q s11ttqtpuT8NN9Fwk1mvMes1Zr3GrNeY9RqzXmPWNWacMePV0bFmtdyslpvVIrPaZFaprqjP2XT5 X226OTrYjOrMqM6MVrDrO+xax651Zvem2a3IZ4Buoe6vWSDpea+wzkzrzLTOTDeY6QYz3WCmB5ph nRnWmeFqM6wxwxozrDHDtexaZ5aVZrnBGX0a21RQb4G4rMQiWWSpHXQ5amSP1R5rsdl57ItRwp6w OertWU+5KpdxprP36/p4A4vyn2Vfw9cavFoRbtTrLL3O6spBj9PvUfo9GvXTtlrbZjljfVwsV87h ba87p7yBCvlhAa+qxCIZf998XoqreV2N8VZ7Xou1YadcsV0e2CtW99Knjj515rDCHFbQYFr4k1FG 50eZE141woNGeNAI7Ub4wAgfGGG1EbJG+Evv2/Wey06v6P11GWelEZYYYQm7t7F5G5u3sXkbm7ex eRt7dDd62uhpEb6Z/dvYv439N7J5a+Js1ey5/v2t0J4/fe57ly1/0mWpcoq/JUctzVt3oN5Oz9fB amB7/j6F2sx3m/luc0XhJ2Mln58ny8+T5efJ8vNk+Xmy/DxZfp4sP0/WwzhW+D0LVLHAOBYY94nc vCxe4CRQibdCMUvs7MrPTSxwl/xcKj+Xys+l8nOp/FzKKvfJz6Xyc6n8XCo/l8rPpWY2nLVmy8+l 8nMpqz0kP5fKz6U8fAQPHyE/l8rPpTz9evl55Sfy85Xyc6X8XCo/l/L6tPxcKj+Xys+l8nOp/Fwq CkbIz6Xy81SKPCQ/l1LlMtGwmjKXyc/3yc/3yc8TqHQZla6i0lVUukp+fkR+niQ/T5CfJ7DzlfLz BPl5AvVupN6N1CuSnyfIzxOoeBkVL5OfJ8jPE6h5qfxcJD9PoMAYCoyhwBgKXyA/PyE/T5CfJ4iw sfLzBPl5gkh7UH6eID9PkJ9H8YKr5OcJPGEsT/hD1yf4XucRD9H8MJofJj+n5Odp0S8pW0PZGsrW ULaGsjWUraFsDWVrKPtzyt5G2dcpeztlb6dsG2XbKNuWP328xb8XqYCW2vtX+dm+nXciZTOUzVA2 Q9kMZTOUvYeyGaqupGqGqhmq/oSqaapmqJqh6hyqZqiaoWoZVcuomqFq7iz2GlXXymG7KfoKRTdS NEPRDDUz1Mwkcp8rjZEQT93UV909L5Tne4Y51MxQ80VqLqfmI9RcRs1l1ExT8xFqTqPmNGpOo+Zm alZTM03NNDV/RM00NdPUnEDNCdScQ800NdPUfISaj1AzTc00NR+m5hJqpqnZQM0GajZQ83Fq1lAz Tc00NTdSM03NNDX3UjNNzTQ1F1NzGjXT1JxDzYepWdH1jTLj8p+qO5pCJRRKyUAr5LkMpZZTqpxS 5dTZLbJfFtlrRPYaKs2l0iaZaKpc19a1b02VjaZS7C3qLBNzndSoo0IDK2/9ywmOpevtEq0smbVL tNolWlm0gSUaWaLRDD8yw9ynH8uj4/nISj6yko9UmcGHfCRt5LVG/pCPrDTqh0b9kPYDaLyKxqto u7Rrb1ppxJX0LRala4y6mI6rjLrYqIvpt5R+dfSroV+Wflna1dCuhnY1tKuh1Ym0ydCkhiY1tFhG g2U0WEaDZTRYxu6N7L2WjWvUDZujPlr18souVc0MO0ZFGMVyk1luMsttNP87WCdrjrlT3+vm+Dqr bDPHOnOcbn7TzW+6Pa8i3K/lfC3nW3mrlg9o9ZpWpVrlck+lFgu1WKjFQi226+dd7KTO7jDFlYtc uYgN3nH1Y65+ng22afF8Iv9tYWayy5Wtrtzsys1d5/hl9MlVJMtctSzq6ardrsplwSZXNeXj5SPn nSisdOUuV6505UonhLUqnKbwFN2nm02D2TSYTY0Z1Gq1K/7IbtKN3oV2mZ5Werm8eAV1fmj1V3o+ LNpPbtkv75V99LBLD7u6znHrPnGO22L8Tcafpbfc+LOMP8v56yLnr5PVOwPs4avs4avyVmnRS4te 1umlUS/b9LJNL+v1sl0vJXpp0UuJXkpYZbtX3sW+Fu/nZu+q7a5a76rtrtpO3bV8fyPf3m53fhc7 81baqP9W/bdq1W7Ny7Ws1/IDa27Xul7r+ii20tzvgQaqZ9fykm1W+b7Kuie/6e0nO1hxq97bvZLR 64q/nrXe52u5dSf4a+En1p67+1Ou5Totc3veu1qWaLlJy/e0fE/Ld7Rs1KJRi0YtSti/mN1f5rk7 5Y/cpySujmIWWCt+d5tF1tw6sc8vdhhxq/Y7tN9Bn7VhgdEWGWkRK2xkhY36WWPlq7XYY9UbjZL7 rdvbn1D5bePk/q6iW/6zlblecnv1Gr2s0Uu7Xtr10q6XzXpoN+Z7esn9JvCRrt+H5c5Nv9dLoV4K 9fK2anQtvZpkq40em+WIbaHCCoqt4FUreNV8yqmds90TbFer101W8oSVPKH3iq7f8q7Kq//JU+7e 3OlWq21dJ9ttWmyLeuUtlNNnt7jOOv924n2x8VF4w9Xjuiw1ztXj+OKVfPFKWu8Of3b1QlcvdOUE p/V+/GnfuWzfqf0UdhuAgRiUO5NZ+TArvlpE9Mxf/f9yZfzX+210c/1c18/t0vqpfC9b/HSdn677 T72052ppbTPaZqJ+/9OnIGXRDll0syy6RRbdLotul0W3yKLbZNFtsug2o+UqqC0y6BYZNFc1bTbK ehlzG+3qRXu//Kk4Yz4Z8/nAfD4wnw/MZ0eutspHy1G0PsqZPml+B1j9gebbB4d43lePh+Jz+TPt JiNtyv+O5NT8etqNtDk/yi69r9D7Cr2v0Htbftccpm69Ogxwkj0pfOyKrCuyrsh2WfRtr77t1SPN +SicYlYDMBCD/Pvs0GiGJ1j5Gc7JOcu3adHGM48016NwOf+6UrQNiw6wigOontTuAGMfgr5yz6H4 HI7x72NxAmVO1fLc0BJ91tW7WPk9LXZpsUuLXVrs0mKXFru02KVF9j/M7FT/PiO/hla97JIbz5Mb T8z/1cjVrF6Qn22PvFWOVAMfhVOMOgADcUbuN7CJ4dFXEz+Kvhp9J7o2/DH6CX6KEWF0dHv4RfSv +DXuwJ1o9loLWvFe/ntVHo7exwf4EB+FhwuOifoWHIuv4TgcjxNwIk7CyTgFAzAQp2IQTsPpOANn 4iycja/jHHwD5+Kb+BbOw2B8G+fjOxiCobgA38WFuAgX43v4B1wfHVrwZkgXlIfXCuajAgtQmf9+ jbKCRViMJVgayvjkQeLtYByCz6IvDs39rQKOydV3+BqOw4W4CBfje/gHfB+X4FJcBjku+kdcGyaz +GQWn5y3+K/Cn6ORKMKtGIXbwwtUeIEKL1DhBSq8EH0lesRe/Fv8Do/i9/gDnsVzeB4vYDqWYCmq sAzLsQIrUQ3nrOht1GA11qI5zKLzLDrPovOSaCd2YTey6IRzF+2LaV9M+2LaF0e5u3IfyOsOjArR A7n7lH8GPbE/kuiF3qBwRGF2uJkdbmaHm7vue3ENO1zDDtewwzXscE10m15uD9exxXVscR1bXMcW 10W/EW1jcQ/uxX24H+MwHg/gQfzljjrN4TEre8zKHrOy+6xsjJWNsbIxVjbGysZEe8x8b7jD6u6w ujus7g6ru6PgT2FlweOYjCcwBU/iKTyNqZiGZ0CJAkoUUKKAEgWUKHgRL+FlzEAxXsFMzMKrmO0U drKzhwiJT/V4LoaGm+MLVFcX4hJnsOudwW4I4+OfIff+3bDw3cTw8CtR/93Ejzz+SjWx0o5THR2S eDs6IrFa1qu1KzTLuC0yQmt0bGKTx7bo+ETG49boIJlgRZRINOfz2wq5uJkN3qJm0k+S1Ez6d5Ka STokqZnM3VM+/18v9MZBoU6U1ImSOlFSJ0rqREmdKKkTJXWipE6U1ImSOsofTPmDRUtGtGRES0a0 ZERLRrRkREtGtGRES0a0ZERL7k6XI3jJCF4yIroudETX4wb8DDfiJvwcv8AvcTNy3xoxItzGo8bx qHE8ahyPGsejxvGmK3jTFbzpCt50BW+6gjcleVOSNyV5U5I3JXlTkjcleVOSNyV5U/K/+du6/3oP 2zdYqAT/m78qbA7jeet43jr+U34DzXiefQ/Pvodn38Oz7+HZ9/Dqm3n1zbz6Zl59M6+++f/sO5De DLPl3FI5t1TOLZVzS+XcUjm3VM4tlXNL5dxSObe0oCrqWaAuKVgOpyIR0UtEJEVE7lMIbaKiVzzY 49Bwp8j4scj4schIxsOdpa/F9eE+EXKrCLlVhNwa3+TcMSz3XUjhBlEySJTc4GTyUGKufbtMNVce bkysCO+KmINEzGEiJiNiEok19tdm+3KLaGoVSbm7tmT8fKvstTbqFoZF3VGIHtgPn0FP7I8keqE3 DgiXi4QmkdAkEppEQpNIyH1T9MvR2fg091q4NhoW/QQ/xYjozOhXPHIkinArRuH26PjoX/Fr3IE7 8ZswPBqLe3Av7sP9GIfxeAAPYmL49n9zd9D/+n0xb4RpUQn+Vx4eXRG1oBXvRWdEO819F3Yji07s jY6L3scH+BAfRccVxKG8IIFu6I5C9MB++Ax6Yn/8+998zCvog4NwMA7BZ9EXh+Jz6IfDtOmPz+Nw fBFfwpdxBI7EUTgaX8FX8X1cgktxGX6Aq6MrCv45urzgmujXBT+Oziv4l+j8gmv9+6dhV8FIFOFW jMJtuB2/xh3a3onRuAt3Ywx+g7G4B/fiPtyPcdo84PFBjxMwEQ/h4dDkXN/kXN/kXN/kXN/kXN/k XN/kXN9UMMc1KbyG1/EGSjAXpUijDPPUrSeHK+NTcZYq/VyPgz0OjYbHF0THxRfikjD83yMvOiS+ Ifpq/DPcCJEXj1OZjQ/lTsnfdko+L1ESnk2UhYsSG+1TzfaoFjXGpvBwYrNKckvUP5FR2W9Vf/QS YX1FWF8R1leE9RVhfUVYXxHWV4T1FWF9RVhfEdZXhEX2oAp7UIU9qMIeVGEPqrAHVYi8uSJvrsib K/Lmiry5Im+0yBst8uaKvLkib67Imyvy5oq8uSJvrsibK/Lmiry5Im+uyDtA5B0g8g4QYb1FWG8R 1luE9RZhvUVYHxHWR4T1EWF9RFgfEdZHhPURYX1EWB8R1keEfSZ6OKwRZWNF2VhRNlaUjRVlY0XZ 2Ogxr/0Rj2My/ownMAVP4ik8jamYhmfyd0YZKzLHisyxInOsyBwbvejnL2EGivEKZmIWXsVszEEK r+H13N1Uwm9E82+iuZ6XIo0yzMObmI8KLEAlFuItLMJiLDHuUlRhGZZjBVaiGqvwNmqwGrXarMFa z+s81qMBjXgnpKImrMN6bMBGNLN/C1qx1976Pj7Ah/go6iU7FMkORbJDkexQJDsUyQ5FskOR7FAk OxTJDkWyw42yw42yw0jZYaTsMFJ2GCk7jJQdRsoOI2WHkbLDSNlhpOxQJDsUyQ5FssMo2WGU7DBK dhglO4ySHUbJDqNkh1GywyjZYZTsUCQ7FMkORbJDkexQVPBPUVKGuECGOEGGOEOGOEGGOEmG+LYM MVGGmChDTJQhJsoQE2WIiTLERBliogwxQoYYIUOMkCFGyBAjZIgRMsQIGWKEDDFChhghQ4yQIUbI EBNliCIZYqIMMVGGmChDTPwfvx9xjmtSeA2v4w2UYC5KkUYZ5qEqzCxYhuVYEWbKGF+QMb4gY5TI GF+QMUpkjD4yRQ+ZYrZMMVum6C07zJYdRsgOI2SHM2WHb8gOIxOlauk0yj7emngzpOzPaxLzw4JE RZgoa9wjY+xJtIZNssaZssZEWSMha/xZ1qiIBojCwaJwsCgcLAoHi8LBonCwKBwsCgeLwsGicLDo myf65om+eaJvnuibJ/rmiaQykVQmkspEUplIKhMVi0TFIt5dzLuLeXcx7y7m3cW8u5h3F/PuYt5d zLuLeXcx7y7m1cV/79sxEsvDtMRKOU8VllgV/iXxdngjUWN1taHByaMxUt18/GE0FvfgXtyH+zEO 4/EAHsTDYuKRMNRqhlrNUKsZajVDrWaoXJKSS1JySUouScklKbkkJZek5JKUXJKSS1JySUouSckl KRY4nwXOZ4HzWeB8FjhfLknJJSm5JCWXpOSSlFySkktScklKLknJJSm5JCWXpOSSFKtdy2rXyiUp uSQll6TkkpRckpJLUnJJSi5JySUpuSQll6TkkpRckpJLUqw9hLWHsPYQ1h7C2kNYewhrD2HtIaw9 hLWHsPYQ1h4il6TkkhSrD5FLUnJJSi5JySUpKoyhwhgqjKHCGCqMocKY/J3qPw5TohCmFEQoCFMo 84/Ogyuo8wfq/Dqx6uOPqfMUdS5wNpxDoVEU+pMc1C3qr0Lqr0Lqr0Lqr0Lqr0Lqr0Lqr0Lq7/TS X07qb2/oL1edY4eqsUPV2KFq7FA1dqgaO1SNHarGDlVjh6qxQ9XYoWo+cb/JSjtUpR2q0g5VaYeq tENV2qEq7VCVdqhKO1SlHapSlXSaKuk0VdJpqqQqVVKVKqlKlVSlSqpSJVWpkqpUSVWqpCpVUpUq qUqVNEiVdJUq6SpV0lWqpKtUSVepu+104WiV0tEqpaNVSkerlI5WKfVTKfVTKfVTKfVTKfVTKfVT KfVTKfVTKfVTKfWLJkaDeGYDz2zgmQ08s4FnNvDMBl7WwMsaeFkDL2vgZQ2qpcNVS4dTvoryVZSv onwV5asoX0X5KspXUb6K8lWUr6J8FcWrVEvDVEvDVEvDVEuNqqVG1VKjaqlRtdSoWmpULTWqlhpV S42qpUbVUqNq6XuqpZtUSzeplm5SLd2kWrop2qNC3RvOVDGdqWI6U8V0porpTOeSHgW98aeQVjml VU5plVNa5ZRWOaVVTmmVU1rllFY5pVVOaZVTWuWUVjmlVU5plVNa5ZRWOaVVTmmVU1rllFY5pVVO aZVTWuWUVjmlVU6jVU6jVU6jVU6jVU6jVU6jVU63q5xuVzndrnK6XeV0u8opqXJKqpySKqekyqmf ykk29nhWqFI59ZONq1RO31Q5DVI5DYovzn26Ner/759uDTerngarngarngbnPuka/1zFNT06Kp4R dYuLo0T8evTl+A1UhG/FKrlYJRe/FS6Kl37cEDdFg+Ld4dq/vkP3Ubg4cWR0QOIonCJ6BmAgzhBR 3wgfJEqjpCrsRFl+pqhblFgpm6+Keoi02aqw7iLtY1l/tUrs112VWKLr9xcJ2X9TYovMn/HzraHd yaxbKHFmLHFmLHFmLIny7/igJ/ZHEr3QGweEUufAeufAervGQrvGQrvGQrvGQrvGQrvGQrvGQrvG QrvGQrvGQme3CnntHXntHeeHeueHeueHeueHeueHeueHeueHeueHeueHeueHeueHeueHemeGemeG emeGemeGemeGemeGemeGemeGemeGemeGent8oz2+0R7faI9vtMc32uMb7fGN9vhGe3yjPb7RHt9o j2+0l2+wl2+wl2/4N+quAy7KY9tP+ehVmgiIgIjYdxEVFcHeQQRUooJSBUFAQFQsEWKsMcau2LDX 2HvHLkFFxV6wIDYUK6Ao+/7f7Gq8KS9597377u+yvz2z086cOXPqB8zCl9+DL78HX34PvvwefPk9 +OPd8Me74Yt3wwcfhs+9D597H1F4oLgPuFDcCbwF3CyGL/WDL/3ISysf8zJVO16u0uXvK8v4h8qb vEKlzT9WPuKfVN68Eu0qlbWkVflY0la1k3RUupJuZZmkV3lT0ldpSwaVjyRDlbdkhHZjlTWR4OO2 wII+5Zdx1vJ33zjAsmTCsmTCsmTCsmTCsmRC43KgcTnQuBxoXA40Lgca8IKeFLfEFkPiiyHxxZD4 Ykh8MaR4PqR4PiQ2FxKbC4nNZStV7yGZ+ZDCe59/O8arIb/PVmXy88Qedr0A0jWTMOx8I+RnMiRz H2nO95Ngfpi48yPEGmN38aPIRpA98HPEF/N8+QVI2UVI6yViyvOJEjjuQEIdiS6/T1ohl9GDXPpC Lmvzx6Qj8B7TPF+rj5WysdJl1Vyx5mv0DYb0yv+hfBlZ0BPVOUJpDPEGl87LeElLYOuOs+gC3OoW JU6qDK1tcVLPcVKvxf+4P1O9B8YHWOUJsmf52Z01xrqIZ3lKUOOK1Ruidp40A+XV0KeFPfQC3UGq szwFe85WZUut4KcYWk6jlovRB1W3EHeVoHYLtThijFoFameIGTyeN3B4w+N5w+N5w+N5w+N5w+N5 w+N5A5M3PJ43PJ4370UseV9oegjeceDQfvhU5BDAdBH7kvEi50TrLaxYxA/jVI6orqN3J6K9Z6Az hdTHuVii961MGeg0JmY0jzjTC6QRdhEs8sm+GKX+P9f64v9c41QneJLqDE9V3eNzSVM+D+994Nl+ 4gKJ/1lqTpSS/M2dHLNqYUYtrNMYnE8hjljpuXzyYiUtyMl1+P9i+P734pyuYLcMrS9QK8EOzqHv PGTnIjLWS9CZfLwvoxfjZKuFFc7hZM5DWi5D3nGSqleYXQKcz3Ea5phTip4TmvHlMkasKn9rbh4w X8CuZT5dxurqER/FCFkitDGiFCM+quVRvjsLeK+qKgRVeRjRQtB5EbZR7s1XXcHZWyByqcAKahy6 GuxF/Kr8xF7QmYfaBdUzzKvQ7PoBeu4TJ0htCeRJH9JtA+k2hcweIBSwRHxTWjkkspLL36LJMVoX Ixlq17F7ufYAtBah5xFwPIHVf4pe+ftqoDeY9QDrFKIU2CHjj4HtCaTzmapUzDfFiDLNCPmGB130 3hXfnAzKVLmQ9NrqXtgXufcx1mUC2xNVkdA3GV8+TrgcfP+kKoCteg7bVIC+T6oSfJLPshSjKvD+ CK5/Up2XtFTlsGPlkoHqLUacF2MvSoZCcj+gVoEVP4GrKlWlpEcYxlai9wpsXSUoLkVvGU6nHOf4 HhjVmOUZlzHjI7BXwmp+BCXFki5WUK8kY7gMDB9xpmXgbjn49R6zKlQqzHws1tImFLNKMKsSs1SY 8VisaYY172EWw6ybmFXKP6jyBZUfoXGVqiditpbqHjAwYLgJDKWSnipfUG6gugpL/URg0gaGcqx3 h1eKkeVY445kJPhdDvn4IPZxHT1FmC/TfJ0YSxZET7IEXdaYY0NMJVvVLcmO6ErV8dkefTXQ54Q+ Z9Rroc8FfbUhd5JkhRVs0euAshbOwlCyQM1S9UKqKuPCCrZYScZlj/YaaHeU8aC9FtqBh2iL0dZE X+CRRzjhs4zLDHQx9D6UrNBSFW9rUgP0mWHkQ+CsAfoY6GOY9VByQL8j3k5od8aYWmhzwefa2Lsx sNwCreodVgOtNkRLg0WefQv0q3dYE33O6FPPZtivBd6WkDkr0GwNvDbYi63qDWbqY33sC/010O+A fif0O6OtFvpd0F8b+8MuVE+BoRwY3kpV8baGpFXDaBucpx3OsTr2bI8xNTDGAf2OeDthTE2MccYY F4yRv+NXPidDwVdrYgE6ZI6Vgw4L0GEAOgwFb51QdxYcLAcNFqDBQD4VwjWnq+azmnqZe1xzsoLn GqoZfE9p5RNowQBIjR0k0gcxRAkksgNiiKeQoAhIZQ1IZUvEEE+gDQMgUXaQSh/EECWQyg6IIZ5C uiIgmTUgmS0li8oP4EIDcKEeuNBAsq4sBxcagAvyebqBE7XBiTqSPcbVQLsDxjmidMK4miidVfKZ uoEbtcGNOvDXiAfhF7zh8Y3h6c1hGeXYsxashwdsxkn4ARPsJBherwEhyMi8SV3SBi8F6UYCiJL0 Jn3Q+g3iTk/k6z+Qrsh4NpIEsonsxqd95BCZT47gtZgcI1fIEnKNPCTbyCNKyRFqRC3JTWpLbUkh tacNyEPanfqQd7QH7UHKaF8aTMrpABpBPtIYvBiNo/GU02F0CtWmP9D51I5m4lWHLsKrLl2CVz26 jq6n9ekRep42ZArmRr2YO2tG27AWrAXtwLyYN+3I2rH2tDPryDrSrqwz60a7MR/mQ3uwniyA+rHe LIgGsH6sH+3NBrABtA+LYJE0iA1ig2hfFsPiaT+WxFJpKBvBJtIoNplNo6lsOptLR7H5bAH9jq1k W+n3bDs7QWexU+wKXc2usQd0F3vMntGjrIS9pCcZYjJ6mr1nFfQcU3FCL3DGOb3EdbgBvcyNuBG9 wU24Gb3JrbgNLeA1eA1ayB25E33InXkt+ojX5nXoE16fN6DFvBFvRF9wJXejJdydN6WveAvekr7l rXhrWsrb8vb0A/fhPegnHsiDGOF9eTjT4nF8CDPhSXw4q8JH89GsKh/LxzJrPpfPY9X4Jr6J2fId fAez47v5blad7+XHmD0/x6+yOvw+f8Ya81KuYq0kLcmYdZIsJFfWU2oltWJRkBSKtz5toZ1DePjI pDhiMSgpMpbEx4WmxJNMxEo0wL+tA3EjRKUiVcRvWG0RR5pBuhTEHRLVjvQgvYCjC+lHQskgzThk nsSOOCEvrQfZa0JakvbEDzJIIXf9SRgkUMIc9Vhj2I3qpCaxQPTpRppCPjuQnpBWBskNJuEkBraX +ffwcSCegf7dHMhgMc8c8q6H/NuaOBNLyHwz+X+fSUfiT4IIJ7VJdxJCIjRjLcTv9Wsgy69FrBBl NkYE6gXd6ATN+AaUuBIfMoBEklgN5iqwIg7EBtFpVURfzaFLbUlnEkj6Ip6sQ3zJQGhRHBkS7pYc zn4SMFPAlQJuEnCPgEfDQ+NSWK6A+QLeErBQwGIB34aHJkeyjzLkTEBdAY0FtBDQJjx8SCJ3ENBF wPoCugnoIaBXRFzMIN5ewK4C+kXEJwzhvQXsL2CYgNECxguYEpUUGs7TBBwv4I8CzhdwuYAbgSyU 7xLwgIBH4+KHDeGnBTwnYL6ANwS8K2BRXEJ4HC8W8LWAH2QoEXQmSdoCGgpoJqC1gPYCOiegkOoK qBCwqYCeArYVsHNCUkS85CtgoIB9E+X2gQJGCRgnYJKAIwQcmwyeS+MFnCLgTAHnC7hEwNXJMfFR 0kYBtwm4R8BDAh4XMCd5SHiilCfgHQGLBfwgQy1dAa2Sh4UlazkLWFdAhYBNBfQUsG3ysMRkrc4C +goYKGBfAQcKGJUCyrXiBEwScISAYwUcL+AUqBOHXlaFRvwznxAzQWf/fkmhC38Npb8B7X4HDf4S ctgMPej0P/OJwoL9Fpr+DcjE7mGURY1qbKcMdf8GNPkb0OZ30PhvwCqCLi5K+hWU6f26zfAvoRZs nwWsqVoi/nc1K03t76xLYZn/Ghr9BXSC9feFjwmBdY4nqWQsmYDIZi5imdWIcnYhwjlJziG2uUOK yAtSSioRnRhTK0Q0LrQhbUq9aEfqqz5XaqopbTSlg6ZsCumXy4HqOmuvrrMdmvpbdcm91O3yXwaL MkXTvkRT7tOUr9Wl1FlTavqlc5qyUl1qadbTyROnSvV11XX9ME0Zp15HP1VT36UuDVzVpWGgWteM dNWliZu63WS2pixVl6ZEU2prSkTL0BlGwukcoQFhdDYgVmcLZR2g7+R8A/lqB96Jd+ZdZP1gZswM wmfBrMQMU2TxxtycW/J6XIG6lhwzQR1NOXjMLTiyHl6X10U0i9gI1CHEwglS2CU1LYjbiSF9SV+i +g7rUfqBIqulKqoinGkxLSIxA2ZAtJgpMyXazJJZEh1mw5C5MCfmRPSYK3NFht0F1BkAV1WskSFv mZqQb6kNrU7GUVfqSsYjju1PvkfsOoRMogk0gUyhQ2kKmYoodgqZjih2AfkJkaofmclS2DCynQ1n w8lOlsbSyC42ho0lu9l4Np7sZRPZRLKPzWFzyH42j80jBxBnXiUHsW9j8gpRnzt5I0d65C2oqU/M 2VLenffgUXwQH8xjeTIfxofzkXwMn8Qn8yl8Kv+BT+OLZS6wJWwJONeNdwPnfLkvOBfBI8G5aB4D vibxJKLDUyBrujyVpyJnGMFHYOeIGIkBIsbvkEEs5AvBWS7sy688tpdPirVk8vnpMCVT4vyasqY4 5easOXo8mSd43R7SLrGurCt47Qc+IDuHhuuBJ02YB2a3Y11YD9aKdRN/t/+3sbAMloFVZ7FZ8jMr Iuds9lINyUFylJykmpKzVEtyEVkatAaZDxHUW39FfQ1ZEnmcPAIza2tG2H01wuGrPiY/J8RoIsmZ JJVcJVchF/K6FpKlZCVVlaylapKNZCvZyVnjl3UZIk0TyUwyRxytLelIupKepC8ZSIaSkWQsmUim UhWMkcDpb0GCPIchyvZCPtpGagMtYYhtrflqvpZv5Jv5cX6Cn+Sn+Gl+hufwX3guP8uL+XP+gpfw l/wVf83f8Lf8nXiWsYqvAsY1fA1o2cA34NwR82Mf8hqSHOF/wb4Kozagdx/fzw/wg/wQP8yP8Gx+ lB/DuAe8kD/kRfwRf8yf8KeYJ2NfzVcD+1q+Ftg38o3AvplvBvbj/CywF4MGGXtDYvGHWP9gH4Jn 9zGPaOb9wcp/sleZ12c/85r2on3oNzSI9qbR9CIbxsaySWwO7EgmX8e3YYwB9aOBOOJBdBDRonk0 D9KUwlIgTWPYGOi/rIl6bDabDS2QbYwBn8/nQwtkThrxrXyrvDNaSsrJd2Q8+R7+YiKZRCaTKWQq MuRp8B7TyU9kBplJZpHZZA58yTxkyQuQFy0ki5ApLyFLSRZZRpaTFWQlWQU/s4asJevIerIBufXP 8DqbyRayFXn0drKD7IQP2k32kL3ItveTA+QgPNJhZNzZ5Chy7uPkBPzTKXKanCE55BeSS87CW50n eeQCuUgukXxyGb7rKvLy6+QGuUlukdvwZAXkLrlH7pMHpBD5ehF5RB6TJ+QpeUaKyXN4uRLykrwi r8kbWJt38Hll2Ot78oFUkI/kE6kkKtmII5/2ZwEskPVCTt2HBbFvWF/k1f1ZMAtBZj2QhbIwFi5n 1ywK2XU0cuvBLJbFsSEsniWwRDYUefN1doPdZLfYbXaHFbC77B67zx6wQvaQFbFHyKifsKfsGSvm +uw5e8EN5OyavUJ2/Ya9Ze9YKStj5ciyP7AK9pF9YpVyrs2pnGtziWtxbeTbulyP9+T+PAC5cX8e zAfyUD6ED+Xj+fd8Ap/IZ/EFfBHfgnPdxrcjH96DPPgcP8/z+AV+kV/i+fwyv8KvSi0lT8iOpdoP CIv+rbDQWbwrLGs+8m9fcgWZdz9yjYfwAeSGsBe3eCJPJLeh3enkDp/JZ5L7QpoeCJtaKHT0oZCs IkjnOvJIaOpjoalP+C6+mzwV+losNZda4CQYPYQz/NfI3T9K3b9K5m7/n0jd7+Xus+T9sez9Kn2y /P0qgVlCBv9/pHCBLD+UUUvYHhvEDhbCDtUUEYQrDaGRpJ6wSY3l52HEncYipmiCmCKNeNDRiKTa 0wV0MQmhO+l5Es6SYKXGsslsAZktPPwqbsjNyGoRG/3MrWC3NvH6iI2OcSWihlNC6m7Cr7WABzaD J7QnLogj3EHTKrxkCN8gPm8StYOa2kHUbuMFm0/r0XqgvSFtiIPwEHdAdqKdsNVutBuREOvMl/++ XkR+m/BCdECDaZSmZddXLb+NJBxFJNGfDRaRhD/zh4b1YX0QA/RlfdETzIIRA0SySMQAsSwWMcBQ NlREEk7E+DeRRE9IxTfAFYHzTpTjzP9BTCGvrCNW1hUr64mV9cXKBmJlQ7Gy/LuC2aQTvUTz6WV6 hV6l1+h1eoPepLfobXqHFtC79B69Tx/QQvqQFtFH9DF9Qp/SZ7RY4pLES3kZL+fv+QdewT/yT7yS q/43bRKYL8k5pg2ki4ko1VTOQpCHcOQp9uh2FTe3+1HsEvLWl+jgHIKJrpA0PUSvcURfRK8GdBhN lW9NpWOIMZ1MJ8OfTqU/EFP6E/2JmMlPZIk5JHAnpPcIzYY8n6SnSFWaS3NJNRHD2AhfbCc8uUJE Mu1FJNMR9LUAhf8EzzR682/cGSSnrizHwO/yl9liLqzgNVi8Qti2l7BjH0G7LnJGC9DtgKyxPnWD 9njR9rQrRQaDHZjQBqLsC52Sy2DaXJQhtIUoB9CWohxIPUUZSluJMox6iTKceosy4kvZRpRRtL0o Y2hHUcZBT+UyQdz9aiJufnUVd7/2FTe/Bou7X0PE7a8DxP2vA8UNsKHiDtgwcQtsuLgHNkLcBBsp 7oKNEre8xoh7XmPFLa9x4o7XBHHLa6K453WouOk1SdzzmilueV0o7ntdhMxKQTxIa9KZ+JEgMpBE k0QygoyDZ/sROpYJj7Ua3mkbvNEheJ4cuh47yATVG0QZTDeKMoT+LMoBdJMoB9Ktogylm0UZRreI MpxuE2UE3S7KSLpDlFHilllXcc9ssLhpNkTcNTtA3DY7UNwzGypunQ0T986Gi1tnI8S9s5Hi5tko cfdsprBxrqL0RaxgTFyJG/EUz5GMIVlWgtdVBY+sNeMlWu3Lp2iZk+JpmSGdK3g1V30bLvpMRaJt Cf9BhYwzIbkcffYY/YqW0goYAW1myKowK2bLarI6Irf+v8yDYclFrvZr5qcrZ0Nfcqn/Jh/6kknJ OEJY3BebL3sA+XmOlehFTZKfW0hfnpSpn5tpnpzZtkdpoW629VRk2Hpo69Wd0HlCmRHVYVkZtnXQ VItRqjRQ6Glr1TPmzEaLKEK19etpU4lmNGNUygpQ9FTU/6rFbrn9ODsckvzqQcJIMkkgcSSSpODt Jb8Ujl8hkyz884eTqz5KzyP1Jzz4dG1Rw/63v62WlWFZoMjgx/FukMVhrJhpp8PV5hRM8+/Yruzm kM5GypUKoy+kUi0QlT5VEMl7SdrmrG8bpaXCXK7omhv2iUxOiUyKd2gXmhiptFCYyc065gbthyWF hcanxsTFRSpNgA2t+ubagdGhw1MildUVtnKDgbmFusGhXWRSSkxUTHhoSkxCvLKGorrczc2tNN2B MUOwSuiQxJj4QQ7t2ijsqxopGivdFO4K8dO3qpFSrjZ2a9ykeZPmfRUBXxHbK0BZVWGpXt+4d2RS TEDMoPj6Dl3iwxsq6ynqqBdy+twhlnII+LxWQGRSakx4ZLK8aAZ1+porVIvwDGpC0K7PMigl63K2 rcw967BZf8zkjROHvdzh+6og2+TwoNCDKyLsbux/n9N4w3jF5KCxP9yMvd10icnhC8UjXg9fPTbB 8/CszUb7ot/Gzc456N9gQ+dW73ZdDh5gy5Z+aBRrv7JsReZqm9Ps3rfd/R8YDyxubTd2r9Ed71M7 CiYeHJA2WNmQL0g3X9vJ4Zwy2ahPg7Mj3BvPMVtgtvdOdKP1RQ+OTvmh7rGpjhOjDn4X1Cdh2GHP 9S4Tg3NMLT2Xjn8amK0ff7zyRNfbe3WqzHMafdOr9gX7EcVLlWdeFTlVu3l8e6d2mTYDsux/Kgx5 92L0qzEbwuj0dz4Gd/Kceq+dc3bTpNRNL/YZvSn0uZ5VEZ21yaLl9onZ+xmH4K9Iv6lIv6Zw19aF xGpp6VAonMJF4fy5rqATrKNTUhJbNGqUEJ6c2DAVfE8G3xuGJwwRslPdnFKVpKvQRsEoUbSR22pI LRQeiqZZ7lluExSa6eFJcf8wu5FaVr4WlXZtGmKUkNTqtSRDhf5nKriuwlhuNJHXkqAB2qAQ9SoS JHNlNUXVz/LNzQ0DA9pA0DwaKBs0afwbreDp6aRr7PunQUfb2yknj1xQb+7hjI30il33s1umBMUX 6NZZEXI6Z5b5I8nfqKRT7UbEY0vhmVm+mflOYZZl3s0ceyQqx72a6jFx++PH80jl+V5zfZ0vrqvt m7Zpd2ibN3XPPTpzPeT2/nrfe+1cvPP6vT6qQztOjH133nDJy3mV9S619Le19ahd5t0VOqxSZLBH Gj02elLvZf61OpOs3bT0QjJTJ/1Wj/8lmvF7dVR4fK2Off7moo0UDdSLuvzVonJfZNJfquQ2P9fO ty9Fp423bh81LHjs8T1Lw11UrdotGl3Fw7RWr+Trw2rHfPLd69D/kv77LNu6z3v1dgy9Zn+z8EDj 2FMlt1c0i/zRdpbhrgD7/qOjmgzQmtKhMtW3IGDc8nSHxZsm9V+uW/ZQ8f6FU7PubfXPFZyscfxK ryfp3jv9V9RfT9NeL18/rUnl0qLgwVpLW8U+ODz3SGXuwPetH+lktX+W3jN+Vd3Xu6aYuj6ffks7 a4Jf5qiuukaK6jmmS2LLngRtkta1XrDN9fF0q42eDwISul1qsnhnQkT17XPr72/1aOSzIWnvrYpc ft5csiBgd+v6c/aMXF+Z77+hTsrYtsXN7ZcPtir6Zr9z9DUyrp3pxHGxGpXMUaSf+idV0vCLSjIF UTRWK2N9RV2Fa5ZLlvMEpz9TxpTk5AbhoUL9rIT6ySj+Gw3UPvK3NND9txoon/LEEYk3fP2pQ7+7 I89kKI5/2ltt7sEZ5NjBs2dPvjW+pnrvc6RxmKLKiXcptvkz7wxY5GC+dXSHQ35nv3s0rup3a2rP GmTesSJnz/w2PHdhz35aU79dm/DG1s/WueHrmGlxTmX7c6zmPDdMORI9/PqzBWETs5N/Kp+cklZz w4r5o+ZtLZteZ6hPw2G2ndvceLnTyCHwyvCseRnhMZ/0zk95OWy/3sLr76v0cskMdTuUxraMmnBo +bGpTvVHXGiSemBmcv/3e4u6W+rXzC28mO/esEtrS0+TgWnOJ1dFlcw9n/jM69Fbo7G3LoxekTo0 JntRj06KJo5bl2+2CfOsd/3H9XV1Rl2z3t5/1P3FqxIqPSf/rMiQzGACPqhNgAnJJlM9PSdVueBV Gl5c0PprjkmwAImfddvA3KldQuLIpJhB0SkOruF1HJTNmzdz8IkJT0pITohKcWiXkJTYUGmvsFMP tvzHnoQkta92VNRQH5P1r/3+CQkpDm2GpUQnJMWkjJTNQ/NmCqVSoWimMQ9uCqVbY6Wm+m+g6C9d OTuYnVjU8rWvrevSeSNCFE+Xr5tWa0B55ZzuK3ZXLl7u4DW65/KFy6cPdIu90DZi5IuNqWcCb7x+ tmiC3fSl46O2n4hNC6t5pbrnHRM68/Hc44cbRGVmRrssyGtR/7DhziCX7I6P9L085tZf59p8bXGX 79o+GG+yPzOuV+jGjNHLBjYY3v3Jgh0RLTP97JS6zhZL1z2aUc+6qNX8cIuBQVqRS6s3859YtqZk Njtpe+lwrw7bJ4873KI4cLbvpk9r0oak+G62zp2r5+pI+vw0MKbZ/m5mOp69Vf0qVkbp666+mN67 T8muliFW6cOlG6WHNo2bU7nl7LdX1tgk9ffMOfBSd4WTYrv292e2Oww3/75AYzfWKtJXKdKXy3pJ pfRMRfq8cab98hJLYpKW1Ow51mKbz4+qX5Yl/f+fX8ZfyLiwCnMeGxyZ9maedZPne6jzteFV3vQf 6LZ0icEvXlozJk0/06LI8fXLPrPq78zqdDqs5OPV3JYt+65rGhhT6TzE+0zu+jtao28rp7Vaapo4 eH+lWQ/rmCMf89o9qNLXocfTsFGb11c7Xa9ZrQaHIpeZTallEr6iLNDuveOZK5Zv/DfGt3PT+ZRR tfzhoDijnqUHX/mfOvjouOKjg1JvUvU5dWx8Lldnq16Nu8t39Hu79fbpPi8iu5zyD9y1g7uaqX66 8lJ3+tg9805saFa/MK1w7fAHqVkkb7B39sWmU+62MVvbZLDt4JtN7uXbSYVrO0in+zb2iPexMwrb rb/8h0uXA707nrXrtTrxplmLibOGLV1zMQtW4RiCg82awGCwwYIeR0j1DVVuHGfLomrv+5wkVP93 mQRFU8QL7spm7u5KdzmAh4l3a/rZJKSv/seQwVxRRZ1u6PcJTY5GKJCCdUyFC0GyoeMfGTEkIT7i M2X6f0bZn23TDYv+bps1FY7qbdh83RMRKYIPORrxE0mBw+8tiZFsSXSFJTmW6zDtQIHKy+9F2tF8 51qlqeccVWfr9vbNWbQ7Y1uTkQ3I8bW6l8PP7F5V+iQ7+8rWH+Yu1/lgsivDP/NZxsmDpifWHnkR O/7HANv9fh8i6ORsq/yMaNJ6RPt3Zh6+FeE9735otfdhs60F4To1Ww5t7d7pbeymju9qJ9s7/dK2 mn3PXf6Zl1bkmZ+s5j1Ue8jrOY7tB7R9fuTMggiHPdnuH5e3Lxq1rXqjPavvvF1WsNDRpDJI2aaX x9jNQY8Ki78ZWWtDWd1GVbw9Rni1/XZNdOFYp+iqRV1nHh/R3r/Tsh7jJ89aeGTQqKd6FRP4mNIF Qz3rrYman1vQ4H49ZmPi3jnynafZ5lcT7aq7+CfkQvb4igxaF/xw+aM4nP9nmBczbT1NAm4J+8I4 J5JIUasbS1aSRa3yet2CTycF/vywNKtuVauK7PcB6YpqX6ZYMMnQXp8EkGFI19uRNgoDEfiIvKOj wuRLgKWl4Ci+0kthxsIf3H2jtWfLUwMD9wsZSq/JYR0u6655Hxp5uiH/4NG5zfmdr2t/d+nBid4B a3dWO5db9Crrfe9dnWd3cn64rsattPxSqzSzm29+si3WDd7+/U97fwjab5c759Kc2Y3fzrijmrQw pFsXv+YuLRxsA5t9HNPfctaxW3Y/vgz193yo8zyqZGTx9HN9wiPnWHfJSiuI3F3gsqnytNmuk8tz Tw6Ymvgm5+aGjHidW5HV9q4tnXBUr+38Vy4bY9K2ZtdbsyWqxqrNE3Vj55nv2dJ0gb3WCnOPFUc2 Krz2OV5VrM4JM7Pb3Gfaw1dpVfaFeBo2ezUre+YkX6mvVv9T56+su35vzIwRtSt2xK+art04aGtI 3SomigytxjBltmozph/acckv4nFL5O+eUPynmIxfbV9z98buTeVsqRliI1SbyFVFyr9kH5p+/if9 fxkSnU2f67Gp//LX2QV38jbMmXbFc3GNqceCJzQMfrk16d2GjZMG77yx1WmUwenTq7rNCHEyf/L+ Xc3FO9/Gp24qebHS89TxI9/0996wPbmxy+qw9NCRy8Lexk+akxd/+9TSiyt7VkkN3Zc4JXLZXKvJ a4LT89pHPbzZe0nrnI+3Up0btleQh1fGjJpT5XJQ9RWPexicmXRr+ZWABXE54TkLBmfODOnuU+Vx o0v9+oUM8F+R3GDV/vEdjH6oZpn6i+6NzNWJlo99imM+BW+Lnf68Ts9mHlNPduxiOdtv/pa30Suv 3tEbOihlyfAfqn8fO+/powEdcu8WDTW6EE5mjVLO/9Fgh/nB7XkvXhU4vlg3MPRFs3atjqlDogw6 Exz58Xe5y6/G4MX12HXDAs72eGHrW03bfsWiDednf/oTy7dObq0ppS9TpC8Z94dWZFnKyn+H/ft9 sNBNnfi1V7RVtM7yyvKc0OKrxG/IZzwi80uMjZFbGyUmJUQMC09JbiQrgCz/kH03kRD2+CoTbado o/D+komyCY01eIcPH/5HeCOTfo8w5Y9yQo/rJXM8FvafbxEcGB9TwE4/2l5x6ajPz402fBtodMNt V/ngIqMKR5vhXqui03bMGTul/+t2x79bGDlmkl/P0RkW775Lvrr8UP8clnjOJa7qAX+LVZOP7C5c lrts2OIZQ1vZHulNeu8sH+9yI6RxxZVaaSGZN1ZXvH3dxmZjr44/d741w8M8SK/LqzfKiTUOSD/2 M4vkTwx65i0znLLg4PXstXm6lrUcd+7qM9nuQr8JTVblfFo/sXhdM+/d7WIfOLzqcGDspievem1b 1vlA5KEA9+tnHmuHS9oj4v1UnfcvfNqu78SbP+uPe/fNifqFD7/t1/Wh28gXTt/PNGyw3a/fyaOt g4I2XDz7oFH22eIhS5uNVGZIv8BsnmKUKtJ3/scYx38w8L8+xs5Kf6yw+OJQXalSh2uJP1KV3azm 6PW40vDrJ+cg/deagdJY8XWvpaLmrxMlJfS2LG1+TqXjUKu7N82vDcqv7nMjYN09RdJXUwyVEYqw LI9xTYkPiSHhJIkkiIfvUSSFOJCO+BQvPvUmkehLxhi5xYE0IQ2JgiiWuYxz/lPZThmZmDAoKTQx euRvo0kpgxLXPZ03O9iV3lvp2u3otZ55untODA7et7NJ0OKcZcXpU3TnLi4df2miXn7vb/1K3McP C6vzWtVGL9nFb3pv6/f2s+5Wq104e16nU/WbDO4/7UybisQLnet0HGr84cdgbRPyfV61yGLTKzNH pk+KnzYsYKnPK1+z6BnftGzuVVd3xLqclql+wT7PHt6OXNRLR3k54/TF0LgZ90OvzjDwszjbtOFT k7yB9y7OiC1O9O4+eejGyKANa2/cnmV9tLlJwyEZQ8Oz8481bHG03zzt5TbG/zXWh3unN5u/urNn vtAU4zmsfwStmH8X7dLr0Jm+lLGyTq1B2dG0WfqD/uxbGmVKSycofWnquNoYytW+9/c9U9vdUgub gM2iJsbfiBhjM2xifAMUegFK3uk0GdTEMpTKw8YBcQATsJRZEGkggZz2uBFTO4zApAeXYTXkB9X3 wAreCDTkYWgRBSx/kZKeEIvA76rSj6mWMgf7N/CLbbKaPw9LEpjx6r/+hhMviy7KJmf/a0g88237 TFPm97UOyrkvFZ2uvzXkruXjzjkvV3Yuetp++Q1X2sR9czbdmiTadOnEasHf55YxKqXoNi/aPiH4 GXP2vXVLnN5N8KnZG1x0rvxd4M0C+97Zj45ey9h8OTjJt5nV8feC4Pcclxl0k4+Gbfj7Qj17xlFN bkWj+wlx6v2RF75MEgnIc9RdeVWJ/9nTYjWmbe9eKJrMfZ2nuzBgX2ry7qM81w7aue/za9j3SVJF my/4cP2k5DyF7vRc70rJbew/7gRWBDBt1WuRnbR0dn6KPa+DZKbv4fesr5+bn2V+x174IyTiwoKd Jk7z27wMjr2W/h9ZyOLje+rmp2+5/QCqJXLxDQplbmRzdHJlYW0NCmVuZG9iag0KMTM2OCAwIG9i ag0KWyA2MDAgMCA2MDAgMCAwIDAgNjAwIDAgMCAwIDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgNjAwIDAgNjAwIDAgNjAw IDYwMCA2MDAgMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDBdIA0K ZW5kb2JqDQoxMzY5IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwNzc4L0xl bmd0aDEgODQwNjQ+Pg0Kc3RyZWFtDQp4nOx8eXxURRbuqbq316ST7s7S3dm6O510ls5GQiAJnaRD FpbIHiBhkQQMQQcEDOICCqigBhDEcUVHZlwRkU7YOgFZFGdkFBdkwFFHUHEZNTo6wDhC+r7v3nQQ HN/85i1/zO+91O3zVdWpU9upU6eqNEqMiKIAIuVVTRgxTK8bsYlYtpYovn5YVXVN1GbDRKIP1xPx K4aNHTMh7oHd54lOfUBUNH7YhIlD1ar9Z4jZ8tDI8TETcvMjPVOHErEAWm2cVDWqPr9jVBraWkpk +vWseU0LTj02DvWzjWhv6KzFixzPRTRHE5WfItKsmb2gZV67eVA+UW4dkerdlqbWBeQhHfpfjvaM LXNvmr1ocepLRMPmEi0Kn9PcdNWbbSsGoz8vygfNAUP/Av8I+UXIp8yZt+jGuR/kn0BfViLbzLnz ZzUtqX1kCtGeG4msm+Y13bjAODksA/IPQd5xbdO85juP1mLuxyCvr14wv3VR0E3y/Bvl8gXXNS/Y u2mdnagwC+XtJOtOhZHfZ79nRqT3rFaHqghPpI5rkuODQ79IlDQ/rhfPaz3I6hR5OSBWb+55GJWj JI10VDx/saQvzJQ54WNoGAlKnpORcuWRCI+jX4UjHmHr0btW9YiqAE0m9sZCE83mZpWKawQd5you iqcoUzpAN1YqI0CoG1XpIB85aKv4efBWeSS8xUdMkiTUnilukGdKoniEWmRpxCFiX4H0lw4S/CD9 QoCcB2VdiI8g/gz0Keg0aAvoZdBx0CGUmxG/A/oc6ShZ/pK2m0NtRYXyJtBk0LJQvj4ULwf9KtSH 3H5DiGcF5YDmgLb31QF1gtaBJoCMoNRL+vyTeISXIv4E/Xr75h+K14OyQ33cGurjBOgW0ETQi6Ad oP2gPaAY0FzQvaF6y0N13wRtAE0FDQEVyXMF3Q/qRr/3h+b961/SbX/oD/2hP/SH/tAf+kN/6A/9 oT/0h/7QH/pDf+gP/aE/9If+0B/+64NAApODShAYZ4ysqq/DDtAPWom0pJaCpCOd1EN6BcMoDBhO 4UAD8AJFkAEYqaCRIoAmipTOk1nBKDICo8kEjAH+SLFkBlooCmilaOmfZKNYYJyC8WQBJgB/oESy ApPIBrQr6KB46R/kVDCZEoAuSpTOUYqCqQq6KQmYRnbpLKUrmEFOYCbwDHkoGZhFLmC2gjmUIv2d cikVmKfgAHID8ylN+p4KKBM4kDzAQuB3NIiygIMpG1ikYDHlSH+jEgWHUC7QSwOApcBvqYzygeVU APQBv6EKGggcSoXASgWraJDUTdU0GFhDRcBhVAwcDvyaRlAJcCQNAdYCv6IryAscpeBoKgOOoXLp Sxqr4DjyAcdTBXAC8K9UR0OBExWcRNXSFzSZhgHrFWyg4cApNEL6nKYqOI1GAqcreCXVSp/RDLoC 2EijgE00WvqUZtIY4CwFr6KxwGYaJ52m2Qq20HjgHAWvpjrpE7qGJgJ/peBcmiR9TPNoMvBaBedT PXAB8CNaSA3A62gqsBV4ihbRNOD1NB24WMEb6ErpJN1IjcCbqAl4M80ELqFZ0oe0lK4C3kLNwFuB f6FlNBu4nFqAKxS8jeZIH9DtCt5B1wBX0q+Aq4Dv0500F3gXzQPeDXyP2uha4GoF19B84FpaIP2Z 7qGFwHV0HXA9tQLvBb5LG2gR8D4Ff03XSyfofloMfEDBB+lG4EN0k3ScHlbwEVoK3Kjgo3SL9Cd6 jG4F/kbBx2mZdIw20QrgbxX8Hd0GfIJul96hJxV8iu4APq3gM7RSOkrP0irgZroT+BzdJb1NW+hu 4PMKbqU24AvAt2gbrQb6aQ2wXcEOukd6k7bTOuAOBXfSeukN2qXgbroXGKANwE7gEeqi+4B76H7g XnpQep1epIeA++hh4H4FD9Aj0mt0UMGXaCPwZXoUeIgek/5Ir9BvgL+nx4F/AB6mV2kT8LCCf6Tf Al+j30mv0usKHqEngW/QU8A3gX+gt+hp4NsKHqVnpN/TO/Qs8JiCf6LNwOO0RXqFTij4Lj0P/LOC 79FW6RC9Ty8AP1DwL7RNepk+pA7gSdoOPEU7gB/RTukl+ljBT2gX8LSCn9Ju6SB9RgHg5wp+QZ3S Afor7QF+qeBXtBf4NXA/ddOLwG9oH/BbBf9G+6V99B0dAH5PB4F/p5ekF+mMgmfpZeA5OgT8B3Av /UCvAP9JrwJ/VPA8HZb20AUFe+iPwCC9JnWRpOClPl2v+HT9/5c+Pb3fp/f79H6f/n/g0x/q9+n9 Pv2/yqf/v3RPr/pf9Om1/T793/r0hf0+vf+e/m99etd/lU8n5S9uZUoI/VXu88ghxTpIhPXKfx3r QIrgXd3waKXwW5XwS2PhL6bDByzBntoEPUmKpBt+VJaogMQw+JspkGjqk5A++Z9+s6RZ//I3wb8Q mJp++qNizuW/E/6ZAKYiqij0p78UaTSZo6JjYi1WW1x8QqI8wmRKSXXjFMj0ZGXn5OYNyC+gwkGD i4pLiErLyn3wwVXVNcOGjxhZe8Wo0WPGjhs/oW7ipMn1DVOmTpt+Jbzd/8Ug/O9V+69bFV9Fna+8 rNQ7pKS4aHDhwIL8AXm5OdlZnsyM9DR3aoor2emwJyUmxMfZrJbYmOgos8kYGWEID9PrtBq1ShQ4 o6xqV02jw+9u9Itu1/Dh2XLe1QRG0yWMRr8DrJrLZfyORkXMcbmkD5Kzfybp65X0XZRkRoeXvNlZ jmqXw3+kyuUIsCnj6pFeW+VqcPi7lfQoJb1eSRuQdjpRwVFtnVPl8LNGR7W/ZvGcturGKjTXHqav dFU267OzqF0fhmQYUn6La0E7s5QxJcEt1SXtnLQGDMof56qq9ttcVfII/EJqddNV/rHj6qur4p3O huwsP6uc5ZrpJ9dQf6RHEaFKpRu/utKvUbpxXC3PhlY72rMOtK0JGGlmoyf8KtdVTdPq/UJTg9yH yYN+q/yWm09bf8qicXNl/Z2XlsYLbdXWqx1ytq3tTod/07j6S0udMjY0oA3U5ak1jW016HoNlFg7 wYHe+MqGej9biS4d8kzkWfXOr9lVLXMar3H4da6hrjlt1zRiaeLa/DT+JmdHXJyvE0d3XLWjra7e 5fSXx7samqoS2qOpbfxN220+h+3ykuysdqOpV7HtEZGhRLjh0kTzxTIlpYjLqdrxFzXL5BG5RsAg /I5ZDoyk3oU5FcnQXERts4oghtDAUMt/FVbkar+usrHNWCLz5fp+VarR5Wg7S7AAV/fXl3OaQhx1 qvEsyUnZTi6aGsr70n6Px5+ZKZuIphJrijGWKfnC7KzFAX61a4HRgQjqo7HQbVNDSS7U73TKC7w6 4KOZyPiXj6vvzTtoZnwH+XI9DX7eKJcc6CuJmSiXLO8ruVi90QVL3qFs8Bi/1n3xF2mMjaqeU+Jn sf+muLm3vHaCq3bclHpHdVtjSLe1dZflesuLLpaFUv6oynohnodSPF5QSmGU0y4Ky5n6cL+Yip9a MeqrAhotrFLhMEeN39g4vBcb9E7nf1gpIP1NrqVEP1ULDdNf4rk8P+Sy/GXDC28TMGDRzWvrprS1 6S8rq4EHamurcTlq2hrbmgLS8pkuh9HV1im4BXfbgurGvhUNSF2r4/01axowiTmsBNbKaWi7i901 rt3H7powpb7TCPd9V119B2e8snFoQ3sKyuo7HfC5Cpdf5Mo5h5yjWgZL7+BapSi+00e0XCkVFYaS nxVgpPC0fTxGswK8l2dUeAjZXbikHxAOdEws8AUQlSjR9oiU/OVyHGZQ4g5dQXlFrnCAFoC2gd4E iTQDuCzEEcgOLAfJ3HVK+SZhD/lBB0BvgWROFzhd4HSB0wVOuRAgJuwWdnWk2NH1ju22lPxvK+KE 7SSBuHCvsBoPP7twZSieEYrXIc5EvD4UrxVWdwyxR1bokGf0LVACcczt0Y5hY/I7lcRgr5LY2MfZ uB0ce4VNeBSjehSjehSjehSj+hbI0OpG8DeCvxH8jQp/IzGlKWdGqKlQ4tGOyNgQB4kKvdAgTMJb 0i7Uh+LJwqSOfPv+ikZhIprepuAmoQ64TsEZCo5RcJlSukxJz1fS85V0uZIuD6VlzL0E7QpGyiiM Fybg/WsXxgkjlXisUI13sl0Yg7wcjxZGKPEoYZgSXwG+FXEt5MyIRwo1Sn4E8lWIhyMvx8OEmo4q e17FAuRnoIyjP5lfhTFUYUxVUJLMWQfaBDqpcGYAl4HeBAmKJBOq8FXiqxAqUMOHNnwo8ZEg+PCV 4ysTylBSCtlSoE/wKnP0QsqLnrzQlRcte7E8XiyPlzSCF+gQCikP5AONBTWCVGgnC/WyMK4s9JAl ZFMK2nLyNRSN2BGK7Xw1JSFO4qs7kuy+Ch3fQWNBjaAFoOV8R4fKHFkRDTlZNhc0BjQDtAz0OGgb SEvlvSW+MF7Oy4UxfIwgwroztnu9+UpcMKg3TkjsjcPj8iMrrhMyoKYMehwkYMgZGHIGptqXs4M4 TCeN9oPeBJ0EyQpPgzLSoIw0TDAN9dMUKbUi9y1IAgkwojS0f7mMSqltB+Ve0orMTQcnHbl01EmH bDq4J4FMqSGXjwWtA+0PlSUrxpysGGcy2krGaHOB5UoqEmgXkju4LjIA/bKSyIrB0PsYEAr5Wmhz LfS2VrYQLm/iXJSUhyTWgbaBVEInvgx8afjS8SXjc+Jz4MMKCklYvfX41uG7B99afGvwrcZqRG/z 7PfwGYXzC5cVrit8vHBb4f5CzR7ehK+RN/r0FBuLk9Bs0sZVGLlI08jAflRwq4LXKehT0OKLm2Y4 Pc3w6jTDw9MM908z1E8zjJ5mqJlmyJ1mCLCZPovH8L7HsN5jmOQxDPIYCj2GAo8hw2OoMLEGNpkM tE/BoQrmK5isYCKb3GEg3V42lZxaWDxL2+FcYf/UGRBZh/12Z0CL6Lbe3NTeaIjM3GXPc7bYs3o5 7t4oxfmiiBZoInueNMzjy9Ic1szQ+DTFmhxNtiZdk6ZxaeyaaK1Za9RGaMO1eq1Wq9aKWq4lbXRA OuXzyK+taLVRjtSijKKSNnIZ5YcZrg6caTmNJH+UUMtrJwxltf4Ds6h2psN/boIrwPQ4U1Wuocxv rqXauqFW/2BPbUAjjfcXeWr9urFT69sZu6cBOT+/C0dWXX2ASTJrZbx8fe0kxrJWro0PxQ0Ncp36 dpGtXdtAsYvLreXmMlNxTdUvQGMIPT8Fq+fSDEaS6H+gdkK9/7nEBn++nJASG2qhOfm228mL+KDq qk4+WI4a6jv1y3lR9XiZr19e1fCTHDnAr+okpxwpcuSQ5cjxM7kkPliWS5WjXrkkRS7pMrn2Umd1 VbvT2SdTqsiUXi7TcrlMiyLTEpIRemWcl8hoTpFTkXFqTv2LTNJ/IJP6izKXaLN5qOffBNZJI9nx 9sqb5adCo6u6GdToX714jtW/fKbD0UmV7HjoFeFunDlrjhw3NQfYcVdzlb/SVeVoH3nzv5b7b5aL R7qq2unm6rr69pt9zVUdI30jq11NVQ3bhzVlbr2su7v7umvPbPqFxprkxjLlvoZt/YXirXLxMLmv rXJfW+W+hvmGKX0pVg+z1NLQBtxNlXg7D9PDgBvjnQ1DY40LyhRrHuK03hrfJRJ7lsJwVQ/Hs88A kouyK7Ir5CLsMrkoQn4Rhoqstw5xxnexZ0NFRrBNrqFkrb66Cr/W1lDiP/y1trYuurL1ylY5Vn6t i64HyctErdS6iDCDinDlfLPDG8u+eTVojeKjhdbWhkWkrGnr9SS3tkiGnxq/mLoeLbPWS42AWn8e ZMvwUC+hudbrGaRkwetDZtPKUIhmSB5kqBUi8XPQBopHnCTMxIlN0skQfSz/199yebBHkvgJCNeF qDfU4btfwTo2qjemq+gYzaN76UHwCtgbtJl8FAn+MRIYsXry0n10A/2JJkrfgeukJ+hbyqJimiMF yUTLKMhuoScYlzVFRfQONdN67hU84ldwjpksT9jCbqNstFJHD5CF3kSLmZIe+e08kXtRq45eE2Zo s6Q86Xt2QDwszaTfMS8/Lr5Ar1M3SxYpeLu0WtooPUoRdEZI7HlZGiDNQ62J1EjX01KMYDn9ho6w Bl7K90t3Y0z1GMMy2k2vMQ8MqhE3uvGQvoMeok7aR2/Su/QpYyySpbPl7B12TEU9h4KHpBHSTGk+ VdNoGkvLUZrIUlkFnyJMEbYKJ3o+CZ6SktB2HS2mG2kJraP1tIVO0J/pfSZwPa/jE4WtFE+lNIVm Qpv3YUyb6TCdZFo2kJUwH1vFnueLRaHnEE54kWKgweGK9u+ljdDpU7SNDtFb9Dba/A46FZgNiz+R TWO3sJXsHvZr9hR7nr3AvuIq/q4gCCvE34tfBY9LeukRaTP6jacEcuCum4U1uALreYS+xPwyWRYr Z0e5h2cJTAzvCQYLpGHSMukV6QS5KA2ypbjXVtMomoxR30S30x76PeoeoTfoM/oHtCQwPTNDFw7m YuPZBHY9RrGVfct6eCzWr4jP5R38mOARjoiTxRd6dgRjgh3Bb4OStEXySy9LryvrOwj9VGIFptMC bDF5xXain1foNP2VzqIPNbNjrMNZLeb7ENo/yS7AnLT8Vv48l3D7XS8cFm3iQ8HRwXnBh4LbpYHS KNiWgEuXjQbiK4E1TaQGtH0btPkEPYeV2Q7rOU7fMCtLYnlsBJvE6lkjm8PmswVsIVvClkKrm9kO tocdZ++zb/B0VPMY6MnDZ/Hb+H18Bz/Ej/PTAgkT8IZZKCwR7hN2CG8JX4hGMUvME0eJjeJN4s0q XMnUsdrXL1guzOuZ2fNIz8vBnGBV8FfB1cGDwePBj6Uwab/0Ka6ieRhjA7VgjLdg/qvoHnoc9vEc xvgRfU5fYc2/hy4EpmNxGLFdWbdKjHsURj4ZV6bZ+Oawa6D/5WwL62B72QF2kB1mr7Gj7AP2LR7P MTwH3xDsgol8NubwCN/C/fzP+M7yf+JZniXkCwV4VTRiNncKd2E+DwofCJ+KXIwRB4gTxGXiH1SC 6irVA6qNqkOqV1Vfqo3qqSEf8ZMHQRBe5wfFMmEubcLrQBC+5Ee5l93Cz7NneCI7iN4S8d4ayyv5 ENyN9sDK51G0ZqPaqXbyaDJqGuU2+MM8W5gsuoVwWoT9RnwKX8Ub6Wm2l87z4bC0xcIRvonPEDaK G8QydgLvi4MicQM7RxVUwcqwdu/QQqxQtrBNfENuUaUVLqjmcYN0p/i5igtH4QdLGRf+yKawbjaW x0JbQ/g95ELeyLoRj8AO/DMsvxPXziLxlLCGj+TvgzeX7mMHMcc9NJfvYb/DuhRhP17HxrJHhQF0 K1sIbRTTNfzXlMwX8GTY80T6O7uNxWDnnsfapPDZJAoGPouO8Qas+lvMzHPYrbDTebSatVEW62EH 6HV+Lw1izcK+C7aedM4udLN2YTi1s/PiYfEwLt/noclEWK4WF+6PYNMb0cvvySm4YTVFpOJ4x2E/ NWKvm/hZtpTPpavZQ8Jf2VO8gsZQs9DKa9gDwbNihVAAjXXBm1Sqi7Wk8qoSxYFY8c+pDNbYQqSe I55U3SanhXeEM1KD5AzOUEUEP6CboZ3h8G6rsZeG03ssll3JxokSrxUlaRJt4dvEDyQLC2dOelvC DgvuZF6WIjnYQimMjYOFXyn//1DE1eJK8XpxKc6m8/Caq2gDPUIv4TR5EudWGvR4BbQ5Db7napwR eZRPhZhdmfxvKGgEysbSJPjTRnjJ2XQtLYTnfYyep3acULXQx5WoN5uuAb8VJ9QSuhX7/05aAx/w AD1Nb/Pn+ON4497FX+GL+dX0Hr0n/EHwsUl0TLxbXEYT8AYex6LQ82Cskh311kjvoLcMiof3H4hd CruXvpKOS8/2vIn2nsbYN6iH0lfqSkqnMeycGMdU8G/Qodiikv9Vh4Zq2tWaAAvfwRmpRDkhkF6t QmKXIPA4nUbm7WJk045ZYvWMNp7xjurxjjae844y9uBR7+3xyjQgr8DkNKU6Tc4WkS44hAMXfCo6 Tw7xAPbTV9LH/GOVCieRncb4Io+HfRrGtRo9GVnUojg0v9sXZaC4sNgXjGVMX5b4Ap5RGqbZy0fg dAiy0WT1GM9N7z592nj6NJWXdxu7mclcjN+APLhFQa12JbvTBHfhwEEF+bEx0YKCahe4YPHdbm4x mS08lee6XDnNaZ7SskwZxA09UxxxcQ7+tDUsOSfHpb+gLfVkeUszs73y+0jPnxEOikdJi1E3tkeo AnyVT8/0Ovn/nqM/oeviT1IY3+cLd5j2m940nTR9a1KZulgscb5vuxZ7P8Cf3JmnnY932V7+ME7z 79jY3nmc6Tb2YDZnuqE7r9ELfWIaztAsfkqgrxq1w2ZzqFmLkrTGOVTi0WCc2253s896Y6xkUDop BEX5tKqgc76SpZqluqXFf2SvO1RDMifltbhacpdo7ii7u2Kz5ndlL5fpU3IzfIW5Jb7p7okl6pS8 AQNcxRV4D+qK8gM84BtQWLgRlD8gv2iAyzVgQArpolFYkcLyRJ2rWMhUX0xGCjlT09LcARa3IynL F5myh63DajFB5bMUkb48SwjLLIyrdE4Nb/dmqW1Dv9trDbCUlbL9jMLcZfuh8lHd5d4zcbZua25c 9xmvsRvLVGwpZr3RnTmeiFuMh6ykNfaUmotzrcz4Xe6ZQ3fKzEOIjIdkxS2cTtOdaeretR7sDhmB pdcS1BqN2+1KVsdEW6IGDe5lqV1qjSVkIUyNotiC/MFCnW/KPTfuWjJ3ZOIDVydXJXv0JltETIW9 Irm6ZcoXpa7xSXGR0Wl5ZcXDkuLikoKVdbNWTlgwYtYd++6+5knHDbXps+6Pjom1mcOjw1wJ8bPL K9YF17U+aDUbYrWbp0+yRJmtXB+9ZGLzPbjoMuYJHuNvsxzSUYHP+hIdpVP0N1yudons7/wgHY3E 855r9rKHSE/zWGKv0ZzuOU253ZjvdOZkvbMdjMPUFDwR77a5BJbT826+y6YPlx/3XVwjRvFl2Ntx vnA6wClOxW3irC3y5j1t/IxyR8kNxTgLxagLz/BlN96IMR2RPsbF+TsyUAKsvEMbJr4bZouY18mS yNq7ZlSOWqmXb62JKUVjxw2W4bsxRSWjZUL/n0mThS9V88hI83wlOl0ss+mEIirW1bARuqm6X+kW sxt1d2vv1j3AHtY9xTbrdtEu9gd2WHecfcb+qjvHftBZwnQsLMBe3SmEldFUXYB1YFBTtS/mCkw4 YQqwPe17oZUz03tgSSG9LJw+nV1UzKCQIzjVM80Ub7Lp+RNh0REmmyrlx/pUW2R4jOpZS4QtMgy7 51PM+wuVfCfLZVu3m7ne1SV9T4J0piNbm1GhQzpdOkNp0j8oFhQj/WNXQoQuQhvBu6QfyCh935EY kS3XyJS+97kyVAkR9ohk8zxtUoKZcliaypDsinCWmrNKVWaVyhBXCq/w+q4BKaURtrzfdjE1WVlW aEsYz0HD5Ub4NnOx7NpMMsDBVd7km8JzjG6rzWKLtcXYom0qdUJ8YnxSvD1eVKe5090Z7ky3qA4L 14frwrXhmnCVWnAnm1J85IiK8zGPOtVH2WKuj7kinT4WbwO4w7N8lMMByoNNeaJlInhWUFEosKJL A16XvhhTUpStPDrJZCk3yRCblGQuTw5I530+JNKiE0yAeCPAFgmwRJS7ZEiLjjUgBRCiISckmcPK s/WAWDmVGG1zyo187bMgERltscu17OVcbzSVWWRgv/BPJuRhN7AYo0bxlG78CguNg5V9H4ufZiA4 adj3PAa724KvIN9cKHyxovmRkbfnJFZHWpCqvS0nqcoYW1eZaUsvHrZ2U6XHml48fM0m/v5bwe9+ s3RIoXND6aTWt5hRTidv8E5adsORUpfNFTx1oPOGN0qTbSnMeUDebadxiH4h/oC3THuHWRsfkH7w RZrUpNXF++LHmsfGi7rILr6ZwtlGn84YHh5p3KfTcpmjAsfMVCrO9mlD/wJeY46P7sIL2MRbdpNK pw238eg9fAVOIAt/w6enFpOJteDUNL7IF+Dp9Fs8fBULkk9Hr7Gn26gcKuXd3YoLpYt+8+yZQ5dl BuTRdGWVTc7e/exU9nOB06QKbaFBg/l65pCdXc9cGZkj+E20LtKm19rEH85Pk12a1RxlEfMmqW2m SINWPhW3QBMnsJc8zNGu5pV19bvjwzwqEQdIgE3dqQ+PLk1WwYuU98iDG5AX34k99aEvKz5l4PDI myNWpa1KX5XxdPrTGXvCd2TqDGZ9bGF4UaaY4cpM8kSnJaW74F1lSzF8ae6O/dHcEyuma/s0+cHu kCJVL7LTcKxhzACnNnWHTqcPjwuwf+5Q+t6DewU2Pfjaj0ylqRUGPh8XOAu4SZAP4/Nwzb23b1ca z52RNyVAdn04qIw9p3HxCKmRetWI3ZlgTzFbY1Md7hin1UdRLpOPWezRPmZOAYR214oVvfpGoIVs oadhsDN0WYEXThlcxgsHyseURq0JHWSh40utIU0PX2mFti8cY/T9wjr7C0uufc6m1oUbTZarO5se +9g9dXHw3a46p7xI1y/97Jv5c8akz3361ulWjd5izHvyyvfaSppaFwU/+K1sqy9LH4tQFGHht88t YhSA1yrIzy80laSMSBmZWll0HamXOVcV3S/eV/hA0VOFTxd1RnVZXot6LfqI5f2ov1i+jvrRIuWa 5Ho7o5OxcKYAVjABiQxtZJgn3STkYiBWUrkSyJbkSHdn2bD02x0Oc1aArd3uLi2IQLzTXKp2lQ4K MINPH1MqJCQUC3EluV1YggS+YneYrbhApTZ83cWW9y4E3CKTXeTp06ONn0H3o4zy3UlejZ7TyOLS UCy7S8Xk8TP1Os2EgYUpqVHRoip1oMvHolQxPpZS6PaxaNHsI1LWZQUCoqLpC4uoaCGLVXaC7FCU tZG9xiCsi7t3RQosSk5Zpb490rtIQtSim88G5n6RE2kxGqM3bt3wStOu6UlxNtvwhfc9snTyhiyj KcxknXzTI4+/PpNvGbhz5oOfT8szmo3WyNbdC2rXT5D3EmubeuV678BoncWYXjpx/x11D+BsOi7v J7x5EgmvFZ8B57mDJzlVifaEWKj1s12JiftiI2PMAdboM0dE7ItxOJ0tXIjmXOBOuwOK3y0IosqZ ZEhCuoMicPjgvEpMkLdBLEWCFxsjBPjtvkimimhJTLRTZBLDVkjq4teSk031hWEPMVuyKMaE47Q6 iuVIubgcC0fhErvQixtsj9d4mozebjnxDS5xuNPK19oer6lYhTuccoWTN87ZY96+OHJA3kLmLGQF pr77RF8i5IgKTCYXE4Sed9g722rscXH2GgWDr8r4WFZwMpvRJKRdeF3WXfBsnzdiM/jJHifs/JBs 59BcFn3oSw6L1yUk6zJsJVZVdsYVGTMyrs14KOOw7X3rV1atTTbiWNmIo5CId7i00UZHSqw9jtkT nfQiFJUq+xFo47RPl1gqinpyp0YF2Cc+naVUH1dqxDOli6+kDD53JyRbUlMC7C+7jbbsVFHfZ8I/ 6WzUGTyUjN0903vN12uSzRdeWzZh+UWj2LFivVZrgkqXoML5bdUB4tWJPmbTWn6yXGxhj2f6Qmbq cxWu5LSfW64ruded9Dl5tmzkXaW/+dPfdtxw7Wif22o0RT3Ycd+Bp5fffrvDYI7lI2UXIm4INtvt H+589YfC1MHOWLPNvPbwM/dsrTZaY3m27IfgPs3Qbhy8iIvy2HO+8Jzk6JSByUmeJGeSu0s6J/8D XV9EoThEWynWaieKU7TqVCh4O/TrCMXJSuwamBKQjvn0svdA7RStIYCay0Txf3D2LXBOVGff55yZ JJPrXJJMZpJM7pnck83uJrvALpkFAQV1F0UuYly8F0u7bL2itlBvCFqhXtoqKnhBUasgF1lBxLfV aqW+4KvWVtsX7IuotCifH7XasrvfOZPshfXy6/fKZmbOmexCznme//P/P88zK824aBej0iqTdo53 znDOd17qXOK8xXlTbKdzW+xd67vCX+1OKzQwppBRldlYKB6+KHRBeEl4SfKywuKGLZGd6d/b/mI5 ZBPOZjDp4Xgh5HQF3QFR8cicZI+AmN0Wt6oW2FBA+SyOIilTJm3wGB32WBH7yPptuXaKMvv64H9r YrDdZUi0m+3S+8Z2kObSoXRDmk7vQq9j1R+DMWBDj26PtDc4oEMu7oSt8MfDlK5KZA7XX8XEHce8 I0fIXh+s6VbPuFoEJDAVz4bCtJNjeVZgKaPNbrUjY5ZOazDkjPTBX2puoFowl4vHkgyezBhyGgyz QXLHCuP2hAZSpoRuFsQwuDadyRFc69UDjs6WaqEnA0dMRbcUHHaIrdRtJxoBWCWJo0wHLjp9/UU3 73vhse/tKk+uNKx7+7pZrZLI24VU+68Hdsvqwz2L16676Lyz25Dzsu/vf+RnX95861P/9cAtC9de FGFlwWNxDTzzYfiNZ+/beNsNvzyzBXvlm4MD1O+xV7rBsmfMFAncRgxdaWQ0UugFs81uv8QNXG43 cGMyYfNY3TZAcRBdYrXwLGehOZt1B/ZEiDZs9Zhl8W+j6PPB03TiU9GBB+OOLiF1Z1ruqIvIMXEb lsK1hSjhCzgE6NSP+x8lWEJRA08zokOQjPQiVXeLtTf/61UvL3EWAaPwh1gzfKhrhjgowuXaScJj kdfAJ+ATG+2lFXcmNydzETJYHbTkc7ikldJd8F7mXuudibWZ+3KPw4cT29Buyw7bjszrltcyziVw fRgVXTnMbDb7o4G+wT9vbojmdwz+GYuNL7byTDIZI3PpZGTH4N9AfPDw5kQkTGiQkElqTLQ9lTIq 7U5Dod1oj/bBP2pcKiVyajv1vre9InaKSOyDRzRrU6idez/bbpYbx8gObKLHSC6CQNEh3VCJneqm 2ZAr+oK8m2YCQkgDfhfGobwJa4YGAw6jQR4jks+NDzmmoIEiFhgjYoIE1q8qCVCF1V7QO5mUVTOD H23BagB/kI+2YJFAzloD1ggGCY8MEr6C5ApK+pzLVnFL+O1uMucmc24yd4I0mDccv/U8QGI4G2Qy tjTXcgDEtp2jrinnwu8eWLfuwHcvPSc9/u2f/fyt8Sn7g1dc/uDaK69a6/nlsmW/fGrp0qfQrU2P Lbj73Xfv7n6suTRu5vkr9+5deX7X+I8Xrbnv0vPvvHPA1PPII9//wYYNGBedGBc92C7ioAl2aTkT Q6dNGZB/IrYjZlQJSEaz+OCQ8MHuCDQ22yL40Cg2ZRNZN2Fi7PziB8KX0f+bPpY37AawSFCSfFcf 2XQR7/9h0IjXKYe/y+jaVnyp+GaRPpexx4DqsCWsSXMaqz98ZVfxhJ1mY6l2i4HgmWYpYECzhNtF u7oDY5YdPapZYu2st+R939Se3YU2gOYR6OKO9WOi9Tk2jQ9AzRoOVmp6gteVaR24Eol8JEq77Q6b Axl5TGecnIujjYZ42oxtJGnFNpJQI+4YQSonzNNEbDIpPOnAhygXxvPbQM5YGMauUeAFqhkCWL1w GMPwte6kQ+kdfV91tjwq5oFSc0Id2d6WMrW7Y8u5cx5esHvdD55vnjxOvfOcH91y9jivxNs8iaa3 YaOrdP/C7z700MUTLmsKo99cdvmF/3Hpvf23L3/qg81Xdv2sUIlwEu+xOmHTh+k/7Llz609WbNG0 DN5nPVdCnQ/sWPMVNTO7WbQym4FR2AlFjAk0FLdZrbLsH0metJ3G1VQESaHAE1Iozm9KqIwcqPO7 WiacTl79q4azLAhcBFfSCymb/q9o2WyKwT70heZzx1ir7FXoTgHiL1YoCBWBEmR/PXVbxZSNZN4K mL2Rf8uQ7qsR2RNGdPG4rvyou8hx1DXaTngAeQ286XE6PeRVs37qr/QmzAqK4AWt4yQG3u94gEd2 x1rLGjuVMMej10c3Ougcw4Ao1YXpmeBlxfjlWau4js2ygUIABWg6G4DzuzCnMjHJPjhBcxZuZJjG Jls27G1yzpfkxodJFvHCOnbpVkqAC4NYG4dJFbku4IBbOaKTqWrdVAO+kJ33q5wiJPBbfF5H0JaE vI9NQHuITcJa4CTWh8MmQagqHIoN2IbqnH/UTG3HTtxGdBfmn9J7XbmHr590xSwSQ+7Ln376Y3uW DPxuVra9kp6VaZ+I0FlkDX8yc2bupMVrA6nZ+miKzfnqPef+dOCMUblnrPcBvZu+A6RBHj6rZco8 Dma+idmW3DThFO+p2am5LqFL7PZ2Z7tyX6TZDEins3mIUM7C9aFHNNG+yr7WjvbboT3F2+0cr1h4 IZoitxyq2pRW1VRaiaazZkqfMhqb9BCsmFFOdupTojhbEEWnoMgCH/GTqZODILgsuDpI7QvCYMoX DPp9SsTn9WbT6YDP6/L5vALPB1AOq49cLBq1mBkAAxk2H8yjfN4s57Kq16l6ZeTdAedilT1Rc6VV n8aaK4CHrC/oO+A76qMx5co+24BUPqcKO+BEwA++uIW3VLDIfFHj8HtZHgK+k/+UH+RpHr93S2HK ImwPtQRIL95IItZrl/16JoRoEmIUVb1Igfd4uUEXJMvzUmb5D09MLVd7C8deGpNr/veH+nebMAEh r1qalhojaWBdSIbhmBsUFaWoa/v/0Pugnlz+DTl2wMu+0PMuj8F7O/TpV4j0WXfnR8H34fKB14ck D3WYuN+/fjUsgZajC/rvJ3WdOdiG5mEb8oMEaIQXa7s2pp/M/MbysvUdi2FVemXm/tCa+NrM03Hj tbGl8csyV+RWWVa5bo2tijNncRdxSy2LucX8YmGx0zQ9dFr4lNiMzM0OQyM7ITQ+PD5eSU/ITGGn cYy5IIf8YV/cl/YVomw6wyzhno+9UqCmhk6JXxm6ObSy4e7Q+tC2EJNlsGjNAKCIiDFkIFSYhpCD iiYdjaGEklLFhMoElECxsVFkkMhE46wtaCvYKrZOW7etx2ay9cEbtFQuDniORyy/mn+R38cf4I/y Rt7bnEhi2Qo4gI5ikik3TV9SswkCd731WlVVl6uEI+L90kUYV8sb1BNlJ8rTGmrEsoLLYnWqmXja lcvBuCWag1khlQMxq5qDYITrEMTo7e2t4v/ifHQUhprEWsGhvtHOcGNLWQeUMJZk5VpyIQxBL9lf xN3/8vobrulaf17/bWT8Mkx1d7afdNdVA1vg4zOvnjjvgVsH/mtWbbu3XXNvd+G+c2fdej7ZclSO +i9t6bzpuHjypeO0qyeSLuTB/fSp9FOgFezXrs65YAFUQCegDKJbnO25yHWhuDC/2HWZuFja6rG0 +MsN08Xp5fme+aVLPd8p3eS/p2BpKrIhXwQCinGInpbGUDTA2gElWKNbM0K8xXorHYhnWigaZcwO lVkQVlXveJ/KFoPFQrFSpIvyuOWjNqGG1P39ZPn1DHdt9XVCQYC6lrkZp2tfMGOT9cwZm2Izz8Ys 0Y85Me8ChPgqg3/bJooevyTW2eQ8AtXY04fyaHVZk9ClC/mDp4DOAuoskHCFPFUqNQt4hvpDLXLx HmSYffld583W1EkJP+S2Lnqyi3cLYuaM1xfOP/fkc1c03vTh8n10cALZko+DXsk3q2NeJpg7vXvq 3DufH/jrud1ukfcUzqlGfSc/+dM5T14H9Vb2udj3Ctj3SlDQvN3BHuNSI8VbHRlBUKwRf7AUjSp+ ymzEuLaFDVTIWcuycsU4G2EUdnk9GadT8TbnyYKiYqZUUvKJHFGfKJ1RVSWH5d8irc2LoGqNxlRv CajxAABWL7IyEZX1w0/9g37k76BUYIZd5nXmfeYD5qNmg7mkqnmQ43Io14cRWIzHYxikzWc4C8Kn wlFCE8rTe2o0oe20I/0kt3OMICdX7T2CXanuPf215A75wt5yBAuq6lttwxd1D9KHmczQjeF5kniG /FDykx/O9gx5DT8kykbeU5+BZ6GbyZ4dP49sRa/uM9RlZKb/UahnJkgERqWBoI6bA1tH0HFgP5l5 fWBGt37nE3Lsxru0DHvJTdhL2qCqtd4WujeEClyF6+SoU2xTY7OtVdvs2KPWR2PPG3fYzHTUE1Vt iagaK8eMZTBuNRg3DijlUoEExya2ETaW842NhbxSsjDBBJdzwoBHwq6YK6eDCkeFfW1quaCWLy6V aGc47qBwqFuohVwuJ0rHaXPg4nw+F4AQeCcmVJYJMoiR25f3jHEhveDO6ekEvJ46ySkcHHGlWgqp LnyF0dn/ai39XxtwL53gZR0WwGH/MpAn7bHASOFXcvDwtpgYEaNDvoadjZRZeyFPvCiP6k7kqeep h3yvlhzFQ5r43dDmGmqZbLqwYHf38tdv71zxyW17bjMRdS0JvAca37j28p0zyxC8f+r1c2o7BTHL 5Fxw88AvSuWu1ZtX3LsSGlb2FF2sN/BCUPYoZy266Pbqlfe88XkoCVvwBkvQ47SLJryj38V+14P9 bjL8lWYTHhSfLmwRdxfoGi2y2jN1NuQN6SyHU6CSCStKKKx4s436FCjAQqqpUGhsUrJtk8gUx1aC FVTJTK5UJk1W2mqcyWrM1ClTjTBZxVSdL2Xi+s/BtDKZiSWT8ZiSmVAiU5MBVsKZ5tbWUrMyIRoJ AAixGlez2UxI9cbVTKbGj9omTLBg8tQUiDUHYpM1f7B57eSNk9Gqyfsno8l9aKfmmyIEwmE+0IA0 tBpRnWgfQizqRj2IQs+jneAk0rQL9OoodlkS6LDrZtp0/UE8t42wIj3+cXrBvRYOx5rK146+efBt 3zX2Z+jkSE8CFDDsmVlXRdTwoYBBcLvDiQf4UBP04a8kheswMZw0Dn9lZiy1uqH/TR0qBv6ke30z IVFf6giCcosDXjn4JZlp7h56jxxcjMoDgRPplQ4ip8KtQ9fHxaH72OY+wGTrY2xzQfCOlivQeUPU FrKHXCF3wV8ITDQ02RpcDe6KvxI43TDZprk09wx/p9IZcJMnKrDl2Mp6URBbUlAf+8vA7w8CRWaQ PjaU9cqWwkgCGSfcZd7tFnhFCqqyoMoSQirDqmYzQwg338lBTg7dtn8IxfUGHbLZZNeP/Dtb+XW7 9ZUq4QlCMYp+OqZSeEAnNLpupCeOLNbIYpJa1JMYfTfidVPBZ9p1P6KWOq9xrUC3UaucK11fiIwZ WV1WN3Uvut/0hOlD7gPXB6KR5i7mnuWeddGNjBqKljCZDMlB/3uSpARNrGC10qEgEjCaSh4CpZqd rwDNxlUOALgM/33eJHuxI8AwJnLDRG4sw0JTTtz/HHy7JtOrmNARjD14el1O1Duc8OLh9cDY+nU0 McKJyOgWXfjIG1iMuqzR5KQ8OcgZMQaLSMjVcva6wkzXySJe0hpm8rUgR5G8K+GGY1aW2njwge7t i0hkg6f9fPoZp7TMH9hODBZdXFvcfu89B+ZcAMu6+X42bVoycPtMdGh4mSGYhxHxHrzKk9CFWlXK SWVvR6yp1NRSnhae33FJeFHHVeHrOlZqKzvu0dZ0bOzY2bGnycmCctOUpjnNNBvJlKc2d5RmF1+q /Fp7sYPxRXzFhZGFxbuaN+YeL38U+TL3ZdnSOAmA4pA1Z06wZgfwQ39TCBt0SJHTDbo4DeVW51BD DuZyq4u5XENRSRdBzdYdwAANTSeYu9WdqZt7KkrGXSqrBtUGlVIzERJvlFQk3NGslenKpEgRCCAQ jrjC4QgIFyN0CDao6aiaTqXkYiQSwv6CHUZCrS3qxEqFYThVwyK1D12zNRyWzI19cO720KRJRTBJ bdwBN4AIukbzaF3FBcXFRQoUtWJXkTpQPIr5WEfLTqxhQ6ACyxp/UjhE/A5w8ChxvcnTd8BZIyUA XX60tcncMW+/hIe9XlK6JKDrlXXsPSJVvEd0WMYCVUfrttqfelhfns+Q3gsZaIE2bM3+FnyQG/HB k8MHV7JSa+uft9zww5cA+QZptCYtfDtij1az1d5vBW2TA8vaWlH/ORAZPLBFjjWH+wYPbMZn/E+Y R2BCp+PfBNnhIYCGYxAbko6NoX6sKFITcPYavdS3boTnwQVkZg066Rxy/geZigw0XnJLJbZgIZl5 6Maty+FrAyu/CjT9/0KGYQS/IP2jyzuO6uXWhXvTBIOWYe+Yi70jDBZprZiglwhBD/sCBFt8mKC/ V+fjJcLHkWr1EYrNmqHZG8W77hTkyPolo1oiD1UxRa4l+0ZY8DD3HYENDKj8NzHgeqnubZTXq/4L yId99VV9FT4YAlR4OglUA+eOAVUIJPx5XsSfpxUltPF/UQ4F0FQwvfVFsA+8Cf/gf0P5HHwOP1cs cZBQEgG1dZp/jn9D4LnAW+At+JZyGH6k2OcGoE33POdaFrJskEVsysmyglOxBXVqw4FIVwRFUmok EleVYEEnN9bGpnJjY6msFKwGfcw00QxjoBWrz137YRJkpaCEpJRLktwuxZdP1jw+05VBmVQik0km lHzf4K2aX4Eg5FeUAEQuSI6BVgACSsCFp7C3Kpo1EFeDwUDAr6iQjKf7/b7WFkS5VR/KFxJltVCw Wm20U7UxaqK1VQkElJZyIKGBvTCY6E70JDYmdicMCS2Rak5oQolNrErsSxxIHMVzfeh9za0EYTdE q+Be8ntwab+fRohW+tASTXSGKNpFBzqde537nZ86aac87ld1vXQacWKvzB2R+HGF2le1Fw+rmUyv xB3y6tVwMsvheNJf83FyqhB40Ac1z8eWQ1JUy3/40nImL2UMP+ReykjfTK16/3f8rFeP6z/AnL4X RuFXa+9DLgrhN5bno+iBBQO7uDV64HmNHKeVyPE/4UQ47j91TlWr2O8J+LDrCqQ0P5YJ9GfRWyfS Keow8co8tuIfYyvOwh5NZBA0+2U/egVBKzT6fFD00VZeNzJHSnA4eOyx8UzNmDDpTmWTyUxWiVto /S2mJspkoilM+V36GCtrj8eFnTkWIONIuEkJhwOKEvMhKMCA3+fC1gR9wJlR4/GAGovhwHTNsz6X ij3fjy81C7RaLJBR/AGIxZnmAyCrxUtstjPbne3Jrsruzxqz3jyiAoKPvN0pdDt7nKucR50064RO OTf+u8OirpeobK6WniJU41CNrLXVyZreSaE3Og9FARYyGPGhi/fjA+fT61/z9DTm/zex+yop1+E7 HP1GAG+CY6GcRov6765h9R69RUPH6j+hRWsIOtU4yTTac7x9TK7yQ+rlER6IwHcwD/wOVuF2IMPj 2uBv2ZdlJBwSD0lfcl8Kx8RjsvEV8Y/cH4Xfi+9IH3MfCyYv5xXcoijRrwj/ZD93Uveb77Y9gh43 PG5+xPaa8TWGuQHdZvgJs8y2wrnCfRdaY2BajC1Mk7nNNp5rEprE8RKTRhlbgYsLcbEgTUCm59nd 3GZhs3Oze5O4W9ohM0+xT3PrhYecD7sfETdKT8jMHOdMsSqt5e523ineJ90jM1OcU9xTxOnSqfLZ 7NncGQKTksazZWeLe5x0OjudmyIwVqOF8Rl9TIpNOBNurItlSDNO1k4DkweTVD5uoRxxkrYMgQaw DhjAVa64Sd7inXxNveGWtImQklG9HZr0uOr/kTwj9txqFdvENtHi5ytC3+DnW/CZ6xv8YosgVUTS hOhw+SqiJCoViRzMOFhvYWVy6zA5G/oGfz88tgpk/CtyNtfPTnLGRNlNvq92PqY5MGl2h+zCRGcA HyAp3jrlir1+RuTMuSu2+lkiNU0775wIHfhgi5Crr+/lJHYMqtCFMCcGPAewCQqmZkQaOEkOT6C/ c8unK/YM7IGlPSs+WXHWJ7ue+Rc0rd/1CZq6YeD9dXAedEAWzl038JfHX4dTB377p8MD78ApxLa2 YCSZj5EkCnLgqCbRXtpnCoCg0ycE476Sb4rvuYwlLST6Bj/RuCu8N3pRgkkzd3rvDqKxfPbr1Vhx mJ5mdS0WBYG4wMYqMRSLSViSpeIsJsDeQg5TRE7Ofz6SFB3KS5O+aqIuqkD38JiG1z6GVTE+WFmi g+fVn6/49+Ua6TFsbYW9Y2XbGI6hNxvG63noaBhuqom4Ad8o3vXRU+9Na5zRNX72wJfQVn14xhPX D7wNDwxcfqJH/27FzOvjrV7nrDOvnnjBA2TdSf7zBbzuOdACH3wOhAdf0k4PhSdmXB5p4vzSxcUr ipQpM744vXi2d27x8tDl2atLPymtTz9R3Ku+HXwztF99O/epymNZW5wSnBq+OntTcGX2p8GHgk9m Xw39NnwoYw/sHPwCmAH7tXt0ooSYMLJHwVA6EzZGctloMA/KdT2QA4FCnix7nqx4Ps9gqaGm00RR B3ega0AOrdPsAH+QANcU9wMVqn2wum2pf5UfRwSY1MivAOiKrIvsixyN0BHCSFhe42CBO8ohTm6d vujEakS192D1YJVocRz3P68nZY7oVSrsCkMyYHRt4t/d+FYwY5NQz+ptDtpCOwaPkV+juTVjK4lB jBCbm0NF7O1D3Rj1pB4pf347aTeJJ/DzeNOwyZz1VaZ+/P53brrv7GU/0cho8X1P9gz8/YPvb5n5 +JKBPcgyMP1Ew3nlh2evLU287zOdknteKM3qWtQ66xeYATyHY4ILx4STwHtaur3pVF9nU7XpKvFm cbl3he+2cfdMspwSmtqBiEk83rFh0tueQ56/e0w+8iGdUpm0883LaKn2CV6JNbgAbHE0NkSpfDOp YfBWWW1ra+bjk6230vlbE83x8GSKxo4f1ksZLfHuQE8ABbxTXXGtqEZVraMntTS1KrU2tTFlSMlT 7t8Bg6N6vA4ewaFad+R6fWOowNHP662ptVavWnOfp/bIEumMgQTAx9Yuaq0LAUQ61uttWUNl53rX Q707K6EO9/pRd9ZiqeCBhodvvPWR/KkLLn6yY868Q79+7wayrLU7Ox94YPvUKQ2/eOOcc958ahM9 0U925/cBUs64edV5jWc0BXm/klh57uo9KxrIrY9IpeOcnz+waNIlAbc3evLJN934AmFmq7Bft+l4 eruWZs22EofdLuIPlklBAzGGEinsOWWxjHWUHBUw9UPYjeQ+2PMsx/EB8v9jx5wuxPkL/gX+vX6a 9Vf8nf5u/2LsTRv9+/2M/+M4odQk/3Ks3lla0eFvTB1hbFXhqyY8VEoYuUCr39WzVLp+fHdgg97p 9RRZvhOTVAN/JlYNrxpYoZ+x0gNnYnu8Dn/uBhjZCfzkV9wOfrE5yPnJQyA+HGsjV/kOGg/5Dwe/ RH83/t33RfBfIbMV0UboswZv8q0xGgWppp3cnBu5m2S3W5IVoZYQcYAczKVALtcAlDRvqWWqU2a7 3WJW+FrWY5raVM92NGBkiqqplKQKFlXgkYKZRCQcgLAH7w1iQSfoJo/9NMreAMN0mrvNPeal5lVm g1kujmKeVT2xRay2OpLiGqac/6uEr/4Ejg4rrfXcFl7xoTbpYfGv9+WUS2OYJNX/t8cWP33NtIDX YQvUeOOaF64/c8UlurqoTdAT+yc9c/T8V65GL+Ads1t0/TDp1l+d+sAF+syQAubqkScD52l+EzBJ DeBUaXpmgXIHt0/5UvoyY9kANijI5qpVALgmN8e53IrNLUbSZAoD/GIVAZVTF6j7VFpVUxlVTWeU SAZY9dS/1GOC5AmtHhNWFilkMlFIsSIYlsnNUxSlSVIUWVLCkseN9WMAf0Dsy1IGa1iP5PJ4JI+Y ViOyGnapNkq1RsJhm82KAGTIb1RQG6QuaZN0VKIlUqCzepBacHe7d7spNx5vGfRAzw54AxDRvi1Z vfPhQtKudah6rKp38VV1XxnSkeRPoTCkJr+m4WFsQ4OuJr91or7NWCXUW7H0LazVuKOw6etm0for BuZ1eFx2u8sDx0lOu8PpeRDebIQ/Xie58ECCrbWzRk80u202t7l2PC5Sh0ePCfpgtkw/gvc2if5P LRWlSW4JiR6DkcbUOul1GdWQDZljyJ2qhU4CHG14SerPm2hn9nh7fD3+HuUW8WbPi4YXXR+J5gXc An6BsMBJ70WQEzmPJmoeWkI+T0AOKoFkylNGZbHomYqmih2eeXC+ONdzi2eD57foVfFd/LH08g/P dXGQK7k4zulS7C53OEFmA7FQbHEMgRgX64q9GNsXM8RWJ2OxRFIJJ4HNqL/FzJqDZsSad5v3mz81 D2JHXW0wm40GxWagQ17yFpfSrUClJCuKV1ZCsgTwBw71DfxTa3bTVMhloOmA2+XCMSSJTUySXZIk I4goGJA8+NqDKASpgFvE7xCR6ulDV2oBSQUQUm6VopmEGvaSr1DIqdqNqt2G4AswCwCOcFUg40Wv ao17ZRiUoaylS7LWXG6WlxXwRTTWLGtqollWNTYZTHYnlyZXJdcm9yY/TTLJnWgJJoEerI89Iv42 USvgF/5WUfOWWPFTvSl17lakqSXM2JZsNoTcu/Bf5wIU/qtpmNPcQRd80QVdKmeAwNBpWGXYa6AN u/DdFJii51cvrLX8HMEm+onMHfRy/Zn+XqIjpEMy19/rlY7UugarB/FdifsEDONbvRZCUqz9eq6F If1ABuwfwxcjDUL454GxCdVvaxn66kTNZ2ZsUjExS2Nith0tQ16PV/TWKdiMTd7hdgc0+LfNiPH0 DR59RuSGKBpJqlar88JR0iU0RoE7nU1O55g56p0bP/n4xuuCOnS2kgj2Us///Pjj771cw1IyEaQq x/+DnjhczYpQheNvUP89CkXfBoAawJ6Gd14bt4SCwnnm89wLxMWWXuti0dhHfYQ+YikG4RcbpDxs EhWoVvIr06il1FXsldwKdAvF1izcap5dN+hapTSNuUGtUsqxiOJpQ8BhRwKmBpBhtVCJ1RT8kv3N rEqT/ElUrsW0HkADr49XbR0hCDthD1wKj0Iayl4c1WrUGjMxEtAwwyZbP/xYOukFH936PbYPfMYm 9/D6s4OfPYMcQ9VuUqPcRpGHGbGs/suW+nm7x1FBFBtsq5Uoq+FwaaSXnA+7oXsotUsNHH8HPdH/ Bknjorf7Z6MbyeJeQ+0y/UPnFTOuOj7JDOPkGkDUPtBP3U1/CHgwVVN5q+MzABqtmFF9BmEjY7Vw jABgzMxZGixdFsoiCxc9PrrEV/m6HPMQI+KHy3S/0wXegZrQo+/4527yLzIc1h/rwLv+P4MzqQ8N lwAWnLrNnLTKzVjh/0Gz4wuzWTZ/Hy5kaEcffHWr8TQ4nyHP5NrAfPOuggM63uGMrzwH9wAc5wqw /lxuP9AfV8byAtbJLKxRVjgePWyReT/fX8Unn2HSP+eKFk6OGx53WzkJQ1PbQD+6S1+LiVpo7Fpw VsFsicEKafWqr8LxoVUYuwaGkb6SOi9ElT2ja5QbDR2ktvZPnf2RX4vWv5d+fSAK7MC+1TQfWulC ofZ08YmdsXf/62F9BatBWe7fO9IDC1ZjnjibWgaSoAzP12Y+YXok+ESeUk3x4AT6cudV3it9y1w3 ee9w3e190rTO9Yj36cI20/OOZ1xbvc8F9jiOFd0WKMM0pO7l7/Kia/Mr82vyTziezL9cfLv4QZFJ YnX5tOaNF8LxeCQcSQqK05Mqh0E5Bakmmzlb7oMHtLPhLUlgaQpTVnMYZLns4iyVTU2w2ZKu+7iw YiI37CAUCmt2scKGYSFcCXeGu8NrwxvDu8P7w0zY2+pZ1RA2kvs9xrXG3cb9Rtoot6R3jtBHmDmt /1C9SFpb+qEHXArVI4RL6s8TDOuecfy4MVoVK1W57na7gQmT6ObBo6CEX/LgsS0Ck2fqbScY/Oqt Ki781p0ggN/iHHyR3MHyqRou1fv9iTga9cATeXy1Vl6p+wCl6vfqfeHU3O37fv7EgXfG39K5bNn5 z4TMnMfiuOC+rrWbFxNvfHnCjadsv+T0q37wvZ0XLLn3np5rnmW5W6ZcPM4iCbyF9abvv6D/LV2x PsRznRPOOPU7c7pJziOH934Otlo/SMLYM4QYPK1ZuYJOCiJ2v0jGTrnglmXRHfEHTBS0hlRb1doH L9imhs2hMNZGF2hpyo+x12S2KmEWrzwyetPRWcAWcrtIsyzr6nHtd2FQSp17++jtIJtwcCidhNGA BD0c6OSD0sF6T9C3PQo8Y5OtvhnarEvNsMHaEJuWnJ28MPl4ZH1sO3zO+nzg2cRLhj3MW/SfmIOG wwwv0kXYaGi3Toad1lMCs+FZhqqpar0QXmxYZL0CXWu5NrAkuCKwI7grsi0uYhQ5utnKJfsGDz8T EGvPwFZh7zzI4z0CbhcgOjc6JvUARz2nAdO/eKcPGgf+se1Pd748qvvrgXfvuOPd/8fet8dHUWQL V3X39LxfPT090zOTmZ5Xkslr8pi8mJAMhIfKU4QFlKghCRAISQwBRF2J636i63sRBR8re131Kiy6 PDSALnsVER+7uFd01XUX9OJjd2Vl90OvdzHJd6p6JplE8bd7//t+v6QyVaerq6u7q+qcOnXqnNPk x30y8OaRwS9eODx45sij1Cy5nm6eHX34D394GH5pbYMZgJkF6My+oMFoJQLNL1NFALzsfD/6bt7J wMngX6J/ztNGnHnSFGVWdFbeAqUpemneSutKuT16i2ySiDhzjUNc7Piec1V0Wd6XHg3vkW1OT8wW E6KeH9kesN3r3uJ51PkolA3D4swqi16qQSn7XKrkAd1sD8a0xj0c7/s3VzBstCR1i7cH8F2BXwWY gKdIDOaSTt6ei8km9125bK5ceDirnwHbqB4YTHZnVZtkCKfS2l8jSpSqkIGsxoiiAdDfjJiBzxYz SNm6keEQqkyginL2JapqQPUi+afuOfjC208ufW2e02Z3tT1y9LXBc9j42n+wZh/Bkl8GPC7v9L4/ 3/fI8Qvmii574eRVmH35NWwiuHA9tPYO4ukN2vuDZy4sWFHAEOHcLnWLP07lcyGd302ybN64y+t1 u0J+gxTK1zcZAA325AehvQEdlFBQ9COTUdQSt5WugF7pIz7QMPYURYN9wHT349v2FBb0ZbTAr0q3 DxGu1VF1U5gZT8H/WYIH51/MlpXOeFpKI8Eei07QERIzghf7UQHwZoqYRxb8uUOf7AnrIvIwjRqe asOV/PASqNyVGcrZJkcco5KYH3/Q89sNG3675v176XH3O1vufeede7e8w31ybjWhLY8f3XBy/dUn rjmK31NH8vb3399ORjJDtRbjMJJlpKA3Uu0GaZuTKWcmM/OYFuYIc8Txqvye8J78vve/3B8F/iGZ ZV+BL8HU+C/yzgws8V4a6PJ2BK733ubd5tvmf1ZjXSsd8B1mDwuv+F7x87qX7B5FgRnYnhN0abmg 3Wia70luR7gbMKgff5RyhZQkTm4XcZd4SDwGpIgT5WDBzqwhOus0VcA/fSpjS0aVrUcRmd2SyANJ 2OsVA36mf+izYVKP4T8oSWOUdtWRiVRHLlqu+Ot/lz564vLfTHJYbG5b6Rc3vDN4AluP/gYbFspv bd583IMfeuTl+gqrbLfbyhdi7yvPAuX4vzfcumvn7YTH+R2sIS+FkZlAr6WiKdNcTZ/mRtMNZdtN u017C18oPF5ocOmsetNRmy2kT5SgMlzWz3DPIBQqAQakH6dSHgwjN5IfQtGmWDAHIUGRS4rdvF5n CMFYTBmqUBFWPMfo0NySMsedKWe38w0n55Qr1+7Hr6c1jWZRxdo628d0yV5HmNUBahw6Rhe9aYy2 kaWg0AsdWhRAhd5YABOhATFaOa+ovyJtHDVi5ck7nRl+MI4pHR3oIvFrz5D4mZ13rN9U4XSLOsd9 KzrX41sooTUPTM+Ix5j9ZDxuXPmgpJMEwcW6OqZuVPlHBn1/8HruehiZeagC+1NlU8VukXk/+Gb0 s+Cp6Lng2Qi/Kra6uCXeUnGN+brYVRW3xfoqHordXbEjtr3igN/C6Ag1WEoJhF6j0elDDPIXlrkV m0uBvrT4N5cFFUNhEG3O1eqSDI95nJ+jYMVgsOm365/Ws1Y9EXg9pT8Gq2hPZUmwL3xXeHv46TB3 KHwsfDJ8JsyF5URB86jBSqkF0diAziAMZMMpQlIbMvYBtWOIRNYoPoi8Q2eRZ+js7gJdef/QV7v9 OtQPR0W6UpLETBUks1iKj4jc0wOdcC64cnhnXdRamPCIj4HqqkpCRZjKhFBRPspa8QZ17ou4u5fM ojrMf7tofZ606a2fnzv387c2vXb77a++evvtrzFH76cUY//8yUWX51Pt2JkXFkz6ej/G+/ZhNDjj ntd/vfmeX/8acGEB4MJqwIUa3JMq3uY5pzAcduJWfi1/F76H2Y5/xjyN9zCGR/nHtHs1+7RHtO9o T3i0Hp3dRem2VQyIjLjELYoud8gei1OGp2hJaVFRvDQUsxlUem/G5iVUmBmyqfyrMbokzb8Sl1O7 UuHKOPU4FarBSswX5GL5+dDdNYjT2gw6vSKfcGOYJx5JGSegoFJ2qPRYKVPaj/+yp3Z687DtDyEy FKPSJJ+KwOznJfj/rI4rnMroPOGhXxHLdUx0nuyetM4TIKTN49Vo+ahXIwewR+tTUZLY54/sxexH /NDZfYopIKrcz2JV+K9a7o/wqMOoq/Kx2vNtyuB5czdftvSWJZfD4iMw+DmZPi6/ce2SSfGObPV2 itnAF51bOH3qnXMG/nsYf9nLrilW1g98NuzBpV616kfPw2iQNHbEAge7MVUQksvllDxPbpF75R/K WofZtkgEPpY36RdpNCGT5JO3OIGPZV9i+vE9z/h4s8mA8EFMxM8MLEMsHKdRnHNELMo5F28cWava Bmgv1TV8eXrMkjVr6dqEneFKxze0TtMNwNx13UZ8EXnvATddzF30BdEx0djffXfw4q//nkWpgJch dGnv4PVsDX2zHPRwqtBGHOgwNvYy62IfcHe+Xmsf6sN9TB+7xWqZrbtT97Buh++AT+PTeckWmg+w WWOE9e7Pn+G4kFF94ZTFyHvmy4rgsEib/WRb44qUnWFY1h8wmZWcnDkc5mT/AbwP/xa5R0TuVN06 s60xcKrhy4ERuwhiKQ0TIHnz4Tcmu7ThYT36qkrmxHU3DJqJegUzfdGiifMHv6ANoF/1Q/L2A19T zG9ZdVdxgCL+bcsByw9Bv24GLK9k+vejGAxjydwQI5YnoommqTmCsWG54zEHcziBC8SCaEmsIJFf WRtpiE6MNSRWiivDxmUOHHZUOZhCcU7s3ei7ic+inyXORc8ldBOiExIrIysrd4g7wnykMhxGKhk3 DtNwH0H6vSiAAwFyU5OtIUDN+YDzDiwJBwKhcMgXRsUVlFqUlk5LlJZWJELFiUq7kVZkiRssFqMh ZCeaZLCCUtXI3NuoHlnIKzqKckn+9FhsSTQWy42GiqKRaCSiVCbEyspEWHQIDgWFRYTCyFEZETVh HEr6fM6kl89NFlUki4uLihhjUrAjXRIzBpEsofVdYRy+PxpZUHkAb0dRyDF3J/oSjJIoTVyZYBOE GuVUO2Duh9mnW9+nZ2x6RV8KAJmHeL1cdRA/hPpUMeWIGihx9Ucsaaisnggk03JIqp6d1vVx1W7i qLLPfljnHt/jryOKGMf3+KrVVC5XU1cxTXePKIBiogG6yZLWGftuOf9Ygnf+skDKvlF8lCqoY+jk Hk8kIVLtEnvCQcgjpNRBF5WujXDQYeCgRV2UOEtLDH2ZbVUCJaDU3HSpr/ZE5YQybOFFVEaGVY9G +JphPdKM3BOPtarE+LmsxeJLuK2Q4oqZEI7mwX78cDPdvD5DcpOD9+F1gz/KWjr+AxcR8kGtnP86 uHjYvHINYNRBwCgRMMqNmlKJpc41zhudwHyYFhGeEbjERYRDFNzOLXZ7yI2AMURYsdtsc2yHbKxN lrOpIXXWdX4qeF4KePdo+vd3Qv8yS4csog7P6iSWxMCTTWMKUnXWamuNpdY6wVpnnWhNWRutU/VC rqnKtNe7u4jLw1WYWeBbql3q69X2+jRV2nLfVO1U3wKtplRXPZHi54kJeMK0+gkTJtaHqp1WkuVX BDxXeEM4KZwROCTYhJTACtMsgmC1hJzRAGUUUMgWYkLT/KFQwB+KVpWqmRW2CqZiWryiojQeqpqW IpltJxpx47SGxsZUQ6g4zvtzS4rzc3w81hZUp5JoGl8QZD1BvZ7VVldVRaNOg9miuKRUoLJU6pMY 6evcHL+Sl0uOc/tymdyv61FcaagngixUf6j+WD1bL08v+Lk7S2YCQGHdcDJsIJM2mMjs3Au16H9h 6dL0TZXqDNbwhApTZmIsU5HmKpT8mFs2mDiNMRrj8gJYw8sGVwDnawoC2G3yBDDKeHuhrjaamoDd 8I4YdBmG/oo4+GmH3oN7vQfMy5sZ3hOr/je05Ak89dQCEVLyJLshVR3rNTmcqg9NunRwjvhoUk3h Rx9ncSpjkfTTVR2TlgZr1ky4rGo69Zv5wOyKkmWTplFwTllx0cRGmv0h1RSkILt0wZqp06ZNTc68 dGAf9Zt5X2r+1LaBNyl8d+PCnFirejCyGIFR3gGjfCGM8hq8KVX9Fv+WjjnMH9Yxj+h287t17FXa Pi3Tom3VtXrZB7yP8sy1gT14L8P6AisDDMIcw/h1giqLsDoDTsY5jW7Qh4SxPK06JVmQBVumpWcl lae1oagtyoxhbM2V01TGtjxZw+MD+CRScEvKkRPktMDjCoLdoDconhMylsmEYqPs7V2l24G9lQlv O8IypTlbdXAOnIXJ4l+3wvpX+VrR69PotDpex/A+DQw4ry5H5W0LKG/rHdYzEuHSP/7CK6rD6ypq Ct3UBBxcVXrh+Y3RMXoUfYO9XbjojsVXzqm5jI6HD6hi6Q9WX3LNVdncbXqsbFw8Jea/9cKBz0e4 28XXNv6fgb+NGSDAA949dIKrgxFiRC58QapGkDhJdEnsK/gV41vM7zV/0L5l5Fdp2+1MG9PGteva DSvNHfY2xzKXzhlkrUE9a9RrTUFELXblBppaXDRNmZ2VTyNsQ6XoSmAx+5lNKbcQ5FPEnjcFZbr4 Q/wx/iR/htfw/fjDPW4gQZl1C0xupweariJLhoz3z1HGmQeRBByoOHR2r020iK4DQx/CjPvhHrPf 7h9ZTxJ7IupWJ2WUiFqwSCI7EW86rP4GowiRzgCRlkR24jooBzg+rWgU4CREkmh31YskcohWkZQ4 nBIAMBiAWdORiG544YyqZpbLHSK7zchnsqVcdYOnXzg8+FcsHH4BOxZ8sH37B+SHn/rV4BlsP0Tc 1p75j5/88cRDD548QSTng9dT7CXelIpTDWUGa20e/CqLL8YLmCZzK4Y+4VeZe/G1BT0lxhf5Xxne 1b6rfy/v3bKP+Y8MOpktYq/V3sZuY3eyvOSjKCvHc2TZlxOS1FnKKBwdNSVNCsXTsxE2x+LWpNOX hJFqiQeNhlgQb+a0KJCM8rlBqw7rPBVFyKL4rTlzcq7I6crhcuTybOE7Ze0yovfTdVSA8G3yg+9W 3ssWj+WbSsm6o5iq7pkVTHq9bOgPv8gLjzLHJQZqKpYR6Q4Rop8XpUbJ0mfsXHvdf64ZHHj+g9vU /cCuLJH6Q29u3Xb8+Lb7jrNLt122pPdYz77BoWcHeVWTDPiKJGWI2u8+9sZdd79xjEgjoe+ehL4L ozieSfw6fbnbWhsjg6/GWrsLPe7dFWXnoSs8rajTszK4Bl3nWVdyI7rdc1PJttwHi+4reSJ3Z9Fj JfafhfEDsR3Kjhirrh8s2WIglTYbnUfTZFklw/MIGc4sDpAnr9idFAgjbykO+gx6IiHKC6LNIW0E y3pZ6TNgq+Gk4YyBNXjKCoLElcn2wNMB7ljgZOBMgA3IpRkhcrZkiJp1AOmFTiWKmQ113yYW+g4q O7pjPaorgzgwwlGxiDj8yhcL+6FnY2N6VpXan9f2QhWKRsaIh3a+RCXJVJ482E1Ferd++NzgAGZ/ efLW41u3Hic/5pVtpAfPvZTpUfyPZzHe98zQ4Iy7jx27++433lD9uHKXsuuB2jtT4nUWXKSfY1gp bBBuEe7lH3JofaoYJ3A0vXrzOg8wu2Cxk0rp04syYgS9KzUnfza1gA4VGi0i/aisRmvGDiRabIZI NIkKeUODDSZDWIuRJZnXYNWe0TJaTzESlYg1PDesCvDOhPmwXDRwx8iEqBpaqXZW1DMrXVhnvFNh e+0/qzT7nZMg9Jw93XP7HKJFEnwZDiqNdaPM3s8ngGWYnz0ydcYNssNgcYQTcvUDh3AvZd1Xk1X8 a9RUgl16/J4FbR6HrHWEPYt2DCZo5wh2F/Ncmr85Rny8A5ZNwX9L3Sw2+CYxwky0GLVP2ansrP5p zeuOVyb/0fG29Hb97yf/xXEq8enkrx1nE19NFowOXtLU6ycHHE7JWe+dfGtoS+Kg1bjQcWlNe83K 5DU11ydvqbkl+ai4WzTckdwXYC7WFcbCuWWpiXUJj9tq0TpNtShRXhrmSqqsFhNrQKxdTk6cGLQH Gw39uHIvq5Tgkn58b8qXWxUMoqR2QW1wjp+o0LJ+z7Sy+eFkzBlMkVlSgvkwtbgrhmPy1EYty+ca gsbL0yhH9WaxKhfHhafTFrhUo5b0cdOIOm1tlkJt2uuBoDp5qqmeLCi+qCPqqncGUNJbG8DVCkTC ZDiUGtwB5HLXT5yQUwe8jCdZVxOoCiBxkp2y0tQ2l0ZpAwXK42R6f29STBh8zw19glyAvVMAbevF asDePSGpzjci11VdR1HuugbmWD0sO5IiRDVkxnXbnHAE0RQyxU4RYVKdIhqtDT5SD7QMKfQsYSxE EmVNsTC7f5uDE+KqMUtNWOSz1IRH3Djm5UbSHtPY69TVLNnXq5m36fbZyWmlNz01pfmK37z88kad 00wVhWVXeFvXz7ZfPG/w5ZtnHt+8iy3MgZF6l98jyXV5NbWFlXX5PqvDHb7uglWPt4VEi8f/cxi+ zpJAacM1U2bH40piRV3HRrLq/DFwW0liwYVeSUXOebHZ6/EyPzPsM7xgeNNwyqBZZ7nJssXymOWI 8W0j79IRH6q7EId7Uk4dx2l1IWwT9U47+Ui4qJFNsX78SMruT0Yi2iTGiDcFZaN4M9ePn0iJRUU6 vZIbPIJ8Np/i6/Yd8mmAA/hoTzFZ6BG/+XSb5WzGaQYxtFM3SskIGjMJk/0Vj9dgNHr0AWTwmgJI 3V9Jm2xnMNwujt2iyq0cvd8iOYHdpzabgzVrr1pwpFo029xm5b+v2ryLqrQ+QDqDXUqQe+C3Fy6t UMzEh3Zw1o/WMnGSST2YkHa8DNpxMbsU5QElNhm4fRKTL2GPzqqnFNgU15lMel3Iqm6kGr2z0xup eUFyXEwclE5TIpGgEsrDklVUgkmUZ3C5kwG/36rTJ21WXgyyRkVByCWRNYg+ZrMrumNarCUC9vyx Ava6OtWJXd1AxmJZpbz/3HSYIbcpA04RYquMEqMLDuI70MHZA0jgRbXlVTR0pNHweeQE9JOAGRKG PkzvGFIFkLys5qd9Uz1ymNH/uGnn0WtTl6iSoBWzf72DdsPndBlx7YONi9YyftoZt89b+ZwKqnJk 0gdJ8t0y6IMwviJVtgPvEHY6WMWgGBXi5sGiWBVYuSVxjTDBsYxZbm8X28NPQaEnHUIqgInjkV0p pxmZbea4mTXPpg5IQga7oE6i8LYBnCUGJd5FdhGPbEuoe5GQnsGq2LPBrco9Zw+LPe0MxopgF2Ed KYYRUhyi6HCIDgEjQ1rA6bUlDWzSoOfDSbEfr0wZHUwybm+wP2Vn7QfwSuTA+pQ5JeBSoUvYLrwh cMLz+CkYM1EcTGtYAiP0MdUtPo2y9MMb6r5TrXiskuS3aER+i4Yk/YxH+BtCvYqxOczTdww+Tj3n YeqT6VaciOIS6jEL15EdkQWsOeOecGC6uv7LyMJqhoa4e6An89mi1KP5Up7rJvZJ6VFXP7Nf2uvS IcbGbJTulJ6SfimdkAYl3XbmaeYYw+o4ndPNuZ35TIzLd+a5arga5wXcBc6F3EJxkXORvCh/GV7F rXAudy2Xl+dfy13t3Crd63qM2cH9u3O7ax9zkOt3Pu16Vn42/xXpZdfvpeOuP0mnXIVGySsVMoVS oWuTvCl/p3RQOqI5Ir4vfYo/dX3FnJO+ctlVHSKLbViJSNUs3pUq6o5gFFEiqQh7hkDbI29E2O5I X4QhqsZMJLKN6hmH0nrGu1KxK6gZAEu0jefo2c/1+CmqcswSW3b9NqqhGUqrHMOozMmJU33jkCK7 t1B946GLUuUZfWNlWN9YydI3VrL0jZW0vvEhfBKW270wmk4SUSQ+mQpzaD7G7HzOkJcMepKKI2nm k6agopjNJr7Ljd0vyphso+eizXKqtFJO5Rcm5FQ0D6IcP0SyByKrPSEnU1fm4/yD+HGqaHxryiUt YFJltQmGlGNIOSZlsyeYfvx4yqxRrnRi54sit1lMaoioq7SSJHtqahP0sFA9hNvQFGqgKVxPU6iM pClBciU0KWflRs2dGoboJTOa5/GHKJaFMV82NQ3P3aeJ7nETUU2GvwGqmNyUUUwuPPsxOYnco/X1 G87W2U4R4F9WTf6GkL+p6apv6PN/W2ZaCzYjcdiXr5N1nG2EocE9QS3L5mVUjzOLkmzV40wee/OK /f0rdsUIMn5ColVb9rT237mSSKc/JkxvPmZ8A6dwFoYuY8SBz5j7s7G0DejtSsDSRubHqS0Be0Bg hBr7QjvjJTKWQOhKvFroCnaFr2x8Eb9o+43wm+Dr4dfLX0i80GjVITfaGmJRORYa7UJj2BYK24KJ inIcTJSHbYJNweUixuWJRkEQlGBCDAYTTBInrUkglI6kkAwmlaSnLFmejCTDyYLJycZkZTKRTKYa GxtqahrC4bySkryGxZpEPy7ZqzTe32Ajm0VejDWmYFAymTRIwpKUg++3arpgaHimlsP5PeH78wRa Lnh/3mJrTjwtRtDkyFMMBo+hgE/yHx/A2uFPHWQY4VPyWfdp2QYR4YXlWafcxEoUuGCZOBIgvXea KL6fdttOkUySkU49yG07fZrYpY2KNJvSG0vC0KtkI0lIbyRBunOPmK8aEQthkn5IZFuQ/nG3t64+ zYimqT0RM4VtVXC9rQguthEfJDYDXGbzwzU2PzC8ttDwVfQyK/ypU/8+u9tsTVT0D326G9K03xC6 B0QfrGLow5ReMDbY/UahoYI4g78IALtBctXbYcqsb5zkFxowiRqrffYGTKLGaq8NIIgaiao2JlHQ kKPUJ6wQlYuyt95G+O5ywmhDKqTTxv6hw3tsIpF8H06ZAQjXQRQk0XmNlAkzjlXLlqxdplGr8yrI SHspHnZwMtrjCR9mtuMbckUrrNL/TpDi1sH9gwfpBDb4ud9jdeTiGwafjDjg/EdkPmvFXpzTSlDo I3I2gl8avFMrmdPbUbWDL6uyTrOkhYXpBTp6hshoPsd2FatMkg6wasvg9dxWwKpy/BwwE8gtuEOF 5qCrElfa55hTrnOO/wkZ9Y4ZjotCK/AK+9WOq0M3O24O7bc/7zgQOhL6XcgCqCmUC/Zyh8rT+M3m +DAz4w35+/zYvy3k94dC3lC4sIzs+ZaU0rWhK2UsLykpKw8Vljv0qhKgRrNNVQHUY0QcM8CU4yp1 YVecOmcIeRzlBRGSuzovLx7Oy4uEQwXhkKO8XAmHxHA4ZAf0RVhEggPhcjgh2DHS+TWCnrA+Xq+Y 9HgAoxnC+kSSBWXJwsICC/LP9TPd/pP+M2RlmphLDEtsGkXTrTmpOaPhNXJFwQFKxVWH8k1X2T4G 8pcRMmQxP2lNy026ErrTukklyt9Fi/9ZhihzaBtbWquz1enUb50Fceb7MOcdXmP2QYNMx+A1st9j dkofU0EfXojnUUb4o4DHJpYMfHYjHXvUJBRrgTYLZqeeEuc5zC/UIQSDa0RiRGj0aYTYv8JocqE/ pQwWIiLGOouBeX7oS2Qe+goZEEfWI9o4db4RMkh0yExxxK0Oh80akiyYERjFbBHNZovZxFiwZGZM 2GJVkAu4XsVoMuAmLmk1NBi6iLxOlpq6TNgku9dmiehmpfWdTw2betSOfEUDSJ3qYo5RN80ZMo0D uaIpUCxI39kN9CpDotzfaSNCvdgXYifO+KTUBivx8PcD2LcHbmVqqL7FAGJ6Br5UF3czBib2Ut89 M5gXegjwMsJ4y+AAO4H7BJWhrfveEt4KMVogss/6K6WQL5TwE7tlEYBwKFJiF2ysVVN0WaoBFnH9 jHsfUnSXpawApYJI8aC84yWm45wmAjz/cU+8JBIMKseRx+ZhPHL5P/bj7w/rGVJ1Exqfsp1CcjwO DInbc1qGpAnSYcfuZaV0T/EqTJyr29XPZqWVBivtxOSY+tUnxpvDfvVh7UvcczJV5YJrclnAYPbI cyqnT67wSZIvMenq+W6PWa+UT8rHf88NFdcPbqu9UMPqTUC2yqe24BXVMzhWEh0Sy82oxisu/75b EEwGVnNR9eDWhlnQVvcMfs3W0rZ6K+UoCOFrQq+G/hxinwxhX1G0OOEm3w6xAJATgihAIhdl4ooT TuI4H1L6XZcgAH5yASeIAkOb1qrxz5JmIUULrWvFVrV1Cy9LkXZO5aitm25Sz3AjAz2Gxn2OeQZV 4IPU1IV8ylFtVzX5ZuNCejrzqUrSwMO8IbBWPTg307LDLuzVdledM/AZz6fUmIE2O7O1wg4NrejN sjw3Mb2xwutyeROTr75Elk2GTEMX1eMVNRdxrN4sCO6KKa2DW2lDO0Ta0INboaEdgknPaqDVlzfM Jh+hrU6Hu9FHasC/zAp/ZXRMCfND9lGugDun+U++S+vXTdD9RP+k4SeGD0gwxiAcMx4z/c38ueUp y1PWH1h/YFtlf1SYJJwVbxT/Is12TXWvkeNy3DPH6/Xe5+vIuTRgpeEoLKRnK7dC2KHsCD4Rujoc D/8hcl20IJfJ0+ety/si9pPY2cLlRVcXTyuJxC3x35XFy94s31JxTeWsqq9qAjUHay+uvXgCPx7G w3gYD+NhPIyH8TAexsN4GA/jYTyMh/EwHsbDeBgP42E8jIf/vwJCaALzS0S+aEn+VtKYwBhJ9IjA DLLg0jTMoktxfRrmsspokBtvTcM88uGn07AWHRkuo0Ol6LE0rIcyr6dhM3M//pT4B6N/ldwP0jBG Ru7ZNMwgrcaThllUrAmmYS6rjAaZNLPTMI8smkvTsBa1DJfRITf3VhrWQ5kVadiMZ2nWQc2YY+Fe Jv5FCmsAtvFvUpin+f9FYS3N/5zCOgoPUVifbkMVVttQhdU2VGG1DVWYyyqjtqEKq22owmobqrDa hiqstqEKq21IYEPW8xvJs2mtFDZl5VsIrA1Q2EaeTRunsANgQTuRwmJWeSd9RxWWsvJleu0cCnvp vdQ6c7LKBLLgCC3fROECCq+icDGFNxBYl/X8uqx7mbLyTZl3eQIpqBxapBRVATQfrUBtkM5CXagT fr1oA+qmOY1w1AMwiZshv52WKIEzk1AHBAXNg7zlcH0vWkOP2iBtg9LrIG6FkqSGtXDcTnMVNBvS 9ZC20/LN8OuldbdC/mpIe9AqyOtCy/4Xz0Vq7aQ1qtctgKN2OCJPoqBLAGqmR+qdOyE3TmtQaN0r 0k/YQp+4kz5XOy1dQt9rOeR20Ccc+zwTzvOWE2gr9EANmeergLrKoNUVlA+1tMO9euDMGvq+vSiG vjemfCWUJ700un619rnwRrOgjS6Ac+vpc5G3nAHneiF00JKL6XUKbdkNkK6lvaO2kNoDy+idemmL kONuet1q2m6ZlltKr8206lRo15nQ/+q1PVlnuunbtMJdWmiNam+sp/dqgfjb76sek7It8NRr6Uho pWW7IG6l57tpy28Y7jf1Xu3pGlrSdbXRmIxO5RtvTkp0UCgfrotBSsbb0uF7fdtzdX6j7n++lUZq b6U1LYe8Hjqa1HHVMjxqv/3tR0by6OdKZrUBeRP1XXrp/TL4QOpX37WVjg3y5l0Ux779TdWWbh7V qm1pvBiLHaRVe6HcWnoledp19G3ahushJTugxHf20RNKeWlplTJ/RZsyq6uzq3dDd5vS2NXT3dXT 3Nve1VmiTOroUOa1L1/Ru0aZ17amrWddW2tJY9fanva2HmV223qlfY3SrPT2NLe2rW7uWaV0LTtv XUp7p9IL5xZ0tve2tSqX9Db3tsHFna3xrh6lC870KC1dazt7oeo1JfPalq/taO7J1DMh65YT1rX1 rCH1VZSUlSr5s9pberrWdC3rjX0vnV9ZUlqaLg/F514ya/4FXeube1qVGW29vR1tPYu71iqrmzco a9e0wQPBCyzr6uxVmtco3W09q9t7ycMt3UAfdeqCmZPgbA896O7pal3b0kteY/2K9pYVWddC2t7Z 0rG2FS7t7VJa29d0d8AN4N3gqnYo0AKl2jp7SxQlc/Ouzo4NSn57TGlbvZRcNVJXZ6b0tz4SLd7a 3rlc6WlbA23VQpo26/a0kdN1JekT5LfDXXrbVpN+6GmHu7Z2re/s6GrOvik8dLP6qNDGw93Rtba3 e22v0tq2rr2ljZRZ0dbRPeaNgAh2URRshsHWCYO9iyAgNsMAWwnHf6IEOnNeJf0EaSiZZO9nf8E+ zx6C3372ALszqy5Sun34+ANad9uoe7WNqo3Wx/m5Mm4GN52bCHEtlG4GpCDopk4SK/DT+KfArxEi MAnK96Snl+YMzwh/g2Gg5GiYl8v+YxHhlCIID1FeCXKIM8MplLe7HOK3qf+438G5d5jbEGZuZ7Yh lrmfuR/gB5gHAH6QeRDgh5ifAPww+Rw58zfmK4D/h9UgzPKsFrGsjtUBrGeBy2INrAlgM2tHDCuw EuS4WBfkuFkPwF7WC7CP9QGcw1YBXM1Og5LT2RmQM5O9FuDr2O9D/vXsRoD72LMAf8F+DfAAB+/D YY74N2AJR8cZCH/FmYFTYjmJcwHs5uAunJfzAZzDhQGOcLkA53HAa3GlXBnA5VwC4EquCuBqDvgu rp5LATyJuxDgi7gZAM/kZgM8h5sD8FxuIdxxEbcM4OVcB8CruWvh7HXcRoD7uJ8C/G+aPIQ1+ZpC xGqK+EkI85P5CxDLX8hfBPAM/hKA5/PzAV7ALwJ4MQ88MN/Or0QMv4oHfozv4DsAXs2vBriTXwfw en49lLmavxpyNvB9AN/A/wDyb+TvBPgu/j7I36p7FTi213R/Qqzuz0YzwkaLEdrc6DLC8xjzjQUA FxrLAC43ViDGmDBOB/gCIzyb8ULjTIBnGYGTNM41zgX4YuPFAM8zXgLwfONigC81zQDOb6ZpFmJM s02Ez+fSI438DIAuxxHb3NO8FIkr2pb2oPKO5t5OVA9n8IJ5UxQkIgQjj1HHKoVIDaQOcoQJ94qY mfMvUJA0b84sBfloPhoVawiRRgqNC2icWL1q9Sp0KY2XDq+dmFGQHTh7Hrh4HXDsBmSEcW9GFmSF +9mRgBzwZE6KBSx9GjX1w5NPAxT8HuDGMkCzdeh6dBO6A937/6j7Evgaj+7/8zxz58mVSSKSiEgk riu5Ie6WBamm9qqqrbE0tcQWxBZphKp6lVA0RWNfiqao2pqqomqnqupFlVTtVFNUVdVeJf5nznNz 3aB9277v++v793zOmTPnmTkzz8z5npl5cu8F82EFbIY9cBLOwiW4ofgoViVBSVIaK82VtkonJU3p r4+KUgvtKJjewvYx9TFhLzD1S9JTf/08pfgv0cuVqw/ys8xKQBDmvTCtr+sDurrSA3oatJ7KGSr0 rzCywrQKSyinhZwMuVJRqxha0V6xoX4/dHvoodALocX6/bCVYTvCDoddrASVgnQ74dP0NGKknlbu QCWNpgRTU1OqKduUa8o3rTXtIa1v5MbI/ZFFkbeifKJMUQlRTaM6RWVGjYmaFbVC77UlTXJMc3Vr lil6Gt1fT6sP09OYlXo562ZXupM8QbEWYyrLxv0a/9+/sK2yFL2A4paRIpY3RqlAEBSBfA0anjgD EMfVIJAQHITYbQVhWjIi2ITYbQ9mLQURHIk4Kw9RiJL2YBMpiBUnKGUal1kgz0gYVeMArE2QEGH2 fZgmI6WgXIgpxl1rGtIQpPFImwGcGAntR1HOdN2vI/8TPhfh2Ta+IabDkSYhTUPKQZqDlI+02JWu QFqFtA5tncZ0BxJGB/tZTPdjehHtLEFqitQSCdeMeDytx3fFtBdSf6QCpNVI65G2Iu1Uw6w+9mq2 +Y5e1ki7nSjGXt8a48iyNrSnOYY6RtiM9tvWk/bbtlB7qiRrf3uOtSvRNGtXxxjravtmSbY4+yUi P3uqI1cva7MgnbWfsRU6Gloj0LakEBcVYD1JAfY6SAm201juKJbrgPXzsJ0ALBNQ0h97c+xPqmOo Pc22DG1uxPtOexOipqifgflaKEtqifm5pfo5Hvu5wCM/iSgL5V5Ek6wHkEbYVxCNsa+wrcV0CfZt iauPW5F22ne4aDfRHpQlHUD5AOmOE51E+aRHvghlSZf/BZ20n3fRbmx3t3UoypLuoFxANvR5wPG1 BeHzFWGfTuK4u+bFZn1g/Ns7AmydkLIdEbZhmJ/vcBItsu92oH3bMkcta4GjwNpWHz/bSk9y+JQ8 v+2so6mcP0xb0jzqfrEa56QJ0UlXv0xYD8k9v/q81nHPo+d4Fty3a02yN3Gs95i3B+dRzr0+/32x 3a0458lEbe2Zjp2Yf7D8w/VT0J/3YP0hWP8AjmmOiya5qHT+vp/MIZL5LMrnIy32LI8+61l+MZXP Rd+RlGdf5aJ1RLkumoH3ZtB9XT/XvsJxGPMLMJ3rSk9iuh7Hab3L97a6xu73qKScC49u/zxs3490 yMN/DxHd999DRDvtZ4hOYnlJJf57AX3vgoef3iCfPG9TUb5Dflt6/ovIJ5qQT6IvPnT/AsoYUyg2 WOg++bHbn426jP58jejBuFLi53UxX4R5lB0XMN8Y85flfQfY4hw3bH4OH0eu4w6VTUQqiUcoO1XM N7OnOo0y79CcqkOzhTp8bBakRAc4VaefXl7mXeVbY3nEna27I8AZirgaibiagvl0zJswPxbzszCf gXkL5ic4IpyJhMMQxGEI4jDSNswRo+POaUX/He7Y6YxDrNWyLnEU2NY6atn2YbrMkXT/PsZf0mP+ fryag343R8ZAou3Y1n3cBkh6yDcKHk22XQ/QPheVYP4iplcoJqc58rAvJeXO2uvj/bZYrgOmXW23 cPwkFevk4Vv7S/lWEeYllcQ2nDf02WsUlxL1eYo7HDdD4oEwUbK27MNnW4tz4UqtMfEWooaOEY4Z GNtrYXyQ1DLeihhK02NGfBzFqhmOERgvmludmG+LeRzT+ER78/hEd371Q+VlTMpDPy5Zi3q5xv6R MQLXwNz4ukiN45vFt8a0vXvcH1wj7ujYKcFUfHf7eaJOKHe6f98lP4ytB/KPwgJRCRYkDggL8emO 3PiM+JEOJ1E2tjcM14DSa8Jt29r4sbZ98WNLxiV+gqNW/BSnHNPU+EVIszA//37+wTXGHXsejEGu 5/8v79BUqKD+hGdYwLMn5lg8nkCD2Sg8Y4biKe9ZmGRoi2e9PG7lC2EaX8yXKj68gO9Q/PlOvlOJ 5rs0RamGHeBKd82o+Sppmr8WrPTVQrRQ5QWtklZJydYitNrKYK2OVk95A095acp0rZeWrrzt/YL3 C8oiPJdFKO+IjmKX8h6eEVaqfvf3i+ZgpEqgRM7H1IxUDeVF8mfakRKQcD9pTkHCPaAFzxKRy1Cu 77rvjeTvItw7Vg/AtDkS7iXNuNc04/7TjPtIM+4vzUNcKe4nzbiPNI9HWysxxX2lGc/9kfKn4fMx 3Yh2hiKFIEUgRSLF4J7eiWktpCSkEUhjkHKR8pBm4NnKgiNdBxrjOSoFT2f98RQ1EnJhGp6hlsAq 2Ag7YT+oljvRxmg1Gp8/2ttSHO0fbUDJx3ItOsByGyXVciHaz3IZy92K9sa7wShdshyKDogOQanI ssdyx3IApaOW7VjbG2tolnWW85bNVLfAcsFyA+8WWxZZCi3LULptmWM5ZDmD0g1LnmWrZQZKVyxj sfY+lKah7RUWPFtbcrFmgWU9SiMt6ZZZlgyUhlhSsfbi/7pvMnrPAdpAPP0b6cztjz4SoAzHk5IP rIcaAJWvIGEPKhcDmPDcasJ5N+Gcm9BfTOgjJpzjqmcwraTfq4x7/8oXdTKhf1kuYSp/5QB9xIS+ Y0LfMaFfmdBXTMmuFH3MhH5jQr8xoZ+Y0F9M6CvReF6wXEO6jTIeYaM1JPQznBGI7oCE54hoPEfg 2Q+is6BG1KKoZVEro9ZGbYzaHrUral9UYdTRqNNRZ6MuIl8bdcUyBEvciiqOWmQxSI5UHLXS4m3x twQj7bYMt+RYxlsm4ezMsezH2TtuOWM5j+NUDmcBx0G9pl4HVb2JM2KgGdFoRow4IwFQhmbEm2ak LM2IP81IOZyRlhBCM1JJa48zEoFzEQCVRRDOSCTNiIVmpPr/YUsK4iWdZjkGvHC0EYkmPN2Z8FRn wtOdCU92JjzZRVnAK3Jn5J7IA5GHI09GFkWFyr/QqlfVq9jHG+oNUFggeqOqtUKvY+hv7cBA/sZF oAgE7U+Xboonc9N/4NTtp05Up2OrM9XZUIbeK/rQey1f4x7jF+Bn/NJ4AAKMh4yHIMh42HgEyhuP GY9BBeM3xm8gxFhk/A4qGs8bz0MYvdGqRO+pKuN4FcBqGrUA+U4FY2YLs9lczWw3J5jrmKeZ65ub mJsjTzanVFlkTjWnmfuaM81DzMOr7Kuyz5xTZaV5fJWVeBWb55hTzJPM+VgyucoivFbqZNb/eVq8 by9N2pKWPOxMw/spKE1BzZTSl3zboWLUAU3NVzfhWGxTP4UI9TP1LFTVhmnDoJFcIaCxqCws8CS9 q5W/khbgetMW7K5vwPq4KqiL1fXA1Y1oK5Tq4MoBoWCm8ZB/wYVIH6ReoJhGyDdi9AYXbWAb0tvq 3x83U1cINHXA64DpMNJJeUWOxKtZZOvI9pGdIrtHpkdmRGZHDqM+zELbZdR31XexD++puIqp76vv o/1V6ipg6hp1DfZwA/aK47PtAiM9lTf1UGA0G6/sohUvGcq5otNfJ6XqbmhROR+vxUgrSNIvT/lR eXmtekC/6hFl5LXuN/R/9vq9Pj7Yv9/qy6P6s/jP9wVnwJtQCIRChVCoEgo1QqGRUFiGUCgIhT6E Ql9E4fdQ9g97saI2UaegL/vgHiAUIBxjjgfBI+i39L9V1tOWWuU0pS3CJzx0LcOrRF6J18MlJoRP wWtC+Nrw04+8q18bw88in4VXaf328H1ueVf4RY87V0hz63dsevZqX3gx8kLi//71+0+tP6/e4tFS PZnwwDN6Pt2ffa5/+5Lxwr1+zMTYMxtXEW/jP43/RN/cb9yPvvmV8Sv0zePG07iWfGv8FgJpnQgS LUQLqCBaiVYQQmtGxT8Vf1OQWiNlUASuIP8XEFgEkzCX5IrKFajcDiTcq8PR++UUf7iNuSB3ORmB 30Ss4S5Pb59ai6DW5Gd1jIRBIAwaCIMaYdCLMFiGMOhNGBS0Evr+hy3J0QAaDU6jEfU3W5LjKv9W gNEJCmkMQ0gnP7Em/+ZQfF+naPo8KZU8dBE0S4qS4KGrpc+T0txD15ZmSVH6unQqiH/L16SXhfzm 3GhkCciSQpZUssTIkpFslPnN2gbs2UTs2WTsn0I906g9r9+swdRJap7rWRj10/Cbc/Rnyv5+Tx5V 4489uUTYHBhD86kjpyLNuo45BdFXolNx7zeL5tOz3AJ9NmGdS/efw9Xv49fz7sNP/8fuymcqdPm8 /kyhpLsCx8nnPXSKN1zzGCNdl+DyeU9dc5fPe+r6uny+RPff9fj/nM/+e3j6X/V4BdbCHtqLy9mB EDxrh+BZu/xmaBG083/1ks9sPGg8iE93xngGn+6c8Rzq/vCuEFbB+vvnlEDctVUYDi0CD+F1XPIK bUl2p647xz1yD1z3SwY11Mmjnvu+h72HbXlogtaXviRGjV8bj/7VJwwoJmoRPAKvMXiNCAwIDJC5 wMPEuxJ36qlLxis4tyQva+gl75dxX2MC95RYvG+vpBzZ8bAQPCLgWsC1wBGlL3rCQuPZP7E/UpVI On2vcEWSMNQxZYEyV7FifpanVjWqqiJPwDmltBlqunIL6H868dAWqvvUVMy399SyOixBlfus+qW0 +WwOi8F8jIdWNQDL84hwYR7PFqAuUBfis72jLsaou1Rdirheoa7As+pKdSU++Tp1HXjhk28Do7oD n7+M+oW6H+PjAfUg+KpfqV9BWfWwehj81aPqUSinnlZPo81vVRkTTcKEMbGqqArlRZSIopn/vajx f9sXeXKfSHzy39j27L+l7cl/Y9tT/sa2p/2NbU//G9ueTdEpTsYhpeTTapVIF4MxS4HLpXRmOjcc L6ULVeQuclcpXYDig7nVpXTeivx0U34pnQp3MDfBU4dnwWse+7pKrn3dRY99na67AEUe+zpdd4b2 f0mldEfpTFStlO4A7SOC3DoZyWXEAdqHKLQPUWkfwnAfchJ3w6dxN+JVCiFujzUeL+W9kk/10Oty 4X0vk3sc96xP9JAn35c9y7jqTvewqcsnSnmPfK5qYEYeLD8ZSE8Wfr8cPoUstwr0d6MKeAPHXb+3 O19qFfYrAiibCC1Exv/q5XFS+IP7DGWJconep2bhc+P2HBQ/PzfJ/IOk61UP6vRAvrtbVvzSkTIo 1XVGaOHt/Buvk39r63/5+o+dsf7o7vOMEkx+3wRwtn3sSAkAZTIfTT7eLjnlPvkEQwtjk79++cC/ U/tfXX/xXP+XMOVVAIrXCDfJ/INUWt/14TLG0PtlUS6hEl0L7fj/8HXGRf9j1/85puTnnW97nCXk X+eMxZl3izyvP7Hqyh2GQiiV69iue4kl65rajZcnHoE8jfgg7iRZIX015H1JnyK/kauaDS1IH428 D++BvL6hG/K1huakLyvrGp5F3smQTHdlmQF0t6NhGt2Vcm1DR5KLpEz2k6lkR1d5eXc7W4bcKb/l qzq17SRfJjlVclYouSGR+A66i71lPlLPfAxzJecTiANx+T52O5sluaEryQnE75BGWthI1lJkLeUa 3yVll2YocovUoP64lKl1C9Wy8DTiE4jLz+WnyrtKquwD8h3E9RYLqa1EyankdsMNkocSpx5S69tl XbUx2W8s66qNaS4aU93TVDKPZKuLzyW9tJlHFhbxfOTDJVfHGEYjNxEfxs8gv8UXIl/J7+LIZHL0 DzVXjjMr1KySy3FGOU/qpQbvypE30lNvJJ5LfcvVZepbLo1ArrqERqYrjQb1U2qUPJZJfd5BciHJ K0n2kf2nMlay1uVeLHHpY1n3HkM+5F4b5On35Lwn31uK/NK9N+WMS09Wp909KmXJ4XaxfC97mzx8 F8m7iuX+b4bkaoDUKwVSrwYUryV+Xs6pSyN7lXUXvVTxk3eVLCrvV5xJvK7UkN5KdVOo9RSqmyJb V7a7+mCSMtVNpdZvU+sbyX4e2dlOrVipTJ5ekvp8u3iF1NMTBehclkdZYucotRhAZUIkVy1kJ7WY xlByuE2aPNkrJU/KaBMtwFkajWVkzUh20nhFGhlZ8hrNSDPXiMkenqaZukYzeI286xr5lZ/+vLqH 01NbycIeKtmMxuea9EOYQM8botsnBKVI7CghdHeX9Fs4Lm1iiyuot0dJP5f0+fIdjtTDavLkffwz tDCar0FeXfotPulRelLyQOmrIP8p9+YSX0l7+DiSd5Csn7HoJHOvr4oW7vmTfFhyPMFJeTzxbL3W vZvINVmymN48KYvIgn6Ouk1lmkuOPYCScxOOnYwGKaS5TnwL1c0i+T3iR0gznGT9NKif694lvor4 F8QPUMk84qdJM4M4nSuVEJIvEP9QclV/v7XJJePphD1JI7yT0J1wrz3WWic56luTPkjKhl1S1syk 2SxjgiwDOw14KlMr3d1JcnNZV8poAc+26jdaCvH6ksuZZcEyQjKT/L4Z8hRpR5ZnsyRX07RWxD8k 39tF8iI5VhRhWmrDpcarAkV4GXkaa37yrlcK6fcTJ1nbQ/FwKMl5ZI28iyw0dmmO012yeVeuMmnF /ZDPuSvj6pC7H8lV5u7ndFfKTxva0BpUTGvQe7Q2SYxP5rh+qq/cm4fcbrhOlp+gulPJfi95V3tH WtCktSHE12ij5NpH+jSSk+UIq8ncTKvbl2T/KPFd1OJ14lvkXfkpCXUIlz3vqD1DvCHyQO2YtKCV J8xSTCC05hMenYTQUcXlkNcnvodWq0AZu+BrimDb5TqFXJ79LlNMmEB2Nso4jCud5EbJYRchK1Ui Gm4TrlPlCKMs16lA6VHYqvR/jXy+qY4p16nZJvFO/plKfDuVMZFPWog3Jj29X9XfmmA8kmUmER8m OfZA8iLiG8lyU2kZ4F4wtbKZOO4W7qUWfy852dlNfBvxS4D7EKwj5ffJQj3iy/Q4AfI7hWOVDPD8 TmFT+k5he/d3CiPoe4FeIH9vxAhloZz8zxlIJ/doXlAG91T+EAACuPubhiq9Syj9XcMIj28ZKnhC 0FM/COzRY0AmZBMfRnxkWv8+vWF8rz4Z3WAS8Wl9Mvpkwxzi+X0GDewPi4mvwILdYBXxdf0H9ugP m4nvIL57QM+0PrCf+KEsafM48TP07Kqbq/SdRaDdoeTcg3t5cIMHFx6cucYSaIcpuebBjS7uhyNg ATvUeuS3HvV6ma50iP49Ppig71qVTsjLYDrElebpqXZAT72tWB5T3516Pb+Lrm8/Fuj6cq5vI5Zz fU+w3HB5pgOFvmGqQLb8zCAYvHy8fL38vMrS35Z+kdFdqayY6JuD29FKCJjBir2vD82gLfZYosTA AuQnNUl6yi01dUtPu6VmbukZkjRsMQhCwYRjYiUrP5OFK1T7KtW8RrWuU40b8pdv0MtCcBQjGZ4k 1FusAtUKpVrBVL6iLC9PBeDDypOdIKor/2r4M7YKzIt5gRd9EtNIp06mjdReUcljmf7jP97Mm/bQ PjQOWIJ9rwWxqbKEFqwFIwxCNTxRys+fyxJKe1jCIpiJRbJqzMrsLI7VYjlsDBvLxrNcNonlsWls BpvD5rMFbDFbxlawAraSrWJr2Xq2mW1nO9luto8dYIfYUXaSnWFn2QV2kV1il9kVw7OGdtzGHTyW x/OavDZ/jD/BG/An+dP8Wd6Ct+PP8868G+/J+/ABfCB/gQ/ig/mL/CX+Mv8Hf4WP4qP5q3wcf42/ zifyN/hUPpO/yd/iC/m7/H3+If+Ib+Bb+Db+Cf+U7+J7+Zf8K36En+Df8O/49/xH/jO/zn/hdzVF 41oZzVcrp5XXKmtVtKpalBatVddqaDbNocVqNbXa2uPaE1o9rYOWqnXX0kWICBWVRCfRVaSJdNFf ZIpsMVQMFyPFGDFW5IpJYoqYIeaI+WKBWCyWiQKxSqwV68VmsV3sEPIvnktYOAvH2ajMKuNsVGVV QWXRLBpnowargV5kYzbgLJbFgsZqspo4p6PYKDCy0Ww0lGGvslfBm41j40Cw19hr6A0T2UTwZW+w N8CPTcXZLMums+ngz2az2VCOzWPzIIC9zd6GQPYOeweC2FK2FMqz5Ww5BLP32HtQgb3P3ocQ9gH7 ACqyNWwNhLKP2ccQxjaxTVCJbWPbIJx9yvBUyz5nn0NltpftBRP7kn0JVdhX7CswsyPsCFRlJ9gJ 9OBv2DcQxb5j34GFfc++h2j2A/sBqrEf2Y9Qnf3EfoIY9jP7GWoYWhtag9XQ1tAWbNzKrWDneIGD O/GU6uRxPA5ieQJPgDhei9eCeJ7IEyGBJ/EkqMnr8/pQizfmjaE2b8qbQiJvzpvDY7w17nzq8La8 LTzOU3gKJPFOvBM8wbvyrlCXp+EqWY+n83Soz/vz/tCAZ+CK2ZBn8kxoxLN4FjTm2TwbnuRD+BBo wofimvgUH8aHQVM+HFftp/kIPgKa8ZF8JDzDc3gONOdj+BhowcfysdCSj+fjoRXP5bnQmk/AlfRZ PolPgmQ+hU+BNnwGnwFt+Rw+B9rx+Xw+tOcL+AJ4ji/miyGFF/ACeJ6v4qugA1/L10JHvp6vh058 M+7ZOvOtfCuk8u18O3ThO/gO6Ip+vQu68T18D3Tn+/l+6MELeSGk8cP8MPTkx3GP1Iuf5qehNy/i RZDOz/Pz0Idf5BehL7+MJ75+/Bq/Bv35LX4LBvA7/A5kaDKwD9QMmgEyNaNmhBc0H80HsjR/zR8G aUFaEMjvpUTAYM2kmWCIZsZd5YtapBYJQzWLZoGXtGpaNRimxWgx8LJmxb3fcM2u2eEfmlNzwggt QUuAV7RaWi0YKX/ADEZpSVoS5Gh1tbowWnteex7GaJ21zvCq1k3rBmO13lpvGCcqiAowXlQUFeE1 ES7CIVd0FB3hddFFdIEJoofoARNFb9EbJol+oh+8IQaKgZAnBolBMFm8KF6EKeJl8TJMFa+IV2Ca GC1Gw3TxqngVZojXxGswU0wUE2GWmCwmw2wxXUyHOWK2mA1vinliHswVb4u3YZ54R7wD88VSsRTe Eu+J9yBffCA+gLfFGrEGFoiPxcewUGwSm2CR2Ca2wTviE/EJLBafik9B/i+Mx6EfMzMLi2FOlsCu sQlsCpvF5rJ8togtYavZOraRbWU72C62h+1nhewwO85OsyJ2HuPlRXbN0MbwHH+c1+ON+FP8Gd6G t+LP8Y68C+/Be/N+fDKfzmfzefxtvpR/wNfwj/kmtGHhn/F/8i/4Qf41P8ZP8W/5Of4D/4lf5Tf5 r/weO68JZtYCtYpanNZJ66qliQiRKrqLXqKvyBBZYogYJkaI8WKCyBPTxCwxV+SLRWKJWCFWitVi ndgotgr5Gex+FMmAIplCkUylGMYohhkohnGKVRpFKS+KT0aKT2UoPnlTfBIUn3woDvlSHPKjOFSW 4pA/xaFyFIcCKA4FUhwKojhUnuJQMMWhChSHQigOVaQ4FEpxKIziUCWKPeEUeyIo9lSmuGKiuFKF 4oqZ4kpViiuRFFeiKK5YKK5EU1ypRnGlOsWVGIorNSiuWAnxNkK8nRDvIMQ7CfGxhPU4wno8YT2B sF6TsF6LUF6bUJ5IKH+MUF6HUP44oTyJUP4Eobwuobweobw+obwBobwhobwRobwxofxJQnkTQvlT hPKmhO+nCd/NCN/P0B6gOSG1BWGxJWGxFWGxNSHvWUJeMiGvDSGvLSGvHSGvPSHvOUJeCiHveUJe B0JbR0JbJ0JbZ0JbKqGtC6GtK6GtG6GtO6GtB6EtjdDWk9DWi9DWm9CWTmjrQwjri154EQaxKiyK VWcOFs+ustfZZDaTvcneYgvZu+xD9hHbwLawT9hn7J/sC3aQfc2OsVPsW3ZOeoUhmV01JBvas9d5 HV6XN+RNeDOezFvy9rwDT+XdeS/el+fxaXwWn8vzMWov4Sv5ar6Ob8Q6B1kU38l38338AD/Ej/KT /Aw/yy/wS/wKv8Fv82J2jtfRvFkVLUAL0eJ4Q5Q6al20HvyACBOdRTfRU/QRA8QLYrB4SfxDjBOv izfEVDFTvCneEgvFu2K5eF98KD4SG8QW8Rk+66D/zxAn1/xwwl0E4a4y4c5Eq3oVQp+Z0FeV0BdJ 6Isi9FkIfdGEvmqEvuqEvhhCXw1Cn5XQZyP02Ql9DkKfk9AXS+iLI/TF03qbQBisSRisRRisTRhM JAw+RuttHULi44TEJELiE4TEuoTEeoTE+oTEBoTEhoTERoTExoTEJwmJTQiJTxESmxISnyYkNiMk PkNIbE7rbQvCY0vCYyvCY2vC47OEx2RaM9vQmtmWsNmOsNmesPkcrZMphNDnCaEdCKEdCaGdCKGd CaGphNAuhNCuhNBuhNDuhNAehNA0QmhPQmgvQmhvQmg6IbQPIbQvIbQfIbQ/IXQAITSDEDqQEJpJ CH2BEJpFn672wRNOV1gAK2AtbIXdUAgn4TxcgTt4YnGdfyCGfg0yieFZB88aN5GPYb8gH89+RT5J G4U8QusDKrdp/ZA7tAHIYx9h4QZZuEUWbpOFO2Qhhyz0JQv9yUIGWcATnDZQliAp0y294Jay3NIg t5Ttlga7pSElkk9zt9SCJDy/YdQ5DYDR4Sds9Qq/CgaMEnhqxEjxKxgR4Vvl+wllLlSERGgIzfE0 3RUjXDaepce7x+4oFMmvYClBSoRSTYlTkpQmSmv6ZJxBVMNz4WySqrulmBJJ3YvSLJL2uaUv3NJ+ t/QlSYxO90HqAZlTt4EqWqrfojyDyhx0ly50S1+VqneI6m1HPlH9BPl0KvO1R5lgdYe0p36K59hZ mB52Wzrilo66pWNu6bhbOuGWTrqlU27pNEle4I/eYXK9pUhSP8fW5mF7n1Or89TP6HttuzE3H/O7 STtfxd0N8m/cts6QJL/7qH/eN19djCWXqCvAWy1QC6CsulL9APzVD9XVEKCuVddDkOsXeIPkr/rQ d+WA/oIsv3v3Nt5Yri5Hm6uxPFM3qZvoc8OqOo3+Gim/VyXP6V5og9P7rKquX1QLp99Si0AbW6Ay /XWxHv11UdpvRt+SskACvSvwF3G4HqDHsQslkhZMHhGPuat4hj9B5fzYK7h64D09ZRforYE8WQKd ERWseYrelwSA/hdMg3oOeyrf4CtqPrXLcYxL3qPQewr1n/Qse9zzXiQ/lULSd27pbImkDZOlf3ds St5DuX41LEy+aQwiLYQlOXPCErUyMWObjr3pq3ip+Tlh1VEVpSpKrHCW0XgNP6aGcnB207xraIpB yamtKob8Ns5nnVYPTaUFESMrQRJdraA7/Shqf/ox055QV17OKh7GDEFfhyx7ZcvgsoUdO1c+GLcq 2LG89kxrfk75U84ctgPJls9URVX9n9pScfqpiclNGt08NqCpb+wip6+7qwrHTo16nTrJ2hm0QLVD g9jyzkCZMQb6PNdzUHbPrAxTo26ZPWODnAFS7RUoGg/O6t4tY0if/v17xpZFa6j1DtTapnd7Mbtn bLgzTCpEYJCuMDXqmZXdp1efHvRLlLGVneHyNgsMdt1u22cAttJtQKb8YcVGDZwRFXyd8bFxzgQn /etQwTdWZuPj4ms+VvOxDs42Hp1t1ya2grO83r5f+55Zfdr06Z1hNT2d0cMeW8NZXW/IXHKDmpI/ fqm31aZnlvxxxUGy0RzF7DkqCgeWo5QF1HurOYoCS3evWrRnr+l973+8tmLc4MurW/58alvZLb27 bVqYVunohl92xy8f43wtZcSEY/1O1JpfdsuXF4deeXHxiIFJW6a+77s+/Vr/abs3JduWN33i+tqv OncJU9+67egXsejmwjmLQ3ep37zSPPlbv64X61ca8bHvyXqfrT41blOXYX1j7Wz2qMAlT5n2xQ7y fc62d2hC/PSA2QEfn0x3LDv77fbcCTGfvF5lXK9No1OeGzh4S9Iyy7jOu/3LJ7015kLbbd4ZO4o/ bXbiY69yM83Dj9WN/jJi6MW3Yj//+ay54rEdHz7VaE5ol/yIvKLU65eG//yP5d2VN663ECf3m9sv mb63YPyQgkvrfa8WtTiS/2t6fkHQ4x+O27ZBZej4C0cdc4467EzQjOixnHspiqGa0+KMLMk7lbEh 6dnZmXUcjoE9BmXah+C4D8Jxt/cYOIB8JzxQUe4ZjE4NE1UBZwOpq2yo40x01spPyI8b63RV75HV v1Rth+4rnq7SqIEdS5GnhkcZfJzeJb1gRqefVJaVbRkQARr2EPPlDOiZiyo6K5T4Nwv0adumATpa oi3WVjP+AVSwUaOgWb9fLqRsb1wp9rWXZteYsSVnhXKoUvO9K3NTMk4Zqy9M3bV7auA5Q7LvT09F OyBxZdHnU1vOKTR3L3+zXu0qrTJjR/78euK4D8+fnwnFX7Sb0TLywNLolsMKPurW4GrMvnOfH0k9 saHGq3XXzFtz5Jvn7m1e/emI61/4zL88s7jGwceTw8ISo2/Wa4YYvufMUc+5cOz7fY3LhYerjw+J 42VS5wwZ/yCO/yvIeBiOzkRPOD73Bxt1OG16o5Z/1ai81zPrX0JyVetqTU8cTB82JqRxr8GdR+xY 91YPy70nGs0dXi7RP6rdoCODo/vcbfmxqdNB71/yw2J+bNe+SrfDEceKNsb3++ynEwtr95wUNtVn bZuITsN71ezCc58sHtLyVJuRC0aZ5hWM77TAePM75y+XzLWbN/Ted2pn5R2H2n0/qt6a5IXWZcqw KwuWTaxZ/NbZzn35W0/0+3bLjK3Fe7r+Uv+cV37jH0Y9m/FOzJW1uf7VfnzjuJY/tvWcl5sZfZ3h u/3n97v5fUqBYWn92auqnX8jeEXSt20GPnOw5rw1A9PCP5xh3fDEuZd+GDDsl+Czlvfe/2l2m4/q W6eve2lZcWHy8urZIxpefCxiQd/gs89viEw/DCMb+Y8b2c8Fyd3OUZ/9RUj6uCGpOsEZr4PR6oxx Vsu35EeONf8WGLMHDbL16EbwCyb4SRO/g0Bt6x9CYMKDCJSzPG5o5tGWyYqp4+mXPs9x7rj7ccUZ mybDJ5v27t15ze/wvV9abI3v7iz36fXssMIpJ7vMNQV+MPzJza33jj43ssLod6On9g5s8uvudbMa sD1vPtuRv/7KkoFXw1qHRdqv9JnY33xzw+7g6T/6ZG9Nf/HID7O7j9s2KO/Wa9nDqi5fOOvlmR/c fKP6Cy3sg8OaNjh6eY2vqe2hF/Nn5vToc7fMF7mXB28o8+b/q+48o5pa1jAcIHQQCEW6dCuyE0JH kCLlSA1VmkAIVTrSBRIRQRSkSVMghCpVqUqRKCJVQYoHRFGpAtJBEJQbisK56jq/7j3r/MqaPdmz Z/Z888z7zl5rpn+NwUAoxQpW709cGhBWn/kkku+Eb5eYd22sp9nagzENZir+9pGXPfCT6qeZZeks /QWasm1nb71wm5IbX6INGuwKxHm7O+Bva6sCYrz3MkvYrWWP90fdPUYe8CdrmVnAhzvZrt9kI4oA DBhCQMCXHQTQgfCgSFnZcIYuuRXk9NDp/W8MTCCA2/exTc3Ip+Tq5uextXs0zxHkUR6olJQEz4/9 mrf3hj4J5QY4d/7M/Nec3V2jobzAoZ1uYt3LR7i6evEoXPSyd/Vw8PLbwoOUBACFAoDELh5gABQm Ct1N/gM1+tupnLgO7zYms6DFcSQ90dcCmMzMvyF4fvVbggau6tudTB65QN3M1MxoS5hTl6KN30yh d4v+wMLU7TDO6PRQ27KnTv7W/H1csm/piGInbjU+ErZNSbEXSu6UPvGIpsJYCK8yTiUneetE/hGp vGn1y4rDoXQ1KRcMrAoxgVhLYR+Nj8nlNjIpOpxQCgGm9PzxmOOsY6eSkEyWxqSodC4JxNXPubPx xE0c3Y8MzpRFhDySntaP1yr+muvv7KVVwtp+i/IIL8jopqWDRM1ZCLms4abpepYtFUXOS7Sh0Wyl jAUL2gc8sFJfHJLwrbQjuC+X3cNMtrV2jgLHB5SRXWkp4/FhvDK0y408AJ0NoDO3xiURGJ0CoBND 6E073WYdPNL4dYOY7mtGbbZhPf7//Yf5mxjfpkLCBHXDjcVEVrFP1UQCf/owLJpZwtLTqNvkSGPC o1ukx3gX5oziTlRkqDZbz268apeRMckX13f4JuAs39J+9y1p4BvojVPp9G6ONd8g2qwODRudSsMM Jjzak9YBJXfZmo9LCArXo7CQa4J0SNxnfc413pY+5kVEoYsSjPwr5uDqqN0FWt2VunnEs7rxRmCD B0oZzpVwlF2zl4s4ez7kHUm56dK9N81GMyj1Zwj9ynKSI5DNm31zFNFB1YlPCyROjPiP5PkMe2eA Oh3l8S/Fr71TgOSJOXI4vhZ738MJHsk7A242EZV00eSkta6iyrze3asvr9LBaZDj9hoifTXuYnru ywwCFZ4QxEHJrjBwpE7WbgBxFTAMNBJjbQ8//G4SuP4pJADiBL0Ah0rA4VD4loAnIB4m/h0J6Jy/ SgZGgGHHblAZWXnaE6SAF+E59NtTCMFskCNQNs6uLjbfa0b1u5r9rpkwwkN/aiY/wLvTDPb9OTao bfGxpUZ0tk0Bz88kod0iCcU2SZ6089yoHdqU05nxf9wjILji/Zx3s+OYoVbr7SrMfTE/YVBjHkUv sqUqe+UjHt937/qtTPIvdJUYRMoUpqmO/mlew4xTaJQeR43OFxuiCDxLD8YedNpXeRkiqbWO1H33 5dSDUYl7Q0hyfhn303DVJadileXDntx8bYps3LqViJRuXCdjE5u8O5nzQgKv8nnFTw0tyTY81Xj4 RqbyWMB9LpHqnLdL2KFUXrpvxlAFA8mgEuPxkelzfoIFn4+JMMhL+sopBufajwTx2R8c+yO20VcZ oYrVDo2IS22wC5ikXA8jubSS7C57PNc2qX1I+MNxYnY6uBpqWRZSMn+Vk0sI4dpOiD0SHIboGOF9 CP1Kh5P8O/ACIaPcNeDMBL4Qk5CAwNsWlesAmAXMJLh6/Kx5s4d+0ehKxrGDLOv4NT00wPbjFiZi MA03FUgPdJFg15VACgD1tvDZ9h0qAN0PgUUKkBB+9o3LbYwhh98tklaXTlJTw7swULkI6zO9FLlr VqjmkyRfJNUUXlQsHL7cPfzUUC+vgu15+9h8xpphpVq8qsBo/qFB/54VFn/I68WbHNMU5mVXbj64 blzD2Z7QnRAvuhTzdjM81eKsuo6UkDQPh77ExiUz5rgng5xRc1YI2VHyT7azftPRz42QqARW9Qz/ IVTVkFDxt2ZIZVNme9P5SLfF1tcFGBfyQRTbg7yVsMeUiknzQoUO/vfwx3NLbQ9ll1ylcEpkrC4V T+YmxTFK4hoKAbmHvK+AnFZrCGeJ0Y3ReX+GhxayNBLzcfjYcC2wCanZsxd9+f3vL8X4Hl4vd8mO JhM1vmdxjIEOwJCKElDGsYMxKiuVtLbthRbUTysU/xZk7LFPCi4KF99ySxIEbURIim0lAa//STt2 80l+k/+3kqgDfUuy2CxzAT/0trMg4Uaf7J1DkU/Mw06az93zWC4oDHesGLjHF0Dd3Jx9NsaCj/Hj 2jL/nYolF+/i2Zks2WeNDefM5AvKPEWFcqzRVn5Y6yWX8IROlzfP0l9m6TJ4Wz10u4bC3mKJyDVH dyrbjr42TDvdujHoLXBSGQCN9l0KSGDoNebCTWhTt4QPZvbpJV9oRbYmO6bEWmhoMkyIdJuaWpxH 4DyFs2tCz9BeZ2P2bqMYSMlxY57QnHb4an7fKfrTUV0JycgmFXXmeJ2k0iX7rFdvKd3tvNJ8rnNd cUqcHD9/pv3dmDttFxIUFwBNiqIuZ6wr65yZH+Kdybe0mpFQOvVkRxJhiGIJbyTqJ++yB4OZfqf8 i3od2jMcWmxk3LjbBS/iv/6GfPlbV/nBaCyATgv5JUWwXln/BP9+Fgtnd4yfMqAInM6Qy5ANk95n /Jy/l7Pt/NycHLauiuyex+IpsjUAtuKfEPuwbUOovc+JKgEKgPwPJ0ocJrpbro+Pz6/KRXn8XKDX rzyhZP9sgmSqWRKTub6LwxBx83jZevdjzSKRgmB92gFY5arjGO06L7uPXLa9f3lC0DWzBaXGy6mo S+E6uoEYpuXLnq8y681aid2eC104WItgyo5oqBrBtmMv3olxP8XRYAgyrFgNFRqwEF3vE/S3SBnI WV9aUGAvNFApUhuMkWQ0plSfX4RePVQLjjKFoEg+Uut2YmmuJdf14/M6KZgFeSsqjSI4u0zDxLJb v969Op0vIV+l5DTMM3+mNqj447zBfaxaLapeD97fMkGGBJP5uuhsqtWkTiqZXH1dRBWyfO7piZHR YNM/RmF+M3xXYmmEy3RMmx6fNjYueNkxLILvmHZOl/CDYsBtBGw+IyYiAtAV/xo4/gXwe8vYGegJ gOnHhHqECEpOQrr94WJrmt3tekoSKM3+lXNC1fdS1NADwP5cZoB/70YwlDButSOJq0Or2MXDD3Dw TMgEY9+TbVoAHvtuoYHaANYZkiHivziRjAek8uOUqN+cTYYVChH4bWx7+bm52nlYudn7/beaBGOI QDqkvCx1qYhZ27ZAbZ2pnCfcaN8ZVoSiIkiG8Rgyj7F+oDI3FRP56RDIXmgi7k3xl01nxWjMUTXc ifiNctH6pSxpdWsvroIRuVcjD1THV6QQzoZPxvThBYzCwzFxcMGmta54ZKHAapYW/CSnbf0FX4tF zRRpSg3tD7GKyiefzvDguAWQhkpDdjeJxEuKPitrnH8jy+BnXlDE4dFWlxYZhbsjjF1YpcsnQjFN vXES0SVnKYgPKbUOirm9WnPGZL1iJBYS2Y6JJYMZvLtTHRn4YvZmxnzlYTqaw7SguQa02IEiz7h1 Xz29OY8PY4mf81b0ClWi8Nqtj6YE0rOWPi120bMjsBiCLMIQre/1GBkUQzRNuDSxFd52/5NFzV8s pdKQUexUgJhAmYxzAOv+2KPe+7RDRAi9HzmkULqt+Z4wwcO2ljzE4CYE/u4LPQiYHrch3bbgKyrd a0nZpTWlqv+LEHBKCjMris/TF9HS1HdwGzNA+hU9LccohY/7+tIGm/T6hNIL2cUPvQwnQwR3fBYq ikK9b1uH+TDj7Z9xxWa5Mn7MmFQ18KU7J/ao37Z3mmuQSUQavq4U670ozxl3PX5qvMrs3YkHJrE1 Aip0pO5qDPLTpMG2vgYHpzP8jPPg0V0jqycfXGbipvB7XWc/LdZjwJ8UmFXO4Ug5ajTC0aGr1ZOJ 0bDWgDTCUH/CuuUaR5CCbX9wZJcvT/PbRcs7CY+SB3cpONPoNxTjxSyHW0LuErOLXKgp3ThbS8/B eeoLl32ardrgpVwaA+tXdL1xjKQTBwUZExPq63rmcNgFKflDk6qUuP8A1cbfhg0KZW5kc3RyZWFt DQplbmRvYmoNCjEzNzAgMCBvYmoNClsgMjI2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNTggMCAw IDAgNTA3IDUwNyA1MDcgNTA3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjA2IDAgMCA2MzAg MCAwIDAgMCAwIDMzMSAwIDAgODc0IDAgNjc2IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA0OTQgMCA0MTggMCA1MDMgMCA0NzQgNTM3IDAgMCAwIDI0NiAwIDUzNyAwIDAgMCAzNTUg Mzk5IDM0NyA1MzcgMCAwIDAgNDc0XSANCmVuZG9iag0KMTM3MSAwIG9iag0KPDwvRmlsdGVyL0Zs YXRlRGVjb2RlL0xlbmd0aCA1NDYxNS9MZW5ndGgxIDEwMjAzMj4+DQpzdHJlYW0NCnic7JwJfFNV 9vjvfe9l37skadM0aV6T7kk3Ci3Qhu5QCi1ttGVtgUJREQQqizAWUdQq7su4466DShpAi6KioM6I KKO4L4OK41rFfaPJ79x30lIQHX+O///M5/Pzted97z13efeee96576UBQgkh8XASSENl0/iaM16q 3EPo0lGE2Fqqyiub1WOm3E/I7d8RovywqnxixZXWt4oIuXkfNEivqayqJh5hHtS3Qi/JNQ2Tm566 wXUHIfcdJOSeuJqmQPkX+zS9hE6F9lbn5CZf/qlXLfuSEPoK1G+bs7B98bJLZiwnJNZPCPfOnNOX OT2f+6YTUggi+2re4vkLb/6o/B5CzKmEqGLnty9dTKxEhOvvhPbG+aesnPdq16rvCSlpIGTSG50d 7XPfad38HvQP7UlRJyh0OzWQpFfAKbVz4bIVFfkJUM7B/EzKkzuWnDrfN2cFIZcegjqrTlk0p31m 6lIDIednw3x3L2xfsdj4jbkYyvqgvfPU9oUdG3ZceCkhl59CiL5w8aKlyyIN5EEYz0ZWvnhJx2LT 49/B/B3Qf7yLMNvKCPmk+OOPZxnGfE0SlIQdD328+hnGx8o/UB82hJeqPlLcCHVVhCN4QDs5CRO6 W30GlLerPpJ6GnYIItMI7eRy6H8KtOOIkfhIGyHaJOm6lPCCm9sBpUrZNbIC6DIZye8jD3JESTiD guMFgeeEjYT7zE+cZwz2Xd/kdBL4+VHAMShu5DxOQm5iZfxOmZ7NFHrXHxkNfQ7G8iqxkN/xkGnI ht+zv996cHcQ/tfUk4d/fryyBaThdxvQf+Eh1BD1b2nH7yFTj9vfpWT9UfUuPjr/i2O5nrQcR/er 2w8/uAXH5A8fvx95LVkvPHX8MuE1Evgt15bauo+xwyJScbx6/BnEdlS7e8jZv/WaR/W7l2j+ZZ0v Sc1v6ruV1B5Pr1iDern++OWCgkz4Ldf7bzvA923H6oQ6Uncc3Z9+72vTb3++z/8X12MH98rR/fJ5 ZPzx6sn2H63nnvzt+4rM/79rC3Nf+VuvNfzgnybm/0197lFSJLGSjJL4FCmReD2xcj8eHSPp6Zjn vj9aD48OU7kSMob+QJKObQN72O+6N/9x/HH8cfxx/HH864O7jvzzZ8sWkOeOyhv/iNP/bYdwF5nE vUUS+C/IZP7Q8Z+/pXp6UgxyBUgLyM8+8wvLSAt3L0niN5JG/hxS/982Pt5HxnIyYue2klIuiM8j v/b4d9py24gP2rq5xSSXW8Y+4/n36v1/PPioJEU/pfkGclTKC+Q1YDZxQkpLUiBVQMaRSniDqSeT STuZQzpIJzmFnEq64MlzI9lCtjsXO9dFIoR9xpJNcn9Se75Ue4lUOyTVPpPV5jP4HZFdkf2RQ5Fv I4fJzeResh2eFXmqhPOkyBy+mi99l71LUuj1eEeidLYO08SxWfETaAOdSi+kl9Br6TZ6QJAJckEh KImcfiLV+vzYT6Ygz0U/x+LILx/YEq5xXKNGPZT/hO/nP+U/+4V+hJ+MXXp6BsuRn75PHWcYME5q ZJ+QgcBso9pF0rM2pqPzj+ae+td9/oePX/WJ1a8//NWzZs6YPm1qa0uguWlKY8PkSfUT6yaMr62p rqqsKB/nLysdO2Z0SfGokUUjfN6c7HSPO1V0OaxxJqNBp1GrlAq5TOA5cL0qsbrNGfS0BQWPWFub w/JiOyjahynagk5QVR9dJ+hsk6o5j67ph5rzjqnpx5r+oZrU6BxDxuRkO6tEZ3Bvpejso1MbWyC9 oVJsdQb7pXS9lBY8UkYHmZQUaOGssnZWOoO0zVkVrD69s6eqrRL669WoK8SKDnVONulVayCpgVQw XVzcS9NLqZTg0qtKejmi1LHLBnl3VfvcYENjS1WlLSWlVdKRCqmvoLwiqJD6ci5gYyYXOHuzd/Zc 2Gcks9uytHPFue3TW4J8OzTq4at6es4NmrKCGWJlMGPVQStMuSOYLVZWBbNE6KxuytAFaFDmNorO nq8JDF7s/+RoTXtUI3cbvyYsyaY4ZCYoH0wTGBuMEOaXksLGckGfn8yGTLC7sQXzTjLbFiJ+X1Zr kGtjJTsHS+IDrKR7sGSoeZuYwpaqqi36e3qnNdg925mTDdaXft3wC+XOIO9pmz2nk7G9o0esrES7 NbcE/ZWQ8LdH51rVm+uD+u1tMIkFzAyNLUGfuDgYJ5ZjBVA42RosaGqRmkSbBeMqgqRtTrRV0FdV ycblrOppq8QBsr7ExpbtpCByoLfQadtSQApJKxtH0FwBi+Kp6mmZOy/oaLPNBf+c52yxpQT9rWC+ VrGlo5WtkmgMZhyAy6VIV5RawdyOqT1Ymc1c4VY6Wzgb38pWCxTOajiJ5WOgwAjLJWXZipaPcbZQ GxmsBleJ1mCpo/qBDO+uqGVFPGtaUWtLaU3B4xeGZIuOSeYOKof1ZQTF0JjwOj87NKzNBpThrOqo HDbAozqVRQcY7e344+SYLaIXhhZKtpy1g0W8G+5c0HHQjaRiq2h1BkmDs0XsEFtF8CF/QwubG7O1 tL51TWJd49QWabWjXtJ8VA7LR2EuSFKgeDDDVYAPVmfZBpdVytdI+aFs7THF4weLnT1Ksa6ph3Uu RjskTriDYNJyz/j2C0bFFMKtWQ3RTaxuF51GZ3VPe1+ke3ZPr9/fs7iqrbOE9SGOn9sjNrWMsUlj ndKyxraKXSqG1NG65vKcbIg95b0iPa+x10/Pa5rast0IDxTnNbeEOMpVtJW39qZCWct2J8R2Scsx LVOyjJNlWE9TIKOU6tu2+wnplkoFSSHl5/RRIumUgzpK5vRxqDMO6jjQCajzSzp2wCJZO8HEEG6r nHPZ8qxu7expa2U3FzHDUsIvDVKxlAQ5sbSXcnJtUC12lAc1YjnTlzF9GerlTK8Ax6BmCsZhMamn TYQ4BQ7VQmwUXZFnXTr7IpHmlpS9tv7WFHC16SBTW4KqLIj9MvcEqFfDpA3UNcHuOe1sHCTQwtoq 3OPntILbDnYIVcYHVdCDKtoD1KiW2jB3hEZzYG1gAaX23ZAJdrcGW7PYRVsWtErubAySWrEElh37 lHnYhXytPTFivnRvwq2gdp/LoIKxkaYW1NggCxdrRSMptDDyOSIUzWlzgrUFMqcJXB1jqdqGmg4I iYKnQxK1LVpI2LR4t0anDqq80CH8srTGy25JmVvR2oqDl3LnRivAtY1BDYzIM8yU0QZgHSgaz8YC v+fCUFnVx1g3jX1kirgCIgsbtNSTAoqDOvf4dgj+2F4DGnHUYGMlixGaaB+7UatgM9eC3Xl3c1/k TnFlyrAjJ1tkmwNzTGKDh18/ae05VhGclpWTrTxWq5PUPT1K3fEboL2UuiGCkvSq+D7u+1Cy3dHH fRdKzgJ8G0rOBnyD+BrxFZZ9ibkvEJ8jDiE+Q3yKNfsRn6DyY8RHiA8RHyDeR/wT8R7iYChZBXgX c+8g3g7ZYwAHQvYEwD9Cdh/gLcSbiDcQr2OV1zD3KuIVxMuIlxAvIvYjXkA8j/g7Yh/iOcSzOIi9 iGcQexBP42X/hjX/ingK8STiCcRuxC7E44jHEDsRj2KfjyAeRuUOxEOIBxHbEX2IBxD3I7YhtiK2 IEKI3lBSPiCI2BxKKgDch7gXcQ9iE+IvoaQ8wN2Iu7DdnYg7ELcjbkPcirgFm9+M2Ii4CXEj4gbE 9dj1dYhrsfk1iD8jrkZchbgS212BuBxxGeJSxCWIixEXYdcbsPmFiAsQPYjzEedhg3MR6xHnIM5G rEOcFbIVAtYiuhFnIv6EWINYjTgDsQqxErECsRxxOqILsQyxFLEEcRpiMWJRKHEE4FTEQsQpiJMR JyEWIDoR8xHzEB2IuYg5iNmIdkQbYhZiJmIGYjpiGmIqojWUMBLQgjgRcQIigGhGNCGmIBoRDYjJ iEmIesRERB1iAmI8ohZRg6hGVCEqERWIcsQ4hB9RhihFjEWMQYxGlCCKQ9ZiwCjESEQRYgSiEFGA yEfkIXIRPoQXkYPIRmQhMhEZiHREGsKDcIcsowGpCDFkYZ7sCllKACmodCIciGSEHZGEsCESEQkI K8KCMCPi8QpxeIVYVMYgTAgjwoDQI3QILUKDUCNU2KcSoUClHCFDCAgewSEogkigEUQYMYA4jPgR 8QPie8R3iG+ly9JvpBnRr1H5FeJLxBeIzxGHEJ8hPkX0Iz5BfIz4CPEh4gPE+3i9f4bMIuA9xMGQ GTyLvot4J2QeBXgbcSBkrgD8I2SuBLyFeBPxRshcBXg9ZK4GvIZ4FfEKdv0y4iXs7EXsbD/iBcTz 2Nnfsd0+xHOIZxF7Ec8g9mC7p7HrvyH+ioN/CvEkXu+JkLkcsBsb7MILPY6jfgw724l4FPEI4mHE DsRDiAex6+3YdR92/QB2fT9iG2IrXmgLIoToxcsGEZsR92HX9yLuQWxC/AVxdygeAi69KxQ/DnAn 4o5QfD3g9lD8JMBtofjJgFtD8VMAt4Ti/YCbscpGrHITVrkRq9yAZddjzeswdy3WvAbxZ2xwNeKq UHwD4EpsfgXicsRlOKRLseYlWPNixEWh+EbABqx5IeICRE8orgVwfiiuFXBeKG464NxQ3AzA+lDc BMA5obhpgLOxbB3WPAurrPVvBh4yVDk+09c6DmgnOR4HeQxkJ8ijmhMcIZBekCDIZpD7QO4FuQdk E8hfQO4GuQvkTpA7QG4HuQ3kVpBbQG4G2QhyE8iN6k7HtSDXgPwZ5GqQq0CuBLkC5HKQy0AuBblE 1em4GOQikA0gF4L00TNDsezu+1MohnnSMsTSkIl50hLEaYjFiEWIUxELEacgTkachBiDGB0yMpQg ihGjECMRRYgRiEJEASI/ZGBumYfIRcQgTAgjwoDQI3QhWIM+qkVoEGqECqFEKEI6trJy/zTgpyD9 IJ+AfAzyEciHsHr/AHkL5E2QN0BeB3kN5FVYhVdAXgZ5BORhkB0gD4E8CHIDWP56NbN0N1p6VcjE PHwlGmcFYjnidEQXogJRjnYYh/AjyhCliLE45XhEHCIWcQZetglXdgpevRHRgJiMmISoR0xE1CEm IMYjahE1iGpEFaIS4UKk4ACdCAciGWFHJCFsiEREAsKKc7AgzP7rgAMgh0F+BPkB5HtYxO9AvgX5 BuRrkK9AvoSV+wLkc5D3Qf4J8h7IQZB3Qd4BeRtWcC/IMyB7QJ4G+RvIX0GeAnkS5AmQ3SC7QPpA HoBVvR9kG8hWkC0g10krvAZtvBqxIGTyAjoR89Ee8xAdiLmIOYjZiHZEG2IWYiZiBmI6YhpiKqIV 0YI4EXECIoBoRvgQXrRxDiIbkYXIRGQg0hFpCA/CjYuSihARMoSA4BEcguLtRvy3ACMgYZAPwKIv gbwIsh/kBZDnQf4Osg/kOZBnwcLbQc7h3Y6zea9jHfU6zqrtDqzd1B04s3ZN4E+b1gQ0a0avqVvD a9bYAGes2bTm9TXy1bWrAmdsWhUQVsWt4tQra5cHVmxaHtAsp9rTa7sCzV0Hu77q4uO6mrvmdi3r uqJrPygUt3Vt7drdxfdFdvpjukaNru7uuqSLi4NyjnRRA1OndGn01ctqlwSWbloSEJYULuFGH1xC 9y2hnHMJ9S9pWMJBrS1LUtOrWe3IEnNiNVniXJK7hD+tdlFg8aZFgVNrFwaeW0hPhqmcBFNa4J0f 6Nw0PzDPOzfQsWluYI53dqDd2xaY5Z0RmLlpRmC6d2pg2qapgVZvS+BEqH+CtzkQ2NQcaPI2BqZs agxM9k4KTAJ9vbcuMHFTXWCCtzYwflNtoKGW1nirA1V8kYM4KEmG38XJ3cmHkgVNm32xnVtsP2A/ ZOcXJx1K4s60UUPimYkXJ/IGOHF4SnAkXJxwU8LmBJlBSvDaxTHdMdxiU7eJyzX5TftMB0wCMW00 cYaLDTcZNhv4yYZZhs8MEYOw2UA36x/VP6f3t/GT9bP0i/S8Qc80vNGv9+ZVG3QOnU/Hj/HpynST dfzFOurXefOr/brUtOoy7WTtLC1/k5b6tZ6M6s/UETXnV0PBZ6qIiouoKOGpk1JCjQBeCVbeSuMd 1fwO9n15IiOUXtLb3JSVVdeniEypC6oapgXpeUF3Ezv7G6cG5ecFSWDqtJZeSi9q7aVcRXMwjn2Q K+XP2bCB2MvrgvamlhC/caO9vLUu2M3Sfr+UjrA0gSqtWTOXdi1duixraRacQGYuBc2yLviVQOEM 7FrGSpYtJVAl62eOpShLu2Z1QVvIzFy6lPXalcVyTNgV/u8e9D89gP+zh3XWTPaXY8WNhIQvH/an 5LXwcz3ZRLaRB8lj5GnyAvmSqkkbOYc8St4lH5EvyI9wMypoPE2iGb/fX7DD62QLiY7fSeTsG1aR HyIfhu+OfAj3vH6Y5nLIWQTPEU0kJtJ/rC58ebgv/KxcQ4xSWyO3B7SHaH/kB66M5SNFLM+dy9JS i0OKG8ObwzcdNZzFZAnpIivISrKKnEHWkD+RM8k6sp6cS84j54MtzoT0BeRCsoFcRC4ml5BLyWXk cnIFuZJcRa4mfybXkGvJdWDHG8iN5KZoGcvfCD9XSaWs5BZyB7mb3AO8ldxGbid3krsg/xew/j3k PtChBvP3gmYjuRm0d4CW1WK6zfATJL0kRLaQrbBmmB/M9ZGd5H7yAHA7rOZDZAd5mDwC67gTVvZx Scc0g/mfr4nnXWQ3eYI8SZ4ifyV/A8/YQ54he8mz5LnfVPLEkIbl9pG/k+fB1/aTF8lL5GXyKnmd vEX+QQ6Qd8DrPvlJ+StQ4zWo82a01ttQ6z3yIdTsh5pYD+u8IZV+IPWwH9oeIAepknxNOfIjiUCK rd5V0gpdI60jWz22OrdJdmbrsRnybIXuHFqbe8HG98J6shxLXxtdjfugbi9YcNB+x7fas9HVQXvv gDrMFqxkb9QWT0VXgvXzyFDbPVJZSGr3+FCvRyyKM3xxmHXeGGbD98g/Jcug9bD0iPVYjYNQh1mZ 9XG0bd+Btmh91pbph7dhZa9B/kOIDp+ApRk/llbiY/L+UPr9aHk/+ZR8Rr6WzofI5xBPviRfQf4b 0ByC3E+1x2q+hZ/vyPfkB1jBw2RgWG7gmJIBEoY1hqcGylGehI+kjmglEaiMyiGmKamKqqmW6qie GuAZRHFMiWaoxPSTEu1xylSSJobG0jiIlxZqpYnUBnHTTpOpg6ZQ17CyhKESJ5SINJW6o2VmqWXC UFsH1LAMq5tBc+lyOGdRL/VBOo8W0hF0JC0GTQ7k8yFfAmW5EsvZv3cML+Vfh+jIEwUpJvVkEmne QXT0BgihJXTP1spKZY7iEchyxEn3ECWY6gZ/rMDpbLYycYT8Qr7RNL5McSHXTMoG3nrzSTjtjSn2 7aW+N/tf6jcOPGkq9vXv78/LpaYUkyRxek6hkMtFl5cbkeYpKijIL+VGFHpEl56TdIVFI0v5gvxk jo8b1JRyLE/51w9P5qsGUrmVKaOb8mQ0y21xxCqVvCNZ5y5wGurqxaL0RJmglPMypSKtqFwMLJ/g elZtTUuyp1nVQHsScOBxmf6HL2T6H08UKn/cwX1Q3FKaKl+p03AylfKG9OT41LyksXU6g06mt1kS kxRKk16dWds+cE2i26JWW9yJSW7Wl3tgNFjEEvlB2CWLIy7iIW+zR8xAy3aSGvlgq8ZAJ4p9kQ/8 ySzl1upEq46Yqd7s0ahFl5o4BZGaRI8b3sD8yX4N0dIYXqtNs6eKYrJaZyaiy6qIsU+JCcgCxFpW VhZjKR5lKjCBZWfNnFGQWN+fTxN8M2ckWvfmF6w5d/duat09cwYm83LhGdR29DC2scS/c7W83Kys VrfZjOuWxqco9Lzo8niKRlJcLItC5FOEXq3cPCqvoDhZK5wYTpwi6OwjsryFcXItvVhuFEsLRlen meSP0wfootmpmfEyXmXUUWFAH6sR5JZMUVhtitfwvMYc++TAa2DdDYQI7F+wxhAHOQ2t+yiJ5a6D LTmRu4yoiDU6RSu85PpV+kableVs7AXYL2uGqcDQs8r6syi6IBjl17bIy21ljiqmuDwjTIVFBSkw RVmhlxNFE/NXYeeM+76/J7wnJScnhU689/PbTwgfypp15cpzzj/lijl53LWhgY11adlCZ3Za400f 3Tr9xmXjDl8y6rS72L/zjXzC2cBj0knroL8Q7oqtdr04RdVH5z0Qa7VGx9cBIzpBGtFA1v7+Murz sSmE/lW9wZG7vPLBG0e6w0zRTDxnS5ncPTN5dF6qVinneIVOrbImp9tsGTa9zl7o8eQ7dLSzZcOc QpXeqNNbXIkun02j0+sM7tI8fqXaoJbJ4MS+D7oh8oP8NFifMeRVnItfo8vNtfh8aq/VmtjHzd2a mqfVqiHxAEktakzQaqwP0RziJ97Ioa1GkZuY1xc55HeylMXIzjo8W3y5eV65I73RERhySeaT7EmV OWN+Plhjf3++qcDITqbisb6CAlMBWGfb73sVsKV7MAiZRMpcHpyfiqYhZSGLX+D9tIDdB5J95adp 7Lnu1NwkLRc+X4hx5LpcuY4YPnwVp0n2gd6uKcq5x1ue69RSq0BdOkfGKHevLS1Bl6o2quVyOAn2 Hw/qTGpepjFqhKQf3x3Sry0oMojFmYcHeJpZkmrQQyv2vd2GyIeyBJmbxJK0I/dJHPc43CfJcFaT hKjXJ/TR6X6VoUm0YmCgM4Z855j75Ne2OOJtQ2Fauk0gmMfHoefJEhpu/PCaq9++qg547eVvX10f /sRZ393WflZDinNidzsjd9XN4d4Zk2/5YdMNPwZnTrrl2/vn3bl83PhVt0476e4VZbWrb4dZqiHW lgrZJBXunYZtVkua1qPr4xr9ar/F4wSlxgOedss24nHbM9P6qNGv0mpj7B0xnbJOwlYW9iGIaBA2 rfv7TcXFMcWJxjcTMZWXeyS0pR0b2gQMbVkapXn0yLxRSRphXHjeWBkLbTl5sQoNnSQ3pZYWZIzO SDSphSe5S6l7lpgOwU1h0D3Sp4d1lJszXfw1xli1QAWF1qS9PTwR7p6pkY/5C4TRZAQZG7KStIe4 F4gWtogRW512andJn67P4/pozP2+vLI8Li+7j57cq1gAu+z+Gf3Sia0WRHvwUGGY/YX46HoMXwNp O71AZS+onTai6+H1tfXn71yW1VQzKkkrU+qU2tSSKcWlbeNc6eM7SgvrR6VpFWo5f1tGrj3Jaqg8 75lzz3v+ovF6S3JSXr7dY1XbnLa8qX+aOHVdU1qCPUFpzmA+uB5idQm8ebFYncai9K1SlD6TRWma G9LPhRib1yubT8r6y/qjfvaLEbak8coXLwm/lZyRkUxLLtp70YTwNym1y9pOPrllSb2Hc12576zR qR7+Mk+qf+3j51evaM0faM8+sRvsCiPhc2Ak2WRsb2JaH3fmAypnrDOWqBL7qP5+o4d6PPIE9jcF 3VxwE1OvHMcE/nEaDGxvcbHPZ2QbnvvY0UmGTYk/kjSxJJ/DTDjwOBsoVwJJQYBTeC2tUupVgqDS K8MP0XWgkrXb4AkCx6wye5JsqRb1QUjYEt1mVTissrhZTG2JfCQkC2MgfI3fkpxssLLvUJB0wyPc RnCUMhoDD2wiVd2fADd8Qq6a/Z2lZF5cHx3Tm7sgOg1p/Eb0DnBvX9TOR3lE0cgRQy6Tkm+ON8XJ FRjdBr1IsMlUGrmpYNKpdXWrW/NzT1hR4yi3PaSAecB8FXRVckq8WWxunZmz/sUrG5qve/WciSun joTte60jzcJcJHdqd+MJZ7Vk63SvqeNTExNT41XpKeFJCW6FzmxU1fbsWbvu+cvqY5PscTls3uvh 7jbD3e0jhb2iln25xJKq6eNu2EosmR3aPrrQr0pNPeZ2xl3gyGJJETllWHCO7nigG0wKZm1ygduT n6wNL9cm50spoMcNpOdLqYJkrUONS6emfw53Dqb59+EEe59eFV5PVw2mpX8XEfmUHoSxp0vfQ4Mx w27eATvz4l6ZtCi4df/yrkwPOqpPa04a6XVqFQLsyhqlKsbitCS44tUwqjRPvl1LJ7edcaJPrtHr dHFOi9ubqNJo1FpH3ijuHpVOJZPBiaD/c1/BaKxsNLHMggpdB7hIca8wH0ezt58ZTB517iEjwZn7 KjZmIJycgSZxaGkVzFPoGOkFt31k8CKHd6ut6dE1k+2CO20Uqd2aHZ+TBs7a6le5dD51To6rEKJx p99EXCPm5pg1vN0z195pjC4e22Zx8WJg7waXtbKNvLh4+DqKNBqQj7fdxhbEStutOV62S2PLdXty k9Rc+AVhVJkzJ8nAh1/mQOvx+Gxqr2dzjt/r0L4q/EPnyCpJuzcte2h1+bzDT5sMglKr5IsOPzek DWVkG13F6QO7ueLMEtGQnTHon+PAqqOJtzclhn1zJEnIBfh1JKmoQ5Npcc61dPLz0TWLj/JMuQjb SRrv8aSJcczQP52N2Wwp8PJH1kIYl+X5W0ZuzJsp/mTKcVRlzXS5chJUXs++GEeiWfW0u8LJwcsq VSVkusSsBFUgI9uTSZ+svnRccnVtTXKYGz4ZVaw9Ljx98mW1YsOUhlS6U4WPcOz/rwlAtDkHog17 ckhjzwx3Ss8Md7FnBggthnki8xv04qOi9i/s98I5NT171q19Yn3VeODqXefVhr+wlXaMnzivzGYr nTt+wnx/Epey/oXLJo5Z9/fL1+67tL503TPXNnRPyx05a3VV4OxpvpGzutmOEvmBfx+8qwBiYfl2 oub+sjXPmGUqZF/I84w2sRCRlGXqo4oto0dbivuobhtbAnQwFs37i2HA+ftZRHyp/4hnpaV5efFo lxqM6Ipk3mIxm+mRXYh/X+ssyckqdOr5er3d7XNPkIJGgV0Lu1Jzx8WdJYkjJhUmZLpdxoBaGX7M 5BlTdPqpBWWZ8bEKtYwX1Ebtu+nFnpjwmUML8rAn1VW7qK5oas0Iozo5Z2zaq0l2bk9SrhgX/jTO Xch8rSLyEZ8Jq1JHGreTcm71Nk+hp1BvZ18lJPrchyh7T1fDg0FsMfxYS/uoZpu9QpY1z8q2M1ws mDR7tBncCvbjvvBzUahwKC8/5ulBzmeWLrp2xojZDcWx7G1BqVVrfTVtpe6STEt6eXNL87j00fMv bPCeUJ1vVMh4iFsqTebYhtyUgtSYjIpAa6A8g46etOZEnzHBHmOId5gd6VZ1kstmdGQnufLSUtIL auaUT1jWkKmPTzDCy0ZCYkqc0pJoMSalmV25Hldafk07WMQGvtAGvuAkjl4iwLawxWwQjH105Bbb XDVbcXgf9u0e2MvmJx++usN2Odiq20zGiM6e70nLs+siSh1bEZ2S55RalcA/Nirn8K6hVRqLnxqw N/40uP7ZcJ+kw92fRVJ3ECe3Gu4SM9e9Te3pMHbYjtwiZcfeIkeia9yxAV9IL12+ecnCe5eP1drz 3Wmw/yQXT/Z660cmaZJzPRk+u4Zu7LrulJKCedeu5U4ajL0DdzY1j7TZR06q4zqGgj4lGrDPLunZ 2LedWLhTQzptIvsGYqqVwH0CT8KODqs8pkPOTBXDotNA8Zv9xjelj2WGxgoPRkVFw8JrPjwTK7iT 0OOTdOHdsbq4MSO9Ix062VP8o/AAXJBVVBKvjaHrw9cMbZjzuXGp6XEyXmnQhk+nPVqDkpfFZYhw P9dEPuRP519m9zPNwLeUkMoCt/O0rSQtjZT0cVV+o4m30C8t1NKnLaSHC2kh+9OqSqujEwsLveMy +6jVbzvgovwa1wYX53c1uNpcvMHlcHFaweUS7H2RA369Fl5U7FYjrbf/4J0wln0Go4LM2IN+bb1A rL7BN5cs/HRjxoxZM9h7gS9rxmn9M06DBdxdzJ7/YC+y+Q3/4dFI759sG/R4RoyIfmTG/KdgRDTm RjWC5FEKvGfN7PGOPz0uKzMnwzRywwk1y0/MHbty6/ITTWnjcsvmTCwwakwauTqpeuai0QuubMv+ tm3sCUUJNWUjWr0OvVGhMOprRpe7x59SO2lpXWpRZllmXJIrSZ/osThS7WJybEZg/fTXYlILUkb5 i6RoVQvRKoV/CR5Pb4iuahJJe4RbRvTw5O+A14HBD6JS2RdDYicID9JakgeW1GhofV629GKZzb5d 4lfVD36MkQVvOFn72Y6zG7ZQ245/uyd8k5cP27cg0skx0MmPektK4WUKa8mEE73zbzplZMWK22an 11eMMKtkfJzR5CmszZ/dmVhQX1BYN8qjU8GjWjBRtBosKYlG/5qty9bv6i7VW5PNBquYUOIDs119 We2pE9wOj0Nty4zaSiHIVpAusnTL/FmNJzHnzx3ZSJL6uFlb0tJmxT3CzSJKiPnLyCySRe1+zaKa wu9Kyr7Mn1sbeAhmO5HU0Gq/emo9SeJdE/Xs/by+l58gBR/23DGwv7+sgJ1wt2bbYP5b+/czn4J7 HW/v4U8g0vwVRxSe/2HvS8DcqK50a5VUi6pUkqq070trl1rq1tJr9eJudbd7sdu73d53Y3B7XzCG YONAgBgzxEBIIMkkL0ASbLzQgAnM4ODHDJ4s8PJlvvdgQsIMIRNnWDIQmLj73VuSerEbA+Fl3vfe Nz72ratrSXXvufc/5z/3nuoOlg0/Mb16xClKlExgYZbUiYvEo623dC/e3+tl7dX+QLWd1QfzweoV 2cpLys7UdCUkewDElkZB503PqC7rsrvWD3SpIXBSI+W75imalzcenKHzcjZzdtvje3OLWiMCvkBu blj/pVWXXq3sQaGXWrprHR1tlx6rtBC3YqglUnAl6qt4yWerS1pd1tIcOANOxhr1WH0mXvKYldk6 9MzuAkla5FjLtnnVJM3qhdIMkT8nh5EbkOtPIbs29OMj2JJTxVw/B8jtMpnJNGb6gewyBheNYNtl etfMD2bPf7f7+uJmODurkWVox8mtvRngiV0nucaiHSZPxXvbRlD7CU2HwqKaMxfT49OkBGmKa1b2 snQvvHJRd06AUzWuWEwUS4pX/Jo0aSKIiosLTjUKn3r20D9ZTDXr71+3+uiyxN9CFRoNzyfqjW6z Xq2iNQQjuBMF58xri97VBiPU7ipDoBDw5atEk58iMaNO5021V1+Gh8nokTceAnOIn7G0xFqGB1PJ RQfn9dGmkCOXHB0e6lJTarXot8dSAseqg/2716KnkzlHyETXxGfEJKmq4Is2+XkTRNL4LJaQ5JmM OTCLeRXcgegG/uUM8C9RpAYlS5bopMHgicHs92gNIA1bZdqDxwwxzBZ7noCm3KRFexFCR2AzB4jl BPYQcZzACMKeBFb6JI/2wqvsBu9JvhHsNr+PcDoOE3COMrNoL2UGb6A+lO0VQxN9BZjvi2VLPjS8 dCh6cekQJKCvQhBCZ0L9595b2ZkDMd7HTj94XZVV4K7Gz4T9l1631Q+1tK7uSvEAizhGaLR1i7a3 7jq5u75p58Mbtzy4NvUHfPGyVGfSgqEfJWKFoRavwWRQ6z0WySXxnNkkNOx9av+uZw91tO54aKl7 4x5/42ASwRHb6N34N/GXkSakD8ADK+8U9/MpNZ73dWe6n+/GXd1o9+svsigYHfviIOocRM2D6OA7 F0TUJKKIqBMxXhSX5/EPG4oRd6z1bCuGtKKtF/Ld/GJUhy9+SXb3l7YkgR6aLw4NAYqjeFHoUMHL oZ8rFxB0wnmYO/nOTDf6yTefuHdD60utGNGK8le9/9KJHkzpQKkHyrT4JKnEtINVKgBRyWQCFnRS YJWD+M/mKlZAMnkAXGuC4x6+CTPUBKuqOLz8Cv+mpNsgGWpW3Don2ieyhkziH2fumhWt2/7Yjq3f WJcUPClXNJmN+iK5lV+cHen1oDZBHH1moCuQD+gHOoP5gKG+2HzS6jKo1iwp9KWM+PJUwtzo6dsz GBU5rV9yBDANHmhb2tC6Y17aLy+s9TTk0iZTf7J+RZVvZVffvrlxmoqNflgcsEQLrvZ+cyR3aV48 hZEGn9upS9eYgkmI0R6wFl4CGG1EBpBlj6edAyPY0lMIxyEdEJ7akAOZne9KNw04CV8LTDGNd/eM oDNk2jeTft9o8BswAyBVT+jFosH8IdkP90KjwxeVbS9ToVnIZCbTt8B0kU7tlF0uzDQOBXzc8ylv zOEvtez5wTX1GwZrBQgGFatmY8U1bXVzsrZAS8uMqrV3LAxlVh5dFursKIYZS8jlCpvpj7KrstWd UVEfbq+xVmey7uiWB5bHGL1RqzO5RGdQVOtNeik9qzDPm3bxfYeOr9hx9mCnzl8XWVbxYKOvtXdW z1pdk984K817s1WQNdwA2P3PyC1IGtlcOTNiMKC+iHEEW37SGbHoRsrECIREvTIlx7v9HZaZ5MzS mQakmPpyMAxPkD7d+6ecfVzBE8bjmjKlwH9WcfMGfyGYWlnLOlKBQMrBVq4th7sgN/B+vO8mfbSO UakYHT1qKHn68tjRvWDsItJcthy8VkQB4WNoVIugDAECnOWnZVrXUeo+mgTdr04pXHrIdrLSPHU0 lT23vZf30ntlZyr6B6s2jdxU6sOJiOFpbDniVKYBcQJ1vn0SUFBFrWxFrQxQa8Ti7xpXLLAJULVR GI7rLhaUcxbdZ/rkp5sT8ZPmhLaGXe6Iie6+b/AT5gS/vlJbNzDQsO62FSVtYE8rcdyWsjaCPJgD mUWsPO2ikzSuxWnoxsC46BF0UKblaHeQF91dojIaSFPhaJZB/3iurAf6k98/6ahJcVrTDFw5r1Fh TwPfRWuMFqdejMTB8C8btq8pn7drnW4zQxIY3uNPWGm1Ri34G2KXXrly4NelW4I8rqZoVoyA0XeN vYW9C0bfhbxVwWILljjtT/vTrG0Ea5e9CEsk0MQbObBA6TeFnAynN+fOYXhOyAkS34A2wPNIG4Rf wxstNjLcLelgTIlIqI6Q3pXJ3nFfElX2caJDyk7OsqGo7uIQ+Dt5O8cmu//Cd5tQO/Fp94ywdwvr 7xxMLy6mJJbQsBQTledmvbVVxkBj76zexkB66eE5kX45ZgCUH1ezGipY6El5025dsKl/Vn9TEHXO 3N5XxZvMYjzm8Ilqi9PKWUNWZ9Rt98bkRc3yppkRVi/yvOgy2bxGtWgWOavP6Iq47Z6YvLA0S+QD gMUfRb7yLJLHEsgaZAnWjrQgW7C2U/6wYd8hyOZF3sJvblnTYuB5Q8saovcmpHcfzFy3y/YdHfkl Gzuq3kz0vDk7AWR+5o3gxu7573b0HuJh8Gkp3gqo/QkQZ0Lvk1Zo/fh+mwCXrHI6cQ74pST4oy+U +P1rEPm60m6k6uPpO3a5RsWrzsCkMOxjogXyAUyl4b2JrH3mtZ2+DXqRZHhqvaEK0Pm6sGSxU7iG gdMwc/I0XH0Sa+dekzN6eYu5dsNX1646ujxZiSDiDUa3RVAiiL12r6jleEYF6P1s9MUKvW+PS2Iw 647nrTXhaeav8eqz37ahGCAJY1tQvnZ2YnJMMdRVjimg3zCN/Q67kziB1CF3l3D6hCBo68OILw6f 6DVp4xUXGIehmq/o0FYatHB+TcVqGLrJ6jI8ALm+oByQZy6lz6WFEqV/Eon/OV9SsuJXRm9Xm0Ds TkbvS+bsPSAa21SKxjYyjpJ1nxy6QcUzKnJvLGm4TO3ngUMjSeDQzl+hLkVbpIZ4HcBk8ePJFg6q KNq3AGLEoG3V2oEgtdE5SF+xpbiAi4KxnSrW1xb1cHSB3iUQCeoSEpovnLuYTkM3fC6ZmRTYXkwn J51Uw0M66YqoZDpdeD5hXWsYgy+Rs8EgdfSmSQoAYajOm5heX+iBCc1xDCnqlSWrBL1qoLmEkWPL mpvQkd3ukXgt93Eq/aCSovHBdGtxD4hMX8JfAPxhU9ljMlVPYzDj2gU0zBviXVUMaenym8t7W72n ZK635PqV7cHSgdLFVxRfKXOf5u2TmUJl5/CyzehsbrwBf4m2hF0ewGC775u9ZH+vR1EQcJn6ACAO K3KM4kHtE/QIsoH1t67FxhtGNR0KdcBmjScIoYg0eg9+Cozbj6wvjfsMSlEcYgV+svWM7Le6aat5 BNsm8zJndXVZaEMX3UP0Iz3lVBwwaJisAcZUztXQF2BmIdQBO+3bwaA9eGmwOUMwWIUGayZtaEND KRnV2M3XUAO9oZQZU+/SiuToBa25kIym7Zz6Z/hzKkMsFy3YNKPnLJJaZxbQqMrC4TW+gKjBWYvp 0qPYCqug0UgBJe8mi53F1pBOJA6sTNPjarFuBP3BKcTnQ2pG0O/LBt7ttom3J5O07VhoOHcPvR3f Bk8qSodTQiEJpvRCJViBMaH3Yzd5J6z75D1ebE0wGvd5FjYm+uo8of6d/bW0OeIONcZdtF7StW2S i+taXD+s9Va7tCGvu9qC/ZLTsnzQGzIBC1zdERdtokuk9aKQipgsTslSOzt/u0aw6B1OO/zZiHns GcxK2pEUUvu4GQmMoGdkjha//mOYnfLX/DD+7djI2HMwFouFHlZvV2KxKXkpqIL24JUkQVXqvzIz mBUnNd4FhTuOxge2tBkiVQGJKR0zabTuake+qaHBlw2yFEWgeK3eIjCi/d47B3b2BsES4xnBpOfs Zl5l1fcODPSYPFqTG85LHZiX28C8BJAE0nIiQYygx0/ZBMEWHEG/J5sQG8dRxB3Hg88FsWDQHL7b PUzdZ94+kQSiTI2ybaMc4E7dRZHEKcOa2EPBbrPZRr/L+/LhcEvGQ2sp2hbMdsQfejAysK27e1O7 +yyeqbGFrByGf+ByOmJOnmJpk8/v4MBY77qvuGMgGupcUTDlG/WuiBXBETP6LraDtCINyExkMbK7 hUFmoV9CQogePYJEkRnol5FqpBE9ItPqaLVaXR3FA73wGW/ENgeuPneAOFa4LjTrHrF4F59Q49nj 7HMsxrJu+a7s8Pwj7p3j4wUU5eJrFwvN5YyREmPRKTxFOSD6xN2K7BWbFeCf+srNCpWq/ArbwTEN DOWTl+RNEU5DO6yHa/trraG+HX0zN81wx6tsjoDT4gy0Lsk5MtJZhnsrFhKdRjpWJbqMtCvoW2kV atLeiJUm/s7nYm18opi2aDQageEFjMTM4QZ/uKPWIQZrPYE2K1tt9zaajI2JZFeNTaVy3esLaUUH 7wuyom10tSShhGjXWUy03gRt9SLsR9hDKhas+uSJkP5p9DhiRxj0hMwjdiFk4k5Eh72bTdvIbUoa A6ThpWguPeXQL3j1YBl7iJKCDnvARIWi1loXMCcOe1CiaSlodwQkTWRusn52RsJ+rWZgMhGjRpP5 rN87+nDlNa5T0SocB8Xom16vv2luodxz1A56LiIG+MNEj5+idZuVfqLJaY8kUfvlN56448QdKjp5 EOAphsRP+IUJnXCInTteNew3ubdUVKJX1lE5vr2KRrIQSZVAFXsQ5kPZgyV9OCkpYIfd8iWTvtSq bMNg2jRFFzmgi+9WXmMiB/7kUwl/4+xCWQuvKTY5eNJrRQBZPy6zVvpvqoa9vOjcIm5DShEl6OWl c/rC1OSoK3tYygBEX8NIWq2mtYJWa7Y6hYrifMmUV6oKePWcw6jGUeJZqwdcSUKjd0mjz0ztYj34 AEWoNXo36GUDsFAk6GUzMuNJpIAePe2OuWOsZQR95BTCRu6sVh5LlSzF6uwRS4EMDNNHBOkIqRhZ 5Wwf2tppTvUnxQdZ4D0qL4kpttdJYGRoxvKCt6naxYLealSUM5Lz+WJVDTPqQ355YdaVjznAGlBp SJUtlHEEPZHGYmMY35fsTFkYjmcdToOZI3mBM9tNVtEUbsnGWuMmDaNl7C6DSUuwOtZuNFtFKdQC xmrHzqIvkA8C9hM7ifhcVXBGdICduq6r+raF+bbhuugj6pL1vaAkJ527dO7VSe6jVjG22akEWVKI YMmPKI8GvKDRmr1Bw7rlMqfluGa4hBwAX8MceLnV6rG4SFINFrTD4dVSanLFqj95whHndjWjJghQ bHdGwp5fBvwsyVuUNXQWe4g0Au8RP0H54HpHEAdc74KPwsNbTFvcj7MVZ96smIASN0NLhy7TES5p Ct/CHvKmzG69JrE21zA7baJMCv6ocMSSc1KmgM0Blgr2a04HV08hlfI3DRbQPtBPmF+hHv1ZLu/3 ovMrr5VoB30PuwP02IPIEPvvntRoaNMIeuKM7JHclGQcQZ+QWVqybxEpfgu1Fd+JTCJYE/RKWUpl ApXDJ9IBcuPpAOgdKrnBG5YwsvtlGjdEA94qM6saxlZhlBTyesNGVIWBQIsAzPh7GGZy6FQYpRdG z6FoG81TBMnbJOih/2XsHQwh1wNbFUZcZxEJG0HciIjdeYYhA7ZeXQfo3qv/UEmmKKdd4xXtGS5/ LuR1lLZEXe6IhUatrKs2FKpxaUmtJxsO59xarTsXDmc9WvS7lR09/HatUatSaw3a/+gP5708782H IwUfz/sKsG8/HnsL/QVxrdI3N+zbN5W+ffMMo4uA3m1AQNd05y7P9MAn5vqy3v2QNoXdnoiJslL2 2mg046BYZ6YqmHFpta5MsCrjZNG1lBaSZi2FvcIZQNdYA/enmkDazXHudCBYA681cJZH/xf6HdSD 2BDxhA4Zwe48qWdMdkT3ygXQmxdKO97qch5nzjDege9o9HbxFrVg9lodfh1K7tV5awK+tIcfCbXU 5RzP0ZwG3FzHoMaveyOSWi1FgBb6xt4iFhGNE5lhJ5TMsONKZljr4/wS3wjadoJc9pkywxa1HfzR Tbf97b5826FzynX0HUfjUrl+SbPHWbq6MfPuC1+ZM/vo3+2C11l3v3jz3IOLkvH5Bwbn3rw4EVtw AOjBMvYRVkekwGp3nTAxI9j3TyICy4ygN560LyaXgrVz6YKSfzc5nVCtUpX4SS5QemBFxOrK6Z7c TySHoMY1HINKwAAEXVUJi9rDgOWKUzyLq7cxKiEatPpMOvUJQoWjuIaBOTf9CII/DDTUhBSfBKvk gzOZABCk8DT2IcIgYbTxpNtdsI2gu2UqL0i4KrFEVxhBd51QDSFwxwjSLvhslBIFKBtH4ynH5SOg XBN+WZ6HKlPJVFMr+UwPqxiBvuSX3AZKxVsN/1rojgqGqvpQ3aLWmFatBS5cTRnqh/Z1LTuystra vmPRCfT3MGbd6AhZGY056vel/Hb++cRMuWBzVPuMNrcNphoaHZJOcHukUP+2rtTytVvbvsRawjAv bXQMfwCMeBGy/kkkg70qawfmhgZaQwMDoVYc5qf9++MIRz2N7garphPddabRAMSchz/opGduYgQ1 nvZ6yZ4l5hF05wlyRSlNLXmxoLssU00hoIK+oLv4MYc4Sn7eeJhUaZlOTaITxx9o2vf0/o5t83Mc Bb0do2ZSPWtasoN1jkDn+vZNvIEmSFrQXlO3qMEtRdsStYs704yK0ZAYSYmNS3YXlx5ZmXbUzy80 b+qLHZl117UtosPB6Rxxj8WtV9nddlt6RjTambZppKDL6RfV9vSMiLchZnEH3Gox6DJ5JMEY8Fli g7t769f2FzhMlerfBC1NYewt/OeTMfaYgrHHFIztKGFs52fEGP7zmuGTN956fE1VZuvJA+AaGv3A EO8t1PSkJH1iJrhWS5i0+6V7AMb+fvfuC38FsfaFhTcviIXn3jgPXKOhuRBjfwVW93EiA3xg6kkk jH1f5gWnwABBzAa9b3FYGEFbKkv5VQC3c5W9nstWcSYzDfQEJdPmuIrhqEtZgDsVCWrv/MTkEFSY hmMhDM1VrmDSrHmZ4hlytb2UiAcf42OwNdsYUogEzS6JV58iSBxGi5o/PcGYlbOyBaDfZ4FO65AW iMo/nkn6gCC1P1RQGQRr0wmUu/uMlFRFluhqJwMS0qpPgmPwiqyrCTSeBUaUvmSW3EZKpbMY363v CvM9fYXFHSmthqNVWmtx9V555V3LU9aOXUOn0X+nBVZ1GRJTvS0FR90Mu9cODyuCEavfLYV6t3Rm Vm3Y2lJG4VyAwjNghAuQlU8i1dg/ydq+wWCfHOzrC8o4Z4M/0RThZgDrfLK+XspC8HUNxiD43G6y a4kCTwGRyhAs8ckyCJNXw1/2z4Tfme6DI5tbty+sFwD8dDq6eubaltyceodvxobOLVo9S5KMwA7X LWoE4GtP1CzpyrAaJReI0jUP7e9eeteqjLNufqH9mp7Q3Su+si5rtDkFvSNsTwVsLrutuj0U78qM Q8+W7ox56iD0XCpj0GXxSLwQ9NsmoEfX9q8ByFsAvJt9MvK+pSDvWwrysqW85+xnzXu2N+x96vov nNqSbtz75P4bT1+XGX3flRtIZQfydme+P107K2fHrAd/eldP55deOnjLT4/0dN524c71X5ztic0/ uGDdrbO8sQU3Q74MvJudSI57t6+d9Cje7cBJ+xolu/mS8nDtx3i3XMW72eFjA/Cxhickq47E1Frm Nd7iAIsqYda4KZ4iCYqncd1KmjCE/RafRVAdpuDWC4haII5mwd/pQDQgDTBCkbC3J7zbewBHEXRz 2btddyYjqRJroWvbVHqUJl1OPv4crk0Ct4bJrptNTr1apbOKz2Vag7zgrfVV99eHGQ0IrDAVZWya v6mw+PDCuKVl24Kb0f9mFNfYg2ZGLYa9nlTIbzibnt1eZwXMULA4LQBjwK+JOoPHaYz0rG+sWbH5 wOzrc2CkvWO/xTvASBcgOyCevn0Fnn4B8fQ0qkfqEQrNy6zw5foH67F6oV6A8NLLOoCvf9W50evc KITYWmkETY2nYSeHhsc93NC0Lg793BDraN/z18vqVnZXCxSJ6zi6qnFeIdmZtloL85vWagWaIGie uSZeTFt5bzaYGpRjFDydATGtkBu8Rh64cUHcmi7GIf1Cc3P2D4Y50SLorSF71CVaRaOvxuWp9RtU Rr/T5tOrxECtCyjVYHGaVQavQ3RKgs7pMHrb1rRXz25JsrgqKs+pMEgygMBnXQHGROx+UHVh9wGM WdE5j/OD/hF07gly3tUwJk5DIQ+dP/jF5/bkWw+dP3Trs3sAhXQ3L65vXdro8JSuduzwVz/8/tCC R/744Nc+emxo0SMffF17+NTmRGH4ka3gGs9vfbjCIUkzQJn9ScSDHZUpk8CwjH02ORcGHwBiFzIX Pw+B9DE8TQLFs/hvt0ICGbD5TLzmFE4SKK5mlSd1FAYJNNSE9ECM/W4CY79XMLbujJAvlGC2QYHZ IITZwhOqOZNhBi+fi0QqbstTIZGvt86O8qZYczi7oDXOUhwFbAdtaBraNWPNsdXVlp5Dm4+hf4Cu a5MjDFyXKebzJAM+8e2ObcsG/J76mMXpdzG2pE9ymwV9MGDNLN5fbL7hy49c81XovpSnG97CHwCj XgBZZDV2/gq8vVnC23wFb0vPCBWkzS05MkJxZIMAZfPKq+cTWeTnh9gDDfvO3tC+dV4eejFex6S6 145TyI1aAwwsBXbTOIVc1FnNqRWIaaSmoR3ty+5eNU4h0Z2zjmxuNtqdvN4e88R9gHRbU4BBdqTt aqnK5QgYNbZ0R8QLVOkKuDTGoMPsMekUBjlnT0/92oE8h5OpgQkGqTz5G0XOV/IR4mPPneGxXiSO Gp/C7kGQsVdkGr5GUB5H3E+DJhqxlfItbJXzSvgEvMzxgwEzaA0oJ0sBqPGJh32VLHUIU5gpAHQ6 FLXJenAPyo1SNIoZUQx+v23kz/ziUsIO+NrpnicmJpkAAv95evj0zYd+sDacGT79hUOPrQUMlxZd sby3vjeul5LdNVUNcadBjd3+1Y+OL1386AcP3P8fyvXhJXesL0b1ha2PDN92elPUkp65+oYK0yVN gOmeLmcYaakwSoVQTRWK6tGUkvQP9CenUBwJj2BHTzrNjDAy9tpp0CgY9CPofpnyzQ7zOpQhdfAn 68mqOeNJFWnFXUcvnMvAp1OWDUWRIRRmJsnmcAgNg/tMuhW8w6f5PrCglw2VvmdoaOFflm7j3eN0 m9NAuq1Yr/94GdLtMtuGFgzVl3XHETGUiKJUHUoVUEYeKa9FGZVGsN9XDNxT0MCN/ba0LBmwbJgI NHEVa3flEtoga8v2T1lB0ApOaCVaMoXR6LgxVJbouEEEOgeLC4VKN0zpHegVj/+fvDOcmKVD5bst /KyG+LL44ZdtsxOCGG6K1C+ekdBSWg2Jq2hL28qdMjTE5pm3bT2Gjl7VEAdcrD3pNblMgjngMyuG eO8djw5/tRxHwHxpaIdBIFfKkNB0onQHyiyqTNoitHoEe/Ey+/wU9hYwKb85Bd/AwSxlZRI5oElo tOddZrRLCs1WFDrJistCyYxDuyApuoUWfYpdKNt1qN5xyw6n9pXoVPNemmCbrC0PAHScx//ynZmY 7YWf38FUwqQ6/WcKkxQavHRfcXKYhO5b8ZW1tQa7U2e0hR0wTrJZk23heDEzycF0Rj31UeBg3Gpj 0AniJJ0h6LfEBvfMLDkYTe3AmrExpBF7CnuP/GdMTZAA6feAFgf2I/QY+U+gRVVuacL+HtuvvEdd bsmDTw0rLRrYAvxU41gAew8bUOIt71nEiL4J4y30TZmiLT/g9/h+QF4/mQYGLnMB6stYIPZedP7B hUM3zw6A64KlN88K/lT017j9GbfO6K91+TMe3TPL7t2QL6z/ytDSYxvzhQ33rOpbWZBsdcta+1bl wXUpZCKOsRR6DOsGHNABOCD6pEwrHPBt+25yXznOUkggeZU4Cz1GSSGnE1jM3YLIkpiKpr5HskaX xeHTE6cqe/RYU50G0zotBgvA63qMwFCcVJOwD01jWWw/0EwWyT0J4tCG03FP3INkRrBFsp7yPbzF fqMds5v+MbSHrXkM36vwvvIZ+4Xy2Q+pPMn9qTYpJGy/lh+1CmZOBfrIH/QlLFQq4aoJu0BAoMbV xkRLX7R9TbuHSy7sKaIRVn99xE/qnFazx27WfcGXr44agwm9qNcYPTaHx2iReFdhIOmbMbimvQ3m EeXBPA+D0fQh8wAPQd+RtR1d/o68v6PDn8c5ywhWJ9sRrvE7tbLRUqxNfa+lO/INp5Ns2UMdF6Tv w0UwsSExfsZ11f2I7OU4y46PPzgBMhXEGDZcu3hfR6In76HUBMawake8IdDcpg81RhsZVoMTwLHJ xY5UjacQc2m0NIaTbKxpVrJ1dYu72BNqT1od8lCjk9HxlNbgtrjsnMAl4lLAwqoEhyRaeVUm4Y/o JJ2zSjDzNGsWeUdNd6xzpR7DnclGyNeSY/+G3YLdO4GDUwoOTkEcPMgf8D1EfuFq4dAVOLjF171t YO7Wdru3a9ushdtarS+w5pDNErSwnDVocQRNNNrVf2BROr3w+p6e/Usy2SV7u3O9KUlM9mSb+uOC KdUDZi0w9hH6LexugAM3xMFTMmsSbmRQGA4dIG8qh0NDHxsPjUPhWxpTyOUMAyjoJZZAVYzmOMHo 3SAiMJBGNbBrwIGp0X/IqwnGZhHMeoZchWEYipEqAvQiBRTUBnSTReIQCcEzEAlxCIV6maJMj4YO aGu+iSNJmG05Nd75DOu/TcuOtunNHIlTAncDJDgxvzNVZadISkWo+Uh9b6wZzLEuUszNQlU83xF0 E4LHpreKovZaW8jnNTiCnJ5X610mm0UnGlhbdUfE1dBSDMtw/fvA/BbBGGYhO+H6f1vWFnv9xTp/ seivw1mw/kNyGmFra8NISpfCjKljbUgYlcJHXTwPYmOdCyu87UKPu1CXi2w78Kzxx0bMeK+yJIYg KIa3Lh1SslKWDsF/Sp7K9PggruKIslMVNOGGAEKKicHtHeHOfEivYWjKFq6LuGI2LefNhZtprVpJ 1m2XmyJpR03UqQEqA2xQxUSaBhKNQ80uwZvxRprDxufSfbV2ihP0fpfbqNVpWYOV1zuMNMlZDAaz lgj7bAFe4EnObOBFTkOLelaKyiF7OuTUEJaqDPAgSWwndgvpAh7ECFbFYdASwG5Cv0VaQYtYbklh h7E25T1SucUHPlVUWkywBUDr6yVBez+lPPH5BXNMI69PFnzOf7Kc/XghfJNkfVnOTydk27h84yry m5KoHJPkbtXohKhnXlVeLIlm9iQ5WpZffbJQNZcL7b6KnJkQ5jBzmF09IdrUX1647Lj8tCJ8/6eW uyaLzvwZ5FhJhI0Tot9UEgN2VTkxvRjjn0K+Nr2ILJANQF4SX5IOS2+UxCQAWVeWp8wp863mX5XE Uvdf8l/y/6x8cYr8j5JYmf9vZKH1AZtoe2ay2Bn7OvsvHHunyH93Ms4bXbFPlH2uZ9x592uTxXOj 1+n9k5+bIia/2x+Gz2FNK/v9zwaCgTPTSxANtge/U9U9RQarllStqbr2/64gys8XQ3fCnEHkOYRE vosQSJ3yu+p7xt5ACPT+sb8B5fmx5xECn4tYEDNCjP0ElHVjv0HM+Nyxl8G7CViC+u+QHlB/A5R1 sA7/F8XAN1wE5fmx/4nqUGzsD6gTtLwLyvOgfQC0vApK3dg7oHSO/RaUA4gAyvthC7ijE12kfMMi 5Rt2KvWdSv128NmXQakb+zUonWNvgXJg7Dfwt7OPvQnK8wiF3g76sBH+tnbwv0fAp15H7wef+h0o dWP/DEoneOf94H9/g54H7a+DUjf2L6CE33YefNvvQHlk7D1Q3o/QoDwPS/CdB0HPCMQJyjokjs8F 3/Ar/H38j2P/hr9PqEH5R/z9sQ/xPxLk2IcECdsJErYTathOqGG78pPf45gXqfx+9tVKiSszwimv YB1DNHikXMeBlolynQDat5brJKg3lesqUJ9XrquRj/Bry3UNEsHfKNcpxE2sL9dp7KHxezHIPOKL 5TqLRIjXynUtdi+pKdc55Br1Q3DNKH/SGrZcRxG1pqlcxxCC+ka5jiMO6s5ynUBY6r5ynQT1R8t1 Fag/Ua6rkf3U8+W6BhGp0XKdQnS0XK7T6MD4vRgkSg+U6ywi0vvKdS06kz5SrnNIlvnfrJwNfFPl 2f/v0/QlTVtw6vMIPjyYbW6i09KxyRgwrDgdKlJEQWR+oKFNIdCXLEmhYCkVX6azA7Ro+BTEFrBY UGQo22BOwsC0RVp4qFtTaEhNQ2PZ0bXFlSJdz/97zklL0W7T5/n33jc5yXm5zn3d1/W7rkPrmrkT KTo+4md9W/ezvq37Wd/W/axv637Wt3U/69u6n/Vt3c/6tu5nfVv3s76t+1nf1v2sb+t+1rd1P+vb up+rhFmM48k1hadWs3hA2ESGcIg84YQs4eK7u9hyCLv2auEbG1u5Ipk9d4pshlnM4rtFYjH7nNon K+9Wjl7GayZH3sV52RyzkO9sHGHTjrNADtfK1I7N5ZOT73K1ffr5Nu7ADBaOs3GFFXxazpYLW+ox +VzRxfdWPqn3nM/ZmezP5W7Uq+RFruriiJyITfUIM3PM02yqVpzaXO7V5prFN+oc8/neqp3h0L7J 1u7aFZlHBntu1a6co32TrV3Rgo/07/ut5HCdbM1j9shd5vJNjmZVv6Y6T9egO1At2rW56P7u97Z+ 76qlPDxgZv66x9W7yuFYC/Zd2id1xq6B9dB9plsxa/eeG5lXnubbhdqRl+948IxUrxVo5+mzXsrn ZC0eBq/mTdrVcrQrrND8kB9Z+cH+VldMn79Vu391/vq6OLRoUN91i+pam7mGfWA2+j0uihzj5NPK yNVdzEJfoWUDq2TRYsTCtzlXzKs/mjO4E4tmPyNiP3mIqJ/4pXmaxVT2ZXO1iQMZc7uYE4kgWyTW blf/2oxx5bm3DZw7dCZYIzGtz9ASmdMiba9+j9aIF9X7ztSiWZ3DUm0d+88Zem/W18rqyxGkr9ds Ptm0e1DtP6RlgOuKtR0buYO8QTPIiOSiS5ulVYvv6XyTIcZo634zx2Rq1/+Zdlf6uS6GHe+OZSzX RrKW91feebJ29RyOcRFv6v0v0mZg5wor+FZd1SxtLmo2XXnV/u9VRdFXYOnA9R7V7lmP5BVaBDq1 O3RpuebUtEE/26zNQc1TqxZlNs2G7qGF2rn93rsb/01HJfVzHYP26Dmeqfnkct4u12xlaHk9lF39 s3psBlGUr/kwcyAPMrX9qtLoM+iPfbs209xI9OvXsmqvajZ/cd7qfl01xnDWzVp05jAv60Aef/mu cr905a/uo8tX71duc0R79ejJuEIDvzz3y/F65X1NGuQBdSb6XPRK0B/1joGqkqnpaq6mr5Z/OlPd z5YrfGqNRP8Xc0D1qhp5+dqZmZpGqbOxDlxHPTJb07l/tUL/v/Lick6M1e5GzQG9OiVra2UXBVXm cSkp480P2DIcec68LJf5rjyHPc9hcdnycpPNd2Znm2fZFi12Oc2zrE6rY5k1M/kuS7ZtocNmtjnN FnNOXqbVkWt2WnKdZvbbssxZlhxb9grzcptrsdmZv9CVbTU78vJzM225i5zmPA51WXM4MzfTnJHn yLU6nMnme13mLKvFle+wOs0OqyXbbHNhI8N5q9mZY+EOMix2ttVTcvKzXTY7l8zNz7E6ONJpdWkX cJrtjjzuW71trp6dnbfcvJgbN9ty7JYMl9mWa3ap8+DOOMWcbcvFVl6WeaFtkXZh3ZDLWuDiZNtS a7I5Ms2bnOYcS+4Kc0Y+k9fv27UY+9blZoeFuThsTJsTLTnmfLtqhisu4hunbSWHu/KY0DJ1Shbz cosjR7elujljscXBjVkdyQOun9hv0zw1Lztzorowt8/BQUzJfHtySkpk723q3kGLYMXTGLRgaZFN vSMrt+iwZFpzLI6l5jx1z6CPWUMvteYg5jU71+bi/IdcFpc+27FcIE8zkMEquhw2qzN5en7GGIvz ZnOm1fwzRx57XS77xLFjly9fnpzTf/HkjLycsa4V9rxFDot98YqxGa6svFyXM3Koup1lYQJL1eMe zcvHySvM+U4rN8GU1N1mC2tqdeTYXOoNLVyh3d7ds6ffyV6H9oEVz8zX13b5YlvG4kHn8m7LzcjO z1R9kWfOtDnt2RhQvW932Dggg6Osua5kc7/tvFxCY4ztZrM1Z6F60uVL5fYfPOQdaYerwY37nbgn Q4/AAeuaXyPXmqTdwBgbVkgC1fUONVUy85bnZudZBhvlni36neL4gRXIy3fZ8124fZktw6oes9ia bf/ChL7KWmgrMTbTmmUhnZItTntB5FlRKA+IA2KoH4kjeNoQw0WcovAaFXnCEtIY3ov15/1/8RMd /c3ERIljpNe/6vFJSerxUV/5+sOHa8d/5etfdZV6vOErX/8b39CO/8rXv+Yajo82qE/kRhGtHa8+ ZV+vvY4QSaj79eKn9NL3i8lSlLhXuko8LI0WC6SZYok0TyyX8sRT0jLxglQiNkvrxQ6pTOyV9on3 pGpRa7hP/MUwW7QaZCEbPhEXDZ9KsYa/SdcYLkhmQ490i+GipP6fnE650r409Wvafxr7pdjfgv0q 7L+D/UPYP4b9JuyHsd+B/X9g34T967B/I/aTsT9Bs3eF/ainBtm/Dvvfwf4PsH8f9udiPxP7duwX Yv957Jdhvwr7+7B/CPt12D+N/TD2uw2zpRiDLA0zfCKNwv4t2J+A/XuwPxP787CfeaV9w8eD7I/E /hjs/wj7M7Fvw34+9p/A/q85ezP238D+u9ivwf6H2G/B/qfY/9xwnxSP/ZHY/xb2v4/9VOynYX8+ 9pdgfxn211xpP2bJIPv/hf3x2L8H+xbsF2L/Oey/jP1t2H8b+0e4yp+xH8T+37DfK+2TEqRqaQT2 x2D/x9ifiv1Z2F+IfQf212B/LfbLsF95pf24qwbZ/2/sT8T+/YzF2H8a+6XYr8D+W9g/hv0z2O/A fp+0XkqUyqTrsX8L9idgfzb2F2H/F9hfg/1S7G/H/j7sH8J+HfabVJ0wxinGuBEjJt+YVZSVZYwT RmPPMS8/x3qMBmGMTtd/PMZ4YTQdKm5lXCj+c7G/uJahHV7o1X4KY2NEbGzHiAKfryA2WsTG2D38 2LVv7b4ej6fAGMtmoc9n9xT4Oowxwhjr8XT41B+j+u8wnsiPfh3t+1iDiI1u0b/VL9liT2mJi1bi otM71NtK0Q7Wji0wRjZn2lPS041RkjFaO1F4PNEGJcqgTUI1atcO99m5HWNsin1PCj+9+p6NI0ak pHt6+j/YR4zYaI+JEvGGVE9qamoMGhvtMacWt/RvmT2aByZMyM7O7vN6jbGS6j3tp8cYjfdS9J8W Y7xkTPiy9yRj/L/xHi6LKzjW6/EUXuG9+FgRH8cBurF49RY9A/5Tz9F3aFfq+KL/1DuLSe93oHq0 dnDhFQ6Mj5LidQde6UGcxg1pPwXahwEPantKEhNx4cCHgsTEkgK8ZTKkt3B6TLQwRbfg4o7+rZSW +HgRHz9KjCLbxtMvZ4jV4lDxoeL4OCk+Xo9EQjE+WsTHpPR7Mz5Bik9q4aez5X/STzOOptcz4o1S vGly1mH1J2tyXKyIU2+hkJnFxUhxsfYa5lJjj4uV4ozMoNdzpMDEdlyhT3Mq8+GjyTjg1WOmKMkU PeBWj3ZiZFdctBQXcaxH3Y7VPMudxXCf6ek9Ws5M0M7QTyg0xXE7Xi+BMmHCiJQU9doxnkH+FVFq qnm0hY3491iB9ini4JRefZ/uYc/lT/0+Toju93FCTL+Pta2UFpNJmEyJYjTjBwxL8WqGatpklEym 3r5q1WXVfb0mVmXAzR0tpkTJNKzF3sFP0x51HE85nuJlmOIlU8IUVqq1+FBktBavFlOE7qNenN6r OT2uoEf1Z4Hu9F6c3osn2C5Sp+ch+AsT4qSEePVemvu0xU6IkhIGed0Tx+HxkX3aOqpaMuD2Dk86 N6q6PRa3q34vmKCdoR3ft8xkFHFGwiFr8mRyO0W9eL/br/A7y2MyFupWvH2FWiSkdHToju+N7H0m VnV9X9/Ax8Ki2Gf6CuMMIlH3fXp6XLRIjElnwfC/tt3CJoGREC8STP1RPl6Lcj3ODxUnxEsJCX1C EYcHnHmo+HCxIvpYPpEQOyLys7HHnpAkJQxvmdAyoaOgo0AVsbqNdRuPb6weUT0iwSQlJN4hVhd/ NMh3H3lWF98hNFkq6C0hE3qz1Q9xBb1HPJ4jvQW6AvV5+zx/6lMXwmgs6jvWW+DpLcIHiXFSYmRh 2jS3JEZJiYNXxqOd3r/XGCMZWRtdrdUP6tp3FIzo6TDFCFP/6rA82lkRRy9LMKKf6vpEFigxKiox dsDA4BXS4qR/hbi9hNiohPj+JWKNIvufiY0s0sDnwsJYbZWilaToSC4RR0mqwKtiHxcjknSx32hP TBCJicPEMKq/Or5f/P3i1Z7VnnQP/0tPNEmJiawTqzPYCYeKleI+FlokDqyUulSJw6TEb7SMahnV Mbljsi/bl60mdHVJdcnhxMOJiQlSYtINov/K/SMdWzcITfnUGy9SHRQfK8UbJxSGsBQqnKBLXFH4 sOL5aPWURFU6WXORxSgSk0U6r8QRFIoko5RkUm/wjNKqSeLhpCgpKWbwrXu0yw3sj4+R4uP6V9Cj GSZQWgpGlfQWJMRICXH9a8giamfqp1Urj2s3ooZthqbgaoSPEomMEWonGxWVdHlJ1TWNMUhRMeqa ehKNUqI2H+0nXDRZ+2JEQc9G3ZGKon2hL6u6rnwR1//FwMKKYTGXF3bY5YXVt9WFFZEnApMokEzC kLHCkS2uXeSwLhXjsi2uXJHKHumhWVPN4lqeshTt+Sk2siWJOK0n0z/RqYirRNSstAfM4vqHZ91v FjdG9qhPYPoWKhrZIn9FYobdaRf3aa8ztdc52utj2utC7XXxUqsjV+Rqry7tdaX2Wqy9PqO9lgw8 1fy7V+nfvEYxt2GRT1dpM5JEMpi43zFipjaDaLGGJ4KUqJliddT2qEZRbnjF8Ir4kAfEzao3ogqi Px9qxKXEpZheTCy/PJIq9aHu+eIY9uzV4wdGM6P76u5rHrvmseteVMf1735xxKX8197RNTe8qI9v PnV5fGuLOm4aMeRY+73t/WPs0XGP9Y8fdetjYsmXx6TKSZWTN/xkyeUx5UZ9qHu+OKZ475D7R+qM fzLmph5NPXrnZ+q4cs9d3x1qTKq86+O7r777HX3cs/fy+NkedUzbPeT47N5P+8d9zfdv7R/T39DH AyuHGjPenfHuzGEPFg8aZ9TvvjhmGWcOmzlsllE956EX1fFwS//QrzRnypxpc+bN2TCn/hHjI1Pn THlkujq+aG9u5VBDvYeZw+bKj0bpY960y0O19fMy9XWWUeWxjgUz+ofljYWV/cMarY+sU1mnFl0F UxgFi7YuamZ7K6Nv8bTFL2rjw8Vdi7tsKbZ5jHRbke0dKLIdsPUsGa8OW9GS7CXPMF5fsnfJ75cE lwSXRi+dwUhfumTphsj4bbY5e232O9nBnFsZ43Nm5jhy1uecjIxQzqc5vbkTGdPyrs9bn9eljl/s cczXRq9zi7MmMk46evlc4+zQPnW4vuv6rrPGtT5/dP7k/PnLRy0fVXBgxcO/2KMfzXuHftSKc+px K3pWjl+5eGXZSs/Kc+p4fMLjRdrY8/hfCq8tHM37nsIUxpLC7YU7C0+sGsaYvupljpuw6t1V7xam 8PqpurXq3SJRdH3RtCKHNuTVU7XhWr1l9RFeXavrV3esrueI64uHFf+weGLxs4z6J0SRzLH1+p4n vrW6fs6UJ6atWbjmsyfXPj396TlPpz83viR1feUL9v730vtK73MnbjyzsaPs6rJRZfPKCsueKVtf tqXs92VHy+Sy7k1i07BNozaN2zR5032b5m7auunIplObb9w8bvNPN6/cvGFz/eaPX/nuKw+/snaL cUvylswtZVve2FK/5eNXb3k189XKcnP51PLs8mfKN5b/qfzD8r6KaRVrKpor+raat47bOnnr/K2L t/5q67Gtfdtmbluy7alt7207sT1q+6jtWdvLtwdfu/W1rNc2vvaX1+TKb1WmVq6tPLbj6h3pO7bs +PD1ZeLX4mrlY3ENXAv/Af8J18FNSliMgZvhFvgeqH9NMwnUv6eZDg/ADEiDmfAgzIKHYA48CplK urBCFixW/MIGS2ApZEMO5EIe2OEX4ACn4hYuZY/Ih2WwHApgpfKoeBwKYRUUwQuKT7wIpbABXoKX oRJ2wOtQBTthv7hZHICjbH8Ax6AO6uE4nID/gZPQAB/Cn8EHrcpKEYKzEMYfH0M7nIO/ggyfwKfw N+iATuhSKsR5Zb/4DP4O3XABLiq/FJ/DJeiFfyi/VP9KSdoEm2ELvArlUAFbYRtsh9egEnbA61AF O2EXvAFvwm54C/bAb2AvvA3vgEepV/8WSqqBWjgKHyiHDQ8ob6h/HWWYK4Yb5ik/N/xc2WqYz/sC 3h1K2PAevvOJaGYVA7EQB0aIBxMkQCIkwTC4WgkSYUEiLEiEBYmwIBEWJMKCRFiQCAsSYUEiLEhk +YksP5HlJ7L8RJafyPITWX4iy09k+YksP5HlF/MVWSyAdLDAQsiA1Uq3KIYnYA28oHQRHV1ERxfR 0UV0dBEdXURHF9HRRXR0ER1dREcXUdFJVHQSFZ1ERSdR0UlUdBIVnURFJ1HRSVR0EhWdREUnUdEp /MolcQYC0AIfQRBa2ReCs9DF/Z5nfp/B36EbLkAP+y7y/jlcgl74hxKUopSzkgGiIQZiIQ6MEA8m SIAkuEoJS9+Aq+EauBb+A/4TroMRMBKu57qjlTPSDWCGb8K34NtwI3wHvgs3wRilVroZboHvwa1w GyTDWEiB78M4+AH8EG6H8fAjmAA/hokwCSbDT2AK3AGpcCdMhbvgp3A33AM/g2lwL9wH98N0eABm QBrMZi5z4BGYC4/CKu67CFZDMTwBa+BJeAqehmfgl/AsPM85ZbAJNsMWeBXKoQK2wjbYDq9BJeyA 16EKdsIueAPehN3wFuyB38BeeBveAY/ygXRI8Ul/gsNwBN6Har6vgVo4Ch8oH5BlPvEkGSaTYTIZ JpNhMhkmk2EyGSaTYTIZJpNhMhkmo7ENaGwDGtuAbvrRzSC6GUQ3g+hmEN0MihVKPdp5AO08gHYe QDsPoJ0HyBaZbJHJFplskcWTZMFT8DQ8A7+EZ+E5+BU8DyXQCiE4C11c/zyR/Bn8HbrhAvTw/UWl kehuJLobie5GoruR6JKJLpnokokumeiSiS6Z6JKJLpnokokumeiSiS6Z6JKJLpnokokumeiSiS6Z 6JKJLpnokokumeiSiS6Z6JKJLpnokokumeiSiS6Z6JKJLpnokokumeiSiS6Z6JKJLpnokokumaiQ iQqZqJCJCpmokIkKmaiQiQqZqJCJCpmokIkKmaiQiQqZqJCJCpmokIkKmaiQiQqZqJCJCpmokIkK maiQiQqZqJAlL5lZzXsN1MJR+ECRDbPR2nkwHwW9UwznGe4mPDoGboZb4HswkT2T4H62p8MDMAPS YCY8CLPgIZgDj0Imz0RWyIIXiJYXoRQ2wEvwMgxdOUdTOUejkX400o9G+tFIPxrpRyP9aKQfjfSj kX400o9G+tFIPxrpp1p2Uy27qZbdVMtuqmU31bKbatlNteymWnZTLbuplt1ETTezv2iYRwX6uZhi mM/7AjFFTND+XjcGYiEOjBAPJkiAREiCYTCcO1b/sncSZCqt5Ecr+dFKfgTJD5n8kMkPmfyQyQ+Z /KgjP2rJj1ryo5b8qCU/asmPMPkRJj/C5EeY/GghP1rIjxbyo4X8aCE/WsiPFvKjhfxoIT9axH7l U3EAepQO0adc4NH5giRAUi6of01smAvzlPPM0MQan2eGJvFXZljCDEuYYQkzLGGGJcywhBmWMMMS ZljCDEuYYQkzdFNbO6mtndTWTmprJ7W1k9raOXSsKBvwxoavFSvzlbPU2LPU2LPU2LPU2LPU2LN4 K4xnuvBMF57pwjNdeKYcz5TjmXI8U45nyvFMOZ4pxzPleKYcz5SL9VpNPkHcnSDuThB3J4i7E8Td CeFm30bYBJvhFdgCr0I5VMBW2Abb4TWoVI4Tq8eJ1ePE6nFi9bjYxfdvwG54C/bAb2AvvA3vwD74 LfwOfg/7ld2s2G7xB7bfhT/Ce3AQPPAnOAxH4H3wQjXUQC0cVU6SFyfJi5PkxUny4iR5cZK8OEle nCQvTpIXJ8mLk+TFSfEXzmkEH9tNvJ+C09AMfqLmDASgBT6CILQSqSE4C2H4GNrhHPwVZPgEPoW/ QQd0QheRf55M+Az+Dt1wAXrw+UXW+XO4BL3wD+jje0U5QcSeIGJP0I/U0I/U0I/U0I/U0I/U0I/U 0I/U0I/U0I/U0I/U0I/UfI1+RKYfCdKPBOlHgvQjQfqRIP1IkH4kSD8SpB8J0o8Eqfcy9V6m3svU e5l6L0vp4tuSRcyWFvKeIcZImWK0tBRWce0iIHPpA8L0AWH6gDB9QJg+IEwfEKYPCNMHhOkDwvQB svZ39i/Ai1AKG+AleBncqPBs5UEydoGWrWSqIRtluJkM/Dva0o22dKMt3WhLN9rSg7b0oC09aEsP 2tKDrgTRlSC6EkRXguhKkJX8jJX8jJX8jNX5lNU5z+qcZ3XOszrnWZ3zrMwFVuYCK3OBlbnAylyg ZpylkzhHJ3GOTuIcncQ5Oolz1BGZOhKkjgSpI0HqSJA6EhSx+Gk4fhqNn4bjJxOq043idIuR2n/t EAOxEAdGiAcTJEAiJMEwGI6Kr9D6g3ayvJ0sbyfL28nydrK8nSxvJ8vbyfJ2srxd/W8o8FinlIRG 7UOj9qFR+9CofWjUPjRqHxq1B43ag0btQaP2oFF70KZKtKkSbapEmyrRpkq0qRJtqkSbKtGmSrSp Em2qRJs60aZOtKkTbepEmzrRpk6eMtt4ymzjKbONp8w2njLbeMps4ymzjafMNp4y23jKbOMps43V ame12lmtdlarndVqR5u8aJMXbfKiTV60yYs2edGZI+jMEXTmCDpzBJ05Qk28lpp4LbnvJfe95L6X 3PeS+15y30vue8l9L7nvJfe95L6X3PeS815yvJ0cbyfH28nxdnK8nRxvJzIOExmHiYzD5HgDOd5A jjeQ4w3keAM53kCON5DjDeR4AzneQI43EEXVRFE1UVRNFFUTRdVEUXXkGaOaSKomkqqJpGoiSf2v RNrI6TZyuo2cbiOn28jpNnK6jZxuI6fbyOk2crqNnG4kpxvJ6UZyupGcbiSnG8npRnK6kZxuJKcb yenT5PRpcvo0OX2anD5NTp8mp0+T06fJ6dPk9Gly+jRdoJ8u0E8X6KcL9NMF+ukC/XSBfrpAP12g ny7QTxfopwv00wX66QL9dIF+ukA/XaCfLtBPF+inC/TTBfrpAv10gX66QD9doJ8u0E8X6KcL9NMF +ukC/XSBfrpAP12gny7QTxfopwv00wX66QL9dIF+ukA/mnMazTmN5pxGc06jOael+eJ68uk28mkB +TSWfLoN3RknZZGBS9GgfN6XwXIogBWwEgphlRJAlwLoUgBdCqBLAXQpgC4F0KUAuhRAlwLoUgBd CkjPcc7z6n8dxPuvYS2sg/Vk1QvwIpTCBngJXgY3lCl1dK91dK91dK91dK91dK91dK91dK91dK91 dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK91dK910j7u5bfw O/g97IcD8Ad4F/4I78FB8Cg7UK1dqNYuVGsXqrUL1dqFYu1GsXajWLtRrN0o1m7t+ecoPe04lCOM coRRjjDKEUY5wihHGOXwoRw+lMOHcvhQDno98U064W+iIM0oSDMK0oyCNKMgzShIMwrSjII0oyDN KEgzCtKMdi9Bu5eg3UtQjXpUox7VqEc16lGNelSjHtWoRzXqUY16VKMe1ahH59NRjrUox1qUYy3K sRblWIvOT0fnp6Pz09H56ej8dJ7khoun4Gl4Bn4Jz8Jz8Ct4HujlUJ0GVKcB1WlAdRpQnQZUpwHV aUB1GlCdBlSnAdVpQHXuQHXuQHUaUZ1GVKcR1WlEdRpRnUZUpxHVaUR1GlGdRlSnEdVpRHUaUZdX UJdXUJdXUJdW1KUVdWlFXVpRl1bUpRV1aUVdWlGXVtSlFXVpRV2eQ10Ooi4HUZeDqMtB1OUgyvIY yvIYyvIYyvIYyvIYmR0is0NkdojMDpHZITI7RGaHyOwQmR0is0NkdojMDpHZITI7RGaHyOwQmR0i s0NkdojMDpHZITI7RGaHyOwQmR0is0NkdojMDpHZITI7RGaHyOwQmR0is0NkdojMDpHZITI7RGaH yOwQGdJEhjSRIU1kSBMZ0kSGNJEhTWRIExnSRIY0kSFNZEgTGdJEhjSRIU1kSBMZ0kSGNJEhTWRI ExnSRIY0kSFNZEgTGdJEhjQR9XuJ+v1E/X6ifj9Rv5+o30/Uv0nUv0nUv0nUv0nUv6n+94FU5qmG nyvZVOephgW8FyqHDKuUVw3viR8YWpUKQ0jcZjgrxhnCHNuu+AznRIz4ifbfKcZALMSBEeLBBAmQ CEkwDIar/30jVXzSkP9qECaiw0R0mIgOE9FhKv4BovogUX2QqD5IVB8kqg/S+wfo/QP0/gF6/wBd QZCuIEhXEKQrCNIVBOkKgnQFQbqCIF1BkK4gSI8t02PL1CSZHrObHrObHrObHrObDqZLOsZ7HdTD ce05UH1SCuKZTnqv4Ximk/5ruHifWecz63xmnc+s85l1PrPOZ9b5zDqfWecz63xmnc+sXcz6aWb9 NLP+nFl/zqw/1/q1Fcx+Jb3W41AIq6AIVuOtYngC1sCTynpmuJ4ZrmeG65nhema4nhmuZ4brmeF6 ZrieGR5hhkeo7t1U926qezfVvZvq3k117xatIk6wTuIsfI2nYqq1j2rto1r7qNY+qrWPau2jWvuo 1j6qtY9q7aNa+6jWp6jWp6jWp6jWp6jWp6jWp6jWp6jWp6jWp6jWp6jWYap1gGodoFoHqNYBqnWA ah2gWgeo1gGqdYBqHZDG0D3S8Uq3wPfgVrgNkmEspMD3YRz8AH4It8N4+BFMgB/DRJgEk+EnMAXu gFS4E6bCXfBTuBvugZ/BNLgX7oP7YTo8ADMgDWYzlznwCMyFR+HrVtznOWc91eoFeBFKYQO8BC+D G8qwtQk2wxZ4FcqhArbCNtgOr0El7IDXoQp2wi54A96E3fAW7IHfwF54G96BaqiBWqAaSh8Q/bOV G8gGdEJcSzbcZpjP+wLes5VdVM0GKuZwcftAJcykKlohC/T87iS/O8nvTvK7k/zuFCtENNH/PtH/ PtH/PtH/PtH/PlVrJFVrJFVrJFVrJFVrJFVrJFVrJFVrJFVrJFVrJJVoDJVojOhhuw8UMVISIMFM MUF6EGbBQ/Aw2ESa5BXXoXYLDHPEZGaRyAwSDdki17AaVXtCfNvwpBgtCv/Fv2x0UPs7qP0d1P4O an8HNV+m5svUfJmaL1PzZWq+TM2XqfkyNV+m5svUfPmf/tYgE6yQBU6UbyhvrVRO4alTeOoUnjqF p079i39BO0PdPkPdPkPdPkPdPoO3THjLRN0OULcD1O0AdTtA3Q5QtwPU7QB1O0DdDlC3A9TtAHU7 QN0OoBUX0YqLaMVFtOIiWnERrbiIVlxEKy6iFRfRiotoxUVq9cdD/nvsReb2OVyCXvjH13gCX6U0 k0vN5FIzudRMLjWTS83kUjO51EwuNZNLzeRSM7nUTO37dMjn1GqogVo4Ch8o5wxz8ck9X+t3SuqT 90SerCfBlSv316HjXPmE1Wti9ZpYvSZWr4nVa0LVL6Hql1D1S6j6JVT9Eqp+CVW/hKpfQtUvoerq 73J8dE0+uiYf3m3Auz6868O7Przrw7s+apofDx/Awwfw8AE8fAAPH8AT7XjiEzzxCZ74BE98gic+ wROteKIVT7TiiVY80Uqdk+kAZOqcTAcgk9U90mg8swDPLMAzC/DMAjyzAM8swDML8Az5A0kwDIYr c8idBnKngdxpIHcayJ0GcqeB3Kkhd2rInRpyp4bcqcGLv8OLvyOHasmhWnKolhyqJYdqyaFacqiW HKolh2rJoVpyqFao/3qwANLBAgshAzJRACtkwZNKKp5NxbOpeDYVz6bi2VQ8m4pnU/FsKp5NFeuV o+SQgxxykEMOcshBDjnIIYdws28jbILN8ApsgVehHCpgK2yD7fAaVNLL74DXoQp2wi6+fwN2w1uw B34De+FteAf2wW/hd/B72K+4qeNu8Qe234U/wntwEDzwJzgMR+B98EI11EAtHFXs5LidHLeT43Zy 3E6O28lxOzluJ8ft5LidHLeT43bxF85pBB/bTbyfgtPQDH76iTMQgBb4CIIQVvaiCXvRhL1owl40 YS+asBdN2Ism7EUT9qIJe9GEvZGoPUnUniRqTxK1J4nak0Tt8aF0ge4sTHcWpjsL052F6T+s9B9W +g8r/YeV/sNK/2Gl/7DSf1jpP6z0H1b6Dyv9xwz6jxn0HzPoP2bQf8yg/5hB/zGD/mMG/ccM+o8Z 9B/Z6E8a+pOG/qShP2noTxr6k4b+pKE/aehPGvqTJs1UcqQHYRY8BA/DbM6fA4/AXHgU5otv84R+ P0/oa3hCn8cT+gKe0GfyhO7mCX0aT+huntDdPKG7eUJ384Tu5gndzRO6G41LQ+PS0Lg0NC4NjUtD 49LQuDQ0Lg2NS0Pj0tC4NDQujSd0Nz1DNk/obp7Q3Tyhu3lCd9NDFNBDFNBDFNBDFNBDFNBDFNBD FNBDFPDk7ObJ2c2Ts5snZzdPzm6enN08Obt5cnbz5OzmydnNk7Mb9fCgHkdQjyOoxxHU4wjqcYRu eR8K4kFBPCiIBwXxoCAeOuiX6KBfooN+iQ76JXqGqYY59AePKDvpHWbTO4yk6n6H3mEklfc79A7P ojIuw3tKmaGVZ4uzwmRoUw4a2sX94r9RnlqUpxblqUV5alGeWpSnFuWpRXlqUZ5alKcW5amN/Mal BTVpIfvDZH+Y7A+T/WGyP0z2h8n+MNkfJvvDZH940PNAt/Ybr7nqv0VhtRSrpVgtxWopVkuxWorV UqyWYrUUq6VYLcVqHnoXQO8C6F0AvQugdwH0LoDe+dE7P3rnR+/86J2fO9zDHar/0uhD73zonQ+9 86F3PvTOh9750DsfeudD73zonQ+960DvOtC7DvSuA73rQO86hFPEM1MnM3UyUyczdTJTJzN1MlMn M3UyUyczdUZ+61GBzlWgcxXoXAU6V4HOVfwvf+tRjs6Vo3Pl6Fw5Olf+v/ytxz5WYN//4bceVehc FTpXhc5VoXNV6FwVOleFzlWhc1XoXBU6V4XOVQ36rUfVEL/18KJzXnTOi8550TkvOudF5wLoXACd C6BzAXQugM4F0LkAOhdA5wLoXACdC2hVuI+IUuhtBEgQpaxDu9ahXevQrnVo1zq0ax3atQ7tWod2 rUO71qFd69CuUrSrFO0qRbtK0a5StKsU7SpFu0rRrlK0qxTt2o52udEuN9rlRrvcaJcb7XKjXW60 y412udEuN9q1Ge3ajHZtRrs2o12b0a7taNd2tGs72rUd7dqOdk0epF0L0C4n2jUb7fKiXXeiXV60 y4t2edEuL9rlRbu8aJcX7apAuyrQrgq0qwLtqkC7KtCuCrSrAu2qQLsq0K4KtKsC7fKiXdvRLi/a 5UW7vGiXF+3aiXbtRLt2ol070a6daNdOtGsn2rUT7fKiXV60y4t2edEuL9rlRbu8aJf3/zF37+FR 12fexyczmtTTsiLWartrLdai9VS11ar1WKyH2gpWuxW3tbtde5V26/MoHthrtaJU0apVPK9ZjIoH DkLkKDFDRDkEgsEQE0gghGRgJhkmmQwkP4Wov+c147Tr5cKu9nmuvZ4/3iaG+f2+3/u+P/fn/k4y k/Cu5bxrOe9avrsTDn+aw5/m8Kc5/GmOrv+Hoj8t1f3f4U1H8qUj+VIFX5pR9KLLSvbhChVcoYIr VHCFCq5QwRUquEIFV6jgChVcoYIreD4W3skVklwhyRWSXCHJFZJcIbn7V7aFM7jCDK6Q4goprpDi CimukOIKKa6Q4goprpDiCimukNrjKWi88+ad4SSuMIkrTOIKk7jCJK4wiStM4gqTuMIkrjCp6ApV XKGKK1RxhSquUMUVqv5CV6jiClVcoYorVHGFqr/QFSq5QuX/hStUcYUqrlDFFaq4QhVXqOIKVVyh iitUcYUqrlDFFao+5gpVu3GFTq7QyRU6uUInV+jkCp2f8eefwR5eobJ+Dz///OTpZwEHWcBBFnCQ BRxkAQdZwEEWcJAFHGQBB1nAQRZwkDkcZA4HmcNB5nCQORxkDgeZw0HmcJA5HGQOB6nmIAs5yEIO spCDLOQgCznIQg6ykIMs5CALOchCDrKCg6zgICs4yAoOsoKDVHOQag5SzUGqOUg1B9mXg5zKQX7L Qc7kIGcWfz5Ry0FO5SC1HKSWg9RykFoOUstBajlILQep5CCVHKSSg1RykEoOUslBKjlIJQep5CCV HKSSg1RykFoOUs1BajlILQep5SC1HKSag1RzkGoOUs1BqjlINQep5iDVHKSWg9RykFoOUstBajlI LQep5SC1HKSWg9RykFqnn/yrYzZykY1cZCMX2chFNnKNy7nGQxzjMo5xAMc4gFvURKbq+ipdX6Xr q3R9la6v0vVVun6+rp+v6+fr+vm6fr5ur9LtVbq9SrdX6fYq3V6l26t0e5Vur9LtVbq9ao/fN3jI qpPxMB7Bo3gML+BFvIRpmI7/+Glhje6o0R01uqNGd9TojhrdUaM7anRHje6o0R01uqNGV9Togowu yOiCjC7I6IKMLsh4ZlrjmWmNZ6Y1OmKVjlilI1bpiFU6YpWOWKUjVumIVTpilY5YpSNW6YglOmKl jlipI1bqiJU6YqVumK8b5uuG+bphvm6Yrxs+0A0f6IYPdMMHlLuWclsot4VyWyi3hXJbKLeFclso t4VyWyi3hXJ3Uu5Oyt1JuTspdyflrqXctZS7lnLXUu5a6muhvhbqa6G+Fuprob4W6muhvhbqa6G+ Fuprob4Wyltb8m94CuWYgqdRgWfwLJ7DVDyPF/AiXsI0TMcMzMTLmIXZqMQrmIO5mIf5YRslLnQO r3EOr3EOr3EOr3EOr6HOGuqsoc4a6qyhzprCM/iPnr3XlFxrbo0yt0aZW6PMrVHm1ihza5S5Ncrc GmVujTK3Rplbo8yt71JwJQVXUnAlBVdScCUFV+725+Wnh/ebW/dT8lxKnkvJcyl5LiXPpeS5lDyX kudS8lxKnkvJcym5k5I7KbmTkjspuZOSO//T62bvDEeaYSPNsJFm2EgzbKQZNtIMG2mGjTTDRpph I82wuC64Vhdcqwuu1QXX6oJrdcG1ZljcDIubYXEzLG6Gxc2wuBkWN8PiZljcDIubYXEzLG6Gxffw DD5uhsXNsLgZFjfD4mZY3AyLm2FxMyxuhsXNsLgZFjfD4mbYHWbYHWZY3AyLm2FxMyxuhsXNsLgZ FjfD4mZY3AyLm2FxMyxuhsXNsLguHatLx+rSsbp0rC4dq0vH6tKxunSsLh2rS8fq0rG6dKwZFjfD 4rp1rBkWN8PiZljcDIvr3sm6d7Lunax7J+veybp3su6t1731urde9y7VvUt171Ldu1T3LtW9S3Xv Ut27VPcu1b1Lde9S3Vule2fr3tm6d7buna17Z5tnz+ng9Tp4vQ5er4PX6+D1OniuDp6rg+fq4Lnm 2TjzbJx5Ns48G2eejTPPxpln48yzcebZOPNsnHk2zjwbbZ6NNs9Gm2ejzbPR5tlo82y0eTbaPBtt no3mCtdxhau5wtVc4WqucDVXuJorXM0VruYKV3OFq7lC/ieENSVH4xh8HcfiOByPE3AivoGTcDJO wTfxLZyK0/BtnI4zcCa+g7NwNs7BuTgP5+O7GIkL8D1ciItwMS7B93EpfoAf4rLwl1zrl1zrl1zr l1zrl1zrOq51Hde6jmtdx7WuK/n7sMPMHVHys7DK3D3T3P2VuXuJuXuVuXuBuVte8isO8mv/dqPP b8LNuAXj8S/4V9wajuF+Y7jfGO43hvuN4X5juN8Y7jeG+43hfmO43xjuN8bsLeeA15m95WZvudlb bvaWm70TzN4JZu8Es3eC2TvB7J1g9k4weyeUPBHO55r1XLOea9ZzzXquWc8167lmPdes55r1XLOe a9ZzzXquWc8167lmPdes55r1XLOea9ZzzXquWc8167lmPdes55r1XLOea5ab8+XmfLk5X27Ol5vz 5eZ8uTlfbs6Xm/Pl5nw5d32Nu77OXV/nrq9z19e56+slyz3jWGHPtViJVajD6vBBzyIe9CziQc8i HnQeGOo8MN6ziBucCQ5zJsj/ZGSYZxHjufDkWGeY80xiaawrXO/ZxPBY2hnvec68nTNv58zbOfN2 zrydM2/nzNs583bOvJ0zb+fM27nyJq68iStv4sqbuPImrrxpD+9i6OTGndy4kxt3cuNObtzJjTu5 cSc37uTGndw4/1rU/siNuAk34xbs7ueRn+31AR/9VGaVz+uwGm+hHmvwNhqwFo14B01Yj4+/a+Gz vcdl9+9w2P27GwLuE3CfgPsE3CfgPgH3CbhPwH0C7hNwn6Dw+3QPxFAchGE4GJ/HIfgCDsVh+Fvd eDi+jCPwFQzHkfgqjsLXcIXHXokfI/8atZ/gp5EDPvbKnuN08EnFVxSO0J1J3ZnUnUndmdSdSd2Z 1J1J3ZnUnUndmdSdSd2Z1Jk5im6i6BaKbqHoFopuoegWam6j5jZqbqPmNmpuo9YvU+uXY/n3PV2g 0ptUepNKb1LpTSq9SaU3qXS7SrerdLtKt6t0u0ofp9LHqXRnJP9qv9V4C/VYg7fRgLVoxDtownrs +X0rD1DAAxTwAAU0UEADBTRQQAMFNFBAAwU0UEADBTRQQAMFNFDALAqYRQGzKGAWBcyigFn57+1R wS1UcAsV3EIFt1DBLbFLw3+PXRHZr/hOo585Nc2MXR3+U+zvw/mxn/r/n/n/a/z/z/3/9ZF9I2d8 6lcZPITJeBiP4FE8hhfo9EW8hGmYjlVhh8x1yFyHzHXIXIfMdchch8x1yFyHzHXIXIfMdchch8yl ZC4lcymZS8lcSubyPZDaw7PM/M/eAhkIZCCQgUAGgk++AiL29xzr57g+bIl8U7QZ0WZEmxFtRrQZ 0WZEmxFtRrQZ0WZEMCiCQREMimBQBIMiGBTBoAgGRTAogkERDIpgUASDIvhQBB+K4EMRfCiCD0Xw odq/rfZvq/3bolknmg7RdIimQzQdoukQTZNololmmWiWiWaZaJZ98rtuPDmprn1qmn+9aV8s/32S 4yMPeP6z5/fr/ef6LIocTOEHizIlypQoU6JMiTIlypQoU6JMiTIlypQoU6JMiTIVSVDNFmzF9nCX nXfY+Q4732HnO+x8h53vsNNdxXcbfC92dWRfdTiq+K6D78Wu8f8/jxzFTe/UnRPxe9yFuzEJ9+Be /AH34QHVWxR2OXt2yWeDfDbIZ74/Nspnt3x2y2e3fHbLZ7dd1dlVnV3V2VWdXdXZVZ18dspnp3x2 ymfnx941kM9prpjTXMz5PZY/v1/0qV+B/0C4SA0SapBQg4QaJNQgoQYJNcioQUYNMmqQUYOMaFaK ZqUadKlBlxp0qUGXGnSpQZcadKlBlxp0qUGXGnSpQZcadO3xeetHvZKRjYxsZGQjIxuZ4k9RB2Vj UDYGZWNQNgZ3o677ZONWdfuiuh2tbsOKdfuiuh2tbvleOkp2fi47P3cSWB9bE/lK5Auiz3/PbVD0 g6IfFP2g6AdFn/e+AfUaUK+B4quyt9vhdjvcbofb7XC7HXbZ4VY73GqHW+1wqx1utfpBVjwoEvXZ IT47JPIlFWlWkWYVaVaRZhVpVpFmFWlWkWYVaVaRZnvatEc/3s1rpUT/lug3W2mIlYaIcmss/76M i63Ya8VeK/ZasdeKvVbstWKvFXut2GvFXhmYJwPzZGCeDMyTgXkyME/956v/fPWfr/7z1X++Hhyi B4eo/wL1X6D+C9R/gfovUP8F6r9A/Reo/wL1X6D+C9R/gfovEFWvqHpF1SuqXlH1iqrXZNlismwx WbaYLFtMli0myxaTZYvJssVk2WKybDFZtqhEj0qkVCKlEimVSKlEqjhZulWiWyW6VaJbJbqLvTyc Jv5Whs4p9vJwmvhb2TqHv74Vyb8y85DIRPwed+FuTMI9uBd/wH14IHKabDXLVrNsNctWs2w1y1az bDXLVrNsNctWs2w1f2wmf/ZXeSTCKfQ3hf6myFCzDDXLULMMNctQsww1y1CzDDXLULMMNctQswyV y1CFDFXIUIUMVchQhezcKDs3ys6NsnOj7Nxo5pbykB+YtxP4yHnm7d285Afm7QR+cp55e3fsX83m W8MnYm9Hjog1RIbGGiOHRk6krXbaaqetdtpqp6122mqnrXbaaqetdtpqp+b8T/a28Yxt/8Upo06k dSKts/tNe6jvkk85afLO2FF8leDeomorvlJwbxG16Y5MLP+9uos/9av4HgjvUfOcmufUPKfmOTXP qXlOzbNqnlXzrJpn1Twr2jrR1ql5oOaBmgdqHqh5oOaBmgdqHqh5oOaBmgdqnv9+d/772wMyNCBD AzI0IEMDMjTwiXdYbpeh92ToPRl6T4bek6H3irM4K0NZGcrKUFaGsjK0VYa2ytBWGdoqQ9+WofN1 xiEydIau+KKuOESGztARX5Shi2XoYi55S/5d3vlpZ05PxO9xF+7GJNyDe/EH3IcHKH1R5DCKP8yO N9nxJjveVHw+MGDHA3Y8YMcDdjwQeY+P7DQhd2EQ7+ODMP+bHc+NXRkZoYY96pd/BUyP2mVi/xA5 NvaP+E3kF8VXiB0ey+/t7E99PnooTKtjWh3T6phWx7Q6ptUxrY5pdUyrY1od0+rXrX7d6tetft3q 161+3erXrX7d6tetft3q161+3erXrX5Z9cuqX1b9suqXVb+sbPTIRo9s9MhGcg+vyPpPz47U7j21 e0/t3lO799StR80OK5yjfuZj/hyVjz4p+qTok6JPij4p+qTok6JPij4p+iQl5zPQIwM9MtAjAz0y 0CMDPTLQLwP9MtAvA/0y0E/Jg5Q8KBP9MtEvE/0y0S8T/TLRLxP9MtEvE/0y0S8T/TLRLxP9/0Wv f1wX+bmflom0TKRlIi0TaUreIBtNstEkG02y0SQbTfSQ5FSD9JDkUIPUmSlEP1H0E0U/UfQTRT9R 9BNFP1H0E0U/UfQTRT9Z9EtEv0T0S0S/RPRLRL9k9+/nCVeJPv/qnRWiXyH6FaJfIfoVol8h+hWi XyH6FaJfIfoVol8h+hV7esWv3psUuzLcFPtx+JRaTtKDR6jnpcXp9EN9eIS6XlqcTj/Ui/foxXv0 ouc94QtOLSfF1vrc+T3WFLkkcqDoG0XfKPpG0TeKvlH0jaJvFH2j6BtF3yj6dX96hYVdtFl9vbu3 uXtb5Cx3meYu09xlmrtMc5dp7jLNXaa5yzR3meYu09zltv/iuw8Nctgghw1y2CCHDVastmL1X/Qb Ntr0xCa0YzM6kP/ezRXheDlskcN8FL+Qw4PkcKQcHiqHP5HDg+RwpBweKoc/EeVkUU4uvrrlLTk8 Tg7r5e+CwvPImSKfKfKZIp8p8pkinynymSKfKfKZIp8p8hdEvkHkG0S+QeQbRL5B5BtE3iryVpG3 irxV5K1/fu33XzL59/R68fcKz09uFX2n6NtFP7YY/SnF6K8tRn9KMfprRf/vov/3wmuCvyHaQLSB aAPRBqINRBuINhBtINpAtPkz8SKRLhLpIpEuEukikS4S6UKRLhTpQpEuFOnCj72StVqk1SKtFmm1 SKtFWi3SapFWi7RapNUirRZptUirRbpNpNtEuk2k20S6TaTbRHS4iIaI6CrRHC6a/Nn2KlFMj5wn ivGiGC+K8aIYL4rxohgvivGiGC+K8aIYr2ZjRBIXSVwkcZHERRIXSf4nC6+K5FWRvCqSV0Xyqpq9 rmavi2SxSBaLZLFIFotksUgWi2SxSBaLZLFIFotksUgWi2TxHr8P8CFvDcMeDt7DwXvU71L1q1e/ /DnlvOL59BzRDhftjcXz6TkiHi7iG9VvovpNpN77RP8M9Y6g3qXUe2zk5M8w9/Z0Zt3ddwz3Vs+9 ZaFJFppkoUkWmmShSRaaZKFJFppkoUkWmmShSRaaZKGJm2e5eZabZ7l5lptnOXmak6c5eZqTpzl5 WsTHiPYUkR4jylMKTn5ZyYhwoORoHIOv41gch+NxAk7EN3ASTsYp+Ca+hVNxGr6N03EGzsR3cBbO xjk4F+fhfHwXI3EBvocLcREuxiX4Pi7FD/BD5P9K11MoxxQ8jQo8g2fxHKbiebyAF/ESpmE6ZmAm XsYszEYlXsEczMU8vB4mSpaEfSVv4E0sxTIsL7xSeENJLVZiFerCDeZiZyz/k7wfyWBOBnMymJPB nAzmZDAngzkZzMlgTgZzMpiTwZwM5mQwJ4M5GczJYE4GczKYk8GcDOZkMCeDORnMyWBOBnMymJPB nAzmZDAngzkZzMlgTgZzMpiTwZwM5mQwJ4M5GcwV/kbaUyjHFDyNCjyDZ/EcpuJ5vIAX8RKmYTpm YCZexizMRiVewRzMxTy87rnxEryBN7EUywrvK9pc+AtttViJVajDas8e3kI91piQVxW+p5KLXP3/ vSYfFNVDmIyH8QgexWN4HP/m5PgUyjEFT6MCz+BZPIepeB4v4EW8hGmYjhmYiZcxC7NRiVcwB3Mx D3vO+AYZH5DxARkfkPEBGR+Q8ZSMp2Q8JeP/8ftNDin8Nb0Y9sLeKEUZPod9sC/2wwG41Qq34Xe4 HRNwB8y5EnOuxJwrMedKzLmS/Jzbt2RI5ISSq/Ab/DOuw//C/8b1GId7IydE/sE+2u2j3T7a7aPd Ptrto90+2u2j3T7a7aPdPtpL/jpsKzkQQ3EQhuFgfB6H4As4FB+9J3pjyeH4Mo7AVzAcR+KrOApf w2Xh+pJRGI3L8SPs7n3It4YdctAhBx1y0CEHHXLQIQcdctAhBx1y0CEHHXLQUXgf8YN0/hAm42E8 gkfxGB7P/zaayLCSJZGykjfwJpZiGfJ/KbAWK7EKdfhk71wRlptsk0224Xz+KhNtOJ/Pz+7GwrO2 CrzG85eg0yklEbkgtsXU2xoZFkv5/y4fuyNnxtK+ts2zz8sLf9swhr2wN0pRhs9hH+yL/XAA8n8B 8UAMxUEYhoPxeRyCL+BQHBZ2F/5O4uH4Mo7AVzAcR+KrOApfwxUeeyV+jL/DT3CrtW7D73A7JuAO mMiynpH1jKxnZD0j6xlZ7y78RcanUI4peBoVeAbP4jlMxfN4AS/iJUzDdMzATLyMWZiNSryCOZiL eWGXzO8v86fKfP4dVafKfL2Mfz62OHJo5MeFv00Zw17YG6Uow+ewD/bFfjgAn/4nbt2Fv3N5OL6M I/AVDMeR+CqOwtfyfwszcmDJKIzG5fgR/t9lOCfDORnOyXBOhnMynJPhnAznZDgnwzkZzslwToZz MpyT4ZwM52Q4J8M5Gc7JcE6GczKck+GcDOdkOCfDuY/eoRsZKssXyPJQWb4g9pvImZGor+RfS39o ZK9iFS4rVuGyyF/xniG8ZwjvGcJ7hvCeIbxnCO8ZwnuG8J4hvGeIK0915RWuPNWVVxSuHOHKEa4c 4coRrhzhyhGuHOHKEa4c4coRxXcD/rb4bsDfFq4c5sphrhzmymGuHObKYa4c5sphrhzmymGuPMmV 57ryJFee+5l2m7/ykuKVlxRycFz+vYiRK2ktRWspWkvRWorWUrSWorUUraVoLUVrKVpL0VojrTXS WiOtNdJaI6010lojrTXSWiOtNRZfcVZLa7W0VktrtbRWS2u1tFZLa7W0VktrtXt4ddlyulpOV8vp ajldLaer5XS1nK6W09VyulpOV8vpannh1WUPhll+meWXWX6Z5ZdZfpnll1l+maW7gO4CugvoLqC7 gO4CugvoLqC7gO4CugvoLqC7gO4CugvoLqC7gO4CugvoLqC7gO4CugvoLqC7gO6Ckvmm5PVhlY55 Pdxl3r5v3r5v3r5v3r5v3r5v3q4zb/vN237ztt+87Tdv+7n0Ni69jUtv49LbuHRnZG+9uI9e3Ecv 7qMX99GL+0RGFf4CbQx7YW+Uogyfwz7YF/vhAOT/Tu2BGIqDMAwH4/M4BF/Aofjo/cXdqtatat2q 1q1q3arWrWrdqtatat2q1l34e7ejMBqX40fY/Xt6P+tv90n9d7/dx+QbavLtb/Ltb/Ltb/Ltb/Lt X/i7u7VYiVWoi+yT/yu8Jt33i++juaT4PppLCr+1In8Wzzo5Zp0cs06OWSfHrJNj1skx6+SYdXLM OjlmnRyzTo5ZJ8esk2PWyTHr5Jh1csw6OWadHLNOjlknx6yTY9bJMevkmHVyzDo5Zp0cs06OWSfH rJNj1skx6+SYdXLMOjlmnRyzTo5ZJ8esk2PWyTHr5Jgt/PXgp1COKXgaFXgGz+I5TMXzeAEv4iVM w3TMwEy8jFmYjUq8gjmYi3l4Pdyyh5NhuvC3i2uxEqtQh9U89i3UYw2vveqj90BGrpDRhIwmZDQh owkZTchoQkYTMpqQ0YSMJmQ0IaMJGU3IaEJGEzKakNGEjCZkNCGjCRlNyGhCRhMympDRhIwmZDQh owkZTchoQkYTMpqQ0YSMJmQ0IaMJGU3IaEJGEzKa+B/7DZLzwx2y2imrbbLaJqttstomq22y2imr zbLaLKvNstosq827eYbTKKuNkcd1e6du79Ttnbq9U7d36vZO3d6p2zt1e6du79TtnZ/x93n16PYe 3d6j23t0e49u79HtPbq9R7f36PaekhFmzdE4Bl/HsTgOx+MEnIhv4CScjFPwTXwLp+I0fBun4wyc ie/gLJyNc5CfZ+fhfHwXI3EBvocLcREuxiX4Pi7FD/BDXEbDozAal+NH2N3vILtVLLfhd7gdE3AH 7sRE/B534W5Mwke/a2wXN9rFjXZxo13caBc32sWNdnGjXYW/z/0UyjEFT6MCz+BZPIepeB4v4EW8 hGmYjhmYiZcxC7NRiVcwB3MxD6+b5UvwBt7EUizb/W8eoKReSuqlpF5K6uWCd3PB64oueGbRBc/k gusK6kpTV5q60tSVpq40daWpK01daepKU1eautLU1UNdPdTVQ1091NVDXT3U1UNdPdTVQ109xdd3 9VFXH3X1UVcfdfVRVx919VFXH3X1UVcfdZVRVxl1lVFXGXWVUVcZdZVRVxl1lVFXGXWVUVcZdZVR Vxl1lVFXGXWVUVcZdZVRVxl1lVFXGXWVUVcZdZVRVxl1lVFXGXWVUVcZdZVRVxl1lVFXGXWVUVcZ dZVRVxl1lVFXGXX1UVcfdfVRVx919e32NWm3cuzb8Dvcjgm4A3diIn6Pu3A3JiH/urP833h/CJPx MB7Bo3gMj+PfIqXUVUpdpdRVSl2l1FVKXaXUVUpdpdRVSl2l1FVKXaXUVUpdpdRVSl2l1FVKXaXU VUpdpdRVSl2l1FVKXaXUVVpU1+5m6u7U1U9d/dTVT139xRl7z27U1Rk5i7o2U9dm6tpMXZupazN1 baauzdS1mbo2U9dm6tpMXQ3U1UBdDdTVQF0N1NVAXQ3U1UBdDdTVQF0t1LWGutZQ1xrqWkNda6hr DXWtoa411LWGutaoVItKtahUi0q1qFSLSjWoVINKNahUg0o1qFSDSjWoVINKNahUg0o1qFSDSrX8 t7/Ha37+dwEUnkcPL7y3Jd9XHSLvEHmHyDtE3iHyDpF3iLxD5B0i7xB5h8iTIk+KPCnypMiTIk+K PCnypMiTIk8Wn8V9ujPaCK5xNI7B13EsjsPxOAEn4hs4CSfjFHwT38KpOA3fxuk4A2fiOzgLZ+Mc nIvzcD6+i5G4AN/DhbgIF+MSfB+X4gf4IS7jrqMwGpfjR9j9s8y0aqVVK61aadVKq1ZatdKqlVat tGqlVSutWunCs8z/vq/+J117d321u+/SfLKvJuqrO4t9dW6xr84tvO70xs/4+wA3UNcG6tpAXRuo awN1baCuDdS1gbo2UNcG6mqlrlbqaqWuVupqpa5W6mqlrlbqaqWuVupqddILnPQCJ73ASS9w0guc 9AInvcBJL3DSC5z0Aie9wEkvcNILnPQCJ73ASS9w0guc9AInvcBJL3DSC5z0Aie9wEkvcNILnPQC J73ASS9w0guc9AInvcBJL3DSC5z0Aie9wEkvcNILnPQCJ73ASS+grgHqGqCuAeoaoK4B6mqlrlbq aqWuVupqpa426mqjrjbqaqOuNupqo6426mqjrjbqaqOuNupqo65W6uqlrl7q6qWuXurqpa5e6uql rl5eEDj95Zz+sk5/Wae/rNNf1ukv6+SXc/LLOfnlnPxyTn65P39H4oDo6eHa6Pm4MLwyelF4bfSS 8NrYpeHrsSsi++Z/70rxd/yXF3/Hf3lBC/tFTwyT0VNwapiKnu3jheE7rl7m6mXRS8O3KWl94Sfz Pw2Tkb/y6IxHZzw6sF6bKzLWbIvqxejf+dqYcGP0F/hn3OPr94ZthXX2dWW/K/tdtd5V/a5a7xEd HtHxsVdFLyus0eqRrdZY55GtdrTejmrtqDZaiCd8rfjqyIHCq/9/6uPPIsMin3PvGe47wy5es4vX 7OI1a6y0xsr8d8kiQ937Jve+yb2T7n2Te+9y75x759y71aM7PbozdsWH71pjyG5+/9L4wvO//J2u cadrrLnGna6x7prohZHD3OEn7vATuzw+dmX4TPG1ACcXO/GEYieeUPx59TWRv3anX7vTr+0p526v uduv3S2/8yvc6Qp3OtqdbnOnW93p4MJPT/M/Nf2NU9n14ZhImateccUrrnjbFW8Xfn/az5D/eeoQ 2cjKRjb6q/Cp6NhwYvTX+A3+Ocx+Qh+T6OMV+ZxEH6+4eru6jZIpz8hd/Y6rl7l6mauXRX8bNhVe afAnbZQUXk1U5vH9VmyxYosVWuxlP3vZr5C1A/xri7ttdLf17rbc3Za723J3e+1jde0v1rW/UNf8 nTeKY1Q41bVbXbvLtYFrA9cGrm117YmuPVOW93XtCFnO//beEXJ0f0F/+avH29db9vVW9FeRz9vb W676J5nNyGzC1fe7+kuFn13+1Mf8zy5/Ez7g6srCvn9t7Zw7VLtDtaurXX2aq9e6el7xNwYf76rj XXVn/tUckVKPXunRKz16pX892L8e7F9mU+qNYrhJpm4Ou6MTdeH97v2oHnoi7Is+GfZFov51ZzT/ s/wS/31XHW4O343e4mvjC19fE70rsk/0bne5L+yJPkZFT/j6k+FO977evW7Ajb5ys+o5W7p/Kspp oo+711CPeNsj3vaIlHvm3DMX/R3nuB0TcAcmRv4mele4OPpHj3tQJz+EyXgYT+jEJ8PayF522eFR mz2qO5p/VW3U3tL2lN/x9eK7Af+x6yYK7aXQXo/odZd+d+m345vCdjsN7DQTvc1eJkaGuWunu3ZG 86/DO8y9lrjXEjtOemS9eybdMxn9F9Gb8a7KiKBPBH0i6BNBn7uUWq/OenXWy0YfUPkHw4RIEiJJ iCQhJ+/I+0p7abKXpsgXrZSxUsZK/fb1mtX6rbDRClkr5KyQs0LOCvl9HmKfi6ySsUom6lQu0z32 PctKPVbqsVKPlXqs1GelHeJptFqX1bpU8HpR34B89BOp9C53uMej7sX9vvZH0e8n2l2i3SWDW9R9 3+gfPPK+wloe4fPH8IR/fzLcVajuZvfc7KqMq/J5Sdl1yq5Tdp0qrPOnHf/Rrh6U5YcwGQ/jCXl9 Ukfna5ml8g55/FNWHhHJRzrNeEymULuej+0vI4J+ecjvPBBrwBFuEsFE+7nLun/w+X0088fIoXY9 lG6vp4QbkO+IW3GbR0308R75vhf3ud/9herlXHV0QcXOznaw3Q62FzSY74ysHWRdWffn3slFYoUe m4j8b/waYq1mazX/+dG3hQP+daOd7We9Lut1FXL7R7t+RKYepawnKPvJsLtwr3c9ept7vRc5JTpL rPNFEaeexVjCE9+wtzfDcdGl4ZPRZVgRPhet47T1Js1aj2nysRlZWe7DDhNnILw3GoQvRN/FzrAh +kE4JRbhO3uZQmU+fg4H+Nyz5JhnyTHPkmMjcDSOC7fFTghfin0jfDl2Ek7GKeHm2GnhO7Ezwhmx sz3mT3/l58rIYbEfmwkfvQcn/9tHpxR/++iUwrOtv4lOFX0+qjdk/009tlTky7BCJWtlos7n9aJ4 R+aafGxGV+TgaDdFDrgucP272GVXkbDd7tvtvj12aBjYZcout9nlNrvcFvtm2GeHicgXiqt2yN+g VddZtc2qbVb9wKobrZqy6jqrbrfqOquus1qv1TJWy1gpY6WMlTJWedcqOavkrJKzQjZynRWuiU4P f2WVwej8cGb01fC66CLEzZ3FWII3wvetOCtaZ0dr/f87drXeY1p0ays2YCPasCm8PtruY6cZluCO W3y+FSl0RW6Pdqtk2ufbkAlvjvb42ItseIOq3xDN+Xw7dthTf1glkpRIUqp/ldy1RQf92/v4AB8i NBNLEEXMaWyv8IbY3j4vdbLYN7w5tp/P9zez8yoZEj4U+2sciKEYFp5AOaMoZxTljFKLKbHDwidi X/RvX8LhkbGxI3z8CoaHp8eOxFfDu2NH+f+vYUQ4ktJGxo7x+bE4jmKOD/9Rpt+Q6QqZrpDpCqr7 vpq+FvuWx5yK08KFsW/7eDrOCOtjZ/r4HZwVPkeVo2Ln+Pzc8BfFCdxW/J1VYws/Vc7/RPlXYQ1V vhb5uio1q1KzKjXTR/PH9LGaNrYWFLnW1/+kyCyP7MMODFBx4HHvYqd++yDcQC/1MriFZupppl7W MjK0Q4Z2yNAOEfeLuF+kO0TZLMo1olwjyjWizImsW0RrRLFDX52hr87VT+v10vrI1+gsoK9u+ur+ 2M7X2vlOO15ZVHNnYcfveGyTz5vRFTnJztvtvN3O1xedoM9O2+2wSx177HKdXa6zy3Xq9iX16lOv PjtuteNWO26246Qdt9txux2323GT3Sbtdl1khB2ttqPVBcW/yflXhJXFrk7a0Wq7SdpN0m5Otpu0 3aTtpkMeN8pjnzz22VlemSl5XGd3aXlcJ4/rKHDQTjvscotdbrHLLXZ5uN0l7C5R3N16u1tld6vs bpXdtcvnBjtcbYdb+MhU3vKm7l5q/i1DLb+t49/1dvkOt27ysZkbR+3xSPc/gFNPtePpHvuq6xah Nnyv8I60vzOfDvCv3f51p+7v9oh3PeJdK1xrhcet8LhHN1nhzXzHq2O1OlY7b0z1lenhKleti862 p/nq8qr/X4Q3XbEUy1BLYXXhh/a3OtpgKn1U09X2uJp/JHhFigek9WlaDRvUrFnNmu2vyf6aIsOt 9ICVbrdS0iqVVrnVKrda5V2rDFhlwCrrONMwq+y0Qr8VdlphpxVmWGE+x1lrlTes8oZVblGDXjXo VYNeK95pxTt1dV7bvWrRqxZZuc/Iea8uzH+34CK7uUgulxRUkdfjBSr8oep+qLofyvT5Zv1UEb7J d5fa67KCTg74uN8WvPZG0fxeJFUiuVMkd1LdWqpb696ro0udvJdhBR+u81xvra9/5LXj9uC1dxe9 tpHX/h/mzgQ8qiJr/+dW3QTobIIhLGpAEjAuqATcWHRURlRQAY0CCoIsigQiEBQYxRkCYlCQ0Qgo 6uCMRAU+xAVighAQBEJLE0iUVmmBBBIwQQiSsARz/79b3Tro4Kc4883zf3jeur3Uek69b53TpG9/ 9jOt/Qsrf+8UrU0/RWsz2L0Zp2jteLS26BStHf4zrS3+Ba3NCGntO1g3PaS1T7LTd6G1WWhtFlqb hdZmYfnrsXw/LN8Py/dDaxejtfPR2iy0Ngsb9kdrs9DaLLxyG165Da9MQmuz0NosvNMH7/RBa7PQ 2iy81ButTYc1m7HyQqy8ECsvxHM90do8tDYLrc2CQe+jtVlobRZMegOtzUJrs9DamXi4H1qbhZf/ jJeHobW70Vr3G2UT0dp4tDYerd1i8pUH8d59eO8hvPc+3huK94bivc14bzPeK+CU3InnVrLjT+C5 zXjuKzw3FM8V47liPFeM54rxXDGey8RzxXhtI14rxmvFeK0Yr43Fa4vwWjFeK8ZrM/FaMV4rxmtL 8dpSvFaM14rx2mK8tgb9OYLHcvDYHjxWjMdcbxXjrWK8VYy3ivGWq0dL8VYx3lqHt2birWK8tRRv bcNbOXgrB2/l4K0cvHUL3pqFt2bhrVl46yO8tQlv5eCtHLw1FG/l4K0cvNUTb/XEW//AWzl4Kwdv PYu3nsVbOXgrB289g7fex1u78dYuvLULb+3CW8/gLS/eysFbOXhrJ97KwVs5eCoHT+XgqVV4ahae ysFT80J3clyOp5abzw7GOFukDd7JxjvZKMVGNKkCL3nx0j/w0j/wjMvMD2HmWpi5FsV4O6Sba9Cl fXhqD6qxBtVYg8fexjufwKkyPOFzlQMLl8ONPXBjD1b+Gu4HsGIN/A/A/0BIWd7EEm9jibeZZTWz THO/lymtT4mk8tkfCxj5oImi9skd+LQIn7oM/IRRAoyyjVG24c/3YN1ORirEb0WMVMhIhfiryrAr Dt81AU1BC0nG9sex+RfY/IvQWVKInVdg5xXYeQV23oJtt8KAjdiymHh9H6ePe052ICuKwWpHsNBA LPQiFnoRC21gnm9ghaPMK/vHGPwElvgeXRTi53qgvrNIImn51I+23YAie9nB1c47P7YKnogVtKig RQUtDnISHQLf0V+18xo1l1NzOev2Uzub2i+z7m9p8TItXiYXLMFq1c4X1NxJzZ3MpIxam/BDObU2 UWsTJ2QJJ13wPP6CWl9Qy41rvqOmq1JV1CzS7q/7nI2fX8HPr+DfV07xwhZmsIVWVbSqNpYPZxyP 8wr+/Du7bju7bjt+fdX87foA8ymSVxrSQw091NBDTWj8HYy/g97cnvaaHWOfsmOC3/JqS76RwLm6 m3N1t7FKOb2U08tOetnzQxRPLzvppSYUnZX/EJ1hlYNkjofAd2hNtXPMtR+1DlNrF7UOa/dOHjGs dR+W+Zbax6l9nNqHQznJD7OsZM2FtNxNy+Os+QCtd9N6tyhWeiUrvZJc0s+cKsloT3A6epwDnFA/ nOIljFBpfFlMr1/S65ehHvPQnqqQ7fPoMU+797F2Wy6jZS4tK2iZR8tDP673BHY/Zb/QIi/0f2ET xFLu98ca0L4ixMvgGk6YPVbCSHtpV0K7ErPyNxkljxFWnOJlHyvOo8W3xsMe8+naCyHv7jDqPwaO uK1fpXUOrdfTupTWpbT+2o2WaVnKWK4d1pu53Q3D7gHu38SMcdZLI1r7ab2WFfrQ+TJ62ciM85lx HjN2x383xIwPsJGrKO5+/4CZf0CvG+n1dXrLM14uZOxCxi6gh4OMv5pW7uwLafEtLb5l9/ixYAkx f7XzPGMsZozFjLGNmhn0vZ+aGdTMYL+NZ7+Nx59BZi+j5jJmslrC0fnjaMdxtGM/2rEf7diPPh+T CPRtM+/uReMCaFwglE2emrN+Tc/f0PM34qF2tclsE+BeImjHXkwG7cEVvN6JFteTf8ZbyvFaGtgg DISDeqA+aAA8IAJEcUpEMmYsXIyjdRPQFCQQeySC1uywf0ZwFejaPpTOHcX9X/q3sORb5htn7rfM 3Iy+MTpapWN5Fke81wQ0BUl49ELQ1uTLpcy7hHmXMO8SExNeIQ3Q0cPM/yt6PwiP/wiP3V8s2cjK N0ok8ytl5SXMayfz2mnmdRnRfzvmkQzaAze/74dlBxCre1hVGXPYxRx2MYddzCHAHALMwR1zN2Od YKxdjByL5ZoRvyfAz0TQjufJoD24Att0gu0uXzuyyo5Sn7ruKlb9JEu7gvH7kV8OcP4q9Xi36mef CXz7ox6547mfTxxgvD2Mt+dn/t5H7QNiMc8jcraOEk39BT/JFhM4oRNBa+aWhLUuBG2xnpspuhni 9awsxVmGb5Yx65bMuqX5nLwhPb1HT/vpaT897aenD+npQ3o6Qk9V9FRlctBgnL6fng7T0xp6WkNP F9DTBcYXu5n/17TeQesdtHY/a/nmZ7t7F+s46kb6WCyOFTcBTcE//bCDcfyMs9PYZB/97aO/fWY2 l1GjHXqcDNoDdofcJEOIGIeCYWCs85ZMdGbJn8Dj4AkwCZQ6C2QP2AsOU+e485ycALXgJPjeec5K coqsC8FF4GJwCWgLLgWXgctBO5AM2oMO4ApwJbgKXA2uAR1BJ9AZdAHXguvAH8D14AZwI+gK/ghu At3AzeAWcCvoDnqA28Dt4A4wHAavdgpOe2fuDWAjKACbgNdZJ4nSiHPrbBALGoM40ARcAJLAheAi cDHoDnqA28Dt4A7QE/QCvcGd4G7QFwxxFmPxxVh8MRafLunOOzIOPAoeA+PBRGcJXliCF5bghSV4 YYm0OaM7Sv2+O0ktw8/L8POy0N3ni4RsS6pBDTgKjjv5+D4f3+fj+3x8ny9pYku8hIFwUA/UBw2A B0SASBAFokFHaSudwBBnHnaYhx3mYYd52GE+dpiPHeZjh/nYYb5MkEbYYgq2mIItpmCLKdhiyhn8 2kmy5IFSZzYrm83KZrOyRaxsFStbxcpWsbJVrGyVHJOGrG4mq5vJ6mayupmsbuZ/6+8F1eXSTLWT tqoD1+vAzc48dYszW3UHvaSpGu4sVA87k9UIkOpMRv1G6Xudp1HAUfp+rulEBeNgfyGx3laJ1UXg Mzj/Oapf6uTrPTzfK0m6zHyDI0F/w7VCYtDhLTwqxVruI/ebHvFSjUdj8GgMHo3BozF4NAaPxuDR GDwag0dj8GgMHo2BKQGYEoApAZgSgCkBmBI4/d3cJQHvJ5zRfZuHOOnslHR2Sro8REw1HDwMRoBU MBKMcj+3AI+A0WAMGEsUdrpdNdHpxo7qxo7qxo7qxo7qxo7ysKM87CgPO8rDjvKwozzsKA87ysOO 8rCj3N9fLoODZXCwDA6WwcEyOFgGB8vgYBkcLIODZXCwjN2XwO5L+F2/UV/KqbcH7AVndt/k99jd uezuXHZ3Lrs7l92dy87OYGdnsLMz2NkZ7OwMNNuPZvvRbD+a7Uez/Wi2H832o9l+NNuPZvvRbD+a 7Uez/Wi2H832o9l+NNuPZvvRbD+a7Uez/Wi2H832o9l+NNuPZvvRbD+a7Uez/Wi2H832o9l+NNuP ZvvRbD+a7Uez/Wi2H832o9l+q6c0s3qB3uBOcBf4b90LcbWT9wt3j83jrMjjrMjjrMjjrMizPhWP tRn4wBb3bySIyNuROXTgynkGm2MUZxaMzoXRQ2D0EMPoe8kghoDhzpxTma1Gmr/87Qa7H4bd3WD3 w+7/N+uxZO4rYPIqidJrnGl6i7MUpsfAdA9ML4fpHr2dWKyUfDf4Xa1488tzbpxbAZs/Ftu5T8JA OKgH6oMGwAMiQCSIAtEgxrnhtPdK7OgslE7gjBgs3WUoGAbGyqWSjm6MA4+Cx8B4MJET7k/gcfAE mAQynC4yBUwFT4Fp4GmQCaaDZ8CzYKZz0//yHfKVMHMlzFwJM1fCTPdOs/MlD2xyCmBmAcwsgJkF MLMAZhbAzAKYWQAzC2BmAcwsgJkFMLNASjlP9oC94LC0kO/QyiPA1cwacBQclyZyAtSCk+B7843J 9eQP68kf1pM/rCd/WE/+sJ78YT35w3ryh/XkD+vJH9ZbZzmLrIagETgbxILGIA40AU1BM9DcWWrF gxagJTgftAIJIBG0Bm3ABaCns8rqBXqDO8FdIIXX7wb3gD6gLxgg/ayBYJCMtx6QQdZg6WkNkSHW E+z0SeBJ8GfwFzAZZIApYCp4CkwDT4Nn6GsWLP4reB68ALLAi2A2mEPWebnTX3UAHck8r+N6I9eb 5QZ1i7RR3UEv50FYUgRLitRw6awelpZqBEgFI3kt01mnpjvriKjvJqLupfPIv1c5Q3QJ2XIpp9oe cxfR1/U+4t39nH3fcD5WODWW+0vKUTAhCiZEwYQomBAFE6JgQhRMiIIJUTAhCiZwytW5dxPN54zL 54zL54zL54zL54zLhyF5MCQPhuTBkDwYkgdDZsKQmWd0t/JTf4lposTChFiYEAsTYmFCLEyIgwlx MCEOJsTBhDiYEAcT4mBCHEyIgwlxMrNun8xy9vwvv9C0R+aCeeAV8Cp4DfwNzAevg7+Df4A3wAKQ 7aTBoDQYlAaD0mBQmizi9cVgCXgHLAXvgvfA++ADsAwsBzngQ5DrzIV1c2UFjz8CK8EqkA9Wg4/B WrAOfALWgw1gIygAm5zRsHU0bB0NW0fD1tGwdTRsHQ1bR8PW0bB1NGwdDVtHy+e02Q78PP6C65fg K7ADBJw18jXYCXaB3aDEvXsVOnkC1IKT4HsJg7mTYe5kmDsZ5k6GuZNh7mSYOxnmToa5k2HuZJg7 Geamwdw0mJsGc9NgbhrMTYO5aTA3Deamwdw0mDsB5o6HueNh7niYOx7mjoe542HueJg7HuaOh7nj YW4GzM2AuRkwNwPmZsDcCTB3AsydAHMnwNwJVn/mOkC6hH5PoCfsvR72Xh+6r3HAGs7OH8f1UfAY GA8mgIngcfAE85oEngR/Bn8Bk0EGmAKmgqfANPA0yDR/CznBepbrDDATPAdmOTNg/QxYPwPWz4D1 M2D9DFg/A9bPMHdnXw5ywIcgF+SBFeAjsBKsAvnmLu6VnMOVnMOVnMOVnMOVnMOV1noU5DS/nm59 SpvNwAe2OAEU5kYU5saQwtwYUphmKEskyjIDZZmBsnhQkxmoyXDUZDhq0gU16YaazNIfOZv0SrDK 8ejVXNc4pfpjVGSt8zdU5nUUplbvNSpzByrzinY/J/nGWaYrzK87Zjg9YG0PWNsD1vaAtT1gbQ9Y 2wPW9oC1PWBtD9i6Draug63rYOs62LoOtq6DebkwLxfm5cK8XJiXC4vyYFHeGf9ih/tLHb9w/xPt YyWFaCSZod6GlnLm6WJe+5xoYjsreVQy6k7IFDAVPAWmgadBJpgOngHPglmOl9X0ZTV9WU1fVtOX 1fRlNX3RHi/a40V7vGiPF+3xoj1etMeL9njRHi/a40V7vGiPF+3xYoFeWKAXFuiFBXphgV5ojxft 8aI9XrTHi/Z40R4v2uNFe7xojxft8aI9XrTHi/Z4sdoIrDYC7fGiPV60x4v2eNEeL9rjRXu8aI8X 7fGiPV60x4v2eNEeL9rj3icuBWunYO0UrJ2CtVOwdgrWTsHaKVg7BWunYO0UrJ2C9njRHi9WT0F7 vGiPF+3xoj1evJCJFzLxQiZeyMQLmXghk5i/iJi/iJjf/W34jcTxm4njNxPHbyaO30wcv1mOOTtP dy9LqXOWi+MstwRYznI8OpD40IdXX8erT+PVxnh1EV69m1gxH89OwrMZcohoJQGdSyDTSyDTSyDT SyDTSyDXSSDTSyDTSyDTSyBCSyDXu4qTsJKTsJKTsJKTsJKTsJKTsJKTsJKTsJKTsJKTsJKTsJJs L4lsL+mM7q89BA8PBcPAQ+zP4eBhMAKkgpFgFEgDj4DRwP0sbiz1051pZHvTyPamke1NI9ubJhOY 9USnPRlfezK+9mR87cn42pPxJZLxJZLxJZLxJZLxJZLxJZLxJZLxJZLxJZLxJZr75f3y/dgOsTsP sTsPsTsPsTsPkfVdTdZ39e+7/63zJDvgSXbAk2R9FWR9FWR9FWR9FWR9FWR9FWR9FWR9FWR9FWR9 FWR9FeyW0eyWqeyWqeyWqeyWqeyWqXJMWrFbOrFbOrFbOrFbOrFbOllKIiwNbBAGwkE9UB80AB4Q AYiFyMIiycIiycIiycIiycIiycICZGEBsrAAWViALCxAFhYgCwuQhQXIwgJkYQGysABZWIAsLEAW FiALC5CFBcjCAmRhAbKwAFlYgCwsQBYWIAsLkIUFyMICZGGu+s9H/eej/vNR//mo/3zUfz7KPwfl n4Pyz0H556D8c06ThbUiC7uELKwV6l9OFtYK9S8nCxtOFtaDLKyHus39i2JJ4CQo5yRw/zr6WTKx oWRiQ8nEhnIqlKtR9LVQzldLpJ76UFqoXLDWGafWOcvUJ2CD87ryOjepr6WTqiZ7qyEmPQq+d57Q sdJMXwYb2zkf6mTQHlwNKz8iO1sll3OabISlebqQU2Ob+bzGRxYXAzNrOV12kck9HcrkPKHPbTyc MlV6PyeMufOGc5BcynayiWWziWWziWWziWWziWWziWWziWWziWWziWWziWWzyeoWEZ/6iE99nE6Z nE6ZnE6ZnE6ZnE6ZnE6ZnE6ZnE6ZnE6ZnE6ZZFer0c8P0M8PiIV8xEI+YiEfsZCPWMhHLOQjFvIR C/mIhXzEQj5iIR+xkI9YyEcs5CMW8hEL+YiFfMRCPmIhH7GQj1jIRxzkIw7yEQf5iIN8xEE+4iAf cZCPOMhHHOQjDvIRBxURBxURBxURBxURBxURsxQRsxQRsxQRsxQRsxQRsxQRsxQRsxQRsxQRsxQR sxQRsxQRmxQQmxQQmxQQmxQQmxQQmxQQmxQQmxQQL2QSL2QSK2QSI7xOTOAjJvBx/vfGI5Wc9zWc 9UvxQmXw/ic8r6n7WB91YvWxuoA+XlekT9Qt1LV1fn2yLld/70ToOl536irtsLqP7XAn1q5XF7Dr 1xXZDeoW2p46vx1Rl2tHOhF2FK9H11WKjVovRanL9WfkLO6vbN2Mgi1CwRahYItQsEUo2CKY7YPZ Ppjtg9k+mO37//7eUu53YtbD7A3EcBtBAdgEvE4lrFwAKxfAwAAMDMDAgHrDKYFt2TBrH8w6ALMO mL9CXeO8qbfAgEInAGuyReGZbHgxg9fypL1eIYN1viTq1dKcup/qj6WxXisXaJ90p11387nJNrle F3EtlmT6qHQ/KZX6uoRXS6UtfOtuPid1/4ZqPydm8PPSZEZa4+RSP9eMuZT3JolmvCReK3JrSjia 6UEzPWimB830oJkeazhtbcaOx6udzf102D+MF3wlXrtxWKn7+Syn9D63Jx5XOFWMUoqK7Jfrzeez bt1kxnN/+bOM2bn33tHBO066+uF+Dm++69PH2arTscMax2d3MZ/y9nG28WwHtVcSw652qnlWwrNU 2q12jvNsmzQiGkgmGkgmGkgmGkgmGkgmGkgmGkgmGkgmGkgmGkgmGkjWKdJQ93M26AEgFYutcD6n p530VMi63H7z0KoVrGuls1sTzfPuF7y7ggj6W+aZLhfjq4a8W+X6iHnGSiOrUM6ztkrr0P+jD9X9 qBW8b8PF5r4NqeZvSr36UWLT2XKhngPynP14oBUsfc++Ri6yO0prVnavRNMimnEuw/LpWGul8y0j ec1IUYxQwQg+c2/2/iire2/2QVzTGaXQ2UHcVEnMdNL49XMJo5VHwmnh1nbv29iMms2oWUWNaixS ClPRB07vGvfbKmZEci1isUo8FAar/fR3BGZX06LK7dNVevpMYS19qJWOFX286tZ2PwmO+Umf99F+ IBgplunbvSNXIa9vpb9t2LEIL37GifK5RJh+I0L9llA7hlnU0qKEFpW0qKJFeOhTwzCjMdHUrqJ2 jbkbs3sX5jHGRwnMqJ5270YQHKuGlhGMVUtrNzuoYs+VEhfuAXvBcWlDBt2GDLoNGXQbMug29DzQ ZFT3saf7S4oeyHUQ15FEp2Po+VFnrX4cT8xmV82BHT4svgX2urbd5rxnRit2trO/Y4lcT+LjZHyc bO7u4f4KQ1t6a8tcY0PWQ0HZga6Nt+Mz19P5jJ/PysrNbzYM5Or+bkM6422hl0JUZavzHWNVMdYx 1y6mlc/sj36M4X6vd4C5n2+CHodClEiT4FnAfinHuu7fUO531jJy0OYBanl4pZp5/PDNrNB3/PRY fPgYXNmHv/Zjv/DQvV7LaYMOsIIysN8JyFlEw+VEw+VEw26EW27W2485DQDjWIFbu5QRTXTAe/tR D/N5r1PJfo03Xi0y95HtZ+6xHdBjme04VlGCTUudb1jF8eAqnKPMqJYeCtzPyMzYVYxdxdhVP+7Q 0N9I00sYvbRlfA+9lJs8OBihuDPfxRzc/w8cIjfJUDAMTCSO/hN4HDwBJtE6xWlBrxfC8ejQ91uj zfdbU505WGkZVlrHvshjX3RmX9ykF7JfShi9lPmbEdHfcmy+zwmwJ65iT1xld3H8rs2NnWrM3cWD fgsz9iozXqmiTMFSfTgzgrWahWo1Y+wqaiab/l0fhOvUujf1MecgZ3nArucc5KwO2El1Gxk3tW4X r9bwSo2d5FxCr6l123UNFq2l9Ul6+t4pscOc47bHqbUjnCpqllCznWm7hHf9vOKnt2rT1qdPwDW3 7fd4zaFNA6ln2kY6RXY01yQnXhpRcyOj1BJ1VDGzSn2cay2jnnRO0HIrLWsYtZZoo4oZV9r1uXqY RYRzgp620hPzrduNtVOJU4K9VNNLLb3UuXM2YwdbV9O6ltZ1Zu7BOYRJHC1TmUOJPorNjnE9jv2I RkIr9+vv4VWds5eejjOXEjtcmtFbCb3V2ESKIYuwfmlgRzl76fk4c5rhnhx1JfTo2qBc16G79cz6 y+0oHic5Ymq8YzxywtQKeqWBqeV6ZhvW/Zm/OP9CfqL1r/jH1DV+oe6v+EPO+nf9IJFnan928X/Y 7uzxX7C3eee0dpZoO1bq243ptal47ObgHNqcS/vzeEwkZbfgvVY8TgStea8N712AHtt2HH2cw7st ubZ2bWDH8qwx621Cnebm3SrTVzyvt+Dx+TxONLWr3H4k3NRuakatNjVamVGqpRHzCuPdSjuOV5qA phLP/GKoWUmf8cyPfkELnrfk/fNBK15PpE5rXmvD4wsYI5peypmru8IwuxmjNxcd6sVtXc783RWG 2Qm8l8h7wdZhchZz8ND6gFlpU/ptTq1zsN65vB4c30MPB4wFWvF+Iq+15v02vO6OzSrovzHvxjmH 7CbuWtlxZg748lzGPY/X4qnTgtdaUud81wbUMXOhThvqXIDSuX6KMXZtKrEhP9Uyj1jmEc08Yoxt W/E86Kda5hDLHKJdrxjrhYVaHfnJ7N11B1sc+XHWMb93T8DaYh79bF/A9hYSdaZ7g1YJsPQX9gfv Kjn7P7VH6K0xr/zOfULrSGn47+4VeolzV/Sf2S944g3jx9+1Z8yKos503zDmMSLCmrqtaGFbFMdG 1dqRR69C1c4hj16L+lxDHl2Lqp1FHr0VbWyLGtmoWjvy6FWo2jnk0WtRpmvIo2tRNThY9wUWaY5F orBIlN20biMWaWw3rytjVolYxcYqyo6nXgvqtaTO+aAV9RKol0i91tRrQ70L2DUNyFZiyDNuIquM JZt0I+NYIs14oopk9zMZIq5moqQ/WVRbEeko18lF5G3Xy+XSXe6UdnK33MOrfYmHOstD8qzcKjNl saTJEsnhUZ6skrmymn+vylr5XF4TPxH1e1JuNZbV1jnWOXLQirfayiGrh3WbJdYd1l2WsvpZ/a36 1v3WECvSGs6/RlaqNco62xpnzbXirJf519F6hX+drNf419l621podbFWW1us69TlKtm6Q3VQV1m9 VUfV0bpbXauus+5RN6quVl91k7rJulfdrLpb96nb1G3WQNVL3WkNUnerPtYQda+613pQ3a/utx5S Q9RQa7h6UD1ojVDD1SgrVY1Rj1pj1Hg1zXpMZaoZ1jT1nJptPavmqpesLPWGeteard5Xn1hvqA3q cytH+VWptUHtUxVWkTqoDlnb1WF11PpCHVe11k7laLFKtNLa2qPr6SirTMfoRtYBHatjrSodp5tb h3UL3cI6qs/XraxjOlG3tk7oC/SF1kl9iW5rOfoyfZmydDudrJTuoK9Utu6oO6l6uou+VjXQf9B/ UBH6Bn2DitRddVcVpW/Td6hofZfuo8hx9WBFvKNHqpZ6jH5MtdKP68dVkp6kJ6kL9Ww9R12kl+gl 6hL9gf5AtdU5OkddqnP1WnWZ9untqqMu0RWqq67RjrrdDrOjVR871k5SD9hd7C7qMbHYKx6rY/gm 0YMnjCFvfnDM0BEyKnVQ+ih5mfPSurP3DS3JdsRxpCEZeLicI+eTq1/EvurAfrpR7pAU+rhF7pVB 8mCoXhT5+7nSSs6Wi9l5V0gn6So92YEWu+4+eYD9Z9MmWDeaPP88SSArvoRxrmR3/lF6sVcV+7a/ DJbhZAOq9x23tZTOd/Xu3lIeNu3ONn8TFi9NJVEas+Ovki7yByL93tJHtFwgPWQAGUCwbiw9eKQF /GgtcXKptJer5VqY0Q1e9GUmSXKb3E+uMCLUc0OJkJbSnPyxCdn7NTDpBrlZ7pJ+nDIXyu0yEA6l ysjByWMHq1mmfNmUb5hyiSk/NOXHgwelpqtPTVlsyh2m3GPKSlMeGTxo7FB10i21MmV9U0abMtaU zQcPHvmIbmnKNqa8xJTJprzalNcOSR3+oO5qyltN2XPIqLSR+m5T3mfKB0z5kClHmTJ92JhBg/VE U04x5UxTzjXl3025mM4G6eWm/MiUH6eOGjdSbzSlz5TFpvzSlLtMWZaaNjhVV5rysClPuKUtvDnG DjdlpCkbmbKpKeNNmZjGxb7IlJeb8kpTdjblDaa8OW3MkFH27aa8y5T9HnFfH2jKYaZMNeUYU443 5aSx2NyeYsrppnzelHNN+Zops8cOHzXMXmzK90z5oSlXmXKdKTeNHTn4EbvQlF+bstKUJ9wyrL4p 48aOe2BsWKIpLzLl5aa80pSdTXnD2HGPjA272ZS3m/IuU/Yz5UBTDktn5mGpphxjyvGmnGTKKaac Dp00vGwCI37PIwWz653B1YILv17av6E891/KiF8tNZrRAE7/nkcWCvbz8qzfUCqzekVP7jPLlGLK +r+hjPkNZfN/KaN/Q9nQzEubq3VK6c731Ncif7UMQ/tiUdPgjvj3nsWFnv2WcS2U+dfLqF8pW6H+ t3PGDECdR8mjMkmeIq6ZTSSTTYyznPhmvfiIbL6WMvlWaqTOCreiiVLirTbWpdaV1rXWTdbtQb9a Z4WuzUPXlqHrlex+99o5+Fy1DD5Xs0LPC4NX3Tz4ug7V1z1Dr08MXWeHrr7glZg0eA29by8MXb8M XsM6BK/13jBetRrsCD73XBm6/iE4jufW0PPpoevJ4DUyKci1yB3Ba0x48PWYh0LXTaFrcegaGjem hvE8YLD1omHAA1YWZX1WOs/lgFXNs2ix9R91N32zvsXlh2qkGrH5YlWcaUFdHe3Wdb/7wnUAaBTi znm8H2kdsg7xtJq+LOuEdUKU5ViOaBWmwsRWESpCwtRZ6iwJV41VY6mnmqvmUl+1Uq2kgUpSSeLR tzByBH01YXWT3WlbMfKk1dw6T/5sJVlJMoU49T6ZSmw6Up620qw0mW6NttLlGWu6NV2eI1Z9SWYR j/aU51W6Gifvq8eIjJapiWqiLFdPqEmSo6aoKZKrpqlpkqeyVJasUHPUHPmIaHK7rNRRrLGK2K6D fEck11WOMJtL5Gz1N91D36GH6Qf1w3qEHqvH6cf0BP2Eflpn6un6Gf2snqFfda2gXlOvIVLddXcs dbu+XZQeooeK1g/p4RJG5DdG6ul0nS719aP6UbKB8Xo8KycWlAhiwQyJ1PP0PCyrjXb808bxrhdU J+X6pp5qp9rhmysV+0Zdo67hnc6qM7buqrpi61vVrdi6J3YIp3ZT7Hu5ukJdTesb1S3qDtVFdef1 Br+9FzVZTWbUF9QL7AMlbkYWb7ewW9rn263sBDvRbm23IQdTrDmPnEbM7JueMvsWZuekujVsN+cN 1jj3lBotT3lPuf+jRG2x3VzRspPsJLMv3HFj7cZ2nN3Ebmo3s5vb59jn2uedMq4SN7duZJ9NhBxu 17Pr2w1sjx1hR9pRdrQdY59lN6SOjaWfZApuG0X8fK1E2tfb18MARdzaVGfrt/Ri/Y5epz/R6/UG vVEX6E3aqz/Vm3WlPqC/1Qf1IV2lD+vv9BHtcidcL9AL6PFN/SZzWaQX4XeiedbhjmG7sfuPvS+g 1iLezdMr9Ed6pV6l8/VqvUZ/rNdSr1Tv0Xt1mS7X+/R+/Q3t3N6zdTa9v6XfovfFejG9v6Pfofd1 ejO9V+pq0/ul7v+WnabX06zD2KyEdhJqd5qRf2Gtrq03m3atJNpKse6x+lp9rLuth6xtapyapJ5W L+qX9dv6PVdzrJ7WXTj4QetBCbMKrUL2UrpKZy89oZ6A/S4PGxgeevRcPRcOuBaM1O/qdzkJlFUj xyRDpshUzoBp8rRkynR5hpx3BifCczJL/irPywuSJS9yPswh732JXGeevELu+5r8TebL6/J3+Ye8 IQs4O96Ut+RtWSiLyJb/h5PkHVkq75IZvy8fyDLOlRz5UHLJn1fIR7KSUyafHHqNfEwWvU4+4czZ IBulQDaJVz6VzZxAW6RQtso2KZJi+YzzaDuZ9hfypXwlOyTA6bRTdsluKZFS2UMGXiblsk/2yzdS IZVygJProBySKjks36Ey1ZxjR1nrcTkhtXJSvpc6cVxhJlvure5Ud6kUMuZ7VB/VV/Uja75P9VcD yJsHqkHqATXYzZ3VMHLnh8icH1YjVKoaqUapNPWIGk1W/IX6Un2ldqiA+lrtVLvUblWiStUetVeV qXLy5f3qG1WhKrVHHVDf6gg3d1ZV5M7fqSOqWtWoo+oYOfQJVatOqu9VnZtJa8vNpLWtw3Q42XR9 3UD30r31nWS79+n+eqAepEfq0XqKnqqf0tP0C/ol/Ypeil/f0++T4X5IZuvTW3Sh3qq36SJdrD/T n+vtdie7M7umcVD/jZI/aZR5vr4VRS0mo75dPieXvlf8eoC+X740OrFDP6IfkQCs/ot8rZ/Xz0uJ 2U2lRkv3GG7uNTurjH35tpQbhu4zDN2vl+sc+cbwtNK+xu6IJ5S1Ch/+3+y7n+66/6s9F/iP7Lp/ 3Xc/7LzT771/7j53//1zB843e/C/swtfcvePpazGqE5zYoZYo0AJJnJIsgZYQ+Vio0bt3c+5pIM1 gljiCmKJiXK19TjRUVfrJetVGWAts7bIYDUGfZqkMtVLkmVO9gU6UjeSbPczI/kfHacvkiX6En2Z rNXtiBY2mF33FedZR07eRpyA8dKG+KEDc1rAP7fkTDCPl5hnK0PPVvIswD+03rrYupi5X2pdiiOu tq5mN3azurHU7lZ3sYlx5hKZB6O5JfwjKrD6W8NCryw/5ZWfRxDnmwjiPvWwiSB6q94w7B51D2d/ P9WPd/qr/pz9Q9VQzv4RagRn/2g12kQQrdw7sf4kgujFruhLX0Pw9yNu7HgGsYQ7cj0zcn0zcgMz 8v+r1krgqdra/l7nHDOZ5+mQZLaPISoZImmSzMl8HDnmOMZKzqkMzSVEg4OIFCEaNFAqiSLlhkpd YyWhkJS+dTaVe7v3ve/v/b773d/r/KznrLX23s9az36e//P8F9yYZh5MMy+mGeI/jLDloAU8Ao9B K/gFPAFtoB10gKfgGXgOOsEL8BL8CrpAN+gBvaAP9INX4DV4AwYIeAIBP4Yfx3/ET+A/4Sfxn/Ff 8FP4r/+bMQI0PoHFG6Wgd+Gw6lSAxSwgt8BD7iEHp1k1Khv0N7hL6G8uCAd8D24IJ+ZpXLBqDYT5 kFW18oAIEAkr5q1gK8ygySAZ4Qe7wR5EABwABxAh1nkrIgw9sAJ6bzWogf58G9xBxEEDaEAksdpF CsvBMlgGR7EKxgKrYCzh+hbBFf4HNpuJm39wZ9Bz1LCawQVGzV8xwAaIgk8g4nVDbBuCOPYZrp0T 8kARuG4iZIIaQAdGjzGwACuBGtyHCtyVJiZdYEyxpBtYiEl3sAiTHmAxJj0hK2RJL7AEk97AGJNk YIJJn+/SDJO+wAKTVGCJyUAYpywZAlRhJPLDaMbBngbCOmXXwmJTG7buAIWtByDB1hPowNYL6MLW G0C0gLr0YesDeSoOUIABbH3BUthSgTlsA8Ay2AZCVMBBLVawDQWQF0AutBK2YWA1bDMhB8aBo2AN bI9BRoUihogpYoXYIM6IJ+KHhCLRSDzMbPtgjGXCjJUPs1MZzEbXYOapB6fhDjLhqosw6QbOYNId nMWkByjGpCcoxaQXKMGkNziHSTIow6QPKMckBZzHpC84gdkiC7MCE7NCNmaFHMwKeZgVcjErnMSs kI9Z4RRmhQLMCoWsvWEYp4JJa1grzEFUEB3ECDsbmgM9SwyztThmI4mZ6wlA8vs3P5YlsRMwXpCG 2QprWcwACEDfR4AozB8A83Ec5rl4OCcHrx4GY2ASggA7jhcniBPDSePm4lQxvvx/yX8hkmMc7Qfj 42SxoO8c6l/woO8MivUMd1zgd8xnZQDWGY0YNgt7BE/k28kdMnP+9f00TNoCSpHpYWkjlCFtyM6l lmCVMM4HOHBMhrQqHJqHA4DEg3Kxs6nPweOk2BDUi51bnR0QAMMABwhMO3QdqjFrRCZHLl4GviTW Zy3ijYQjIUggQkFo8NeY9UEVZj2MIPKpV7YrvTi21mHPRxNJq9HwiMxTq5kM0U6Uga+Fv5pMPAQr nMDy65KpnXttLc3HO4Ks+EgnUb7vSwVscFH03dgi8Q4EdmGcixlJFBVmdTiFeZ0o4TRKWDDR3CuU QhJBhVjDHMI8FhFh3l7BkdTAQAqJHz4NjnILs9v7eUXRKCRZVJo1wCMsMj1ANKeE0ai+VLIXjRoS TJJHZVnTeGGxmWl7ahDU4hUUSg3eSDQ3Q+XE+VBdkg6qh2I/LuJ8JFZXV0dXf6H+QhfUbtZiHexI 4qjotP45jpQwqh11Y7AGcUUwWYukjqpOK1L8NoGpItp902VHCYukkinhLKUMoDjbKoANwTMAPwLH uXEMAJDC+rKTDY3EEu6tyWcSI4bOWw931vBf3+h1NddHpr1qol63aAea7By3pyPg2YIT/NebB6JH ovLjQoyup5TwXfb7EHi4/qqtZpHVktHKx24e0risT9oBcifHczPzpepwL7ettu2a4zlgKhN3ie+5 yZ3znYlXPWL9SVr4DLpwwXLifVI4n5NmY7SebqpQhtCl537ap3u7buzao3Zzt0Ki79Xtzk4hEdeN TisnutULiBpl7XhtX8MdXDt1a+WzSxyC6YpbOoznN8tFD2SR7g73Kkp21JYvN8+U8mDKHeh2Hx3c Mry1yBvsH13D87xJ0bEgtbE4KbJ48DLf++41bcxJP2axyOLyxJoqHB46fi69A6U/QfXYOaHHsrFx ABhwqDKq9K2PggQJPxotdJG2dgg5PFQrEto9HNpdixwShPmOrDAAXwmcKDsUOICgZqwxecIi1BBd wNRj6iSgM7eTwwJ/c7f2tK/MdhVzMy14FeapsvMIvCj3t1XgOdE5rEF+li4CjAB2uELYFyRAzzwp iYp/82+8MK+9nRl0NENNkqa+7u+iAk+nIysDJl4737CQISXHZKinXWecAa0yqxvP7XIO7uRUzXWv q08R7iPY8r1bPl8bMTzXfTfFOvORorfouImBwtpQUvzwbsPE8v7+dGTqgUOatdLDwvnWscUXvMze q93vu9vm/qxKfadxxfGKtpdOX6+dvxU3+oD3xFD6lHrLYltpacP54yYrYQx/RRm4vpk45nulPvTo iWqShA4bl3tmZNLv4/hviYyfwxE1nB2OTv+mUm1Uc1qp8l8pZc1Rwv4yJMtsVKyetfjF7pCw8I1w i6u9mEVW/rrE/NgWQUOBeQ7hbRHzqV+sLxFdW7gnmNJqbx0cFbyeyHV0X9ENuPPuWa4BZZ90Cm+l nZzrFl99D7Zdy6YirTvt4nPoxOPFSa45nOM96MSgosHqpdz3O2/L17Y6vKKbVNjmapwGsSM5p/fq T2X1uvmzZS0J6LqeVj3V4Dlh2sfBtHhDXxecpzZSuUtA5e3+p+zMBJvMzSs5+VDZeoETAeOvnIsJ haYZZSr9+8XOGHXZhaxq0T9eEeIjW56mUbWkL+ZNUOyEWK/y2ZJ3GXYXTDVSL8acnnpkW6RKi1s6 sFAux1+sd32Vkt8TJN5cIDE+YCYk61H6nf8wJHm/hyQORVDd6WDUQNVQFaYyUylB8c+CkRYerkn2 wsJPDAs/1iP+RQSyV/9bEaj3+whkveXE6NB2a1tA3PAi5i4Drf1ySTLt6kHk5tXGxtsf5jz5OrGm WtcbFbw1SpN+dOi5xzGicOmWZddsGrf3xYtvPzU/ZaOw5WT9xSNm+Iaj6zaw7d5WEPJe2kZaSWuE ujdQcbyqXiz1LS+t2i+q7U2Gd2JN+IGPybTYuUW5Rzanl47vV920RitC2sqsfaiCj2jfGsVMZ5Cp X7ge7BqKqOI62jYh6KCc6aVzLRZ3bnPCtZybuxU1opv1I68cCneduNS7WpR7bkP3w0d6WitMRY34 PWOVbuf5vkt7EPrGuO8DX9zT5i25kZuoNcfWLkf1FUpzSqS8jdTb9p1W49j8RKLcdfOvx/NCpoyS z6IMghCEgE/TEMCP1CC7jYySBJuNx8gDnaazLUaACBD6LbZ5hBXNQ0Jjwqgb/WhEFbIqkbRwoQFx DZUcFhIe4ksjmoeEhWqR5FCZ6YtFfzsTEjadqxVQ+enXJPFj3jYkhEY0i6D5hYRRaTEseFhogJJI KGowAw86KElHlzTT/QdW9JepHHe1JrR38Yi1tEpWerQ7+jqncO88j49TqatzL0wdzyEab1mXczRn v6dOQPNSn5jBM5F37dtH3hxLkNmftcO3/FZArPfcVlmj5/zgUH9a7XVN38xMP+WMpkUa13krnJVr LPu4jQ3TNApVFhYMrNi+tGsHf1VmoIPXGcaWbE/NqNWvMs77LM60kSFxKolkFfYdVJfoXXKELOLp zEbJkjWwTRw/9e4w7rZ0y3WHZeXJ8dcXDdgfti7+cio2iGZdItGQxqWigDgd8KQaVK0S4jBy/Lph 8qQvN2f+Q7qj07vKxe5i9ChC+9i14vjUqXON21pPSYW5GtVfGeLMVUTL2XfeLSdGCe/snMGNApSe h9JzWHEJCPRMlJ4eL7ChKfQdNezE3HVxImVr9n29lx32///+GH/h4xgqpPbzVO99ny6h//YiUHoS Jfje1VMn6wTPPWO2g0n77y7qVRgZckrRqGAur/N+9/mXhsWLXQoX2FOnlIJM7jacfs625Rlp75Is gVD/qimhtRLU6s9N5l2CLsS1r703l5yWrFM3mKd5jZIttGsePzl33F5mQuFuq+h72zPB5jocXxji H3s2BvKtG7s6bHvnal8t+plI4kqSTVWVWvNYFpc3HP8Cf37Dh9JndU6DlBV3bO0rz+NVhL4eaB3i 3B93Mf1WkYFGd2x3QVRXJBNp8jepebhg1wszoQJ9f2n/Dv2Xj2QI3QXLCHUuuobBa2T4vC9w5+xp eWxvYtko45Af2iG0KDElIuvUQyZEhZuwOCiZKQz8eTLWViOyRYLttbhs3/mXv5EE2X8KEtAFsF7Q Ixno6ZH0WAU8hHidBd8ggZ7/25JBGBWcphvcTl7hfrAUoEE9AlgKgWSDw5biExQS7PNtZdx/trI/ 26YOVPrTNueiCtPbkJo940PBig9WNWKDkQLiz0jCx0ISTgxJbjYQ917p/GpsMxh745HSvLHI+wpf G9UcreuPXWCU6cdoIrUFnI/Jdy/kjb2qqWkt3ZOWw/GJv5Jhm/mGcfuqwK2C6sGAHfvspKtsPvmA 5BqxRww/xDTaYlTI0HqSvO7FpyWXegxKO8kccxdvMtVb/iGg2HJ0fric4r2lknLrKm0zW3KbhG9L mmxiDxpJVbDwWPq2+m6GD/Fijd7nHIvezWWy2hfzn3/I7jyqwD/lTDJzMIwrce7rHlgfM69oXE1b 0MQw2njptlN+3XGKfuK9Kw/VRlvYLs9euyM55Wj1xs2vuSYT8FvHMjYZqZ/yPdLQqfmrOk6KX8+K MmokVDKcKCOrbBvSAH0Pn8sAatAeyn9Uh+P/O+BFiJ1rhoCLQnzB4fEIAaOosnMIYgSReR/VV7nV hdmf7RljqomLTdZM2NFRye+3iOAIvHLciB0SAem6OWKG8mCFD8Y7LFH+7wUWG4qHYlZcYjBG7nrx nu3iudc8PHrNDJJxsveyx5ynJrwodVr4T4ZWZg8qRuZvb+m65WhXUCF5v6F3mDnhWGl1eLlST6H8 09hHY2KxQh3vD0gPcLqV7zxwaY9zlUxDakvqYd0PB59/TTrqvmqFzULlRURpe4PPW11FU24+ldk3 5GVr1MPx1vddzMD++05kSqrECmZsJ+VCp3LxVJ1Q5e2chtseu0Pf13cUMYI5nlIkLxWMJdzgWnpk WPkMNba0Rv3UOV/5vJJEzoB04YvnFmTIseUKG+ZWn0GNLyv8gubXewvJlDjt7RmOFbzsbsRrMJxS cyjJmuDC5nrnQWth28utB6PnT54PztvPrutc6q4myI8y2HQhlElPwxi3l+WJe9hxC+WnE4r/Fsj4 gX0L9XT1FrDYkgGsjWBXn9VFaX/LPmbm8X8y/5clUSM9zbDYNWekpvN5U1Hq3laj4/K7b7olaLkN lYaNFp1J8q9oL1XczFNXl7fqoLui8KuJ0bnHKz4ERxa/GzxpdKe2er2rSVF5uK5yvjfdKybb+0Nw UmpT8LM7WQ9PrhOM9LocuouSnSaWfMqN3mTh29PheMK0/vPTSCUtCxTpad26OVXwsbNsbv9anrtJ T3Na7TIC68n1Gf6Zh9xXrxHs127ZsMHdwzY3XDOvascyvj2SopH3ONsz80NF+9cMUL+4lQXsf6u6 zsBw923LFaKHbY6c++B38pfnXJs20k5E7ZHdGZD+us9jWcOL3k18zWQkZTPpyD6e88JXy5sGhzsV Bgs9vQYNzJfcnC6JGOAQtMi+n7jLDzAYbAsojLBrXDsobS3JLpd7rOjB4S9/gnyFrNG5BHo2Sj8R /4cokk07+U/g38/Fwqpp4meBLkVNmcZMo4RFs4hf0LfnYMwvNIDKGtUODQvxiSDTwrVZAcDyf+j7 OhghXDuLiZqjZqjJdyaKS9CdeW5UVNQfPZcS9vMDaX/ECQ3b3qUaHnU9IuJmH0ztxNX1lU+23Fhz Vrtomz1fu07lR/9evkkFqSjjPL/Y86lxu1xHzGu3H6VsTbJZt4UhMro9/Jeca671uND7yoHiV2xF 8pKrL3RnN2RHHD+4aYl0tSPiWPFxh3K7u+5k67xY98z2/MkPI2ZSZxwsz1o9PWgo7My1Yvg9KVH+ CmHfBiEK/hXPuqZs3l0ZV9tqCpo4RecpVFQ6Jcs0b0jQz6v/cjpxoNDA5IJ5QBdxeNmVuOJXww5l 2VZXKNfs9Nru9rOTCezRwTZfraqOvjZ3Sew4yx0/uv6WRnfPtg0re3RiBhV3HuLVLLfZcPuGqbNz 0cPGLu2axoGgLIMYEoNwD8LmHRwAKL3ivwYcfwPwP46xmfR+VOR7QlUBJA48G/aPp6w0O/PqufAk 3tkn53DpP3o8pDno7FlRdO6PGwkkGLcVEZtqLwc8ZBSZeqR8Mtupe3O4JQkNm3ULL8kH9WYaxi9A 1iBUhIyEISHY4bsvQkOIiCX8Fox9c0QocC4cXsMaISL6iBaCImi2crzSn/o2LSY0ZGOYV6hfzO+r SQIDIKtuBxz94j1e9V6lf+BZZOgNYFe0M0A+723gFseDxesbY1c4FNT0Lnnou0riwIu0BSfua1I3 WJW5ze89cuDN0PmpedudDxuwXUh9MNkimCNYMrik7Zl5ybri/LVk5Y+budotO8mB5fer3ts3c7w+ MWb3gStlKIox0G9pd9Z1BekZqtoau7H0tXXsueG+vsIcxMdU80H/AmKyiPJnN+6xil1Scx8KND2w VZd3OX22s71S8WnNhfpfX/mp5s1ZSGh5JfVxZfvwObpDTEEsj+h5mrPqDfqURpxzmQfCtmfbvOL8 N/ndpzL4E0udT1ZoevAVrvwo12BhUviu52Lrg536yXolL1OWGZWcrMxmwLKIASZ/vDF2EgMMwKF+ lntv/FsONf/gKJWXnXN6ATiIMsz1qMRs3+P58acdAF3v+wwbiZ+V72GC12EdeZBggpef7XpCBIGG I91StjapwfqbXZZFpm1q+wMXoI+RE8LYbT8FML18U9j69j94EbnScOcy29d9xfzZ65uPa1iKi69/ 4bhMckqjW8BpcT1exLn/UGlG2gHDl8lXVDyqZOgvtDPyogWfLmweQyLfH3DmOlrZZlJnWf+ilM4j H7TI83ax/9vViiMyU0s3NYzTPhuSWwdJQZItC7RFXZrrpXpCtW6szgpzyTwuNoZcz2iT8JfraO9U ennvwIVLQSknD15YHDV3tcrS9LMe6/vkp6a4F3uV1d10LFfsqiG8DNRfPgc00rOvJMknuCf77/zV lnl+p36/QHQr2ryvTGU0s7eAYklzvpz6CE+Ki0y4IpW+ZMN9VV7rkc8ktk26T0p0m8QPD/0PEU/w Pw0KZW5kc3RyZWFtDQplbmRvYmoNCjEzNzIgMCBvYmoNCjw8L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMjI3Pj4NCnN0cmVhbQ0KeJxdkE1qxDAMhfc+hZbTxeBkptBNCJQphSz6Q9MewLGVjKGR jeIscvvKbphCBTbI733iWfrSPXXkE+h3DrbHBKMnx7iElS3CgJMnVVfgvE17V247m6i0wP22JJw7 GoNqGtAfIi6JNzg8ujDgndJv7JA9TXD4uvTS92uM3zgjJahU24LDUQa9mPhqZgRdsGPnRPdpOwrz 5/jcIsKp9PVvGBscLtFYZEMTqqaSaqF5lmoVkvun79Qw2qthcZ8f7sV9qupzce/vmcvfu4WyK7Pk KTsoQXIET3hbUwwxU/n8AAevbyYNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxMzczIDAgb2JqDQo8PC9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDQwMTExL0xlbmd0aDEgNzg5MjA+Pg0Kc3RyZWFtDQp4 nOycCVyU5d73r/ueAYaBYRNcAOXGERRRMPctndjEHYUxUFNGGGSUZZpFxJVWjcxsOS0uiGZqaTlM nkKPp2NlZZrmKVtOZafIymosJbVNned3Xf8Bkew8ve953vd5P+/jffG7v9fyv7b/9b9vFgUmMcYi cVMzQ0bu2DGL38s4zKTOZxiLyc9My8iLyJxQzFheGKxqM9MmpO+cM+Iexqb2Ykw6NSYjM4slqktg fwzt3cbkTM59fUP3rbBfz9jOyDG5xrTmY0ENTGIuxjork3NT+1c84vgBfQ/CvrCo3GQds/XrFxgL /4AxuV/RAoeSeDZ1JmP9DYz5nSuxzi3f9E3aTixQw1hgh7kmu5V1ZnrM3xn9w+aWVZdMXlGD/kMH ov+bpWZTcVPBri8w/gS0Dy5FhW6/Ng/lO1HuUVruWBgeLG2ELdYf6iqrLDK9tOnlBsZGoFlzoNy0 0Bp2Puo52G9HhVJhKjfft2/VA4ylH2AsZKC10u7w5rC9jE35ibdbbWZr+Ms/Yb9dYxmL6s64L/0Y azYlJM4OHXmedcGycf3l2yVvcr6Udkp7MfSyPfCbgDrYBjKZ0YV+/uwykw5oF6PdFPiNGKnNpari NWoTm4zxw5CXcU9lhYwFx4p5JaZSJ8j70Krxe9xvAIbsRlQdY3tlpmFyaICsUqtVsrqeyd8bmLK4 ZeyJuYrCkH5V0xoC6uREhbGNYt79fiF8pxg9hF2/rl/Xr+vX9ev6df26fl2/rl/Xr+vX9avNJa9j X/5um4W99X9zLf/qUl30nuf6717H9ev/2KXyKdb304QMlCRRVrNejP/IQS1+khCvdPB6URZUJX1u av3pg7/kETzb/ucRoh/99EJm//ry9VSN+7f3c/363Uvl+HdHMGTNnnXLzBnTC/KNeblTp+RMnjRx wvhxY7PHZGVmpKfdZBg96saRI4YPGzpk8KDUlL59eiUm9NB3j+scGR4WqgvSBmoC/P3UKllifTL1 WYWKK7HQpU7UZ2f35WW9CRWmNhWFLgVVWVfbuJRCYaZcbWmAZUk7SwNZGlotpTBlJBvZt4+SqVdc RzL0SqM0fUo+8vdl6AsU12mRnyjy6kRR0KEQH48eSmbn0gzFJRUqma6sBaW1mYUZGK8hSJuuTzdr +/ZhDdogZIOQc/XSWxukXqMkkZF7ZQ5vkJlGx6d1qRIyTcWunCn5mRkx8fEFoo6li7Fc/umuADGW YuFrZvcqDX32165qDGNzCpODi/XFppn5LpUJnWpVmbW1K1zhya4kfYYradHJztiy2dVHn5HpStZj sPFTWyeQXH4JYXql9jzD4vWnPVfXmHw1/glh5xnP8i22ugntLXmGtWGF2F98PF/LvY0GNgcFV82U fCorbE6MmxlSkwtcciFv2d/SEmXkLTUtLa3dC/Xx/KgyC30fC0o7u2rmKH37wPviIwEfaFdcqsTC OUWlnCZzrT4jg/yWl+8yZCBjMPn2mtnQLxX2pkJswsLdMCXflaq3uiL1aWSACoWfgSU3X3TxdXNF prtYYZGvlys1M4OvS8msLcygBfKx9FPy97AB3k8bBioxzw1gA1kBX4erYzoOJTGzNr+4xBVXGFOM +CxR8mPiXYYCuK9An28u4KekD3MlfYrp4sWMohf21s66xZjvPCBBo+TLMaoCflqoULJw06eNREMY jksU+YmmjVTypRjWYoZZfBY8d9U4KKgS0rN5k4p3Tc+OiS+Ip+tfLCnGtya/BJemzVhhqGhdE83z u0sja76gJCXTnNFmgVcN6udboG+0a69T5r7wTYweGn6c2S1NqgQ8uaiTMYyo4qfYWXGxHCVfb9YX 6BFDhpx8vjfua3G+43P146dMzxen7YuSvKtK1D6USi4Wj+aWgpyOGMxKjmk5VlEeI8qtxex2zWNb mpVajX58bi0fXO8bkCl4grBp/8SxpnuHRgzEo5mFt5s+y6RXwpSsWlOjt2ZObYPBUGvNLCwdzsfQ jy2u1efmj4wRa52avzRmEZ8qgo2Xxuel9e2Dd09ag15aOaXBIK3MnZ6/J4wxZWVevluW5PTCtIKG HmjL36Pg3S5qZV7LK3lB4QU+0lQUNMI+Zo+BsRrRqhYVolzUKDFRp2mpk1hRo0x1YS11MurUVGcQ dfzCIXUuhYvxus1UivnxLCkorS0s4A8X64ijxIfkkvSjmEvWj2qQZP9gl1ZvTnMF6dN4/WheP5rq /Xl9AAJD6ijBOfydVFuox3sKAZXPYiQKRRUfUmn0evPy44/EnC6IR6jNhKbnuwKT8e73SxgHuzFc hage46opMvF1MGM+7xuQMLaoAGHbMiBMxroCMUKgbwRYZIk+PBzRqQhngwMU/WtQcNUUuAqS+aT5 lgIRzmEulq0fjmOnMf0S+USpBbUR+v7i2cSjoE1YwRGItbHcfKqJQRGTFZCTAoKx8iI9mooKFXhb zYpyEer0LtXGUI0Zr0R1ollIG+NrZHxbqoQgndYVmIIB8cHzQSn8kfRLCCgooMWL0gqfAeYOcwVh RYltXOnrAO+gaSxfCz5WYKnc9CU+zJRGNlW/EG8WvmgxUgCaXbqEsSa8/Kl/EGr0Q1s6a/g7Isg3 xgGqDeA7D4bfVQl5jd5t+ur4NlffPnr+yYEHJovZg8BmBbXtK1wzkvv20bSv1Ynq2lqN7todyF8a XStRyRoCVY3yz+5uXeMa5Z/c3ZKBH93d+gAXCOcJ56jtByo1E84SzhC+J3xHlqcJHqr8lvAN4WvC KcJXhC8JXxBOursFAp9TqYnwmbtrBPCpu2sX4J/urqnAJ4QThI8JH5HJh1T6B+EDwvuE9wjvEo4T 3iG8Tfg74RjhLcJRWsQRwpuEw4RDNO0bZHmQ8DrhNcKrhAOEVwgvE14i7Cf8jcZ8kfBXqtxH+Ath L2EPoZHwAuF5wp8JuwnPEdyEBndsf8BF2OWOHQA8S3iGsJOwg/C0O/YG4CnCduq3jbCV8CRhC+EJ wmbqvolQT9hIqCNsIKynodcR1lL3xwmPER4lPEL4E/V7mPAQ4UHCA4Q1hPsJq2no+6j7KsK9hFrC PYSV1GEF4W7CXYQ7CXcQbnfHDARuI9QQlhOWEZYSlhAWExYRqgkLCVWEBQQnwUGwE2yEWwlWQqU7 ehBQQSgnlBHmE+YRLIRSwlxCCcFMKCYUEeYQTIRCwmzCLMIthJmEGYTphAJ3lyFAPuFmwjSCkZBH yCVMJUwh5BAmEyYRJhImEMYTxhHGErIJYwhZhExCBiGdkEa4iWAgjCaMItxIGEkYQRhOGObuPAwY ShhCGEwYRBhIGEDoT7iB0I+QSkgh9CX0ISQTehOSCL0IPQmJhAR3pxFAD4Le3YlHcnd3p+FAPFUq hDhCN0JXQiwhhhBN6ELoTOhE6EiIohkiaYYOVBlBCCeEEUIJIQQdIZgQRNASAmlMDSGAKv0JfgQ1 QUWQCRKBCUhewmXCJcJFwq+EXwg/E34i/CimlS6IHUnnqfIc4QdCM+Es4Qzhe8J3hNMED+FbwjeE rwmnCF/RfF+6O+qBLwgn3R0RWdLnhCZ3x6HAZ4RP3R3TgX+6O2YAnxBOED52d8wEPnJ3zAI+JPyD 8AEN/T7hPRrsXRrsOOEdwts02N+p3zHCW4SjhCOENwmHqd8hGvoNwkFa/OuE12i+V90d04AD1OEV muhlWvVLNNh+wt8ILxL+SthH+AthLw29h4ZupKFfoKGfJ/yZsJsmeo7gJjTQtC7CLsKzNPQzhJ2E HYSnCU+5o/DClba7o24CthG2uqMmAk+6oyYBW9xRk4En3FFTgc3uKAOwiUzqyWQjmdSRyQZqW0+W 66i0liwfJzxGHR4lPOKOygH+RN0fJjxEeJCW9ABZriHL+wmr3VFTgPvIchXhXkKtOzIfuMcdWQCs dEfOBFa4I28B7nZHjgPuckfOAO6ktjvI8nYyuc2wCzwTmhn3fUh23KfBk+Jehl6C9kN/C5oW54Ya IBe0C3oWegbaCe2AnoaegrZD26Ct0JPQFugJaDO0CaqHNkJ12tK4tdDj0GPQo9Aj0J+gh6GHoAeh B6A1gaVx90OrofugVVCjtNzdgT99y9wRPJIcBLs7nEeSjXArwUqoJFQQygllhPmEeYSRhBHuMI7h hGGEoYQhhMGEQYSBhAGE/u5QHpY3EPoRIgjhhDBCKCGEoHPjDBqlYEIQQUsIJGgIAW4dP1l/wwzw O+g05IG+hb6Bvsbp/RP6BDoBfQx9BH0I/QOn8AH0PvQi9FdoH/QXaC+0AZ5fr+WeriFPL3KH8wiv JucsJFQRFhCchHRCGvnhJoKBMJowinAjbTmKEEnoQFhM0+bSyU6l2acQcgiTCZMIEwkTCOMJ4whj CdmEMYQsQiYhg9CdEE8LVAhxhG6EroRYQgwhmtCF0Jn20InQ0bAOvARdhH6FfoF+xiH+BP0IXYDO Q+egH3ByzdBZ6CvoS+gL6CT0OdQEfYYTPAK9CR2GDkFvQAeh16HXoFehA9ArUCP0Ak71eejP0G7o OWidOOGl5OMlBIs7PAUoJcwlf5QQzIRiQhFhDsFEKCTMJswi3EKYSZhBmE4oIOQTbiZMIxgJeYRU Qgr5uC+hDyGZ0JuQROhF6ElIJCTQofQg6Al+BDVBRZAJEj1uzLAZ9EKXoVPw6HvQu9Bx6B3obejv 0DHoLegoPLwHukuVEHenKiXuDikl7vbsGuNtO2qMy7OXGpftWGoMWjpi6filqqClMcDipTuWfrTU f0n2IuPiHYuM6kWRi2RtdXaVceGOKmNQlRS8INtpzHOedJ5zqiKdec5ip8P5sPM4KgK2OHc7DzhV jd79hgjn0BFZNc41TjkS7TJzSqG8Ot4ZFJLlyLYZ7TtsRrVtoE0ecdImHbNJsmKTDLYcmwyr52w9 emVxa6+tY3QWsym2fjbVrdmVRuuOSmNFdrnxrXJpPrYyD1uypMw1lu6YayxJKTaadxQbi1LmGE0p hcbZKbcYZ+24xTgzZbpxxo7pxoKUfOPNsJ+Wkmc07sgz5qZMMU7dMcU4OWWScRLqJ6aMN07YMd44 LiXbOHZHtjEnWxqTkmXMVA2OY3ES64YPa7eabme6qYMKu1q7ytaun3Y901VljT0TKy+PkUKjl0ff H60KxU2mW5e4Lvd32dhlVxe/UJFRBVsjaiJka3hNuNwv3BB+LPzTcDULrw+XQ+8P3Ri6K1Q1OXR2 6Peh3lD1rlBpV8jfQt4KMRSqJofMDqkMUYWG8BpVmCEk5YasUF2cLlWnGpmqG62brFPdr5MMupT+ WQZdj55Zo4MnB88OVm0MlgzBiUlZ32u9WtmgRcP3gd5A2RsoMZWkSBKTwgCVBl7eLUXFZan28f8j zfyYJK1pyMtNTh7fGOCdOt4VmDPDJa10JeTyu2HKdJf/ShczTp+R3yBJqwsaJDk9zxXJf5Arynfd dx/rmjbe1TU3362qr++aVjDeVcPzBoPIe3mewaQgeZbdabc7ku3JuEGz7KhxOPEhIOEOOh28xWFn MEn+nctOsjtnO9EXhVl2Ox/VmcxLXHyG/7mX9N+9gP+xV+fZs/i/HAfUMXb5oTb/lHwb0nq2g/2Z 7WUvsUPsHfaDpGWF7C72N/Y5+4Y1s1/xMAZIUVKslPTv/rv1levyHX7lTKfaz/xZJ8a8v3i/vvyU 92s88yFtah5CqZM68UqNN8J7un3d5YcuN14+6h/EwkTfMPkwas9Ip72/yKN52TuYl+UVPC96nAmo u7zr8sarlmNlNuZkC1k1W8QWs6VsGVvO7mB3sxVsJbsHvliO/L1sFbuPrWb3szXsAfYge4g9zP7E HmGPssfY42wtWwc/bmB1bKOvjZfrkB4RrbxlM9vKnmI7wSfYFvYk28a2o/w0vL+TPYs6qqHyM6ip Z5tQuxW13IrX7UJysQbmZs+x3TgzKreUGtl+9jx7AdyD0/wL28f+yl7EOe7Hyb4s6nhNS/n3Len+ CjvAXmWvsdfZQfYGIuMwe5MdYUfZW/9bLa+21vDSMfZ39jZi7Th7l73H3mf/YB+xT9g/2aesCVHn +U37B7D4EDYnfFafweoL9jUsT8OS7MjmY9F6SoxwHH0/ZSclDTsvyexX5kWOn94j4oQeF+fIT4+f zhbhZ34eu1DmJ7St9WyegY+fwXnyEs+v9Z3Gs7BtgAdb/Hdtrx31nQ75ex9suC94yxGfL173nQQf 58XWvodFm1v0e7l11CsepR2+28Y7H7fx4RfsS+EZ8h61XvEetzgJG+5lPsbVvm1CX/I+78vr2/bh bR+i/DXeDh54mvNbcRLfsq9a81/52k+z79j37Ly4n2Fn8T75gZ1D+QJqzqD029r2NT8i/cR+Zr/g BC+yS21Kl9q1XGKXccb4qkGSJRW7fCV3pVZILflJ/ninaaRASSsFSzopRArF1yAB7VqCWlvCf9MS fI22QFETIXWQIvG+7CR1lqKlGLw3u0rdpDgpXurepq1La4uCFr3UQ0rwtXUUPbu09o2DRac2tklS P6kK92QpRUpF/gZpoDRIGiINQ01flPujPBxt/QTT+O+4XbarPsLbUcUC2DA2kU1iefuYTtqAV+hw 6fDujAxN34AXUZSZIh1mGrhqg6GDWtbFxIzWD/JfpZoSPnZ0wCo5j42+9MmJ13A7EjEs9YiUeuL0 e6fDLr0WPiz19PHTN/STwuPDhSJD5IAAf3999xR5UM/EwQMG9B8lDxqYqO8eIou6gYOHjFIN6N9N VkW21IySeVlSfXRxsirzUg+5On5E7g1+UnJCp7gOGo0qrpsuYYASOn6ifnCvaD+1xl/lpwnoOThN b6wa1/2otnPP2K49O2vBrrHgpZf9Qn5p9gv59WZ1xq/75FPD8kf18K/WBcl+gZoNvbpF9bgh9sbx ulCdX0hMp+jYAE14iLZ3tunS49EJnbTaTgnRsQl8rIRLI+CRL71nZeZXyqJYEovbxzrKjUxhUfLq 54P8EmImhmWx0aNPHJV8DghR8d30VPm2E9Wh/f4+k7RdkuOU3l20UnRw3KBevQbG6fx08YOTkoYo Op0yJClpcLxO2q4NC/L3DwrTqlbpInX+AboOul8nJw3tHhrafWhS72H60FD9MP5/+d7yfi19oK4Q a1P42jaLtW1+PiisN1ZnYVha2IGWxbWspXV14e1X96K2U5IS37tTYHRg7KDk5AFdA4O7DeiZOCBO p4sbkNhzQLdgqSRQp/Xz0+oC5eMhHbC04A4hFwcm9FdCQpT+CYkDOQcyyXteelutljeyUBbuZgFB eySFqVnqaSn1CF+Ivz6+eyKiYEA8ZlWro7pcnBQdFRWtcgdHaP3loUNSU4cMTdV26cm8Xu95eaha rfKT/VUOVoLP1HXX0/V0PV1P19P19P9I8rRN+DrsvyLNkkqup/8fE76G6St3Z/TbHowVizvPSyxE lHheZhpVb9byWyHDVWpfXs06q6J9eT/kR/ny/shP8+UD2C+qCl9ew3qrTvrygUxRl/ryWrm+da4g Nk290pcPZr3Vn/jyOvkxP40vH8LKAupbf6+kvybYl5dYgGaULy8zdeAmX17Fugau9uXVLDjwcV/e D/kdvrw/8i/48gFsaeArvryGRQVe9uUDWZjW4MtrpZzWuYJYsjbHlw9mUdrFvrxOmqBd48uHsMFB H/PfolEH+vxMefIz5cnPlCc/U578THnyM+XJz5QnP1Oe/Ex58jPlyc+UJz9TnvxMefIz5cnPT+HL +P6sH9Jg5CYyCytiNlbJ7FAJc6AuHTkbs4q7CTUW5CpYClpuYmVICpuKurmsFG12UTKDZlgvwL0Y lunoVwabOaizwMIi7ExQOcYqFrYVKNlRVyHaqL8FK1AgE+wsGKEapSrkHJiL2zgxogP1ZpT4mp3o XYz2CqyGj1LpG9UBi3LfnNxCwR4rxZx8FrvYy1ix1xLU8D06UW8WPWyipkys2uHbRxFa+oiRy0VN mRjRBB9Rfcss5RinTHjM6ltlBWrKxaw0Jt+no80K+IxWsRfyd4u3ae18pkp4QMH+yeN8VeWwNWF+ hyjxHTtaz4N8RrMoYu0Vvn1VCt/OEZZXVtx2R9xrC0U/2vV8lFNEPLQ9zZ5itHIxQrXwg9N38m39 zU+M9m8W6+f7p3OxiWjgpBn5WSsYw9q6G1rjXJ+NHaVFvtEd2AWd0ILWUzKJGDGhtvyqfbVEcxFW YhLzF/nmT7lG1A//zT4Vloa2Mow2vPWJGcSm+SLI4ou1QRiNt1zdt29r32s/CWZfTNMOTb49zRWt tEazz4t83cUimvke5otzbOlz7daS/6Wn+koE0XkZUbKINfD5c8UT4LjqbFN9K6hss4Mi37PoELs0 i/iegJoi1kucexJsisX4Y8SqqK8DyQrvpiJViZQinvurV54iRi+HjQPxxtc/V+zAihGqUctPtUTs hT9NV4/aUs/fKHQC81vHKxBrpkiuFhFoFyt0iGfNLt4N1FsRe+DPqVlEmUXMQR6aI/q2eC8T/puA tyT1tbVpoWe8WPjkynNbJeYqEs/1tealMrctQhQ5hQ+LW5+DYtHO3zS0g5bYt4qdVviin8Yyizt/ mtvvm7fTW6MXeiWJ6CzHvsytz/FvV1Xxm5H/uI+ujN7y5lZ8716KnqKr3oG/3fuVeL16XSPaeIDv hPZCnwlaot7W+lmlWLxXK8T71fS7OyU/m67yqdkX/e2fAe5VHnlO0bNYvKP4bsyt43DLMvGe+1cn 9F/1XFx5JlLFavgzQJ+dUsRZWdnCp5T+/foNViZaimyV9soSh5JeabNW2kwOS2VFinJTWZky1TK3 1GFXpprtZtsCc3FKuqnMMsdmUSx2xaSUVxabbRWK3VRhV9BuKVFKTOWWsmqlyuIoVezOOY4ys2Kr dFYUWyrm2pVKmDrM5ehZUawUVdoqzDZ7ijLWoZSYTQ6nzWxXbGZTmWJxYI4iex/FXm7CCopMVuR5 l3JnmcNixZAVznKzDZZ2s0MMYFestkqsmy8bo5eVVVYppVi4Yim3moociqVCcfB9YGXoopRZKjBX ZYkyxzJXDEwTOcwLHehsmW9OUXzb7GlXyk0V1UqRE5undTtKMb+5SrGZsBebBdtGR1O54rTyaTDi XNTYLYtg7qjEhhbwLZmUKpOtnObibi4qNdmwMLMtpdX1w1vmVNIqy4qH84MZNA0OwpaUQSn9+vla +/LWNodghqcxoQkzzbXwFZmxRJup2Fxuss1XKnlLm2LJtY9aOAj7MlZYHOif6zA5aLepGKBSTFCE U3TYLGZ7ygRnUS+TPUkpNitjbJVodTisw1NTq6qqUspbBk8pqixPdVRbK+faTNbS6tQiR0llhcPu M+X5EhM2MJ/bFVQ64eRqxWk3YxHYEm9WTDhTs63c4uALmlMtlpdpnHATWm2igBMvdtLZVpVaikrb 9AUtFUVlzmLui0ql2GK3lmEC7n2rzQKDIliZKxwpSsvclRUIjV6WJMVcPod3ujJURYvxNVckzHlw w/12uKeIIrB1duFX31gjxAJ6WTALHgLueht/VIorqyrKKk1tJ8WaTbRSOL71BCqdDqvTAbcvsBSZ uU2puczabkN/5CzESaQWm0tMeJxSTHbrQt/3isw7kf89w2tcEizw3QYLZQFeL+6y7zssJvG/HaAw 9pu/CXDVpRqncgYHS7CRsv+ovU4n7Ev/qH1oqLBf+Uftw8KE/fY/ah8eLuwP/lH7Dh0kCeS/i68R f1uBf6eK72L53z5ArQ75Du3aO7Vp539hMbJde3Kb9lDko9q1G9q0h/Hx2rXf3KY9HPnO7dor27RH IB/Dz1kjSxr1fn6x/fslf6b2vxgoS4FUdaVOK0tav/1XKgOYOuBykCwFtVTyWlnD/DReb7AsB/vv v7reH/U6WdZdqRcN+JY40FvjrfF5XMsWSlqmKqq2lbHIuTbzfNa/zOSowM61TMqdmqawSESxV8Sn vy8n4Ttp7nkq8T9/GcbkqZMnKiw6b+p4hfXwtfAIp5wao1HOD99VBxdZ7VY2TtxzxH2auM8U9zni XjofnwZZhbg7xH2RuNeI+93ivqo1av6zu/Sf3GXsLcRXChM7kvAZXcKq/fB1T47YgZrdzv+KqpzD lstb5PdZvWqDagM7joBfz70hL1T/cq0U0C+gn/bB4PorSbeVEm9pn0JWRgxuTR8jXYi40GFmh5md HuQpel/7FNAvxt3tYNyDlOLvvJK61/HUs/M10+rkLS0p9VD/mS1pyAVKw1f9No3YOmLryIdvnHcl jepBibe0T6NeG+1pSYZJv5PyDYcMh246x9PVLemJ10ojtqafyozI3E0py30ljXHxlP3sNdO5sd+1 pHEfj9/ckibspDRx0bXSpH2T9uWETKlpkz7hde3TVE1OSE7IVA3vk/sgT3mftiQaadqoadnTpk97 eNrRmzU3p00bdfMEntrPl7/1WomvISck31MgU5qefSXxuWas5fepGq6ZZ2ZPakmmnXO2tiSzmlLJ hyUfzg2DRiEtnLt57sfIb0a6XJpd+qBIx0ubS5st/SzTkQotyyy7oWWWvZaf5g3mybJsXtm8u5G2 z3PPa5zXNK9pvnr+JKTC+fPmP+xLz5cpZavLdpc1lfdBGlyeU24rX1P+ti+dLP+u/GLFcKTsyujK NZXNPN3qss0S6aK9zn7Ql962XUT5oP2MKJ1xJDoS7Qcda5zdnCOds6piq2IX7q3Ou9VF1uAZsqr+ httV/7Ro8KLSRWsX7V/0DU+Lhy5eJpJr8XtLIpd0A11L+iHNW7JlydNLji0NQZqw9BHYDV26b+m+ Jf1w/47nlu5bxpZFL8teZhPJszxNJMfyuuUHcHcsP7r8zPKjsIiuCakZWDO8ZiXS0dvYMg9sj1LL bd2XH5026rbs2+fcfu6O1XdNuGvaXYX3DF5lWLP1AWsLHxr30LhHgx/75LEzayPWxq6dvnbJ2rvX rllbt7Zx7aG1nrUX1rF1Ieti1/VfN3LduHX56zavO7Duw/U91vdfn7F+0fqH1x9df2pD4oa8Davr NHUpdcV1a+t21h2tO7Wx98bijVvrlfq0+rL6u+sfq3+5/nj95U3Zm27f9PGmy5uVzf03j9w8a3Pp 5trNb26+/ETOE/OeuPOJF584tkXeErulZEv9lqYn+zxZ8uRjT773pGdr962Grau3vrktYlvhtrpt x7cvYPexCO8p1gGKhKKgjlAnqKf3K9YLSoJ6Q8nQcBaL7ydj2XjvSTYBmghNgiZDOdAUaCqUC02D CqBibyEzQyVQqfcEs0DzoPlQGVQOVUCVkBW6FbJBdu+jzOF1MSe0AKqCFkKLvAVsMbQEWgotgx7w fsAehB6CHob+BD0CbYW2Qduhp6CnoT34/ncvdAj5w9Cb0BHoKPQWdAz6O/Q29A50HHoX+gD63LuI nYS+gL6CP05BX0PfQN9CHug09B30PXQGOgs1ezexH7x72DnoPHQB+hH62buC/QL9Cl2ELnlXSGu9 L0nroPVQHbQRqoc2QZuhJ6At0JPQVmgbtB16Cnoa2gHthJ6BnoV2QS6oAXJDz0G7of3eo9Lr3lek g9Ab0CHosPcV1UTvTpWRdVHls1DVdO8M1QzvZtUscDZo836lehG++4CpsSs/yB8KgDRQIKSFgqBg SAeFQBHeJkRYEyKsCRHWhAhrQoQ1IcKaEGFNiLAmRFgTIqwJkXUCkXUCkXUCkXUCkXUCkXUCkXUC kXUCkXUCkXUCkXWCzfJ62GyoEDJBc6AiaLn3AquBboNuhx7wNiM6mhEdzYiOZkRHM6KjGdHRjOho RnQ0IzqaER3NiIqziIqziIqziIqziIqziIqziIqziIqziIqziIqziIqziIqziIqz7IT3V/YJ9E/o U+gzqAn6HG0noS+gZqz3B+zvHHQeugD9CP2Etp/BX6BfoYvQJW+TJHu/kFSQGvKD/KEASAMFQloo CNJBYd6vpHAoAuoARUJRUEeoE9QZ6gJFY9xu3k+kOEiB4qHukB7qASVAiVBPqJf3DSkJ6g0lQ32g vlAKlAr1g26A+kMDoIHQIGgwNAQaCg2DhkMjoJHQjdAoaDRkgG6C0qB0KAPKhLKgMVA2NBYaB42H JkAToUnQZMiIvUyDbobyoQJoKda9DFoO1UC3QbdDd0B3QndBd0MroJXQveizFloHrYfqoI1QPbQJ 2gw9AW2BnoS2Qtug7dBT0NPQDmgn9Az0LLQLckENkBt6DtoN7fcell7yfiC9DL0CHYBehV5H/UHo DegQdNh7GE/ZB+wOPGEePGEePGEePGEePGEePGEePGEePGEePGEePGEePGEevGPfwTv2Hbxj38F7 8wTem014bzbhvdmE92YT3ptNrNp7FO/OvXh37sW7cy/enXvx7tyLp8WDp8WDp8WDp8XD7sBTcCd0 F3Q3tAJaCd0D1UL3Qqugz6GT0BdQM8b/AZF8DjoPXYB+hH5C/c/e9xHd7yO630d0v4/ofh/R5UF0 eRBdHkSXB9HlQXR5EF0eRJcH0eVBdHkQXR5ElwfR5UF0eRBdHkSXB9HlQXR5EF0eRJcH0eVBdHkQ XR5ElwfR5UF0eRBdHkSXB9HlQXR5EF0eRJcH0eVBdHkQXR5ElwfR5UF0eRBdHkSXB1HhQVR4EBUe RIUHUeFBVHgQFZ7/YO7+4+su6HuPf8/O3O7Y9fZussuq9+Icmxed+ANx/gC1okXlR0NRUGlHxdH6 WMcGl7Zb6xU3pGrRrpQGiA8JkEoppC0lpiSlMacpkp4krQltzprkNDk9zcnJOTnhm7YntIeWTM59 npq7cV3rQ9w/94/3o0VHzvm8P5/36/P5JifOVISmIjQVoakITUVoKkJTEZqK0FSEpiI0FaGpCE1F aCpCUxGaitBUhKYiNBWhqQgjccns8GcnddEe2lsOo9dj7Y10E4J+wpPtuXhZxMsiXhbxsoiXRRt5 ho08AzeLuFnEzSJuFnGziJtF3CziZhE3i7hZxM1icItnooW0iO4zLeuomu6nB+hBOvPmPN/mPB8j UxiZwsgURqYwMoWRKYxMYWQKI1MYmcLIFEamMDJlW5Zsy5JtWbItS7ZlybYs2ZYl27JkW5Zsy5Jt WTI1JdWfit5oA80LPha9yZ8Lgo8FH5KJfTKxTyb2ycQ+mdgnE/tkYp9M7JOJfTKxTyb2BTO844+4 Yy6lW8oj8jEiHyPykZGPUD5C+QjlI5SPUD665aNLPrrko0s+uuSjSz7y8pGXj7x85OXjsHwclo/D 8nFYPg7Lx2H5OCwfh+XjsHwcDnaUjwQtdLJ8LHi1/LJH55cjAUXKL6suEf0i3Vh+SYXn6PFLKjwn eFGFq1W4WoWrVbhahatVuFqFq1W4WoWrVbhahatVWGO3Fu3Wot1atFuLdmvRbi2eeVbK93Pj/tc1 KzeVR+3YUTt21I4dtWNH7dhRbuU5M8mZSc5McmaSM3WcqeNMHWfqOFPHmTrO1HGmjjN1nKkL1p7e yfvM3T5zt8/c7TN3+8zdvqDGf/d9eohq6WF6hB6lOlpPP6THaAM9ThvLL5jVF8zqC2b1BbP6QrDZ f76FttLT1EA/okbaRs9QEzXTdnqWdpS36tjW4Mf+3kox2klttIt+Qs9TO+2mOHVQJ3XRnnKvXPTK Ra9c9MpFr1z0ykWvXPTKRa9c9MpFr1z0Bn3+nX4a8PekPw/SIA1RytQcojQdpmHK0IhJzdIo5WmM CjROL1JIE3SEjtIxKtKkyX9JEo7TCSrRy3SS56f0+RWaon+hn9Gr/vNyeZ+J3Wdi97lHOt0jne6R TvdIp3uk0z3S6R7pdI90ukc63SOd7pHO13GPhO6RjHsk4x7JuEcy7pGMeyTjHsm4RzLukYx7JGPf h/Z9aN+H9n1o34eRLwcXRG4Oro98xZ9/GVwYuSU4P/LXdKev/Q2SXHdA3h2Qdwfk3QF5d0DeHZB3 B+TdAXl3QN4dEEbW+vM+WkfVdD89QA9SDQpfX54rsQtOp1VSo7ciwzsk8AS2lLClhC0lbClhy0ls OYktJ7HlJLacxJUMrmRwJYMrGVzJ6ORxnTyuk8d154juvKQ7L+nOS7rzku68pDMv68zLOvOyzrys My/bGaMuiXGXxLhLYtwlMe6SGLdHQnskY49k7JGMPZKxRzLBb/FpBp/O59MMPp2DOiXEKQUz0SaB Ngm0SaBNAm0SaJNAmwTaJNAmgTYJtEmoNSX1lfugIOUFKS9IeUHKC1JekPKClBekvCDlBY6FHCtG 3ohRTRjVhFFNGNWEUU0Y1YRRDRjVgFENGNWAUQ3YtBGbNmLTRmzaiE0bsWkjNm3Epo3YtBGbNmLT RmwqYlMRm4rYVMSmIjYVPWXmPGXmPGXmPGXmPGXmPGXmPGXmPGXmPGXmPGXmPGXmdKugWwXdKuhW QbcK2BTHpjg2xbEpjk1xbIrjTDvOtONMO86040y7nXiunXiu7MdlPy77cdmPy35c9uOyH5f9uOzH ZT8u+3HZj8t8XMYLMl6Q8YKMF2S8IOMFk/G8yXjeZDwv4wkZT8h4QsYTMp6Q8YSMJ2Q8IeMJGU/I eMIUdZiiDlPUYYo6TFGHKeqYfsboMEkdJqnDJHWYpA6Zzsl0TqZzMp2T6ZxM52Q6J9M5mc7JdE6m czLdL9P9Mt0v0/0y3S/T/TLdL9P9Mt0v0/0yPSjTgzI9KNODMj0o04MyPSjTgzI9KNODMj3oCky5 AlOuwJQrMOUKTLkCU67AlCsw5QpMuQJTrsCUKzDlCky5AlOuwJQrMOUKTLkCU67AlCsw5QpMuQJT rsCUKzDlCky5AlOuwJQrMOUKTLkCU67AlCsw5QpMuQJTrsCUKzDlCky5AlOuwJQrMIU5g5gziDmD mDOIOYORm4I3y9NF8rRAnt4jTxfhzsWRRRL41xi0zJ9/R39Py2kFfY2+TneW07iUxqU0LqVxKY1L aVxK41Ial9K4lMalNC6lI/f4d77nNVf7859oDd1La6XqPlpH1XQ/PUAPUg39oNzteu12vXa7Xrtd r92u127Xa7frtdv12u167Xa9drteu12v3a7Xbtdrt+u12/Xa7Xrtdr12u167Xa/drtdu12u367Xb 9drteu2ONHkvzbSdnqUd1EI/plaK0U5qo13lJ1BrM2ptRq3NqLUZtTYj1lbE2opYWxFrK2JtPf38 s8dNezFy5JEjjxx55MgjRx458sgxgBwDyDGAHAPI4dYL3uYSfhuCDCHIEIIMIcgQggwhyBCCDCHI EIIMIcgQggxh92LsXozdi1GjBzV6UKMHNXpQowc1elCjBzV6UKMHNXpQowfnv4wca5BjDXKsQY41 yLEG56/G+atx/mqcvxrnr/YkNyNYSd+ib9N3aBXdQ9+l75FbDnUSqJNAnQTqJFAngToJ1EmgTgJ1 EqiTQJ0E6nwcdT6OOv2o0486/ajTjzr9qNOPOv2o0486/ajTjzr9qNOPOv3o8jC6PIwuD6PLCLqM oMsIuoygywi6jKDLCLqMoMsIuoygywi63IMubejShi5t6NKGLm3IMh9Z5iPLfGSZjyzzJTsr2VnJ zkp2VrKzkp2V7KxkZyU7K9lZyc5Kdlays5KdleysZGclOyvZWcnOSnZWsrOSnZXsrGRnJTsr2VnJ zkp2VrKzkp2V7KxkZyU7K9lZyc5Kdlays5KdleysZGclJCkhSQlJSkhSQpISkpSQpIQkJSQpIUkJ SUpIUkKSEpKUkKSEJCUkKSFJCUlKSFJCkhKSlJCkhCQlJCkhSVPfaOp3mPodpn6Hqd9h6neY+qdM /VOm/ilT/5Spfyp6fXC+zXx5dF75Vtv58ugCf369/Fz0zvKj0Z3B+6Mj5fXRbHBRdDS4OJr3f1so D0THgzcEH7XFs7Z41hbP2uJZWzxri2dt8awtnrXFs7Z41hbP2uIJzwGh54Azfdcgb6LzJjpvovMm Om/jt5jqNlPdZqrbTHWbqW5z+6fd/mm3f9rtn3YVZFwFGVdBxlWQcRVkXAUZV0HGVZBxFWRcBRk3 dujGDu2k0I1ZcmOW3JglN2bJBTMZ+ak/u6mHXjj9HFh5Uspwpuj2msGZovtrRrBb1ctUvUzVy1S9 TNXLVL1M1ctUvUzVy1S9TNXLVL1U1d9S9bdU/YqqX1H1K6fvtRWq/5pb63/T1+lO+gb9A7f+ke6i b9Ld5bUqXKvCtSpcq8K1KlyrwrUqXKvCtSpcq8J2Fbbb7iXbvWS7l2z3ku1est1LwUjw24E+BaP0 Op6KbesB23rAth6wrQds6wHbesC2HrCtB2zrAdt6wLYesK0P2tYHbeuDtvVB2/qgbX3Qtj5oWx+0 rQ/a1gdt67xtnbat07Z12rZO29Zp2zptW6dt67Rtnbat05ELXY8u3sg76c/oXXQRvZveQ++l99HF 9H66hD5Af04fpA/Rh+kjdCldRh+lj9HHaRZ9gi6nT9KnaDZdQZ+mz9Bn6Uq6iq6ma2gOVdH1armB vkBfpC/R69243/PvrLWt7qN1VE330wP0INXQD7zWQ1RLj9CjVEfr6Yf0GG2gx2kjPUFPUj1tos20 hZ6irfQ0NdCPqJG20TPUQZ3URbZhZK/pv778VmnAieBcabgoepM/F/jz1vJmWzNhY84IPvCvm/AW W3EhLaKf57so30X5Lsp3Ub6LwYrgN03/btO/2/TvNv27Tf9uW2umrTXT1pppa820tWbaWjNtrZm2 1kxba6atNdMmutAmujA46e+vUjmYGQkoQtcGH4rMpevoc/R5+qugKhIPzkO7BdEbgstU8Z9V8J+j twZ/G/0HVLsruCB6d3B+8PVf8p2NY3b/Mbv/mN1/zO4/ZueHdn5o54d2fmjnh3Z+aOeHdn5o54d2 fmjnh2f9qcEttJAW0RLkO5NbXysf5NRBTh3k1EFOHfwl30E7ZG8fsrcP2duH7O1D3DqHW+fY22l7 O21vp+3ttL2dtrfT9nba3k7b22l7O21vp+3ttL2dxopTWHEKK05hxSmsOIUVp7DiFFacwopTWHEK K07Z1WNn/H7sKbW9QlP0L/Sz1/EEfmd5SJaGZGlIloZkaUiWhmRpSJaGZGlIloZkaUiWhuy+I2d8 Tu2gTuqiPbS3PB79Ik+ueF0/U6o8eX/Ek/Wl9P927sUzz3l5QveSupfUvaTuJXUviepTqD6F6lOo PoXqU6g+hepTqD6F6lOoXvlZzoCracDVNMDdBHcHuDvA3QHuDnB3wE5LcbiFwy0cbuFwC4dbOFHg xAQnJjgxwYkJTkxwYoQTI5wY4cQIJ0bsudAFENpzoQsglOqTkfM5s4AzCzizgDMLOLOAMws4s4Az 8kNvpP9CM8o3yE5CdhKyk5CdhOwkZCchO52y0yk7nbLTKTudXNzOxe0y1CVDXTLUJUNdMtQlQ10y 1CVDXTLUJUNdMtQVVL57sIC+TDfTV+gv6RYEWEiL6O7yLM7O4uwszs7i7CzOzuLsLM7O4uwszs4K 1pb3yNAdMnSHDN0hQ3fI0B0ydEdQ47/7Pj1EtfQwPUKPUh2tpx/SY7SBHqeNbvkn6Emqp0202X++ hbbS09RAP6JG2kbPUBM103Z6lnaUa+zxmuDH/t5KMdpJbbSLfkLPUzvtpjh1UCd10Z7y7TJ+u4zf LuO3y/jtMn67jN8u47fL+O0yfruM3y7jtwd9/p1+GvD3pD8P0iANUco9cYjSdJiGKUP5ciMmNGJC IyY0YkIjJjRiQiMmNGJCIyY0YkLj9NT2mtpeU9trantNba+pfeFMXHCd5V1neddZ3nWWd38sdH8s dH8sdH8sdH8sdH8sdH8sdH8sdH8sdH8sdH8sdH/McX/McX/McX/McX/McX/McX/McX/McX/McX/M cX/cij9V+FOFP1X4U4U/VfhThT9V+FOFP1X4UxW5tvw3kbl0HX2OPk/X+/dvoC/QF+lLdFNwgSf0 qzyhf9MT+o2e0Bd4Qr/WE3qNJ/TPeEKv8YRe4wm9xhN6jSf0Gk/oNZ7QazCuCuOqMK4K46owrgrj qjCuCuOqMK4K46owrgrjqjyh17gZbvWEXuMJvcYTeo0n9Bo3xHI3xHI3xHI3xHI3xHI3xHI3xHI3 xHJPzjWenGs8Odd4cq7x5FzjybnGk3ONJ+caT841npxrPDnXoMcu9GhHj3b0aEePdvRody03Icgu BNmFILsQZBeC7HJBP+CCfsAF/YAL+gE3w+XRG9wHXyhvcjtc73aYaev+qdthps37p26HVSizNLqz /IPoiGeL0eCcaK7cFi0EVwX/A3m6kKcLebqQpwt5upCnC3m6kKcLebqQpwt5uqZ/4nIYTQ5Lf176 89Kfl/689OelPy/9eenPS39e+vOveR4onf6J1xcr34vyqtVetdqrVnvVaq9a7VWrvWq1V632qtVe tdqrVnvV2/AujXdpvEvjXRrv0niXxrsU3qXwLoV3KbxLeYcN3mHlO40DeDeAdwN4N4B3A3g3gHcD eDeAdwN4N4B3A3h3DO+O4d0xvDuGd8fw7liwJPgdlS5R6RKVLlHpEpUuUekSlS5R6RKVLlHpkumf eqzHufU4tx7n1uPcepxb/2v+1KMO5+pwrg7n6nCu7tf8qUeTDjT9B37qUY9z9ThXj3P1OFePc/U4 V49z9ThXj3P1OFePc/Wv+alH/Rl+6hHHuTjOxXEujnNxnIvjXBrn0jiXxrk0zqVxLo1zaZxL41wa 59I4lz69hV81UWW3TUAR+o3yvdh1L3bdi133Yte92HUvdt2LXfdi173YdS923Ytd1dhVjV3V2FWN XdXYVY1d1dhVjV3V2FWNXRuwqwa7arCrBrtqsKsGu2qwqwa7arCrBrtqsKsWu2qxqxa7arGrFrs2 YNcG7NqAXRuwawN2XfYadi3AriXYdT12xbHrE9gVx644dsWxK45dceyKY1ccu9Zj13rsWo9d67Fr PXatx6712LUeu9Zj13rsWo9d67Erjl0bsCuOXXHsimNXHLs2Ydcm7NqEXZuwaxN2bcKuTdi1Cbvi 2BXHrjh2xbErjl1x7IpjVxy74tgVx674mS4cfGrEp0Z8asSnRqn/yjSf2qX/o9j0J7j0J7hUh0ub p1l0beR3UKEOFepQoQ4V6lChDhXqUKEOFepQoQ4V6lDB81j5blTIoUIOFXKokEOFHCrkzvzJtvJm VNiMCnlUyKNCHhXyqJBHhTwq5FEhjwp5VMijQv6sV9AK9+bd5VWosAoVVqHCKlRYhQqrUGEVKqxC hVWosGqaCi2o0IIKLajQggotqNDya1KhBRVaUKEFFVpQoeXXpEIDKjT8B6jQggotqNCCCi2o0IIK LajQggotqNCCCi2o0IIKLa+hQssZqJBBhQwqZFAhgwoZVMi8zp9/ls7yCZWBs/z88xevn2YEaUaQ ZgRpRpBmBGlGkGYEaUaQZgRpRpBmBGlEkEYEaUSQRgRpRJBGBGlEkEYEaUSQRgRpRZDtCLIdQbYj yHYE2Y4g2xFkO4JsR5DtCLIdQToQpANBOhCkA0E6EKQVQVoRpBVBWhGkFUHOQZAPIsjfIshlCHLZ 9M8nOhHkgwjSiSCdCNKJIJ0I0okgnQjSiSANCNKAIA0I0oAgDQjSgCANCNKAIA0I0oAgDQjSgCCd CNKKIJ0I0okgnQjSiSCtCNKKIK0I0oogrQjSiiCtCNKKIJ0I0okgnQjSiSCdCNKJIJ0I0okgnQjS iSCdrp/Kp2OGUGQIRYZQZAhFhlDjc6hxH2JcixhvRIw3okVbsEHqW6S+RepbpL5F6lukvkXqm6S+ SeqbpL5J6pukvUXaW6S9RdpbpL1F2lukvUXaW6S9RdpbpL3lrN83uM+rrqNqup8eoAdpIz1BT1I9 baJ/+2lhm3S0SUebdLRJR5t0tElHm3S0SUebdLRJR5t0tElFmxSEUhBKQSgFoRSEUhB6Mm3zZNrm ybRNIvZIxB6J2CMReyRij0TskYg9ErFHIvZIxB6J2CMRz0lEl0R0SUSXRHRJRJc0NElDkzQ0SUOT NDRJw8+k4WfS8DNp+JnJ7TW5SZObNLlJk5s0uUmTmzS5SZObNLlJk5s0uadM7imTe8rknjK5p0xu r8ntNbm9JrfX5PaavqTpS5q+pOlLmr6k6UuavqTpS5q+pOlLmr6k6UuavN7ID+ghqqVH6FGqo/X0 Q3qMNtDjtJGeoCepnjbRZtpCT9FWepoa6EfUSNvoGWoqp0zidnd4mzu8zR3e5g5vc4e3mc4209lm OttMZ5vpbDv9BP/zp/e2yCJ7a669NdfemmtvzbW35tpbc+2tufbWXHtrrr01196aa299ygQ3mOAG E9xgghtMcIMJbjjjz8s/Uv4ne+ufTPI2k7zNJG8zydtM8jaTvM0kbzPJ20zyNpO8zSRvM8kZk5wx yRmTnDHJGZOc+Xefm727PNsOm22HzbbDZtths+2w2XbYbDtsth022w6bbYfFpGCRFCySgkVSsEgK FknBIjssZofF7LCYHRazw2J2WMwOi9lhMTssZofF7LCYHRazw2JneYKP2WExOyxmh8XssJgdFrPD YnZYzA6L2WExOyxmh8XssJgd9k077Jt2WMwOi9lhMTssZofF7LCYHRazw2J2WMwOi9lhMTssZofF 7LCYlC6W0sVSulhKF0vpYildLKWLpXSxlC6W0sVSulhKF9thMTssJq2L7bCYHRazw2J2WEx610nv OuldJ73rpHed9K6T3h7p7ZHeHultl9526W2X3nbpbZfedultl9526W2X3nbpbZfeFul9Wnqflt6n pfdp6X3aPntMggckeECCByR4QIIHJHibBG+T4G0SvM0+W2qfLbXPltpnS+2zpfbZUvtsqX221D5b ap8ttc+W2mfX2WfX2WfX2WfX2WfX2WfX2WfX2WfX2WfX2WfXocJtqDAfFeajwnxUmI8K81FhPirM R4X5qDAfFSo/IWyLvIPeSX9G76KL6N30HnovvY8upvfTJfQB+nP6IH2IPkwfoUvpMvoofYw+TrPo E3Q5fZI+RbPpCvo0fYY+S1fSVXQ1XUNzqIquLX8Vtb6KWl9Fra+i1ldR6zbUug21bkOt21Drtshf lIft3AsjC8ot9u5l9u5f2btX2bs32rtX2Lu1kb9CkL/23y3z97+jv6fltIK+Rl+nO8vz0G8e+s1D v3noNw/95qHfPPSbh37z0G8e+s1Dv3l2by0C3mb31tq9tXZvrd1ba/feZffeZffeZffeZffeZffe ZffeZffeFfl+uQk1e1CzBzV7ULMHNXtQswc1e1CzBzV7ULMHNXtQswc1e1CzBzV7ULMHNXtQswc1 e1CzBzV7ULMHNXtQswc1e1CzBzVr7flae77Wnq+152vt+Vp7vtaer7Xna+35Wnu+Fl1/jK670HUX uu5C113ouisS98TR4T13Uhftob300/JaTxFrPUWs9RSx1j3w++6BFZ4ilrgJ3uwmqPxk5FxPEStQ eF00Uy56kmiPjpUHPE1cEB134z2OzJPIPInMk8g8icyTyDyJzJPIPInMk8g8icyTqHwIlQ+h8iFU PoTKh1D50Fl+iyGDxhk0zqBxBo0zaJxB4wwaZ9A4g8YZNK58FvV4sIz+jv6eltOZfh75+j4f8POf yuzx9730U+qmHnqB9tF+6qUE/TMdoAF67W8tvL7fcTnzbzic+bcbSuhTQp8S+pTQp4Q+JfQpoU8J fUroU0KfEvoU0aeIPkX0KaJPEX2K6FNEnyL6FNGniD5F9BlGn2H0GUafYfQZRp9h9BlGn2H0GUaf YUkuSnJRkouRymfUvkQ3BW98zSd7LpLgi6c/UXihdOakMyedOenMSWdOOnPSmZPOnHTmpDMnnTnp zElm0UQfMNFJE5000UkTnTTRSdOcMs0p05wyzSnTnDKtf2Ra/yha+b2nK3T6kE4f0ulDOn1Ipw/p 9CGdTut0WqfTOp3W6bROX6TTF+l0Jqh82u+n1E099ALto/3USwn6ZzpAA3T231tZYwLWmIA1JmC/ CdhvAvabgP0mYL8J2G8C9puA/SZgvwnYbwL2m4CtJmCrCdhqAraagK0mYGvle3umYLkpWG4KlpuC 5aZgefSa8sPR64Pfnf5NowWupi3R+eWF0b8oN0Vv8s8L/POX/fPN/vmO4Jzg0l/5Uwb30Tqqpvvp AXqQNprTJ+hJqqdNtKc8zLlhzg1zbphzw5wb5tww54Y5N8y5Yc4Nc26Yc8Ocy3Muz7k85/Kcy3Ou koH8WZ4yKz97K3GgxIESB0ocKP3iJyCif4FYN9Md5WTwAdWGqg1VG6o2VG2o2lC1oWpD1YaqDVUw pYIpFUypYEoFUyqYUsGUCqZUMKWCKRVMqWBKBVMqeFUFr6rgVRW8qoJXVfCq3u/T+316v081/aoZ Vs2waoZVM6yaYdUcUM1u1exWzW7V7FbN7l/8rhsm5/T1mJ5WPm96LFr5Psm7gzWef87++3r/vj87 gj8w4X+gyrwq86rMqzKvyrwq86rMqzKvyrwq86rMqzKvynwwYmqyNEqT5Ve882Hv/CXv/CXv/CXv /CXv/CXv9JXp3zb4dHR+cI4+vH36tw4+Hf2yf745eDua3i2dK+lb9G36Dq2ie+i79D1aTWt0b0d5 zO05xs/9/NzPz0o+hvhZ4GeBnwV+FvhZ8K72eld7vau93tVe72qvd7WXnxl+ZviZ4WfmNb81UPG0 OO1pMep+j1bu98/+yp/AX1PeoQcjejCiByN6MKIHI3owogehHoR6EOpBqAeharpU06UHY3owpgdj ejCmB2N6MKYHY3owpgdjejCmB2N6MKYHY2d9bv15VkJuhNwIuRFyI5z+KeoUN6a4McWNKW5MnWG6 VnPjTn17i769Q9/One7bW/TtHfpWydLbuXMzd252CQxEXwj+OPhD1Ve+5zal+inVT6l+SvVTqq+w 74R+ndCvE9Ofyp70Die9w0nvcNI7nPQOx7zDUe9w1Dsc9Q5HvcNRr/4mr/im4Df87Tx/Oy/47zrS pyN9OtKnI3060qcjfTrSpyN9OtKnI33e06Gz8vgMn5VSfbfqD3ulGV5phipHo5Xfy7jSKx7xike8 4hGveMQrHvGKR7ziEa94xCse8YpHOPAMB57hwDMceIYDz3DgGf1v0v8m/W/S/yb9b5LBGTI4Q/+b 9b9Z/5v1v1n/m/W/Wf+b9b9Z/5v1v1n/m/W/Wf+bVXVEVUdUdURVR1R1RFVHbJaszZK1WbI2S9Zm ydosWZsla7NkbZaszZK1WbI6MaETeZ3I60ReJ/I6kZ/eLAWdKOhEQScKOlGYzvIFZuJ8Ds2azvIF ZuJ8bs3C1+6g8snM84KV9C36Nn2HVtE99F36Hq2mNcGHuNXHrT5u9XGrj1t93OrjVh+3+rjVx60+ bvW9Zie//k95jJQfMX+PmL9HONTHoT4O9XGoj0N9HOrjUB+H+jjUx6E+DvVxqJZDdRyq41Adh+o4 VMedZdxZxp1l3FnGnWV27m9hyBz79i4cudy+/Q6WzLFv78KTy+3b70S/bjffWf5+dF/wtuj+4Pej iWBm8F6zlTZbabOVNltps5U2W2mzlTZbabOVNltp01z5yd6LmPHiL7ky9qp0r0r3eveHztLf537F TVMh4/D0pwTfoKrU9CcF36CilHSE0cr36q78lT/Ft6Z8j54X9byo50U9L+p5Uc+Len5Uz4/q+VE9 P6rnR1W7V7V79byk5yU9L+l5Sc9Lel7S85Kel/S8pOclPS/peeX73ZXvb5/g0AkOneDQCQ6d4NCJ X/gNy0kOneTQSQ6d5NBJDp2c3sVHOXSUQ0c5dJRDRzk0yqFRDo1yaJRDH+bQJyXjPA5dKhVvkYrz OHSpRLyFQ1dy6EqUXF75Le/KtrOnV9K36Nv0HVpF99B36Xu0mtaY9B3Bm038m73jQ97xIe/40PTz wAnv+IR3fMI7PuEdnwhO4sgpG/IVmqJ/oZ+Vk6byE9Ebggv1cEL/Kp+AmdC7MPqV4F3Rv6Rbg1um PyH21mjlvX38V76P7iuP6+O4Po7r47g+juvjuD6O6+O4Po7r47g+jutfQf8K+lfQv4L+FSr/Hx/0 r6B/Bf0r6F9B/wr6V9C/gv4d1b+j+ndU/47q31H9O8qNCW5McGOCG7mzfCLr3z0d6d1JvTupdyf1 7qS+TejZm0/fUQv8WbmjKtXnVJ9TfU71OdXnVJ9TfU71OdXnVJ8zyRUHJjgwwYEJDkxwYIIDExw4 zoHjHDjOgeMcOG6Sp0zyFCeOc+I4J45z4jgnjnPiOCeOc+I4J45z4jgnjnPiOCeO/5Ksv3YuKnt/ nBPjnBjnxDgnxk3yIDcOcOMANw5w4wA3DpiHHFJNmYccQk2ZzvB09StVv1L1K1W/UvUrVb9S9StV v1L1K1W/UvXrVP+c6p9T/XOqf071z6n+uTP/Pk95j+orn97pUH2H6jtU36H6DtV3qL5D9R2q71B9 h+o7VN+h+o6zfeJX9lZFbygfin6h/JBerpLBt+nnNdPbqUoO36av10xvpypZvEcW75FFzz3lja6W i6O9/u5+jx4Irgp+T/UJ1SdUn1B9QvUJ1SdUn1B9QvUJ1SdU3/9/P2HhXaS8+oCvnvLVU8HHfJV6 X6XeV6n3Vep9lXpfpd5XqfdV6n2Vel+l3lf5xi/57sN+Hu7n4X4e7ufhfq/Y6hVbf63/hY2UTByi NB2mYap87+b68goeJnlYqeIWHr6Jh7N5OJOHX+Lhm3g4m4czefglVa5T5brpT7d08/AiHvbw74rT z5FbVL5F5VtUvkXlW1S+ReVbVL5F5VtUvkXlG1U+qPJBlQ+qfFDlgyofVPlBlR9U+UGVH1T5wX/9 7Pevs/nP9nnxk6efT+5UfUb1adUvnq7+kunqF01Xf8l09YtU/7DqHz79meD3qbak2pJqS6otqbak 2pJqS6otqbak2spNvEOlO1S6Q6U7VLpDpTtUul2l21W6XaXbVbr9NZ9kbVVpq0pbVdqq0laVtqq0 VaWtKm1VaatKW1XaqtJWlb6o0hdV+qJKX1Tpiyp9UUVvVdEMFd2omreqpnLb3qiKTcHlqlihihWq WKGKFapYoYoVqlihihWqWKGKFXo2TyUxlcRUElNJTCUxlVR+svCsSp5VybMqeVYlz+rZLj3bpZKd Ktmpkp0q2amSnSrZqZKdKtmpkp0q2amSnSrZqZKdZ/0+wKvYWi5PIPgEgk/o3zX616N/lTvl8un7 dJZqL1Dtsun7dJaKL1DxMv1bqX8rTe9q1a83vRea3nbT+67g/a9j753tZj3TdwzfoJ9v4MIBLhzg wgEuHODCAS4c4MIBLhzgwgEuHODCAS4c4MIBND+K5kfR/CiaH0Xzo0g+juTjSD6O5ONIPq7id6r2 EpW+U5WXnCb5tZELyyci76B30p/Ru+gieje9h95L76OL6f10CX2A/pw+SB+iD9NH6FK6jD5KH6OP 0yz6BF1On6RP0Wy6gj5Nn6HP0pV0FV1N19AcqqIf6OFDVEuP0KNUR+vph/QYbaDHaSM9QU9SPW2i zbSFnqKt9DQ10I+okbbRM7SrPBJ5rnws8hN6ntppN8VPf1J4MNJJXbSH9pYH7cVMtPKTvM9zsMjB IgeLHCxysMjBIgeLHCxysMjBIgeLHCxysMjBIgeLHCxysMjBIgeLHCxysMjBIgeLHCxysMjBIgeL HCxysMjBIgeLHCxysMjBIgeLHCxysMjBIgeLHKz8PuIkByc5OMnBSQ5OcnCSg5McnOTgJAcnOTjJ wUkOTnJwkoOTHJzk4CQHJzk4ycFJDk5ycJKDkxyc5OAkByc5WOJgiYMlDpY4WOJg5feKDnNwgoMT HJzg4AQHJyI/9fTQTT30gg154+nvqRSD+f/fz+RaVd1H66ia7qcH6EGqoR+4HB+iWnqEHqU6Wk8/ pMdoAz1OG+kJepLqaRNtpi30FG2lp6mBfkSNtI2eobM7PsjxExw/wfETHD/B8RMcz3M8z/E8x//t f9/kvMhvlI9HovSb9Ab6Lfpt+k/0O3QO/S69ke70Ct+gf6B/pLvom2TPRey5iD0Xseci9lyksufO icwI3hO5kW6lv6Hb6Hb6X3QHLaXvBu8JvuJ9pL2PtPeR9j7S3kfa+0h7H2nvI+19pL2PtPeRjvzX cirye/T79CY6l/6A/hudR39IM+nnvxM9FHkr/RG9jf6YLqA/oT+lt9P/pGvLA5G5dB19jj5PZ/o9 5DvLwzwY5sEwD4Z5MMyDYR4M82CYB8M8GObBMA+GT/8e8Vpzfh+to2q6nx6gB6mm8r9GE5wbeS74 7chP6Hlqp93UwcFO6qI9tJd+MTvXl2tttnU22wU4f6ONdgHOV3Z34vRTWx39GPOfo4wrZSS4Ipq1 9UaDc6N5/zzmz0JwWXTcf/aip8/P6USoE6FOhDoR6kSoE6FOhDoR6kSoE6FOhDoxqhOjOjGqE6M6 MaoTozoxqhOjOjGqE6M6UdCJvE7kdSKvE3mdyOtEXifyOpHXibxO5Lle4HqB6wWuF7he4HrI9ZDr IddDrodcD7kecj3kesj1kOsh10OuF2RxTBbHZHFMFsdkcUwWx2RxTBbHZHHs/zB393FSltfdwO+d wV1ZIFvNijFtTRowwSS+gUYjmoTY+FIwERNMNK21TzUtaqQoKvrUl7AoYgRJQnyJNsXGkESsMYmI LAoisO46MrDMAsPLBHYHd3f2bXZ0GQSV+/new2hpPtg+9vN88nn++DHL7H1d17nO+f3Odc7szD20 2EmLnbTYSYudtNhJi5202EmLnbTYSYudtNhJi5202EmLnbTYSYudtNjJ80N5/nSejz5RdTrPJ3l8 eHx5cEzwTd7M8GaGNzO8meHNDG9meDPDmxnezPBmhjczH+AvbpE3u3izize7eLOLN7t4s4s3u3iz ize7eLOr4qLgiIqJcDF8Hb4B/+88XODhAg8XeLjAwwUeLvBwgYcLPFzg4QIPF3i4wMMFHi7wcIGH Czxc4OECDxd4uMDDBR4u8HCBhws8XODhwoFP6AZH8vK5vHwkL58bvzY4K4h5Jnov/THBoHIULipH 4aLgQ3JPjdxTI/fUyD01ck+N3FMj99TIPTVyT43cU2Pk6UZOMvJ0IyeVRo4ycpSRo4wcZeQoI0cZ OcrIUUaOMnJU+dOA15U/DXhdaWStkbVG1hpZa2StkbVG1hpZa2StkbVGjjZynJGjjRz3gayNRo4v jxxf8sEJ0WcRg0twrQPXOnCtA9c6cK0D1zpwrQPXOnCtA9c6cK0D11K4lsK1FK6lcC2FaylcS+Fa CtdSuJYqv+OsEdcaca0R1xpxrRHXGnGtEdcaca0R1xrf591lDXjVgFcNeNWAVw141YBXDXjVgFcN eNWAVw141VB6d9m8MC9f5uXLvHyZly/z8mVevszLl3m8K+JdEe+KeFfEuyLeFfGuiHdFvCviXRHv inhXxLsi3hXxroh3Rbwr4l0R74p4V8S7It4V8a6Id0W8K+JdsWKxU/L6sJ5iXgz3OW/fdt6+7bx9 23n7tvP2beftZuftgPN2wHk74LwdcN4OyNLdsnS3LN0tS3fL0m3BYbQ4mBYH0+JgWhxMi4ODiaKW ErWUqKVELSVqKVFLiVpK1FKilhK1lKilRC0rallRy4paVtSyopYVtayoZUUtK2rZ8ueLc6KWE7Wc qOVELSdqOVHLiVpO1HKilnPydTr5Op18nU6+Tidf5/t8pveD3t2n47+7u4+T70gn31An31An31An 31An31An32An32An32An32An32A+vNpJN6H8OZrx5c/RjC/dtSKqxfMqx7zKMa9yzKsc8yrHvMox r3LMqxzzKse8yjGvcsyrHPMqx7zKMa9yzKsc8yrHvMoxr3LMqxzzKse8yjGvcsyrHPMqx7zKMa9y zKsc8yrHvMoxr3LMqxzzKse8yjGvcsyrHPMqx7zKMa9yjDibw9kczuZwNoezOZzN4WwOZ3M4m8PZ HM7mcDaHszmczeFsDmdzOJvD2RzO5nA2h7M5nM3hbA5nczibw9kcpu56n8ow+gRoK6a2YmorprZi aiumFjC1gKkFTC2UPgcZveN2Eo9meTTLo1kezfJolkezPJrl0SyPZnk0y6NZHs3yaJZHszya5dEs j2Z5NMujWR7N8miWR7M8muXRLI9meTTLo1kezfJolkezPJrl0SyPZnk0y6NZHs3yaJZHszya5dHs H+0OkovDN3i1jVczvJrh1QyvZng1w6ttvLqJVzfx6iZe3cSrmw7R4aR4NRU8SO1t1N5G7W3U3kbt bdTeRu1t1N5G7W3U3kbtbR/wfl691N5L7b3U3kvtvdTeS+291N5L7b3U3lsxyllzPHwaPgOfhRPg RDgJToZTYDSMgVPhNPgcnA5nwOfhTBgLZ8HZ8AX4InwJovPsy3AO/CV8Bc6F8+B8uAD+CsbDBLgQ vgpfg4tweCJcDF+Hb8Ch7kF2m73cDnfAnfA9mAF1MBPugrthFtwDB+41tk822icb7ZON9slG+2Sj fbLRPtloX8VP1NePwKPwU/hXWACPwb/Bz+Bx+DkshF/AL+FX8AQsgifh3+Ep+DU8Db+B38Lv4Bl4 0Vm+El6CVbAa1hz6zgOY1IdJfZjUh0l9suAsWXBKOQueVc6CZ8mCm0vs6sKuLuzqwq4u7OrCri7s 6sKuLuzqwq4u7OrCrl7s6sWuXuzqxa5e7OrFrl7s6sWuXuzqLb+/qx+7+rGrH7v6sasfu/qxqx+7 +rGrH7v6sasKu6qwqwq7qrCrCruqsKsKu6qwqwq7qrCrCruqsKsKu6qwqwq7qrCrCruqsKsKu6qw qwq7qrCrCruqsKsKu6qwqwq7qrCrCruqsKsKu6qwqwq7qrCrCruqsKsKu6qwqwq7qrCrH7v6sasf u/qxq/+Q70m7Tca+He6AO+F7MAPqYCbcBXfDLLgHovedzZMnfgA/hB/BfPgxPAAPwk+CSuyqxK5K 7KrErkrsqsSuSuyqxK5K7KrErkrsqsSuSuyqxK5K7KrErkrsqsSuSuyqxK5K7KrErkrsqsSuSuyq LLPrUGfqodg1gF0D2DWAXQPlM3b2IdjVFnwBu3Zi107s2oldO7FrJ3btxK6d2LUTu3Zi107s2old zdjVjF3N2NWMXc3Y1YxdzdjVjF3N2NWMXVuwax12rcOuddi1DrvWYdc67FqHXeuwax12rROpLSK1 RaS2iNQWkdoiUs0i1SxSzSLVLFLNItUsUs0i1SxSzSLVLFLNItUsUlv+2/t4LY7uBVDqo0eUPtsS 6arVzlvtvNXOW+281c5b7bzVzlvtvNXOW+281c7b7bzdztvtvN3O2+283c7b7bzdztvtvL3cxf3f 1WijZI3j4dPwGfgsnAAnwklwMpwCo2EMnAqnwefgdDgDPg9nwlg4C86GL8AX4UswDr4M58Bfwlfg XDgPzocL4K9gPEyAC+Gr8LXou0pl14lwMXwdvgGH7jK7RKtLtLpEq0u0ukSrS7S6RKtLtLpEq0u0 ukSrq9Rl/ve6+mNm7UPp6lCv0vyhrmbSVV1ZV+PKuhpXet/pjR/wfoDbsGsbdm3Drm3YtQ27tmHX Nuzahl3bsGsbdm3Frq3YtRW7tmLXVuzail1bsWsrdm3Frq3YtVWlV1TpFVV6RZVeUaVXVOkVVXpF lV5RpVdU6RVVekWVXlGlV1TpFVV6RZVeUaVXVOkVVXpFlV5RpVdU6RVVekWVXlGlV1TpFVV6RZVe UaVXVOkVVXpFlV5RpVdU6RVVekWVXlGlV1TpFVV6RZVeEbt2Y9du7NqNXbuxazd2bcWurdi1Fbu2 YtdW7MpgVwa7MtiVwa4MdmWwK4NdGezKYFcGuzLYlcGurdjVh1192NWHXX3Y1YddfdjVh119ckFR 9VdQ/eVVf3nVX171l1f95VV+BZVfQeVXUPkVVH6F916RGBY7M9wQOwfODy+JXRB+JzY+/E78wvDF +KSgOrrvSvke/4+W7/H/aIkLQ2Inh+2xU+H0sCP2RY/nhy1GrzF6TezCcD0mpUt/mb88bA8+5Ooe V/e4umi9jBE91szEaDH2Lc99O9weuxK+C7M9f2+YKa1TbeSAkQNGpY0aMCrtilZXtB70rug1pTW2 unKrNTa7ciuL0ixqZFFjrLSfcFn53ZG7S+/+v9zj3wa1weHmXmTeRaxYxoplrFhmjSZrNEWvkgVH mvsmc99k7nZz32TufeYumLtg7q2ubnN1W3zS/j3WqDnE/ZduKfV/0UxXmOkKa64z0xXWXRc7P/io GS41w6WsPDF+SfhY+b0AY8pKPKmsxJPKf6++IvgTM11jpmvYVDDbMrNdY7bI8klmmmSm4810u5lu M9NRpb+eRn81vVZVdn347aDKqN8Y8Rsj1huxvnT/tL+F6O+pNbyR5418bHL4SOzqcGbsGrgWvhvm /4Af9+DHb/jzHvz4jdGvi9tEntKRG91i9Bqj1xi9JnZduLH0ToN3uVFRejdRlesHrLjFilussIUt Q9gypOS1YX67xWzbzZY2W4PZGszWYLZlB8V1oBzXgVJco5m328fE8HFjXzN2n7FFY4vGFo3dauzJ xp7Fy9XGjuLl6O69o/hoTol/0ehb2LWWXWtjk4PhbFtr1FU828OzWaPnGP1npb9dXu4x+tvlteFc o58u2X2NtQtmeN4Mzxv9vNFnGL3B6GfKdww+0agTjaqL3s0RVLq6ydVNrm7y26P89ii/+TWm3mgP N/HUzWEuNpMK55j7xzT0UNgfezjsD2J+uzcW/S2/wr97xOHmcE9suuduKT2/LnZ3MDg2yyz3hb2x B7DoIc8/HO419/XmugFu9MzNoqe2NH9HTKaJPWiuI12x3hXrXdFhzoI5C7E7ZI474XswA2YGfx67 O1weu9918yj5B/BD+BE8RIkPh43BIFa2umqnq3Kx6F21MbZ1sSmy+Hr7uwH+w+qNGNqHoX2u6DPL gFkGWHxTuIOlRZb2xG5ny8yg1qxtZm2LRe/D+6i5VpprJYvbXZk0Z7s522O32r0z3qgeO+i3g347 6LeDfrNUWi9hvYT18rG5Ij8vzNpJ1k6ydpLlkxZ+b2LLRrZsDP7USj1W6rHSALuWWW3ACtutkLdC wQoFKxSsENl5NDuXWqXHKj0xVTlP97L7KSv1WqnXSr1W6rVSv5XesJ+U1Tqt1imC19v1DRDtfiaW 3m2G2a66F+Z47n67H2K3++x2Hw/uEvfq2PddeV9pLVf4+QF4yO8fDveVorvTnDuN6jEq8ksHqztY 3cHqjtI671p8P6vm8fIP4IfwI3iIXx+m6CiWeSxv5cd3vTLfTg7wtMc1PaXY9R5kX48dDPBDZHnR Xosywk12MJM9d1v3+36+D2fuD45h9ZF4ez0m3ACRIm6D21010+Ns/r4X7jPfnFL0CkYdX2Kx2pkF r7Pg9RIHI2XkWZA3MvGedgpBvKSxmRDd8avGWpustem9q28Pd/vtdpYNsV6n9TpLvr2f1fN56seY 9RBmPxzmSnPtcXW3ud4MTo09Za+L7eIF7FkOK+XEl9i2KpwWWx0+HFsDL4c/iyVk2qSTZoNrNnrc BHle7oc3nDi7w3tjxXBhbA/sDZtj74Q/jQfyziCnUJXHw2GYn3XJcV1yXJccHwXHwwlhd/yk8Jfx U8J/j4+GMXBquDN+RtgSHxsuin/RNe9+y88lwUfj33QmHPgMTnT30Z+W7z7601K39eexx+0+2tVL vL+Kxlbb+Rp4WSQbeSLh56RdtPDcRo+boDM4KpbDyN3GFY3fA/tYFYQ7WL+D9Tvix4RFVnawspuV 3azsjp8W9rMwG3ykvGor/71l1c1WzVg1Y9V3rLrdqh1W3WzV16262aqbrdZntR6r9Vipx0o9Vuqx yh6rFKxSsErBCvlgihWuiD0RTrbKW7HF4ZOx58IpsaXwgnNnOayEl8K3rfhULMGiDf7fwqq0a7ZQ 61bYBtshA78Pr4/t8NjmDMvKjrv8/Bp0QGdwZywnkl1+7oae8OZYr8c+yIc3iPoNsYKfX4c32DQQ 1ttJh510iP5lfJeJveV3b8M7sB9CZ2IFxCCuGhsU3hA/zM+VKovq8Ob4ED8PdWZHLKkJfxD/EzgC joTa8CTMmYg5EzFnolj8NP7R8KH4n/rdn8HHgqvjf+HxEzAiPDM+Eo4LZ8U/6f+fglHhVzDtK/FP +/mzcALGnBj+PU+/xNMLeHoBTy/Augliuiz+OdecDmeES+Kf93gmjA2T8bM8ng1fCH+GlRPjX/Lz uPDK8gmcKd+z6urSX5WjvyhPDldg5bLgM6K0SZQ2idIm/Nh0ED9exY3XSozc4Pl3GZmXI/vhDdiN xUXX7YG99PZOuA1fkjy4C2eSOJPktR4eeoOH3uChN+x4wI4H7PQNu9xkl+vscp1drrPLgp3l7Gid XbxBV2Ppahw9pWkpHXwKz4r4lcOv3EGWb2D5XhY3ldncVrK4xbUb/bwJOoPRLN/B8h0sT5czQT9L d7CwUxx7WbmZlZtZuVnc/ky8+sWrn8VbWbyVxZtY3M7iHSzeweIdLN7I2nbWbg5GsehVFr1aYvwq mf/l8OmyqttZ9Cpr2lnTzpoxrOliTRdrWvlxOz/282M/yyJmdvDjZtZ18eNmftyMgW+xtJWVu1i5 i5W7WPkx1mVZly1bl2bdK6x7hXWvsG4Hf25j4ass3CWPPC63rKLu1c6/NdAo3ybk7yQrW2TrjR43 ycYxNo40/zCZ+nEWP+Ha54xbCo3hm6VPpH3L+TTMb3N+u5f6c67Y44o9VviOFR60woOu3miFVZHi xfF5cXxevfG4Z54IXzFqc+zXbFosLs/5/1JYZcRqWAONGJYI97Pv1VizU+lATF9l46vyR1au6JAD uui0SwybxWyTmG1i30b2bQxGWGmule60UrtVnrbKbVa5zSp7rLLbKrutsllmqrXKXisMWGGvFfZa YZEVFss4G6zyklVessp0MegTgz4x6LNinRXrqDridp9Y9IlFnu97+LyPCqNXCy5gzQV8ubLEioiP 54rwftHdL7r7efocZ/3jdrhK3l3N1jUlngw7ON+Wcu2NdnOXndTbSZ2d1GHdBqzbYO5XY6tV3mvg ZXk4odfb4PkDuXba++TaWeVcm5JrN/5Brv2enf/2oFw77aBcW4e9dQfl2ulybeqgXDv5D3Jty/vk 2rpyrv01704r59o7MH2nXDtfrp0v186Xa+fz/Diev4znL+P5y+TaJ+XaBXLtfLl2Ph/+jVw7X66d LyoXisqFonK7XDtfrp0vOt8SnW/JtfPl2vmidLFcO41q1vLyE7z8BC8/IXIXybX1cu18uXY+Bf1O rp0v186npMfl2vly7Xy5dq4IXybXzhflO0X5O3Jtq1wbfaLsVrn2WLn2WLl2Xalf+QfR+2vR+0fR +53oXSV6V4neWtFbK3pNTskdIvcCxu8TubUit03krhK5FpFrEbkWkWsRuRaRmy1yLaLWKGototYi ai2idoOoLRK1FlFrEbW5otYiai2i9rSoPS1qLaLWImpPitpK+WdAxJaI2C4RaxGxKFototUiWi2i 1SJaUT56WrRaRGu1aM0VrRbRelq0NojWEtFaIlpLRGuJaF0gWvNEa55ozROt50XrFdFaIlpLROsq 0VoiWktE6yLRuki0fiZaS0RriWjdJ1r3idYS0VoiWt8Xrd+JVqto7RStnaK1U7S+L1oJ0VoiWktE a4doLRGtJSK1RKSWiNRykZonUktE6pHynRyfFalnS68dXB+uCz4pOgtFZ6FM0SgndYtSQpR+Jko/ E5lImc9R5irKXCVj/KqcN1fKS50itUvWWClrrBSxX4nOGppqF4lklDl4uIM2dtHGLl7+Pe1neLFI /xn6z5Qzyy944lc88StW7mbllOhzmcFxB1VSK/Dj51bOl6qozuBrYpoS00iBa6ySscoGq2wQz99S 3Q4rrRe3lJXWW2m9eBVK6houdkfDR+BjwWi+38vnW/h8S/ksWc/Py/h5GT8v4+d1fNtMAY182aJe 73T6ROfkqbqiGl4b4KEreOjHPPRjHnqZnY/zwh52LXyvBt/HE+/Ii4H6uQoODxcFQ428+z3fviwj JzB4d/jr90YdOBG7jeg2otuIvJOoH94w3+7wp6581pXP2nfa1Qtd/RP77jPiJ0b8RC/Yxmu7wy2u 3OHKHSxpd9Ur4tDhqldc9YoTss1Jd+A83uKqLa6K6po3XBllqYIrU/Ho230+LM6PivOj4vvoQVFY x4J1RhWM2l3yfKV1qsNHxfPfsG4z1m0W138pvXf98tKrSIngCDMUzVA0Q7G8/nbrbzdbNNNrJcYM OogxBz7ldYJ+Y4RztdW52lrySodZOsyywyy73q3izbLDLMVyddbxbnXGK3mdYz+8IdfsDt+M/Oeq 112101Wvx6M7edTYayfP9Ll6r6v3uvr1ck/yrpU99rzeyFYj99pzr9GtRrcGMTv9nJ1+Ti+ZZlOP jnaf07E67HVCvXuKt1mhpxTLFrNuNevW8oz1ck+h7Pt6M9bHo/tYRyMXG7nUyG4j643sf2+/+/j9 IL4YUV/+W9gtQUUs+vzYYOO7y7o8sId9JY61Wek149qMayvt/BdWqbfCsoOinLTjeiP6ShGuLr26 9qNydLeXsv/1NBKN/hejlxjdYHTW6KzRv4+qZSOz1or80FCy7RIK+yZE74m5PmwIjjQ6bfQqO0zK 8+1maWTxChbXszha/zdlZTzDR1FGifj+DMufMWujWR8zW30pyuutvd7aTWbIW/9FoyLr1xvRZ0Qf 9qR5sE3Nvzv8oTWetMaT1tjgyjpz51xZ58o6fJuOb9PF84CyF7tyMUteDCrl+b1yx165Iyd35OSO nPz8ZjBEflvrt6/JcRk5LlPuJg/uWX9v5i4zdwXVrt5d6mxH0N5IOAUXR8MYOM3zY40Yp/88tiIW JiriMAgOg0qogsNhMFTDEBjmlBhqzVpaHG700fARGKH2GAnHYdh/VHDd8lqnTBetEv2V/pc8+cvS J86iT5lFHf1R8mghXut/w9V7R8NHYJSIHg8nlPrlLLvb2N3G7rZSTXhaMFgefZ3928yep+Ov0HH0 jSWNdt4YDGVf1s7b2LWDXTtKdp2k+j+FHaNhDET9/WU8e7lavdqu2tmwkw072bCTDRk2ZNgQrdlq rX3W2mnlWp47Rv0+gj5Hwin+PxrGwGl8M5baI72eaZdnBoe7NtrF8v/UpZ1m/cv0l5eHPwiq/Lbw B68J9L2Xj6L1otcneq23y3q7/iDena7uDSrYORB8OD4siLv+5/+pWxzhhB4Jx7FtFG8dDyfwXtQp Rh3iODubFC4Wm8Ws/jirP156nfwIM/3WTDkz5cyUM9NzZnrOTANmKpipUOpBD9TpOTO9bqaVZlpp pk+Z6VOlWLSy//dGbzd6u9HRay1df8DunfaxJ6r0eWy4HR8NH4H/iMN266Sts6Pkk07zdZqvs2TN Sa44RT4eDWMAO4JzgytVjFfBd+CG8JfBreG84H/DP8NtcDtkw58Hu+A1eN01e8P7g33wFrwN74T3 V4wKUxXHw6fhM/BZOAFOhJPgZDgFRsMYOBVOg8/B6XAGfB7OhLFwFpwNX4AvwpdgHHwZzoG/hK/A uXAenA8XwF/BeJgAF8JX4WswmYJfDJsOeWful6ERmuAVSISrg5HBkc6tD0MtHAXD4Wj4FIyC4+HT 8BkYDxPgQvgqfA0ugolwMXwdLoFL4crwSR5/ksef5PF7g2nhr4Mb4Sa4GabDreFTovCUKDwlCk+J wlPBJz/QHaX+Z3eSWizOi8V5cfnu86lAtxXshiLsgb3hCrFfIfYrxH6F2K8IpgSDgmODw6ASquBw GAzVMASGwjD4EJwZnBCMhSvDR/jhEX54hB8e4YcF/LCAHxbwwwJ+WBDcEhzJFzP5YiZfzOSLmXwx 8wN828nooB6y4QN29oCdPWBni+xsuZ0tt7PldrbczpYHbwZH2N1cu5trd3Ptbq7dzf1jvV8wdnJw TOyU4ITYqR6/COeHj8QuCB+IjYeJwUdik8MnYleHM2LXwLXhDNnvuvi3w3tkwOvif+txmqrgRupf r9ZrDmrjKdhI85tk/Wy4Ir7L/18LRsXbS5/gGBHv8tgd1MjD6/yU5a3op+iTHscGu0W0RkRrRLRG RGtEtEZEa0S0RkRrRLRGRGtEtIZSMpSSoZQMpWQoJUMpmUPfzT0YIfojPtB9m68Mp2HKNEyZFvyj mmoyXA3XwLXwXbguet0C/gmmwvVwgyrsUKy6NTwPo87DqPMw6jyMOg+jqjGqGqOqMaoao6oxqhqj qjGqGqOqMSr6/uV2GmynwXYabKfBdhpsp8F2GmynwXYabKfBduwbgX0j/kffUZ916u2C1+CD3Tf5 t9i9FLuXYvdS7F6K3Usxuw6z6zC7DrPrMLtOzk7L2Wk5Oy1np+XstJydlrPTcnZazk7L2Wk5Oy1n p+XstJydlrPTcnZazk7L2Wk5Oy1np+XstJydlrPTcnZazk7L2Wk5Oy1np+XstJydlrPTcnZazk7L 2Wk5Oy1np+XstJydlrPTcna64qLgmIqJcDF8Hb4Bf6x7Ib4Y1r/P3WPrnRX1zop6Z0W9s6K+4tWg umItJGFd9B4JFfkpOodTPTrPqLkm5syi6KUUfSVFX1lS9Ld1EFfC5PDBg5Ud+27pnb/nUffV1H0e dV8d/b05foPOfRklLw+GxVeGs+LrwqcpvYbSqym9g9Kr45vVYln97oHPah1b+ua5qM7tpuaXgkHh XweHQSVUweEwGKphCAyFYfAhqAm/fMh7JZ4ZPhGMhQ+k4GB8cBV8B24ITgymyRs3wk1wM0yHW51w /xv+GW6D26EuPDuYCXfB3TAL7oHZcC98H+6DueG5/8VnyF+gzBco8wXKfIEyozvNLgjq4ZWwiTKb KLOJMpsos4kymyiziTKbKLOJMpsos4kymyizKcg6T3bBa/B68LHgDblyAKKcWYQ9sDc4OtgHb8Hb 8E7pE5MN+ocG/UOD/qFB/9Cgf2jQPzToHxr0Dw36hwb9Q0PFn4SLKo6AI+HDUAtHwXA4Gj4Cx8BH w6crjoWPwcfhL+ATMAJGwnHwSfgUXBQur5gIF8PX4RswyfOXwDfhW3ApXB5cVnEF/F0wveJ/BX9X 8ffBRRVXBldW3Ibpt8MdcCd8D2ZAHcyEu+BumAX3wPfNNY+KfwA/hB/BfPgxPAAP6jpPDv8mdiqc qfP8osdzPJ4ffDl2QfDJ2HiYGP4DlaSoJBWbHJwVuzr4eOwauBa+67nZ4erYveFqFfUlKuqJ8Xr9 9/LwynibbjnrVNtVuovoY/FO9W7O2dflfOwOixXRNykPo4RhlDCMEoZRwjBKGEYJwyhhGCUMo4Rh lOCU2x/dTXSFM26FM26FM26FM26FM24FhdRTSD2F1FNIPYXUU8hcCpn7ge5WfvA3Md0a1FJCLSXU UkItJdRSwnBKGE4JwylhOCUMp4ThlDCcEoZTwnBKGB7M3d8ZzAt3/Rff0LQreAgegUfhX+Cn8K+w AB6Df4OfwePwc1gYTqGgKRQ0hYKmUNCUYJHnn4Sn4NfwNPwGfgu/g2dgMTwLS+A5WBo+RHUPBcv8 /Dy8AMthBbwIL8EqWA1roAFehkZoglfCqdQ6lVqnUutUap1KrVOpdSq1TqXWqdQ6lVqnUuvUYJMx myHt5y0et8I22A6ZcGXwe9gBO6EV2qK7V8mT++AteBveCQ6j3BmUO4NyZ1DuDMqdQbkzKHcG5c6g 3BmUO4NyZ1DuFMqdQrlTKHcK5U6h3CmUO4Vyp1DuFMqdQrm3UO50yp1OudMpdzrlTqfc6ZQ7nXKn U+50yp1OuXWUW0e5dZRbR7l1lHsL5d5CubdQ7i2Ue0vF37D18uDs8vcJXES946h3XPm+xpmKyZh/ o8eb4GaYDrfArfDPcBu7boc74E74HsyAOpgJd8HdMAvugdml90LeUnGfxzkwF+6HeeEcqp9D9XOo fg7Vz6H6OVQ/h+rnlO7O/iwsgedgKdTDMngeXoDlsKJ0F/ce53CPc7jHOdzjHO5xDvdUNMggh/j2 9IpXjVkLSVgXZmSYc2SYc8oZ5pxyhjlGZhkqs8yRWebILNWyyRzZZLJsMlk2OVs2OU82mRd/Pnwl /gIsD6vjL3pcGWbjL8kiq8J/lWUek2Heir9WyjJfk2UejUevk3SFi+PdpW93rAsnUO0Eqp1AtROo dgLVTqDaCVQ7gWonUO0Eal1NraupdTW1rqbW1dS6mvKWUt5SyltKeUspbykV1VNR/Qf+xo7omzre 5/4n8aSdrJcjdYbxDXKpMy/e4rlNqonNdnJTULd/XzAT7oK7YRbcA7PhXvg+3AfzwoTdXGo3l9rN pXZzqd1cajeXyj0JuSch9yTknoTck5B7EnJPQu5JyD0JuSch9yTknoTck+CBiTwwkQcm8sBEHpgo 9yTknoTck5B7EnJPQu5JyD0JuSch9yTknoTck5B7EnJPgteu4bVr5J6E3JOQexJyT0LuScg9Cbkn Ifck5J6E3JOQexJyT0LuScg90X3iJvH2JN6exNuTeHsSb0/i7Um8PYm3J/H2JN6exNuT5J6E3JPg 9UlyT0LuScg9CbknIQqzRWG2KMwWhdmiMFsUZqv5U2r+lJo/+m74RnX8WnX8WnX8WnX8WnX82uDN cMeh7mUZ7A+fDcLw2YoAKsJnRfQK9WFSVB8T1XtE9ShRXSSql6gVV4js7SJbF/SrVkbIcyN0eiN0 eiN0eiN0eiP0OiN0eiN0eiN0eiNUaCP0eqc7CXuchD1Owh4nYY+TsMdJ2OMk7HES9jgJe5yEPU7C Ht3eKN3eqA90f+0rRfgq+A78I35OhqvhGrgWvgvXwRT4J5gK0WtxN7h+WjhLtzdLtzdLtzdLtzcr uIXVt4ZjdHxjdHxjdHxjdHxjdHwjdXwjdXwjdXwjdXwjdXwjdXwjdXwjdXwjdXwjS/fLe//7sfVj Zz929mNnP3b26/rO0PWd8T+7/214BwbcgQF36Pq6dX3dur5uXV+3rq9b19et6+vW9XXr+rp1fd26 vm5smYotd2HLXdhyF7bchS13BW8Gn8CWsdgyFlvGYstYbBlbEQuGVMRhEBwGlVAFh8NgqIYhoBbS hQ3VhQ3VhQ3VhQ3VhQ3VhWV0YRldWEYXltGFZXRhGV1YRheW0YVldGEZXVhGF5bRhWV0YRldWEYX ltGFZXRhGV1YRheW0YVldGEZXVhGF5bRhWV0YVH2XyD7L5D9F8j+C2T/BbL/Apn/QZn/QZn/QZn/ QZn/wUN0YZ/QhX1WF/YJ2b9DF/YJ2b9DFzZZFzZBFzYhdmH0juJghJOgw0kQvTv6Pp3YVTqxq3Ri VzkVOmLXmeuJ4C9iTwVVseeCj8WWwqrwxtjqcHFsDbwcPhZLhOfGfh+Mje3WvRXVpHvgnfC2eG1w TPwkajwlfC4+GsbAGVT5vO5seXCy06SRSuvj650aG0qv1yR1cTWU+ZbTZadO7p5yJ1ddft2m2ilT iOecMKU7b4R5vdSgcKFadqFadqFadqFadqFadqFadqFadqFadqFadqFadqGubpH6NKk+TTqdZjud ZjudZjudZjudZjudZjudZjudZjudZjudZuuuXpQ/n5E/n1ELJdVCSbVQUi2UVAsl1UJJtVBSLZRU CyXVQkm1UFItlFQLJdVCSbVQUi2UVAsl1UJJtVBSLZRUCyXVQUl1UFIdlFQHJdVBSXVQUh2UVAcl 1UFJdVBSHZRSB6XUQSl1UEodlFKzpNQsKTVLSs2SUrOk1CwpNUtKzZJSs6TULCk1S0rNklKbNKlN mtQmTWqTJrVJk9qkSW3SpDZpUi/MVi/MVivMViM8piZIqgmSzv+LRaTHeV901j8tCj0H7n/i/8X9 L8X3hLXxN/dn4nv3p+L79j8Rf2t/Ov72/qXxd8Ih8f2eD/f3DDps/0uDKsPaQVX7M4MO358aNHj/ E4Oq96cHDdm/dNDQcMigYZ7/0P6eYJBs/bRM3RHfqGeJvmXrfBlskQy2SAZbJIMtksEWUXaSspOU naTsJGUn/7+/t1T0mZgGyn5ZDdcITfAKJMIeqvw5Vf6cAjMUmKHATOzxsI3aFlJWJ2X1UlZv6V2o K8NfxNdRwPowQzULg5jILKSLOZ6rD8bElwV/H18RjIy/GHzUta/GXwqOiq8KPhVPBuONG1963WRD MC6e8tgSjDZHT/RKaXB4vM2z2eAEehtfep00eg9Vzol54PXS0VZaGS51/dLSmk/73e1B3HqjPJeK rgwq5cxqObNazqyWM6vlzOqKycYOsvaxonpW6X46+GO9A88cG4/qsGz0+qxTujOayc/dYcEqWVkk F4wrvT4bXTvaetE3f7azLrr3TvzAHSej/BG9Dl/6rM+3wub4NH5YGSYHnV16lfdb4Qb/2+7qF9Sw L4a7/a/N/6417sVwr/9tCI5UDYxWDYxWDYxWDYxWDYxWDYxWDYxWDYxWDYxWDYxWDYyOTwqOiF8W vhy/HK7lsWXhJjPtMNN6+4rmrZerltnXC2FrXDXvt1v8dpkKuo+d04LPiNURfluIYsTO2uDIivXB n1c0B8eV/45+VfwyVx24b8NnSvdtuLb0ntJE/Ca16QPB8fEHoT7MicAnqPS3gz4ffHrQmcFxdvbt 4ENGfMg6J/H8NN56IeyzUqK00v+h7kngaty238N3mudJc6ckGeI7FYVkKDOhgVBpVho1IXTVRWYu QrlIZJZ5HjPrhgw3Y3KVMmQIRaLzX98+x3Cn57773vu/33N+39rft/faa6299lprr/VVhzpweAoc LrHvZveHyCp8N3sQtEnApUR6F/KmGsiZPrB9LUUimKWCFGCGgC18b6MRYBoBZi1g1IFGKsBTIT7A 6V0v/LUK4wi1FuRiNbBDIvDqm0DvDXh2HcyoFWgKkR5o+sBafAErCbR4CXoFbOFNsOavaPrB/EC4 YhBmtIVv5CqB/itA7yro8Rrs4s9wopQiVUZXVU73AWBrghSNMOMBzKiBGbUwQ0H+1lDEYowGYNcC dj37NmbhW5gT2B41B4kUqfBtBDJe9TBTFXg1wmyhOqgFm6uAvLASrodwNSAbqKBtoIK2gQraBipo G6AcyCoqP7Bpf+RDA6ENgjYGstMEoJwiPUUnw04sBataBt5xCTR+GbxX0O1V6S7G7br0Bti3HmSu H2CP7WGP7dm3ewj/C4MdULMDWfXk2oMIChYo6PgG7Jmw08eB/3FYWTX7PxsCoRX+34Yk4HcZqJRA VLkifQ28aoHXO0EvbNYlZh8jgYfwd70B7Pt8m9NkiBAPUDPZWQD2Ug3aFX6H8rH0FHCW6bwMsFSg pw7k+PSXWfK/8aOJsIfjwVcewX49Bv0pyL/rtRrmQByAFVTB9VhahrQgG66GbLgasmEhw61m6x0J MgXAlQwrELArgCPLDmDsMUQP9r5XWgP2as529Rr7HtmR7Du2y2giSJsMq3gAOq2QPoFVNMhWIX0L EjUChQvCOzLGuxZ41wLv2s8WKv8daaAiAip2wF8FqFSzOliWoQiS3wcZhJ8HhqLeKAyucLhSIY+e BNdkuKbAlQazfaQWQLUV+LiG/O9bNdjft0ZLl4GW9oKWToNdHAK7cAG76E03g708AO4VID/jCPG3 GnT+SFoGNuEENuHEdZXeFHTO9FTPvl1ctm8ipq8qtiu1AH1AU75wZsiwjORYRsC7FjDtGX1hDxRo dNMG+k76As7yMk5R+gLO6jLOtuk88I1uug+99dBTz9lK2wLV6KYbtB402gizPwClj9IHnEjawKlI GzlVaS1gPgBMCZtbAKM3oecmUKtjcy/R9+BrwtyPsGtSmKOMFNlcNek1TgNaW6k50gHM88ClEbKO WpCshjZA2whcP0jfw8wrMLMeuDZCtlELEtdwStCqgBSq0vdA6QpQAnmbfgFtR0OeIqNSB1QagUqT IDPjLZtdB7MbYXYTk10mgwgZwMxokOEBfQs6ewdtA+gPshH5ym/Sj+BXTdKHQKkBZHnAKSAjoPYA qNVzkCnKNQLrR8qcuvQhUG4AmeYJJ0fTA6Ao6KCaNkHcVWTrr+bU4d5WihjGdrYj7xmWbFeUGZaw M1dBu7/ZLzj/5PsEs7+xPwyX7QvgfmM/kNa/ug9I7Z/VP1jxv1nvYON/om828od6RhqcHlLi9IGq IVLhjOEygTmmMN8M7iGT4ixgzArureFqAWM2MNYS4jHHGQANExgVQ9tC0AGnB0/6sN5mgGPMRmsZ LXPot4B7S7i3Zti1Ah2kwLANGdc6hmHFuNQhHZBLBKM1nAH0NIPLEJmDfJqAWQM0zUE+oAuXBTyL YdwSLivotwacFtBnA/ctgYcGUKkGWYUVijgj4G6MqJyKMLsa5BdWKOKaw5g1jMlmi5AWyKACs5+x lRoCXWPAMgHtmUK/jL8KUHjGNGAF49bQ1wLGbaBf4A2rAPr6MGogfck1E9YKFsdkgL00Bb5m0GcO OBbQJwYcS0EHgMNkARwbwGkJkU7YJ02mV0OkJ9+nRpBDD+TQADk0mW6t4Fm2T40ggx7IoCHsCtOe SD7rza+kF9Ytm/Hms9Saf9cmwGuvw91v7AK83QKp/7O2AbOag5f+iX3AKEG6/y4bAWr60PM37QRm qyHtf9VWgIqBsKJ/j73ATqxj+/i3bIatSP2ftRvg+Q4ywvqmKxAL7SDicBDVJFBHH4OoZgJ19CmI Pp2gjm6EqKYFdfQViI12EI04iGoSqKOPQVQzgTr6FESmTlBHN0JUAx9sugUaMQaNqING1DnDpvOg EX3OuKkKpLIGrXCgFcKZA54F4IkBxxIuK8BrDnjWgNcC8GwAryVYjTJUK5pQZ/SGqlIPqkkhM9aD TNMcsgp74Z0MZFxGiCB/qKLsEEKdUTfUGuq2HohHA5AXkqBhaDj0joB8yAVFoLmoP5qPtqI4VID2 w90hdAwtRyfgsxKdQqVoFboJGfUuVI310Qlsgk3QC2yO7dBLPBAPwggPxt6Y4JHYHyvh0TgUq+FI +OjgaByLdXEyXo4NcA58OuMf4dMFr4KPC96EN+Ou+AS+jLsRntjjwcSROGFP0pl0xsOIK+mGhxM3 4o5HkN6kNx5F+pIB2I8MIoNwIBlKvHAQGUZ8cSgZRUbhMWQ0GY0jSCgJw5FkDBmDo0gkicXRJIGk 4AQygWTi8WQWmYczyQKyFM8ly0k2XkLWkZ14KdlNzuB15BwpxfvJTVKBz5FH5Cm+Rl6Ql/gGeUXe 4lukgTTiciKlCD+ghFJcSRWpOq6imlQHP6N6VA/XUgNqjF9RC2qB31JLaoXfUWvaAr+nLWkr/IG2 pXZYStvT9gRTCbUnhDrSjoSjnWkXoki7UleiTLvT7kSV9qQ9iRp1p+5EnQ6ig4kG9aa+BGpcGkIg 36ExREwT6HhiRSfTycSWptE00ooupctIa1pAC0hbuofuIXZ0P91P2tGD9BRpTy/RG6QzfUCfEnda T6XEgxNxGsSX0+NsSTDXletKxiMMtqKCOysUIRoyMQHq5jEJYVEoNjooKRblwHmJvTx7iqHaQVIp 0oYKXAGZIEuo1VuDXTmCPbmhwcgHaPRDo1AQGiPHU4f63RRZIV3UBiyvA+qC3NEQsEAMVueHgsH+ OJgjw9WAOt8MNYequC3w6QjW2QsNBVslYLf+KARFQjVAPAcPEiMXb88BYjSWzdNlvxNmjgyRNdIH i3dCXVF3yPQ9kS+iqCUaiAKgApDh6gEFFWQB/tECGaB2yAE5I1fwjD7gFyNAEls0CI2GWiFKTlkb qSIxMob6sRlU753Ak3qivsgbjYRTphXyQIHgQ9EoJsQ+MYQsZDCHwXUMFjB4gMGTIUHRSaSYwesM 3mWwksEaBt+EBCWGkQ8CpIRBJQY1GNRj0DgkJCaeihm0YbAtg/YMOjPoGhodOYa6M9ifwSGhsXEx dBiDfgwGMxjBYCyDSeEJQSE0lcFpDM5ncDmDeQxuBWJBdB+DRxg8GR2bHEPPM3iJwesM3mbwPoNV 0XEh0bSGwVcMvhcgh2AwgVNgUI1BHQYNGTRn0DoOGq41gzyDHRl0YbAng33jEkJjOQ8GvRkcGS/0 BzIYzmA0gwkMTmAwLRF0zk1jcDaDixhczuAqBtcnRsaGc1sZ3MXgAQaPMXiawaLEmJB4roTBewzW MPhegCIlBg0Sk4MTRdYMtmaQZ7Ajgy4M9kxMjk8U9WXQg0FvBkcyGMhgeBJILopmMIHBCQymMTiN wdngThT8shl4xN+5I+DZiv9Ei8EXvg25vwBNfwdVvwkpxAxl8Om/c4chgv0Wav0FSNjqCVASnjCD iEGlvwA1/wI0/h3U+AtQm8lFWYu/goK8X/epfROKIPbpQTSVWcS/9mQgf/orfDFE5m9D9W9AK4j+ HnDGBEB0jkUpKA3NgLxmKWQy6yHH2Qf5zVl0CTKbe6gKPUf1qAkrYA3IUsyxDW6HO2JX3Bt7yPYV a8lbY3krlrcdwfqF1kX2TMSyZ7JQ/lwia6mxrJ/K8ekQeX+qvF0qby/JWshJZa18nNssb2/LWpGj rFVcx3YVK9+VPat0lLfdZXxU+sufZ8vbD7JWzVbma2p3Za2mgqxfM0LeFsnb6/JWzlezHvipwBWC s5gHBOMlAJVgpSsEH8B18KSBONqL9qF9aT/BP4gO0QHj0yMGbAbgUg0BV/jbF2gD4NKR+44ZjKvh l/glPNYBLYzf4/eIYCmWIkpERIQ4okpUkYhoES2kQPSJPlIkxsQYKRErYoWUiS2xRSq0H3BWBVrN YHUZgthYE32HjbEZmoptsS2aBnmqH5oOuWkMmonjcByajcfhJDQHz8az0QLIVbPRQshHh6BFJIkk o91kPGRGe0kqSUX7yBSShvaTaWQaOkgySSY6RJaQJegwWUaWoSOQTd5AR6k6rLEWcjtH9BoyOXf0 BqRpi3TJajqQDqbhdAwdS6NoIk2m4+lEOoXOpLPobDqHzqXz6EpBC2QVWQVBagAdAJryoB6I0FAa hiiNoJFIBJlfAlKkSTQJKdEUmgLVwAQ6AVYOuSBShVzwe6RGV9AVoFnKYscXHZsLu0C6EGFvFImE SGBvOhKwG9KJdIIRF+ICunYn7qDr/qQ/6HoI6EEBsA1BvzzpQJxhthvpRwaTrmQA9Cv/dSokg2QA 18VkMdgBQUJFZs5ZcGLOkrPimnPWXAvOBmowAms+BDUNYtIbfiW9BbOcaAGDE2peGYbpVxjir8aI 8BMlwEacUCtizpazZXYh8NXj9DkDrhlnyBlxxpwJZ8qZfcWXIKG21uF0IUNW4BQ5JU6ZU+FUOTVO ndPgNDktThtwOND0dyCCMIdA/uyK1LgeXA/wAAJ5qyFdTzfSrXQ7PU3P0LP0HD1PL9Ai+hMtphdp DX1Gn9MX9CWtpa/oa/qGCr6jQPNpPlDcQDeALFvoFth3yOZhHQIPTsjdP1PPB6wtMHqIHqZH6FF6 jB6nJ2ghPUlPAV4FraQPaRWtpo/oY/oE5gnU19P1QH0j3QjUt9KtQH073Q7UT9OLQL2G1jHq7YSf lv0B1T9YB9PZA5iH5PP+gPOfrFXQ9UU2zwppYB88HI/AvngYjsBXSTJJIzNJFs2hm+guIebgIdgb NngMHoNEuASXgC0lkSSwpSlkCni/4IfKzA9V6HK6HHxA0KAa3Ul3wklAcD16h75H09B0OAMy0Uw0 C81Gc6DmnQcnwgK0EP2AFqHFaAnKgvNhGdS92VDrrEA/Qu27Cq1GuWgNykNr0TqUD2fHBrQRbUKb 0RaolrfBSbId7UA7oTLejfagvXCu7EcH0EGonw+jI+gonDLHoYYuRCehij6NzsCZcw6dRxdQEfoJ FaOLcAJdRiXoCrqKrqHr6Gc4j25ApX0L3UZ30F1UBqdTObqPfkEPUAWqhAq8ClWjR+gxeoKeohr0 DE6uF+glqkWv0GuIMnVwjr2FtTag96gRfUAfUROSCoEZqmVP4kW8iQ9UzMOJLxlBRkLV7Ef8SQDU zYEkiASTEKF2JuFQO0dA5TyWRJFoEkNiSRyJJ+OgKr5FbpM75C4pI/dIOblPfiEPSAWpJA9JFamG evkxeUKekhqqQp6R51RVqJ1JLdTOr8kbUkfqyVvyDmro96SRfCAfSZNQSVMsVNKUoyKqANW0ElWm Q6kn9YJq14/600AaRGPoODqNTqczaCZdTLPpj3QH7Osuuhsq3ANQ2V6il2kJvUKv0mv0Ov2ZltIb XBfOBaxGXxb/WST/jkXmXNofIup1qKg9UCnU0qPQTRpAR6PbLE7cpfE0HpWBV6eje3QRXYQeMGuq YLG0kvnmQ2ZZVWCXm1A189BHzEMf0310P3rC/LSG68R1hp0g+Bjs4X/G7n5tdf8pmyv7t1jd7+3u k+X9se19sT7B/r5YYC6zwf8fK8wW7AcTrA9RxxhyBj0WgZqzzMEWB+Aw1IZFIwfhPRdyxFGQS3SA XCIVOePJkB2542y8EgXgvfgyCiEJEJ/SyCySjZawkz2fqlEdtF54Z4S2UQPaGhXQtrQ9OkUlkC2c Y1Z3B86zznDy6sAJaI5sIH9wBJny4SNAOBPYfQF7Oip/OgpPZfCBWI/b4DYgezvcDjbCGTuDNfbB fWCpA/AAxEGOsxwyc1k2VwAfyAqwPw6X9+z7que3GYQlyyD8yFiWQXgST/Cw4WQ4nP0jyUgY8Sf+ cPaHkTA4+6NIFJz948g4lkFYCd/E+qsMYihYxQigFQr7HS/kjv9ELiFwVmSclRhnZcZZhXFWZZzV GGeI/+BhffA1fB3/jEvxDXwT38K38R18F5fhe7gc38e/4Ae4Alfih7gKV+NH+DF+gp/iGo5yHK2n b+k72kDf00b6gX6kTVT6r/RxoHxOqBuNwboIy061hMoCagsKtYc5DAs5qgjsDVYJ9jYSKcI++CMl ZmnKkLVGw3koZK2qOBmnQMY8BU+BE3QWnoU08Rw8F2nhhXgh0hHetyJdsMC9YL0ncCHY81l8DjXD xbgYGbHcxZidwabsBOdZBuPOMpjeIF9nkPBv6EzuN//FlYHltGY5w0jwmm9VgMUQBW9CxKuE2PYS 4tgHkF0J6kA9kFsMlWBbbA/e44rdcX/cGtZhC6uyY+1I8Cmh9cedWBuAO7N2NO7C2kCoCoU2CHdl bTB2ZW0I7sba0M9tD9aGY3fWRuLerI0GPxXaONwKPFETvJnAU1skvGVvx3yzPcAAzAMcjSUAA7E9 wCDsADAYQ7QAXh0AhkKdSnAYdgIYjnsCjMRuAKNwL4DREBUIcOkLMB5DXQC1UH+ACXggwByogQle gQcB/BEqKh45o+6oLxqCfFEgikDxaAKaCifbfPCxHDix1sPptAtOo2Nw8hThzbCCHJB6C2v98VbW BuBtrB2NC1gbiHeyNghvZ20w3sHaELyLtaF4N2vD8B7WhuNVTBermRZymRbWMC3kMS3kMy2sZVpY x7SwnmlhA9PCRqaFTcLaWIyzZa0H5AoayBbZIxf2bkgDLMuA6boZ05GhHJ/DRp/vIgRNsjdgangp 0xWDQmWAtcD2EdaH8wMzGyfMcimMmQN2La7HjRAEFIga0SYGxIQ0J61YvfzvrH8hkrMa7UvFpyRU QZ9rqH9QB32uoAQaAST6c8wXTgDhHY0BG4UnLhB9enOH5O+/Pr8NM3GHVk/WbeLCZ5g4Kyi3ntF3 xlt1rEhyM0xaQVcLgrFElVdWELXRoMRYhPggBZU2CpjDGU4Ec7le/FC+7Vc9pnnmU01hk4TPYBSM ElEcikZhKAkuV+HDW35FjNN7X2VWsawg9bTP3HfdjPrWJSbnbBiYm6FfzmfQ03DZ5VIIVkSrz3Gj rPJ5nr3d3t6J6asuWcerfxYVi0Co9DlMSOrDKeiSkT0k+ryu8KCkqzY8LDEpLCFW7BYUHybR43WE bkVdVffkhOCg2JTI6OgwiSZQg14VXQXviKDxSWESM95E6FDV1ZN1iN3CEpIiwyNDgpIi42IlFryZ MEx1DeTD3pExwCUoJj4ydozYrQdv3kydd5DY8448+zeymbpEeHSwd+jQqUOnkbzXV8L6eEma8foy /hrDwhIivSLHxLYV94sNaSdpw7eSMbL6NMBYib0+8fIKS0iJDAlLFJhmYKuvtYJFiGZgTQT9KiQD Y7SpaNe64ovi7SpTZm3NTH65x6O2vFDz+Jigo2tDTW8fbihy2DKNn+WbNvdOVFnHVZrHr9RMeDV+ fVqcy/HF29UPRbyJXlJ01NNuS9+udft+9h9tQla/bx9lvu7t2pz1xufJL98N9KzQCKzpbpp2UP1e t3N7yjOPjk4dK2lHs9N1N/YRX5Ikqg+3uzjB0SFLJ1vn4L2I9purKk7Ontv61BzLzPCj3/sOj0s+ 7rLZJtO/SEvfZfW0J96FKrGnm870LzuoqL3MavId15ZXzCfUrJZcqK2yMrpzencftxzj0bnmCysD 6p5Prp2yJRgvqBukeq/EatjGrIsFM1MKnh9Sf1056FZuY0RugV6X3ZmFhwkFw1+bfodPv8k7KiiB xYpEihgcjrfhrT8983iGYURSUnzn9u3jQhLj26WA3hNB7+1C4mKY7ZjpYizllHgFaAhGfA+hz4Lr zDvzHXMdc+1n8PLpIQnRv5rdXmYrX5uKW492gMUs1awFp8arfJKCKvEaQqemwIsDD1AACeFZmwPL XGfEN/tk31RXzdurBxias53EroPDb7yCpqej/lENT3xPuptKZk3MbrP0eMZWXGo68OKO2b6x5Uqt 1gacL1qsW815qr/o07I9ct5ReWGxR851q2D9t92cLAfHS6bWznHO3P3o0TLUdNlnqYf11U0tPVIL 9gf1eN36UvWFWwFlh9tMd927cu+tX4ZLj+05k1Z3WW3Vy2VNba518TQxcW75tlt/8GEpn0Gq5X6s /rjNy+s3W800tBcpB+SkzPytH/9HPOP37sg7f+2Ow/8i0/a8nYypzbeYCmNhCd90yV1DbPuWXYtI nWboHp7sn3b6wOoQG2lXtx8naztrtfBJvJXcMvKjx0Gx3zWVhlyT1s98hlkG3TS/U3nEIerci7K1 TmHzTRar7fMy95sc3mG0aHavphSPcq+peenilQUz/fKU3j7kG55bOQ3sqXKp/KzF6VKfx+nd9nqu bbsZp77K2zyvQ9PqKv+xotVdoyqOLz3RVBzY0L1aMdf9afrQ2PzWr/bN1rJ9tuCuQu6MITmT+iup 82ZFWqui3j72LeA2dc/eZftogcFWlwqvuAHXOqzcGxdqtntp28Ndqyc+jUltMKiy2bb9RbbX/u5t sw5M3Nx03XNLq6S0njWdzPPGGlSNOGwdcRNNddPKnBold8kiPv3c33RJtc8uSXjEO8icsS3fmrfN tcm1nmH1Z86YlJhoFxLE3M+AuZ9A4h94oMKJv+SBjr/1QGGXMyfE3/bwxOJR9ydeyOBPfzxotPTo D+jU0YsXz77RuCltGHTCIZjXPlOXZHJ90b3RP4p1d07udWzIxe+rpzb7fkPLxWN0ezcWHVjegxav GDpKNOe7jXGvTYaYWLd7FTkv2urt4SKDrGdqSScixt96mh2cWZi48N2spNTmW9Yun7Rs59sFrcYN apds0rfH7Zd71cXepeNzl2WERH5Uvjz7ZfJh5RW3GrR9bHKC7I+lkh2TZhzLOzXHqu2EKx1SjixK 9Gs4WDVQX6V5ceXV647t+nXXd9EMTLU+mx/+Yunl+Keu1W/U0+5embw2ZVxk4Y+D+/AdLHfmbTcO dmlza/7m1oqTbhru9pv0YGV+XJPLrG18BqcDIeC9LARookI0x8VlpvYV1/qQmvLuX2uMgwgQ/8m3 VXWt3OLiJyZEjolIEtuGtBJLOnVyEg+KDEmIS4wLTxK7xSXEt5OY86YyZP1fj8QlyM5qS95Ctk2G X8Y94+KSxD2SkyLiEiKTJgrhoZMTL5HwvJM8PNjzEnsHifzxvyDRN49ycrQwvqrLKw8T29XLJgTw T/I2zWsx+l1T1sC1+5tW5oldJw/NW5G3INA+6krP0InPt6Zc8L796umPM0wXrJ4WvvtMVGpw81Iz l3uaeNGjpaeP24Xn5ETYZJd0bntcba+vTWHvahVX56VtN9l22ljT7/ueFdM0D+dE+wRtzZi8JtBu /MDH2XtCu+QMMZUoWeut3lT9QxvDqq7LQ/QCfUVhq82cPDPfbnixhJw1uXbcp9fuWVOPd67xXuJR 8HFDakySx3bD4qXKtpZo+MLASKfDA3QUXYZJRzWuC1dRWn81fdjwF/u6BBikj+du1x8rmJrVtOPi d6UbjBP8XIqOvFRaa8XvVph+Ybd4vO70cnnc2Min5/PpeYJfYi49h09fNlVrVEn8i8iEVc2Hpunt GjRf+tOahP///cv4ho2zqJD1SPXEvNfLDDs8O4Ctb47Xfu0XaL96lepPrqIfZi640LnK8tXL4Yvb 7s3tcz74xYcbxV26jNzU0TuyyTqm24XizfdEk8sk87qu1oofe7hJZ7Bh5IkPJW4V2iPFg58ET9q+ 2eh8G6cWdsfC1ujMbqEZsvatt2mD5YVS/deeW2Pd7BU/ZjR793BMtPrQ+qO1nueOVp/mP4glyjPN sloZD/rZjOTXTr1P94x6s7Ps/PDnYf3OeXrv20NtdaQLS18qLUg7sOzMFqe2lamVG8dXpOSikrHd Cq92nH2/h87GDmNNxt7p8Mt1U65yYy/u/EgH59hBpurB+1Xy5l772btb74umPuvj7+h0zlycvHrD 1VyICqcgOdguTwzGqmYPPoHMtmjfPk3WhLc89KlIMPtvhQS+I+QLjhInR0eJo5DAQ4i37/gpJKSv /3XKoMtry8oNleFBiRGQCiQBHy12hECxoegZFhoTFxv6STKVP5Psz5ZpD0x/t8zmvKVsGcZfj4SG seRDyEaGsKJA/PtIoi5EEiUWSU4Vi+cdKZe6DnmeevK6dYv6lEuW0outh3kU/bg/Y1eHiXbo9Eal n0Mu7M+vf1xYWLpz7tI8xfea+zI8c55mnD2qdWbjiedR0+Z7mRwe8j4Uzyo0uJ4RgbpPcK/TcfZo DBl6/33Xgw+ddpaHKDbvMq67Y583UQW961ommlv91NPIfOg+z5xra0t0zxp1G6cQ8yrL0n10z2cn LmSHig8UOn7Ic6+atMus/YH1996sKV9hqdnkK+nh45y23be6smbExBZb3rZur93NeYJrz+82RFSm WUU0q+q/6PQEd88+awZPm7V4xYkxk54oN86gU+qzx7m02RC+vLjc7kEbYqzp2DeszkVne22mqZmN Z1wx2B5dm4Fbgz5s/igPp/8b4UVHQVlegOtDfCGUIo6VqGYanAGn1+JdmwH+5xO8tz2sz23dzKCx sMErnTf6PEWPcGrmKsgLJUO57oZ68Kos8WF1R29e83OCJeIpNF/5JQtjIRX3X4sO7Hiiqup4JUPi Oiu4189KGxqCws63o++d+/a4vPdVy++vVZwZ5rVxr9Gl4qra3IZh+/ou6WP9cJPF3dTr9QapOnde LzSpUfLfPX3hwbm+h02Ls65lLXF488M96cwVAQP6Delk01ls4u30YYqf/uJTd03nvwzydHmo+Cz8 xcSaBZeGh4RlGfbLTS0P219uU9B0Xmff2bzis6PnxL8uurMlI1bxbpjRwY31M04q91xea7M1MnVn YZsNO8It8rdnKkUt0z2wo2O2uWitrvPaE1t510OWN/j1RcE6ptuHz3tYm6p9KMBFzal2ceGimR7c SJHfuculm279MuWHCS0b98TmL1Bw8N0Z0Fpbk88QOUAoM5GFMZWg3qt+Yq9bwn73huJ/JWR8iX2d HB0cOwrVkhPkRvDYQXjkk/4j65CP0z8Z/2ZKdDF9qXOBX96rwvJ7JVuy5pW6rLSYc8p/Rjv/lzsT 6rZsnTl27+2dVpNUz5/PH/BDgJXu44a65iv3volNKXjxfJ3LudMnRvh127I70cFmfXB60MQ1wW9i Z2aVxJadW3113VDtlKBD8bPD1iw1mLXBP73EPfzhnWGruhd9uJti3c6dRw9Lp0zK0v7Z12zto8Gq F2bezSv1yo4uCinKHpuzKGDgIO1H7a+NGhUw2nNtol3+4Wm91Oca6af8pHQ7Z328/qNBNZEf/XdF LXjWaqiT85yzvfvpLxmyfMebiHU37imPG5O0avxcs+lRy55Uj+5VfL9qnPqVELR4kmT5fNU9ukd3 lzyvLbd8vikw6LmTW9dTspQoAy8Cjcz/Xe3yJRg8vxW1Kdnr4uDnJh5GCuZrf9xyecnHP4l8m4Te 5lz6Gj591dQ/jCJrktb9N+Lf75OFAbLCz53vyXfPdc11mdH5q8Iv5hMdVvnFR0UKve3jE+JCk0OS EtsLDiDYP9i+PSsIB39VibrxPfhunytRMsNBTnf8+PF/RDcs4fcEk/6oJnS+9SLLeYXfcj1/79jI cnK+enfjtZODtrXf8p23+m37fe/GVqk3WhqPd82PSN2TlTbb75Xb6e9XhE2ZOWTo5Ay9uu8Tb+Qd 8ysi8Zdsopsd8dTLn3Vif+Wa4jXJK38Y19XkxDA0bO+7aTa3AxwaS1ukBuTcXt/45lUP460+vbf1 vfuDs66vcr/a15JMiyPc/FE6YfSx6tCSNWqzs4/eKtxYoqTfwnLvvuGzTK+MmtEhv+jj5syaTU7d 9rtFVYhrex1JK3hc67NrTd8jYce8HG9deKQQwilMiB0i7Xt4xRO3kZl3tqlMrRtxpm3lw+9G9X9o P/G51fRFana7h4w6e7K7r++Wqxcr2hderIlZ7TRRksH9BGHzHMGYT9/7PxMcfxXgv7zGzk1/xOt9 PlBtsUSRitgvngrHrHzrlalE7es35yD6lydViQb/9ag+3/zLRE4Cfrs3edzpQ1FXM7Z0H734fY/p Dqdqr83kE76aoiYJ5YNznad2RINQJApBCSiOvXwPR0lIjHrDXSy7G4bCYCwRcIQeMeqA2iEe8Wts plr/qW0nTYyPG5MQFB8x8bfZJJeB0YCzUSs+Br89/Nr2UU1ZSvxJ7LVlepRF/rPoycN+KBhxMbWf z8bCqq5XwwcYLry/tOOqS3aRo/ru8m9ZtXzh05d7mlp877vESbQ/63LjNe087e3Pu94qc9s+tGD9 4BCbd5OUb/cuD4nefenwa+8rik9W1Xu9UV78cnxGzaPeXtv8+knK+FalqWN2PvFI3VFbXb0pD4V2 t7v8qKN4lp7NB3+V+r2zjZtf1Sq57NnGYuTmbeW391ndLdxf9OBxRKt8jU7ctcfG7/rfrt2R7jNx Y6qq/p4k31Yn05vapvnuGo1Ec79rUbD+6frKDdmamTt91+21G62+qf8782L3bptePDxQenl6h1mO 239Z3Mtl+7p9azIgLcrAjV92TEGSgWug65Fg3mP+Iy81/+BVqtr/jY0D4gAmYCmzINJAAjntcSOm dhiBSQ8uw2rID6rvgRW8EWjIwxBYwcsjJz0hFoEzM55IBQVMzTOtjnItm1Z4E0sSaPyW3FbEFvQr e0Fi2mTW5/3nH5R5WbS6Br16vo5/YeTFuTpu4uKRD8JcJf/pPBEItz7FLBLxYtLGmdMmWDzs3KMR v1um8YH+zKUVgncsL35jKPs8IYJz9rab9ifcTj3Y2Mgtn2uVcGxd1lsfpU8y/5wKz3wv+WORfO2d Ya7kZTN90aiLp6SeFugd8plfFDVrrtg3hv0zb0pkyd2+dV/l4ekJ23fmTl4ycbt1ubKPhtP0tfGR z+X//eOyTtx04nDYZqXHB1ke5pi68zGebVy4p0O+La4zq/VR0IItraYvBCquGVzs26TxddazFalu JRG7pl5hNqwra9sjNd02+pwmj9+nP4ashcY31htfEJ/yAQAW5GidDQplbmRzdHJlYW0NCmVuZG9i ag0KMTM3NCAwIG9iag0KWyAwWyA1MDddICA4NDJbIDMyNl0gIDg4NFsgNDk4XSBdIA0KZW5kb2Jq DQoxMzc1IDAgb2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDI5MD4+DQpzdHJlYW0N CnicXZHNboQgEIDvPAXH7WEjou72YEx2NU089Ce1fQCF0ZJUJIgH3744bG2zJEo+mW8YZ6Kyrmqt HI3e7CQacLRXWlqYp8UKoB0MSpOYU6mEuxG+xdgaEnm5WWcHY637ieQ5jd794ezsSg8XOXXwQKJX K8EqPdDDZ9l4bhZjvmEE7SgjRUEl9D7Rc2te2hFohNqxlv5cufXonb+Ij9UA5chxKEZMEmbTCrCt HoDkzK+C5k9+FQS0vDvPgtX14qu1GJ34aMY4K5CyQBwprpCSCxIPlAZKTkhZgrfc8vHf7Hsx6TVI JW6nR3QzFlwePla3FEHi9xVmZww7p+het3o5i8v/927/uY1jb6JYrPX9w5lh47aWKQ37WM1kNmt7 fgC/0ZmMDQplbmRzdHJlYW0NCmVuZG9iag0KMTM3NiAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCAyMzQ2MC9MZW5ndGgxIDU4NjkyPj4NCnN0cmVhbQ0KeJzsfQl8VEXW76m6t5d0 p9NLOp3uztLdabJ2QkJCFkKTdMgGRAhLAgkE6ATC4sCQGGAUFRAVNEFZ3AWVb1xGRaCTgCSgAoqO jDKoKC44AzKgzmDEBZgFkvudqu6wjfqc37zv9+a911Vd/6o6dW5V3VPnnKpq2ggEAMIRRMgomTCy XBUychPAga8AomrKS0rLwp/TVAPcvBCAXlc+tnKC9cGdFwBu3QuQN758QvVwuWzPWYAXjdjJkcoJ 6Zla15J2ANKFvXonloyuyewYnQgQbQfQ3z9jfn3T0nHvrARI2448J2YsXmh/PqwRn/UMAFCsntU0 e367IScTIP1hANlHs+tbmsAFITj+TOxPN3veTbNu+2X5BIByH1ZfmNNYP/NQ62252Jcb23PmIEG1 VRiMdZwvDJgzf+GNI4SQ8zh3M4BVOW/BjPoMZdZnADV1AOZN8+tvbNJNVCcjP44H9l/Wz29c9V6F EqDpIoCqtGlBy8K+BGDvX8Lam25obHpp0xobQHYTtrcDk50MYP2NeUnTte5zyhB8FMOT8ePqWb5v +JcxkuIfa8ULShdWQzg/C5jLn+t9BB8OlxTSe+KFSy39YQejhFZCOVBep6CDdDYT4Qkcl1PEg2Qt jq6UPSrLwi5j/LlQD7OoQSajCiGEUhkVxeOQIu2FG4v5DDBUjS62gwfs9mjxi76lbCZ0tgeIJEn4 dIO4nr0piOJBmM24MQ8kchqTCv4HA/Z/8N97Hjb/DJ7uf2eMH+mzGtPL19AiMM3DtO4H+Nf/755D MPx4QHl3/p+eQzAEQzAEQzAEQzAEQzAEQzAEQzAEQzAEQzAEQzAEQzAEw39YEEAgLMgEgVBCwCz7 Sr0X/qaUQAlyqQ9CIETqBRVHNagRQyEUUYN4EcJAg6jlqIMwRD1opQtg4BgOOkQj6BEjEP8BJjAg RkI4ohmM0t/BAiZEK8coiESMRvwbxIAZMRYsiDaOdoiS/goOjnEQjeiEGOk8DOAYzzEBYhETwSad gySOyeBATEE8Cy6IQ0wFJ2Iax4EwQPoe0iEeMYPjIEhAzIRE6TvIghTEweBCzEb8FnIgFTEX0hDz OA6BgdI3kM9xKKQjumEQ4jDEM1AAmYiFkIXoQfwaimAw4nDIRizmWAI5Ug+UQi5iGeQhlsMQxBGI X8FIyEccBUMRKxBPw3XgRhzNcQwUIFZCofQXGMtxHHgQx0MR4gTEP0MVDEes5jgRSqUvYRKUI9Zw rIURiJNhpPQFTOFYB6MQp3KcBhXS5zAdrkP0wmjEehgjnYIGqEScwXEmjEVshHHSSZjFcTaMR5zD cS5USX+C66Ea8Rcc58FE6QTMh0mIv+S4AGoQmxA/g2aoRbwBpiC2IB6HhVCHuAimIi7m+CuYJh2D G8GLeBPUIy6BBsSbYYb0R7gFZiLeCo2ISxH/AMtgFuJymI14G8cVMEf6FG7neAdcj3gn/AJxJeJR WAXzEO+C+Yh3I34CrfBLxDaOq2EB4j3QJH0M90Iz4hq4AXEttCCuQ/wI1sNCxPs43g+LpA/hAViM +CDHh+BGxIfhJukIPMLxUbgFcQPHjXCr9AE8BksRH+f4BCyT3odNcBvif3H8NaxAfBJulw7DUxyf hjsQn+H4G7hTeg+ehZWIz8EqxOfhLuld2Ax3I77AcQu0Im5FfAe2QRuiD1YjtnPsgHulQ9AJaxC3 c9wBa6Xfw4scd8I6xC5Yj9iNeBB2wX2Iu+EBxJfgIelteBkeRnwFHkHcw3EvPCq9Bfs4vgobEF+D jYj74THpd/A6PI74BjyB+FvEA/AmbEI8wPF38F+Ib8GvpTfhbY4H4SnE38PTiIcQfwvvwDOI73J8 D34jvQGH4VnE9zl+AM8hHoHN0uvwIceP4AXEjzl+Aluk/XAUtiJ+yvEPsE16Df4IHYjHoBPxOGxH /Ax2SK/CCY5/ghcRT3I8BTulffA5dCF+wfFL6Jb2wp9hN+JfOJ6GlxC/QtwDPfAy4tfwCuIZjt/A HukV+Bb2In4H+xC/h1ell+Esx3PwGuJ52I/4V8SX4G/wOuLf4U3Ef3C8AAek3XCRYy/8DrEP3pJ2 gcTxSp+u4j5d9f+lT08K+vSgTw/69H/Dpz8c9OlBn/4f5dP/Xzqnl/yLPr0i6NN/0qc3B3168Jz+ kz5913+UT2ffyfhTdOCXw7dgDUtkBYho3YCeWocUEb1rPnqcCWi7C9D6Ntmj2a980f/6qXPQdgNU 6U9XxRnHH/qn3yQHApHD5R8yUwqBXyhfwYBTE2U/8mVSzDX1tP5Czg9xV1yHMHbceFae9CM9/ntB COT/4g9E/8el7Cmq8hQWDHMPzR+Sl5s9OCtzUEb6wLRUV0pyUmJC/ABnnMNui42JjrJazJGmCGO4 Qa/ThmlC1aoQpUIuEwVKILXUWea1+xK8PjHBOWJEGqs765FQfwXB67MjqexqHp/dy9nsV3N6kHPW NZweP6fnEifR2d3gTku1lzrtvoMlTnsXmTyuBsv3lDhr7b4eXh7Ny2t5WYNlhwMfsJea55TYfcRr L/WVLZ7TWuotwe7a1apiZ3GjKi0V2lVqLKqx5It0NrWTyALCCzSyNL+dglKDk/JZnSWlPouzhM3A J8SX1s/0jR1XU1oS5XDUpqX6SPEMZ4MPnMN9WhdngWI+jE9e7FPwYexz2dtAm709dW/r6i4dNHhd oTOdM+vranxCfS0bQ+/CcUt8kUtOmi9XsXNDcc2qK1ujhNZS81w7q7a2rrL7No2rubLVwbC2FvvA Z2l8mbe1DIdejUKsmGDH0eidtTU+cicOaWdvwt7K/36NzlJG8V5v94U4hzvntF7vxaWxtvpg/E2O DqvV041bq7XU3lpV43T4CqOctfUl0e1GaB1/U6fFY7dc3ZKW2q7T+wXbHqYNFEI1VxYaL7XxEmdn pYrxlyRL2IycI1EhfPYZdpxJjRPfKY9BYx60zshDNgy1BJ/yzcQVmesLKfa26vIZnT3vk8XrnPbW c4Aa4Oz56mpKfYAij9edA1ZkenJJ1bC9v+xzuXwpKUxFFMW4pjjHAl7PTktd3EXnOpt0dsxQfDAW ZVtfm5+O4nc42AK3dXmgASu+5eNq/HU7NER1gCfdVeujXtayt78lopq1LO9vufS414mavJ0bdYRP mXDpo9WZwkvn5PuI6SeaG/3tFROcFeMm19hLW70B2VZUXVXzt+ddaguUfOHFNUIUDZRolMBbUSnr LjGzSk2oT4zHj5wr9cwuhRK1klOIvcyn847wY63K4fiZD3VJ37CneHb5scA0ffmuq+tDr6pfNb3Q VgEnLCbQiqrJra2qq9rK0AO1tpY57WWt3tb6Lml5g9Ouc7Z2CwlCQmtTqbd/RbukXW1RvrLVtfgS c0g+aiuF4e1Octe4dg+5a8Lkmm4duua7qmo6KKHF3uG17QOwrabbjj6XU+klKqvZWQ0qCGp6B1Xy pqhuD8By3ipyAq/P6CLAacp+GoEZXdRP03EahrRdeIjeK+ztqM7ydGGWz7POsAGZy1mu1vC8IySr sChd2AtNmLZhOoRJhOmIywIUAWyIhZgYdQ1v3yTsBh+mvZjewcQou5CyCym7kLILKYVCFxBhp/Bi xwAbDr290zIg80yRVegECRMV1glteDGzCdMC+fRAvgbzFMzXBvJ7hLaOoTZtUQjWCZxBlDBRfLeN HeWVmd28kOvmhQ39lA2dSLEVWYSNOKuNOKuNOKuNOKsziAR73YD0DUjfgPQNnL4BCO/KkRzoKlDY 2KE1BShYKFIJtcJEvOvZhJpAPkmY2JFp21PkFaqx620cNwlViGs4TudYyXEZb13Gywt4eQEvF/Jy YaDMMP0KtHHUMhTGCxPwfmoTxgmjeD5WKMV7rE2oxDrLxwgjeT5aKOf5dUg3Y16BfAbMRwllvD4S 6yWYj8A6y8uFso4SW0ZRE9anYxvF8Ri9BOdQgnMqQSExyhpMmzAd45TpiMswHcIkcE4ilGAsxlgk FOETHuzDgy0eEAQPxkKMBUIBtgxD3mGIHsHN39GNXG4cyY2ycmPPblweNy6PGxSCG9EuZEMGJg+m sZi8mGTYTyo+l4rzSsURUoU0vNvbBAddjWcmm2AP5DbaBrGYx9K2jlibpyiEboexmLyYmjAtp9s7 ZAZtkRH5GG86pkpM0zEtw/QEpm2YlFDob/GoaSEtFCpppSCidid3ut2ZPM/K8efRMf481JqpLbpB SEYxJcMTmASccjJOORlftb9mw0RRdRJhD6ZDmI5hYgJPRGEkojAS8QUT8flEziXnfGcwSZgEVKJE 7P9qHhl/2oYp/YpeGDUJKUlYS8JnkpA3CanHEAl/grWPxbQG055AWxxX5jiunHHYVxzONh2xkJe0 iDYhroOGaLtQviRfW5SLcq/EhI30HpTmPSi3e5iGUGbE6dhSGOBYg2kbJpnQjTEZYyLGJIxxGB0Y 7RhxBYVYXL21GNdgvBfjPRhXY2zD1TBuc+1x0enZC7KXZa/JfiJ7W/aebMVuWo/RS70eFZhMuBMa 9EprkY6KUAca8g+OWzjewNHDMdJjrdOcrNO8Wad5pE7zQJ2mpk4zpk5TVqdJr9N0kQZPpEtz1KVZ 69JMdGlyXJpslybLpUl2aYr0pJZMAg28wnE4x0yOcRxjyKQODYS8RKaAQ4kaTxK3O26znXJ0iaTD drujS4nZCn9tij8byogv2jIcs22pfkqCPxvgeFnEHqCavAAK4vKkKg4opis8iiGKgYo0RZIiUeFU 2BRGpUGpU4YpQ5UqpVIpV4pKqgSlsUs67nGx25NRrmOZXGQo8rKOMmQXLTw6UKKkeLHwhQsVtGLC cFLh2zsDKhrsvvMTnF1EhXuqzDmc+AwVUFE13OzLdVV0KaTxvjxXhS9k7JSadkLurcWaj96FW1ZV TReRGOnOKHZ87QZCUu+8JyqQ19ayZ2raRXLPPbVgWlxoLjQU6IeUlfwAeAPouhzMrisrOJMY34MV E2p8z8fU+jJZQYqprUDJsdNuN82jOaUl3TSXZbU13arlNK90PKOrlpfUXuYDO9JLusHBMs4HdsYH 9mv4Ymku44tnmZ8vlvPFXsXXPsxRWtLucPTzDOM8w67mmX01z2zOMzvAI/h5HFfwKI6Dg/M4FMf/ iSf2Z/DE/yDPFdJsHO76iUC6YRQ50l68hF0VvM7SRkxeX9viOWbf8ga7vRuKyZHALSLB2zBjDsvr G7vIEWdjia/YWWJvH7Xkn9t9S1jzKGdJOywprappX+JpLOkY5RlV6qwvqe0sr0/ZctVwd/cP155S /wOd1bPOUthY5Vt+oHkLay5nY21hY21hY5V7yvlYXOtRLZUwvBbPpjzvpGoVKrA3ylE73KRrKuDa PNRhXhq1SwTyLKjxqB6K1z4NJtaUVpRWxJrQylhTGLsRBprMS4c6onaRZwNNOiTrncPBXDq3BD8t LYHCz/y0tLQsnNYyrYXl/NOycBEmtkzQAi0LAd+gKJTvbzb0xsw3t2FazX200NJSuxD4mrYsAtbb QgaXO79UWoQ9k5YrlQBarg1MM1zgT9hdyyKCXIxxUUBtWgg2YjfAJhnoBUD8AtN6iMI8VmjAHRuk Y4F0gv0X5Ky9r1eS6IfIXBVI/lCF8QGOVWS0P4eZ8D7Mh3XwENKyyO/hOfCAFunvg0CA1IAb7oNf wQdQLX2LVAc8CWcgFYbAHKkP9LAM+sit8CShTFKQB4ehEdZSt+AST6NzTCEZwmayAtKwlyp4ECLh EPaYIqmw3kljqBufqoK3hOnKVClD+o7sFQ9IDfBr4qZHxK3wNvSQOBH6bpfapA3SRgiDs0JM72vS IGk+PlUNXlgEt+AMlsPjcJDU0mF0j3Q3zqkG57AMdsJbxIUK5cUT3XjkvgMehm54BQ7BR3CKEKIl SWQ5OUzel0Hv/r790kipQVoApTAGxsJybI0h8aSIThYmC1uED3v/1HdcisW+q2Ax3Ag3wxpYC5vh Q/gYjhKBqmgVrRa2QBQMg8nQgNK8D+f0HByAY0RJBpN84iEryQt0sSj07uffUUWgBEdw6a+DDSjT p2Eb7Id34F3s81uUqUAsuPjVpI7cSu4k95L7ydPkBbKVnKYy+pEgCLeJb4in+45IKulR6TkcNwqi wY5n3VRcg+twPQ/CX/D9UkgqKSTvURdNFYgY2tvXlyWVS8uk16UPwQmJyDsMz7WlMBom4axvgtth N7yBzx6E38Pn8FeUkkBUxICysBMnGU8mkEU4iy3kDOmlJly/PDqPdtD3BZdwUJwkbu3d3hfR19F3 pk+SNks+6TXpbb6+OThOMa7AVGhCE2MrtgPHeR1Owp/hHI4hJzac6whSge/7MPZ/jFxEdVLSpfQF KuHpd61wQLSID/eN6Zvf93BfpzRYGo26JeChywKDMeajNlVDLfa9AqX5JDyPK9OJ2nMEviZmEksy yEgykdQQL5lDFpAm0kxuJregVJ8j28lucoQcJV/j1VFOI1BOLjqDrqD30e10Pz1CTwogTMA7TLNw s3CfsF14R/hS1ImpYoY4WvSKN4lLZHgkk5uUb1+MvDi/t6H30d7X+gb2lfT9oq+tb1/fkb4Tklra I53Co2gGzrEWZuMcb8X3Xwn3whOoH8/jHD+DL+A0rvl3KAuBhBArztjG160Y5z0aZz4Jj0yzMM4h 16P8l5PNpIO8RPaSfeQAeYu8Rz4lZ/DyHEEHYhyKVlBNZ+E7PEo3Ux/9GOM5+ne8lqcKmUIW3iq8 +DarhLvwfR4SPhVOiVSMEAeJE8Rl4m9lgmym7EHZBtl+2Zuyv8h18ikBH3HZg7DvaN+m+8QCYR5s wtuBIPyFvkfd5FZ6gfyGxpB9OFoM3rfG0mI6FM9Gu1HL54NRsUHukDuoEXQK9k0t0EdomjBJTBBC YSHaG9DJdCX1wjPkJbhAR6CmLRYO0k10urBBXC8WkA/xfrFPBKoh56EIikgBrt1haMYVShO2ib9n PcqUwkXZfKqRVolfyKjwHvrBYYQKvyOTSQ8ZS00oraH0XnBiXUd6MB+JFvgxan43HjvzxOPCajqK HkXaPLiP7MN33A3z6G7ya1yXPLTHG8hYslEYBEtJM0pjCFxP74c42kTjUJ+r4XuygkSg5V7AtRlA Z4EoaOgMeJ/W4qq/Qwx0IFmKejof2kgrpJJeshfepusghzQKr1y09CZRcrGHtAsjoJ1cEA+IB/Dw fQElGYOaq8QD92eo0xtwlDfAISSg1uSBjOI9Du3Ji7aup+fILXQezCUPC38mT9MiqIRGoYWWkQf7 zolFQhZKbBd6k2L5ECXI3LIYcTCu+BdQgNo4G0A+RzwmW8HKwmHhrFQrOfqmy8L6PoUlKJ0R6N3a 0JZGwCfERKaRcaJEK0RJmgib6TbxUymShBIHvCuhhfXtIG4yQLKTZklNxqGGT2N/U0VsE+8UF4m3 4N50Ab3mSlgPj8KruJs8hftWIsrxOpRmHfqeubhHZEAmZOPbFcBw9EojsW0sTER/6kUvOQt+Cc3o eR+DF6Add6gKlMc0fG4WXI/0FtyhboalaP+rYDX6gAfhGXiXPk+fwDvuXfR1upjOhU/gE+G3godM hPfFu8VlMAHvwONIOI6ci6tkw+dWS4dxtGSIQu8/GK0U9V46LR2Rnu09hP09g3NfLx8Op+XFkASV 5LxoJTL0byhDcbaM/dOFAsra5YouErqdEpCJrCCASi7DwouCQK0hCkZ7kYBFWXmz2TVGd9Y9utc9 RnfePVrXi5d6d6+bpUEZWXqHPt6hd8wW4aJd2HvRI4MLYBf3oj2dlk7QEzIZ7kQ2qPRoj6hPqalS oQIdCV9oxe53esI1YFWbtuoKiKogZiteoxRE8RIdibtDHxkDZpfu/NSekyd1J09CYWGProfoDUPw MygD3aIglzvjEhKFhOzBOVmZpgijwFHuRCqS6M4EGqk3RNJ4mu50DmxMdA0rSGEgru+dbLda7fQZ szpu4ECn6qJymCvVPSwlzc3uRyr6G2Gf+B4ocdbe9jBZF13pURFVCPsLPKoPQ3bRp0BNX/GE2vV7 9If0x/Rn9DL9LmICSl/pVKLtd9GndmQoF+C97CX6CO7m35Kx/vc426Prxbc524Oyc+vcKE98DUfg LS4XcKwyud1iscvJbF40W+0y8b0+a4LNlkA+9+c4z4PSCYHgiUqDu+kgT4i2w6RWdoDcsBvnYgGR mHao1RZL9PxuEguB5dOhBKGwp7AHB75KVuFXS656QN7YcblXg9AwNnfoGJZ611Tm5Y9hCSWyWTom bsPzXQJ857llqbAsfInxbrpaWBPeavybSRlC1UZ1hPAofUzxvOIL3SnjKZNc1M3Svah70ShmKhPs zmyAGLvFFn3UbI6xKbQGtVq026ghXgwxR8YSAh6NvhA8obrC40CW43jWJO2ssFilUsEaFKxhOWqM JfGxbvKB/zWn4rmUqehJVNWpzYGKm7222zAk3TBkCGqR7tz7bgjkgzKKb/LE6UxUHmEyIupl2iGg 08oV4UJkGtHJDUPARA1pAOz8i8vmdqXcdhs0TyX40Rv5mun9CiiYTFmZuTk52XoHl2OWwy9VYdvJ x6fvnGc2hJvJ6IdGjR+ZO6Vvp81qtdFZsVZrrFjQa33k+KQZJIfV+r4rL0+KvXcc/TwyPDySJXzr bpSyUdyCfuaoJ2VY1nVRlVlTs35lWmlaZb07avWQR4arRtrLiug6269tzxU9O/yDyM8jz0Uqorqk 8x3h5pwu6Y+eWpcnedhQq1krMwLJDcvMcAoDB2s1IOjVlgS3e7A+vljdJg5sSxwc7ygWRJqodISE JSi9ufHTYxfE0lhrmTHeMyjBmeApWpC8LHlN8hPJ25JlyZbSx3YRG5jxvs9lP/pkD+oYk/zo3l7U NQxM6TD26oek96A5DmGJmfEQXkZThry8PDKVSTRgyBF+qSYkOOPkEcZYGmmKNHFBxiX6m7L9jJFM 3jnZg5GVRU4U7vOLzRBJZE/e0fbUwOu8szYXTar9/LWjtyPV7G/Z/fjjO8tKMx5+t67u8BafWBDN JH8k1mqOqlq5pj5zfJZNHx2T2Dpt7Vt3Z7CmL23YVPfQ4/OGz46NsDpHjLjzjlfY1ynV6E3n4+6U R27wpD1ivWCnIokgM+WL5GvJ/XQTeYr6SCdVPS1/RrFdtkPxhuIjxTGrwqrUR3bRrR6d1mgzUmOd 2WiMNMfpk9MZUZ1al5Gamp4Rl6xTsXoYaIimLkSjUYXE6ZLiOEt8nSM+Ps4Rl5SXyerO7PRB2dmZ g+LyiD052iEmJyXp9bo8EBU6lTLEbjlmJuYu+qRHnQ8O+6A9GYcyaEYXOd05pLze3MVWDpcLPTku n5sZCi6Zm8cePRpL7zC0GjNaytn98COVqT/Z1C6nxVXsuyFpb2fUgMGkSzreobcORnOq5aans0bJ FPL4KJnFRqyKaBthd0wXmliFzzChwjdg3GR8WC6d3WEPtRljTagsebV+ddHnMC0wRegD3itgdVn6 wag5Crnin+h+95ZFxo+9b0rD3XXTbBaLre8Ms8Rpty+qK0qfN51b4NcMpzdz2/yi98Kk8tI1lb1/ ZdqDJhxJhSlL0uy/6v2qnyAWmLGEe+vLqA0mmR731mhY5kmJs2RaPJbxlhmWhZY7LIpwja7GaIzT yENDamSyuFBTtOWBiIi4aOF12kXufzFarglVAZ7wp+PzlBz3hImizB5RaSRGS8y4ZX7XxnZgdGZ8 +y0833ONJ7vs0chUEuHMDtc7rhKAo18AdO0ty8go9t69ZvaWZNS52CirTab/+OO+cRe/u/Sm3cxl MT2PwDfbIyyHMpricWtztXlhQ7T5Wrd2mNajLdaWhhgSQnNCt0d1pIqJJIfQ6ugGRUP0QsXCaFmO IjO6VFEaXa2QZShzh3GNPpZP8ssK8vOHFcTlRmgZKdZuIGMN7xiOG74xiGDQGTwGwVAWZjBow+Ii 4m3cWCBOF0fjymLj4myxcfE5GX5ili6LZpWlZ2VlpMfllHkYsfFYMSkuKywu9hTGpaXLYxMGpiXF RMuJIiXXMxTK5CkOweoICREU6Krj4yNUmjB7pMljy84wLTdR08WEmFh7YgKrJyxPoAkXCyDdXljg 0ZgKoWBPwaECocBSnrKlf6vhK3J2qst9KcOlYdaDiOtT6O7p93e4j/yIxfxkbWrzjxmUHA3KxA3q WsMKWJY9KdlsUYWKMnV8sphoIzK5RRWJl1dZio2YQ63M0viWxqwN7W3qVDS5qIDJFbGfen4NIiaF 9AmO9Qka8OE8bn3QTJqL2ZekCjYDa4G8y5+zmXRgzmdApoZHcCfNjDTyspE6uXVeNk7ntdbqvMZa v/zFvKIGR15L/pSc8nKmrRvGZA2cVVTGi5WD0lKHFXPyCQZ+DqGhuqW0rKx06HWTe3cwbaYPeapK G3sP8/K64kkxyTP9lYCaM/sleJcCcRJqeR5Z5cn9QP6Bku6X71fSJ5Ud8g6l0KxYrqAzFDOVM6OE DVFPy+nNtk6ynQrRtuttFIhIaazSYPb79QhbBI0os0REmC1xhmv9ul7t9+thJKxMFRamVsXp/X5d B/G6eHqNc9dkl/mde+bQPDnZRY6DnczwhMc4RAX6eYNBrwpR2a3HLMTCXLyOu/i1GZvQxVuYf7/s NgLe3a+cvWfxFPhzvPm/59uNUdEypUIpV1J5tAwVLkoZ4/fvKdy/9ytbh82Ij/6xPcroV69mdrpq njoVvZhfe65Qnyt9/E+4+Ek199Z6K/OmcH34jLm6shXzJyxpvtLDB3RlWW1JcmzbyN4zlz187c3F d/Z+e42CoIdfh+cwN2qIGiLJCE+ewSSajJEm4QA5oP6AHpX9QfGBWv4LxVw9baSN4lzlXNX1mnn6 xvBZkcoIh6B1hAjqEEWoA5i9aC2FPA+L5LlHE5HtA6LDa6UXN4AuuspjNjjkHmSTe5BngXyP/JD8 uPwbuUzeRU50mtEF9e/duF329E5tZtsmO3Ixv4OnqgqfOiDe3WCSzoJROrtdZwwzRu6STkC4dKJT E6uPzQuEWmDnWWBm7VGbjLqoQiMDPZ4gPeHa2EK1EUGpQlAwQPpXnhiDulBhVBuwEcFk1EcWGBmE G7VGxrHfY8CCSoVndCUDKmhtbvb18dWhlhjBGQfZgyErExSD/Yc+drAT3X09r+7v+5oY9r9Kwqs/ 27TpM5bItr193xD9nr1E3/fNvsf/eOyxjcePofWux7UZijeRVDjgGXAhimiirFH0KdUO1auqw6qT KtnisJVhD4Q9E/aG+ohaHqkkil10K16TbvBEKEVRoYwjOmNIhF6r0xuMMktochd50qOPHTpggGIo XkPkoQ6L2ngXXlmf8xhTU/FUleB4A6J10fbopug90bLoLnqqM41tC7geJ9HQ0N5O8juHrgd3bL4J GPg2cJU1cSMJs0ap1GpriA1UUaE2YOZx6YLRv4HruURy/fdcBb8pZvfrelbg2IzO4U2u3XmLmqvf yDVqdGaN/a/N923dwF0l28uFBqbJve+ObMiyayx6rcYxunURTWfEvzEmpuOd9ITwLZ5pQyAcSjwx ahpFqaAhCr2kUpHQKeHqharvwz+JIAvh+5Au+v0OI4EZL5ldUEh05/GKe/Ysu2Tq2DEFj4/sKBKe FR44vV8udX6yOSQWT0BtmMeYYiziF33jIkMjYpPIHwIFAMgNxHVw6l+LJOl/EY9eG+lvfm4UtopR /ii7V/6EYn5/VOr/L40TgzEYgzEYgzEYgzEYgzEYgzEYgzEYgzEYgzEYgzEYgzEYg7E/AkA+feXS H4G4/tIfhCBg4jVWphBGMqD/L25MJgWBsngFjwzM/P8gyMpyiCa+QFkBb1ziUUIGPBMohyDP24Gy hj5Kvrz0VyCyxRWBMgG1uDNQpqCQWQNlAdJkjkBZvIJHBqGyMYGyHMJkkwNlBcy4xKMEs/jf1H0N XFVF+v9zztw5XBlERURExSPCBQ3uRSAzszIzMwU1NCM1EgEFRSBEfFnXzKw114zMTM1cM3PNNTMz 11yzMjPXXDMzMzPXzDVz3V7MWtc1/H/nOZfLRa1ftS/t3/N5nnnmOTPPvD3f58xc7rm+65cboEyR X25oZMkq/QsiLoG2wqzXWNbfNW1svcOyxfqPWQ5h/ecsu1k+z3ID/xw6sjOHjuzMoSM7c+jIrqAy zhw6sjOHjuzMoSM7c+jIzhw6sjOHWg4N6r/SfQtpxHJYkD5cyyFtWG6s+xbiY7kp5IiQq1mODCrf jMfoyFFB+hZctx/LLbktx2broDJtguR4Ln87yx1YHs1yCssTtewO6r87qK2wIH1Y7VieJpvSMCOp 1AnSQCqiQqRZVEal/DskE6mcNdcjVwFZ8zzoi7mEF3euoxJcNmVDNxL1K2ks5wqRFqJ0FXgBSmoL 45AvZq1NfZGOR1rM5fNAlWy7APoxSCtoNHRlNOIn9EtbLWWLTr1bkCtGTvfEpgGQ8jjntFwKrY8t 2Gy7yN/DfO5xKfermEt7eVwjoS3hHl7Yny7fMcouPAsVsFDbv3TY6ohZtykJVorRVgXujOXxVlJ7 GnRB+ctRXq9SffuO9f4YkX4vqhfujed+6VH2wb1KXCVc8jauZ/PMTkQ6jlfHmSFnBUZwS5U8Izpf zvXG8LzVztxwrls7qzdgXjOx/k7diqA75TyaArSSzxad1RjPbeWDX7pdJ6/L5qPX49gTCrhsGXgB 3y/nmZ8YWDenrWK/hXy/rULm2jvti0auS5SwlIR67ZFqfxseaOtS/Sq9yPYPn6U66wVsaSR0FexN jl/lB7z20qOv8+T6/boqaA70SJyxVHJ7tXjQ9p2xFrBv6JGXMcYuPVJnpvPqzWqhHxcXokPPaiXK jeOaurdVPJrCgB1dsgQlvneNnrbTUlM72QOLCu2sstKyyonlhfb1ZRXlZRV5lcVlpV77upISO7t4 ZFHlWDu7cGxhRVVhgff6snEVxYUVdt/C8XbxWDvPrqzIKygck1cx2i4b8Z227OJSuxL3biktriws sAdU5lUWonJpga+swi7DnQo7v2xcaSVMj/VmF44cV5JXUWunS1CTXaoKK8Zqe+nejql2UlZxfkXZ 2LIRle0H+fWXe1NT/eVRvP+ArIG9ysbnVRTYfQorK0sKK24rG2ePyZtojxtbiA5hACPKSivtvLF2 eWHFmOJK3bnhE7mrN9ySeR3uVnCmvKKsYFx+pR7G+KLi/KKgukiLS/NLxhWgamWZXVA8trwEDWBs qFWMAvkoVVha6bXt2sbLSksm2knF7e3CMcN1rTpbpbWlL9klLl5QXDrSrigci7nK11Mb1DxPst/W VdyDpGK0Ulk4Rq9DRTFaLSgbX1pSlhfcKDqd53QVcxxYjrJxleXjKu2Cwqri/EJdpqiwpPyCESEI ljEE8+BspXD2Mg1AoyEcbBTyn3KArr3vhH4NGg6TYqF4TrwkXga9KDaKVUG2dOniQP4jtl1Yr63C etbYnivW1dHVx3Wj62rwK1E6D6DQcHMeEkXGGuMJ7Nd0ELgO5Sv8j5e82j0j/tW04/fWLvWLXoL0 Tile/zfLzi+1URi2dT14b5cLvg+693AJ2m/OIsN8wFxAwlxoLoT8mPkY5EXmIsiPm4sh/8b8AvKX 5hnI/xCSDGGJEBLCLdyQGwjsskSoCIPcUDQhU0SIKGiai+bQRIsYyC1FS8itRCvIrUUnyFeInih5 o+gDTab4BeTJ4pfQTxF3QZ4qTkP+WpyD/K1L/8Cb4dLfmBR6R+cK1fsrV0PslIQrytUccrQLrbha ulpBbu1qBzne5YGc6MJey5Xq6gg5zZUB+XJXJ8hXuLDvcl3j6gb5OtdNkHu7+kDOdPWF3M/VD3J/ 161oMcc1AvJIVwnkMa5f4O5k112Qp7qegLxUJpIhk+RlJGSydR0ZVnerFwnrJqs35D7WAMgDrYGQ b7FyIN9mYQ9sFVujyLRGW9iPWSVWCeQx1hjIpVYV5PHWeJSZYE2AZqI1FfLd1jTo77EehFxtPQr9 fPcO7NjedH9Kwn1CNSRDhSvMuWqu0B+VpDpAvkx1hJym0slUGepGyL0U+qZuUpmQsxR2kqq/6g/5 ZnUz5Gw1APJAdRvkwWF9sPPLDMsiM6xvmN7nu/yepikUcNlLIq8ibzhFFhUOr6C0krzKUroGd4xb snvYFEkEzzMdX2VJW9A2dM7g/1/czBzYy6ao7H5ZNrViPdXjUgdpspl3YJ4xZvSY0TSY+fDA2cms JzXBzt7CLt6tf3+WFPy+IYVTI7TXhCKoKXrWjFEguDdOGoue9wQEBwEb+j28KprCb7DOo8W0ijbT TjpEx+gz+sYIM5KNDKOr0cPINAYaQ40Co8SZFaMT7BhIz6B9pGE2eoE0vKuTNnbOU0bjFU65Jt3Q Q6QRkciHIO3m6COG+dM9Thq5kcu5mpc0n9p8bvMVnLOiD0WfamG1iGnhbdHduR+zJWZfzImYGud+ yzUtt7bc3/JkK2oV6dhpPddJY6c6aZvBXNJtZ9i97Fy70p5pL7HX2ztZ2zB+U/zu+KPxZxLCEuyE jIReCUMTyhOmJ8xPWOX02lOgOdKZjjXPHCdNLHHS9pOctMMap1zyZn+6jT3BSK5Bqsum/TP9P3/x bxzo6EUct9wcsUIRpZqS4gjU0GXhxBkBHCdRU0ZwJLDbj1pa2UCwDewOojgrBwiOB86aUQJQMohS VA6wkkpGgx4NluozEqJqGlFyTxAQ5t2FNBuUA3kvUsTd5AJQFWgGaDNRKiKh9wDkcv/9LqBufsLZ Nr070smg2aC5oGmghaAloOX+dBVoLWgDbB1GuhWE6OA9hnQ30pOwswLUC9QXhGdGOk7r6cOQjgCV gFaD1oE2gl4BbTNbJod5k1IW+0Ykx3u9TB283ZI7+CqSu3sLfBN8U1Lc3rPJh7xnU2K8uZqSS7zT kocxzU0e5puevM67WVNKmvczpnBvrm+mUzbFAzrmPZKy19c9ORa2NUX7aTXqaYrwdgFlpBxGuQMo Nxj1q9FOBMpE1PbHm4n+5PomeAtSVsLmJtxP9fZk6gX9POQ7QdbUF/lF9fo5A/1cGpSfzVQBeQTT 7OQ9oCneVUzTvatS1iNdgb6t8PfxFdA271Y/7WDaCVnTHsh7WHeQ6RDkQ0H5o5A1ffF/0CHvcT/t QLs7kidA1nQO8mq24awD5jclEuM7ij4dwrz71yUl+YL5H+SLSBkKqvTFpkxCfrEvlWmZd4cP9lNW +jolr/atTh7ozF/KmmDyhdWOP+WYr5deP6R9eR0dv1iHNenJdMjfLxv1QIH1dda1S2Adg+dzdZ3d 5K7enr6NQet24TrqtXfWfxTafQVrns000Fvu24b8heUvrp8Df96J+lWovwdzOs1Ps/1UP1/nJwuZ dL6C80tAy4PLw2eDyy/n8jPhO5qqvWv9tIFppp/m4d48vu/oF3lX+fYjvxTpIn96COlGzNNGv++9 4p+776Pacn48Bvxzv3c3aF+Q/+5jqvPffUzbvEeYDqG8plr/PQHfOxHkp9+wTx5PMSGfY7+tv/5H 2Sd6sk/CFy+6fwIyYgrHBg/fZz8O+LPbkeHPp5kujCu1fn4N8keRh+w7gXwP5L/Q932Ukub7JiXc F+ab6TvHZTuDauMR5FQT+d7e3FS3zvusVNNnpcT4wlI8oM4+SjVTw53yOu8v3x/lgbuU4b6I1Bjg aipwNQf5IuRt5O9Dfj7ypch7kJ/li03tzDiMBg6jgcP4lEm+Dg7uUpPhv5N921LTgLVOySt8q1PW +zql7EK60te17j7iL+uRr4tXC+F3C3UMZNqCtupwG6HpIt9YfWlK2X4B7fJTLeZPIj3FMbnAV42+ 1JY75u2G+wNRbjDSYSlnMH+aahwK8q3d9XzrKPKaamMb1g0+e5rjUmdnndL2p83TeGBM1D5bdmFs 67EW/jS5Q7qHqbtvim8eYnsnxAdNfdOTgaECJ2akp3GsmuebgniRmZyK/EDkMafpnb2Z6Z0D+XUX ldcxqRp+XPssGuGf+0vGCDwDZ6ZfA+qR3ju9P9JBgXm/8BlxzsFOLabSh3uPMw2FPLTuvl++GFsX 5C+FBaZaLGgcMBbSi3wz00vTp/pSmSrR3iQ8A+o/E86mrE+/L2VX+n2185I+y9cpfU6qntPc9GWg +cgvrstf+IwJxJ4LY5B//P/hHZpJzc3PcYYlnD2RE+k4gUaJu3HGjMEp72aa7RqIs161TJZP0ly5 XD5thMnVcqvRWG6T24xEud0yjCR0QBrDLbfV0CiwGltRxigr2oox7rRaWa2MSivWusIYZ3WxrjUe xCmvwHjEGmEVGU+E3hl6p7EM57JY4yk1RG03nsEZYY0ZXrdfjIsCtSIjfjHSOFAS5GVIvaAMEPaT cTkg7AE9OEvEr4TczX8/FNTYT9g7to9AmgnCXjIOe8047D/jsI+Mw/4yrsqfYj8Zh31k3AzYWoMU +8o4nPvj1yNdgnQT7EwARYNiQfGgDtjTpyLtBOoKmgKaDpoJqgbNw9nKg5nuQj1wjsrB6awEp6ip NJPm4gy1gtbSJtpGu8n0nEt0J5qJGH9iqKcmsXGiC1KY53RihOcsJNNzIjHc8wXKnUkMxd0oSJ95 9iVGJEZDOurZ6Tnn2QPpgGcLaoeihuXZ4Dnu2cx1V3tOeL7B3RrPMs9ez0pIZz0LPfs8RyB946n2 vOKZB+mU5z7U3gVpLmyv8uBs7ZmJmqs9GyFN9RR55ntKIVV5clF7+X/cNwV/zkFWGU7/bj5zN4aP RBiTcVIKo410GVGbUyD0oE0NkY1zq411t7HmNvzFho/YWON2R5C2cu61wd6/zUmHbPiX5zOkSSD4 iA3fseE7NvzKhq/Y2f4UPmbDb2z4jQ0/seEvNnwlEecFz2nQWcg4wiZaIPgZVoQSB4NwjkjEOQJn P0qsoMsSliWsTFiTsD5hU8KWhO0JuxL2JhxIOJxwLOEk+PqEU54qlDiTUJOwzOPSHFSTsMYT6mns iQLt8Ez2TPPM8MzG6iz07MbqHfQc8RzHPDXBKmAezNPm12Saf8eKuHhFLF4RN1YkghrwioTyijTi FWnMK9IEK9KXonlFWlmDsCKxWIsIaqN/bATrolfEwyvS/r/YkgG8FPEqd6AQzDaQaON0Z+NUZ+N0 Z+NkZ+Nkl+ChkPht8Tvj98Tvjz8UfzQhRv+F1vzK/Ap9/Mb8hgzRFN5oWv3gdQL+dgu52N+kaqqa kvWjS/fCydz+N5y6w80HzEfQ6qPmAmrAnyuG8edaDd073W9RuPtt9x6KcO9z76NI9373+9TM/YH7 A2ru/sj9EUW7j7r/Qi3cx93HqSV/otWKP6dqg/laTet41iL0ZyqImVlxcXFJcd64jLgucXPjusX1 jMsEz47LabssLjeuIG5UXHlcVdzktrva7oqb1nZN3Iy2a3DVxC2My4mbHbcEJbPbLsO1xqE451+w xTp7BdqWthRkZy7u50CaA82c+pf+tMNE1CHLXGK+hLl41XydYs03zGPUzppkTaLr9ROCeqg2ykM3 8Ge1+r3yCP8nbVGB+i7Ux1PBXG5uJGlugq0YrqP/R44YiuP50H/Bpfgw0Agy7Cn6EzH+BBc20Ib2 tm5182YPo6b2YFx77P2gQ/qKn4qrd3z/+EHxQ+OHxxfFl8ZXxk/iPsyH7Qb6bUb04RkTTzHzWfNZ 2F9rriVhvmC+gB7+Ab2SGNt2cvOoQrmHCtFshrGdn3jZ1MQfnX46Ge12UFabJbiWg1ax5FzB8qXy +lp7gX7tJcroa8N36H/s9X19vLB/39WXS/Vn+Y/vC1YglFFIjEKDUWgyCi1GoZtR2IBRqBiFYYzC hkDhp9ToB3uxYfY058CXw7AHiCFqjZgTRHQJ+i79d5UNtmW2PcxpVutZF10rcdXKa3BdXGJW6zm4 ZrVe3/rwJe8616bWx8Dn46qv39J6V0De3vpk0J1TrDnzPTaDe7WrdQ34Xub/+vX9o3bG67R4oF5P Zl0wxuDR/dhx/cuXjheB58ejiD0L8BQJdb/pfhO+udu9G775rvtd+OZB92E8Sz52f0xN+TkRqbJU FjVX/VQ/iuZnRosfFX9zQP1BpRyBm+vf1qFlNBu5rv6o3JzLbQXpn0s/UFfOaExnkYsMlNMR+DFg Dbs8p31uLZZb09/VcTMGiTHoYgxajMEQxmADxmAoY1Dxk7Dhv9mSng3i2ZA8Gwk/syU9r/pvBYhO tJfnMJp1+htr+m8ONXU6w3LWyWgVpIvlVTKMjCBdJ2edjMwg3UBeJcMY5deZpP4lX9NeFv2da2Ox JWJLBlsy2ZJgS2620eA7a7v0b9yjZw+hfwb3zOL2Qr6zhjBnm9X+sQjup+s71+jHlP3+nlyqxg8b uUbYQprO6+kgpwWvuoM5A+ir1ZnY+83n9Qwut9RZTdrg1/37cPX9+A2+e/Hof9hdPaa9fp93xhTD ulN0kH0+SGeE0umgOXJ0GX6fD9Zl+n0+WDfK7/O1uv+sx//7fPZfw9P/qscbtJ528l5crw5F46wd jbN2s82UFbntf/XSY3a/434HozviPoLRfeL+hMwfviuktbSx7pzSFLu25pMpq+k+XAc1bz6Q5UDq v3MwKHfBVVcysrtDQfUC94PsXWwrSBO5sf6lMep+z33gp44wooYpK2oKrum4pjSNaBqhc033Mx/G PNVJ/TKuqJm1eV3DKVlXJnBNb7qz1mKdvdpybCfIQtSUiNMRp5tOqX/xCPe6j/2I/ZFpxPPpe5U/ krSEThhLjUVGMvLzg7Wm2zQNfQKeVk9bahYZZ4h/Oy1Iu9fcZeYiPyhYK7qIDFPvs7rV0y4RC0UH 5DsEaU0XieqgCNcyaGwR5lLzSYztKXM5ou7T5tPA9SpzFc6qa8w1GPkGcwOFYOSvktvcivE3MN8y dyM+7jHfoYbmu+a71Mjcb+6nxuYB8wA1MQ+bh2HzY1PHRFvZiIntVDtqphJUAq/890WN/25f9Mn9 AeYP/YxtL/hZ2n7oZ2x7zs/Y9tyfse1Hfsa2F3B0StNxyKj9tlor1nVAzDLoi3q6OD43HKynizH0 LnJ7PV2EEYbcunq6UEN/u2lJPZ1J55CbFazDWfB00L6ulX9fdzJoX+foTtDRoH2dozvC+7+u9XQH +EyUVE+3h/cRkQGdjuQ64hDvQwzeh5i8DxHYhxzCbvgwdiMh9RAS8Fj3wXreq/nDQXpH3lvnZXqP E1j1B4Lkh+rk4DL+uo8E2XTkD+t5jx5XEun/VCxKfzOQR9a6rhxGocutJeezUYNC+X/KCA3k6z2F w48SNepMWar0f/UKOin8wH2GscL4jD9PrcC4sT0nIzw8QDp/ITl6M4iGXpAfHpCN8CJQKaeOzk1Z oak/43XoZ239J1//tjPWD919HjGi2O97ElY7zAvKIGpQfmkKC/XLOXUUFkVZ7p4//Qqjf6X2/3X9 xHP9T8JUyGoyQqYESOcvpPr6YReXccfUlYVcS7W6LOvg//B1xE//Y9d/HVP6+85ng84S+q9z7pry b48GXz/iqat3GAajVD/Htp/vXPtcM/NkM+ax4AXMx8pUlg3WJ4GPYn2OfiPXjHNlsT4RvFjmg3dz 5YGvd2WyvpGu67oZfKgrm+/qMmP47hDXXL6r5StcQ1g+qmW2n80lh/jL67tbxErwVP2Wr5lqbWH5 C5ZzNRd7NXd1Zr6V76K3IkzrRZhrkeZyFnNirj+P3SLma+4axnIG83Os0RY2sbUcXcs4Lbdr2a+Z AO7RGugPaplb93AtjyxgPou5/l5+rr5r5Oo+gG9l7rS4l9vqrDmX3OL6huUJzLmH3PoWXdfswfZ7 6LpmD16LHlz3MJesZjnZzxexXtusZgvL5BLwyZqb0133gNvMJ8kj4Gfkk+Br5LeYmXL9f22YM/U8 i71WsuZ6niFXa73W4K6eeTePehPzmdy3mY7MfZvJMzDTXMEzM4xng/upNUa1KOc+b2V5L8trWA7T /ecyyWztjvMdmWsfqzh/JXjV+QHgRef1umeffxr8s/OP6RXXnmzO/faAljWnszX6c9mz7OHbWd5e o/d/8zQ3I7TeWK31ZkTNeubH9Zr6NbpXFd/CS41wfdeo4PLhNeXMr9Ea1idz3RxuPYfr5ujWjS3+ Ptha5rq53PpZbn0T269mO1u4lWQuU+2U5D6frVml9TyiCIfr8pA1dg5wixFcJlpz08N2cmt4DjWn s6yp1r0yqrUMm7BAx3g2VrI1N9spkC14ZnTJ07wivf0zpnt4mFfqNK/gafau0+xX4c54HQ/nUSez hZ1csjfPz2nthzSLxxvt2GcE5WjsGNF8d7v2WzqobaLFVdzbA6xfxPol+jMcrad17Mm75BuwcI98 Aby99luM9ACPlD1Q+yrpf8b5RczX8B4+jeWtLDtnLD7JnB9lwsL5xizv1xwnOC3PYF7p1Dr/d3BL l6zhT56MZWzBOUed5TKZmqMHVHtuwtzpaJDDmq+Zv8x1K1h+hvn7rJnMsnMadM51v2W+lvlbzPdw yWrmh1kzjzmfK41olk8wf15z0/l86yW/jNOJuIFneBujO+P8INTaoDn0/VkfqWXXdi1bcazZrGOC LkPbXDiVma2+3cZypq6rZVjA2db8yMph3k1zvbIiSkdIYev3zcBztB1dXszX3Cyw+jF/nn1vO8vL 9FxxhOlrTdaakOYc4XXk6WGF67shOazfzZxlayfHwwksV7M19i620MOvOch32ea3+ilTUDMafOG3 Oq5Wfft7/ZT59o98V8s3uQbwM6iGn0HP8LNJY/whieenedf5x8G9rq/Z8tVc92G2P0LftZ7SFixt rYr5C9bd+tnH+gKWs/UMm9kyjp9ub7P9A8y3c4tfM39Z39XfkjCrpO75EKsP8+7gTa0PtAWrGWOW YwKjdQnjMZURendNE/BuzHfy06qpjl30HkewLfo5Ba7Pfl9wTJjFdjbpOIwnneZuzWk7IytXI5rO Mq5z9QxD1s+pptqj0Kr2f4t9vpeDKf+pOUXjnf0zl/kWLmOzT3qY92A9f77qfGqCeKTLzGY+SXP0 QPOjzDex5V7aMtH5KG5lM3PsFs7n1nyqOdvZwfxV5p8R9iGoo+Vn2cK1zFc6cYL0O4X3GaUU/E5h L36ncFDgncJYfi8whPTvjbipETXBHRfr9B4thBpgT9WYIkiRDLxpaPJnCfXfNYwNesvQwAnBScOp aX7+mHKqZD6J+dSCkuKRNGNEcWkezWY+t7i0uJIWMl9SPLashJYzX4WCebSW+YaSsvwS2sx8K/Md YwoLimk3830V2uZB5kd47GaAm/zOIvHuUHMZxEOCuCuIqyAu/HNJvMPU3Aribj8Pxwx4yEudLvnW o1Ov3J9WOe/x0Sxn12oMBW+AtMqfVjuptcdJQ5NRHmnDbU698JP+tx9XO/om/rcRm/jfE2wyWZ/p yOA3TA2q1N8ZJFdIWEjDkPCQRvy3pX/o6G60MWx+c3ALrERTHCWj992oNw1EjzVKXCJCf1OTpRsD Uq+AdFNA6h2Q+rBkocVIiiEbc5LMVr5kC6e49ldc8zTX+pprfKN/+QZeFo1ZjBc4SZhnRHOuFcO1 orh8C11enwooTDRjO5FcV//V8Eu0SiJEhFAIfxPTzadOYU217jLZY4Xz4z+hIpT30GE8DyghPrUi xcO6hBVlRQEGMRZOlPr757qEMYhWiFhhi3iRJJKFV6SJTmKamC7uEzPETDFbVIu5Yp5YKBaLpWK5 WClWidVijVgr1ouNYrPYIraJHWKX2CP2iQPikDgijokT4qT4THwhTrludt0iU6RPdpTp8nJ5hbxS Xi2vkzfIm+TNMkveIm+Tt8s8WSiL5RhZJu+UY+U4OV5OlL+Qv5R3ybvlPfJe+St5v/y1fEA+KB+W j8rH5G/kk/K38ln5vPy9/IN8Wb4qX5Ovy+3yT/Jt+a58X34oP5J/kZ/Kv8kv5dfyH/Jby7Ck1cBq aDWxmlltrLZWOyvBSrTaW5dZKZbP6mhdbl1hXWVdbV1rDbZyreFWkYpWMaqVGqqGqQJVpEpUuapU E9RkNVVNV/epmWq2mqPmqYVqsVqqlquVarVaq9arjWqz2qK2Kv0XzxWitWiN1Wgj2mA12ol2ZIpE kYjVuExcBi9KESkkRUfRkSxxubgca3q3uJvc4h5xDzUQ94p7KVT8SvyKlLhf3A9veEA8QA3Fg+JB ChcPYzUbiUfEI9RYLBALqIl4XDxOEeIJ8QQ1FU+JpyhSPC2epmbid+J3FCWeEc9Qc/GseJaixXPi OWohXhAvUIx4UbxILcVL4iVqJV4Vr1Jr8brAqVb8UfyR2og/iT+RLd4Wb1Nb8a54l+LE++J9aic+ FB/Cgz8SH1GC+Iv4C3nEp+JTShR/FX+lJPE38TdqLz4Xn1MH8aX4ki5z9Xf1p2TXQNdASpHJMpm8 Ehf5ZCpOqakyTaZRR5khMyhNdpKdKF12lp0pQ3aVXely2U12o06yh+xBV8heshd1lpkyk66U/bHz 6SIHyoF0lcyROdRVDpVD6Wo5TA6ja2QBnpLXyiJZRN1kiSyh62QpnpjdZbksp+tlhaygHrJSVtIN skpWUU85Ac/EG+UkOYl6ycl4at8kp8gp1FtOlVOpj5wmp1GmnC6nU5a8T95HfeUMOYP6yZlyJvWX s/AkvVnOlrMpW86Rc2iAnCfn0UC5UC6kW+RiuZgGyaVyKd0ql8vllCNXy9V0m1wr19JguV6upyFy o9xIQ+Vm7Nlul6/IVyhXbpFb6A65VW6lYfDr7ZQnd8qdNFzulrspX+6Ve6lA7pf7qVAexB5phDws D9NIeVQepSJ5XB6nYnlSnqRR8guc+EbL0/I0lcgz8gyNkefkOSq1dGAvs1yWi8ott+WmO60wK4wq rMZWYxprRVqRpN9LiaVxlm3ZVGXFYVc53oq34mmC5bE8NNFKspJoktXB6kC/sJKx95tseS0v/dJK tVJpipVhZdBdVierE021ulhd6G6rq9WVplnXWNfQPdZt1m003brdup3utfKsPLrPGmmNpF+p5qo5 zVAtVAu6X7VWrWmmGqKG0K/VHeoOmqXyVT49oEaqkTRbjVaj6UFVpsqoWo1VY+khNV6NpznqF+oX 9LC6S91Fc9U96h56RN2r7qV56n51Pz2qHlAP0Hz1kHqIFqhH1CO0UC1QC+gx9bh6nBapJ9QT9Lh6 Sj1Fi9XT6mn6jXpGPUNL1HPqOXpCvaBeoKXqRfUiPaleUi/RMvWqepWeUq+p12i5el29jn2/iXPA aBEnPKKDSBUZ4rSYJeaI+WKRWCKWiRVindggNolXxFaxXewUu8VesV8cFIfFUXEc8fKkOO0a4LpV XiWvldfLG2UfOUD2k7fKIfIOmS9HytHyIfmIXCAfl0/Ip+Vz8gX5onwJNjzyDfmmfEu+I9+TH8g/ y4/lJ/Kv8nP5lfy7/Kc8L45bSsRZTa0WVpo11BpmFahYlauGqxFqlCpVFapKTVJT1Aw1S1WruWq+ WqSWqGVqhVql1qh1aoPapF5R+jvYozmSEUcygyOZyTFMcAxzcQyTHKssjlIhHJ/cHJ8acHwK5fik OD6FcRxqyHEonONQI45DjTkONeE4FMFxqCnHoUiOQ804DkVxHGrOcSia41ALjkMxHIdachxqxbGn NceeWI49bTiu2BxX2nJcieO40o7jSjzHlQSOKx6OK4kcV5I4rrTnuNKB48plHFeSGfEpjHgvI97H iE9lxHdkrKcx1tMZ6xmM9csZ650Y5Vcwyjszyq9klHdhlF/FKO/KKL+aUX4No/xaRnk3Rvl1jPLu jPLrGeU9GOU3MMp7MspvZJT3YnzfxPjuzfjuw3uATEZqFmOxL2OxH2OxPyPvZkZeNiNvACNvICPv FkbeIEberYy8HEbebYy8wYy2IYy2oYy22xltuYy2OxhtwxhteYy24Yy2fEZbAaOtkNE2gtE2ktFW xGgrZoSNgheepLGirUgQ7YVPpIuvxK/FQ+JR8Zj4jXhS/FY8L34v/iBeFq+JN8Sb4i3xjnhPfCD+ LD4Wn2ivcGWLr1zZrkHi17KLvEZ2lz1lb5kt+8pBcrDMlcPlCDlKVsu5cr5cJJcgaq+Qa+Q6uUFu Qp13RILcJnfIXXKP3CcPyEPyiDwmT8jP5Cn5jTwra8QnsosVKtpaEVa0lSa7Qxpi3WHlyz2qpbpd 5alCVazGqDvVODVR/VL9Sv1aPageVo+qx9Rv1JPqt+p36ln1vPq9+oN6Wb2BsY79/wxx+pnfmnEX y7hrw7iz+aneltEXx+hrx+iLZ/QlMPo8jL5ERl8So689o68Do+8yRl8yoy+F0edl9PkYfamMvo6M vjRGXzo/bzMYg5czBjsxBq9gDHZmDF7Jz9sujMSrGIldGYlXMxKvYSRey0jsxki8jpHYnZF4PSOx ByPxBkZiT0bijYzEXozEmxiJvRmJfRiJmfy8zWI89mU89mM89mc83sx4zOZn5gB+Zg5kbN7C2BzE 2LyVn5M5jNDbGKGDGaFDGKFDGaG3M0JzGaF3MEKHMULzGKHDGaH5jNACRmghI3QEI3QkI7SIEVrM CB3FCB3NCC1hhI5hhJYyQssYoeWM0DsZoRX87eownHCG0VJaRevpFdpBe+kQHadTdA4nFv/5hzrw r0F2FTjr4Kzxd/Dp4h/gM8Q/wWdbd4PHWsVkyhRrNLjPGgPe8RIWvmELZ9jCWbZwji1MYwuj2EIJ WyhlCzjBWWW6BEvlAenOgFQRkMYGpMqANC4gVdVKYZkBKYslnN8QdQ4TITp8jlZPya/IhSiBUyMi xT/JDYS/oj+fMBZRC+pM3SkTp+lhiHCVOEvPCMzdATqqX8EyIo1YI8lIM7oaPY3+/M04l0rCuXAB S+0DUodayfwTpPks7QpIbwWk3QHpbZYEn+4jzT06Z75Kpuprfgx5Hpd5J1B6b0B6t169fVxvC/gD 5mvgj3CZ94LKRJlbtT3zdZxj5yPdH7D0fkA6EJA+CEgHA9KHAelQQPpzQDrMUgg1hnfY/k8pupp/ RGuPo70/cquPm2/we207kFuM/A7WLjaxuwH/KGDrCEv63Ufn+75LzOUoucJcRaHmanM1NTLXmM9R Y/N5cx1FmOvNjRTp/wXeSP2rPvyuHPFfkPW7d0/gxu/M38HmOpQX5kvmS/y9YdOcy3+N1O9V6XN6 CGxI/jyrnf8X1Vrzb6nFwsbL1Ib/ungt/3VR2+/Nb0l5KIM/K2is0vA8gMeJE7WSFcUekY7cVzjD f8jlwsVdeHrgnpOKE/ypgT5ZEp8RDdT8M39eEkHOXzBd5ifoqf4E3zCXcLsSc1z7OQp/TmG+yWPZ GVj3o/+vuisBh6pt/7PbswzCoCFLWc9YIoksocU21mzFNLKTnYSZypJKWaPFMIRslaUkW6kQRaRQ qddayS5J8Z0ZKu9bfX3X/7re/3u95nLNPPd9znPf5zn37/fc9zNzPYf2qxT6p8Fvn4a+fkKF0o7+ r2PzdR1qZdcwDG2lkZsuhWDUATJGFcUkFWUQNccGZYBRyJiNoEgcBoXiWAAmFFJ6DRwmgIQAjihm aRQUASWrwKAIihlgCsiskghmCUcKQtTpL2OIE31TVA/6ZqZEiAbtBYis6gzB/ZTvckRtAHunrf26 DoVrvPIFKqkyFDJPH0CGN4D/shQ4DAqDcejX8if3ncTr6cz1ehqw4bIBtm+uQpGgU6Q4upNwCwQK DbPRwvEAaFqDEc1qRfTzJ/p6YXUcfYg4boCLJmZAs+gG+Do5egW6engQcexgb6CUGY0yd3EM8ifi hAAMTcCC5l4WYHWIvv6uzq4E+k6UuHWAEE0NR/OuqM1dPUErjp4+tI0VdbQA4bVsgCJOAVAC6H82 a9lwtKaigqLyZuXNNoDZKmctzHBrAZ5l+2ssib6uZq4HvGSwO7wIcjhpYOOyIdGvCrop2uaXy7bM iL60zRX9aEbJUNHVowJFQuBkKDsElDPDyFAoJL/5WnZLK7aE+XBsYXTARJnRZF89e+0Bx2rqfsGe qvlmxYKjQKx1+Ile9xebLrLXto8GTwVdCvdWr00sYbvpMuOR1FyNly0w2Dpb8cR+LwaW8UneXTh7 jpp+SaAR9jpiN75/zb7RbYLhlWwvNe+X9UVX7w11w8nB00joPH3sQ5wfm5Vsa7CSYjJXGlflSxf5 y0P9t4+fkLoTJxLtXH3E2so7oFb9skS0fTMHj3rG0bfm9cxeDYt3d76oZOBMFQ3r1ZBsFw4ezcA1 TQ6J8vc2lOrrpAvspQifHnCYHQubPFzgBI2fNWR52SZqmZfcWhwTWDx2k216wLCbsuBCKebeUhpd XwWDg4FPJfUCpGeAEooRjFgkkgEKRWwAJACxr20AGsXn4u/voyYv703w85ELBMfdDxx3OYK3Jz12 hNBQ6BKCEUCBbzAoBNCiydYh1ABVYBNFiaIQBaycTvD1+NPZ8suxsjpUdLTkwKPokSokjmAFmL96 AWcE1tCE7DRbCBABKNBDsM2JACMzmx9Y+zW+4WhWczMtMNBUZXGyyop/QQWcRILsdJ9/a31bVxAX G5ImnVJLLoR2Ce5uvXLc2quPcSPVobE5ET2MwLON60vKQ1SvDDQlGqV3ijrxzGmqiBj74CIn41Sj S0dGUiGLjyxSjMQe50sahRZfd9Salno43NTt8KJK+phG+YXy7tdWSzVld8NnH7FenEhdlO7Ygsdg VCXnNHeCGF4CyLDhFRyzvZGe6Hy2MYZPAcnkkB4Y81cc/y3I+BGOgOpqOFr9j0blAdlloxK/M0rT EX1/C8lrJhsMXnS4hB7l03UOsA9vuJFBkFjaqnM+jFOVQ9zCrztA0vWLUSXWroN5noKRem9hKeL4 TLh34Jai+/3xF1QV4ilMImuFmbBdmLPyXuTx7YuBRn1mkVkk7IXiGLssxrlBYH5MVGW3NvPDvnvr Gros3pA0y/FUmcvQ0KmsyyeVFzOG7N2QGVvd+2tT6hZb9s1vG2ag6L4jmXrlSE1VHOfY8D7+OYoS ZZJ+aCcjGyDUzHHRfe6NdTEif1vatQ0j8byF6v1m3rs6lC+Ue+8XKk2Rqdo6HPLOM3Sed0iiqGQ8 zez6NpnkGyGXFzvxBRv9w7VHNwtnufEO7akSc3kGidThiI50X4FkM0C6/3+EJOs3SMIACKC4DEYZ QArYQJGgiEWJ/gqM/n5+sgRHOvx46fCjdfFfEIiq+58QqPRXBNLucnSwT48RHoq1fRXSRAYavlTy p1Sfgdypbm29N7Pm2dK8YZ2iE8B5d9Yf05nwcu95LPpq2PYak9Yjw5Frj+RKJh5A6y003zirBW85 Z2qLjIvI857GmGDE5KZcT3qIzlU18ya/Z/WvcwnqfpfmFF3vd/pjrH/o+gLq2UOpV+fiNx40lAvA GGj1TJSzYc27giipZILrF6ZHxycCqpjOdc9zWkikOyrUhMKuHIqqyboTJyoT3K4ceCvBz26+cmg3 D/P6loHHnUpyO7bxqLPvCxW7l+M8nvLI553G8Axb+PP2MGrgQdf688b6gLLI1awSASd16e5Tl6UY Dj3jK7U79MeFHO9F9dgigIzgAing0zIFsEPqIXHq6jGc7RofCKN921aPGAJkAJ+v2GZBi+p4+4T4 0naPxm4gbMTiNm9WwX7br5m+N7QcThgQXD6Y58+alV2jcSLAuuXbxPddj/f29sdqBfi7ePu6+ofQ 6GGzCoDDAYDKCj0oADgFRdxK8x/w6LdTOay63mdoy5QRZkNGarAD8DYr/6T43o+Lybup1xcvZGE1 wkyzzmXF71Nwb9feHzJWGNhk3jP17nyUYHzGUefSu+6hTuu7hNRfskMTRlIaamWd09NdJNLa1GRq WcutJer1hpk1VFNk8jdszhvdcUS7/yh7VbqHhWMhOSxzn2zQ7jdpZfu3pJsI4hjFuDPyh89I8w1t PUvg3meNJGYIqeCj53LHk2D3MB21FttLYyNr1UbNk4yKv+SGevoblfC1pDBtEIFYnd7nqlK1i4tB 3XLJdiHbmZnx0mOSpdV4xRYHXlIQoudDTXFk8uKV1oiuXAFfO/XmWxOMVFGgFHWsqRQbhD7Wt8Ib eQApByBl0XAJRZDSAVJqJIdtm8+4q+/F9abh3NcMTy09yPT9/79/5N/EOJ0VkkdY6k5Op/Ipv78B FXsWxDltt08h4yLLAw3kmZj4JrUhkakJq0SZcop+o9P456ctW7bY5G8yd10U89Rsarn8Ehn2Andy awaHj1vVIpcxn2vd5zadfk4brPFbp0Mll/kbpVXEZWuImVzHxdkJ1DlzwXmRpi6eaXyhl44Cwxfy 2o+DBzzYTD9UT+LvVw83AJ+xOKYYoeSNAoZPhGA5k5Gv4GW2M1dfNFqNEXfcx5tXlME3cC2d7ppg jA+/kXq3QEVmIHQgL6g/kAJpc9Osf7zp+CstrjxlN4xbr/LrTkHEQN52RKONoqqXoSCb03XmrBMd T8w19VoFLS759HKpRScGZOQ+poCscAdMDkpWEgM3ljTjOohQAWdPAyzTWfLm1yJB6J+iBGATmC8o 4VSUlHBKtAQepHiFTV8pgXTpzykDGuBcLjeYrRz9XMBUwB+0w0GfQsBigwFP3O/p7bX/q2fMv/Ls V5epABr94TLXAyLLlyGwWrOfSE8+aNmICb0owP7IJGw0JmGkM8mdFuzJW31LGiZjobc7xcQ/BD4U WWqVsjRqPn+dfE05RBbSkMf4hNB0PefDm/r6rqsnUrIYPrFXkPHp78j3qjnu5tWNuR89ZYapMvm0 Hxpbz9tJdoFsC9ad5VI1WiCYvvq0tXJQ5WofgWH9loPblPRn3Iv1ZiX9hEUfaPMLm1bg0zuobeh7 /JoHUZ5TySK6e7Xf1zWl7cfeqFf6nKU7dOiakPyNSy9nMvvOibAvWuO0LFTDS6yHB0b3hIgXzEnJ c2qqBmtoR+S6DISLuqwd2pnQEKyL1880PhqbeK7uwKG3TAtR8MMf0g6qS+c6n23pk/1DGibArmRA nFXnKpmMFhSSwHu3gLEHp5KhUuB4SPwsD4f/O+iFC8W0UoDzgPwCg8MhCHqJKrQGwYvgFv8ovcu+ 0de8aPADRWot70L9vBkJ4P92CjcMwSrMDDGDBIDlug5EC2ChJz70ukMPYP+WYCEBOPi2Cpd0GiP0 v5pG3rjyloVFqZ2M04h12v6EMXfekdgoB/+kaqD1qHxK8khH/11Ls7xy/octQ5OUecsKgyR9scH8 dc9DOz/whnL1Tp/GjDLalx47XXnCukqwJbkjOUlx5szLpZhzDrt2mGyWUMNizFU+H7bjSbzzXPDU hCNefZDhvfN4yGj8QysCMZlvByW0j3i9T6J4sZGr4l5Wy729cT7Tzb0FZC+G50T+yrwPUbeZtM9O ShS6hl6tl8694rwupySa0T0VfePKpjRhJBWtSq0rBDRuijwFLjU7cQmWWJ0cnAzlvOmgzqoymVif EGOEsEHa3X/Uld/9+vCZYMmFMq+ceJSi9VUHKU52gIxUBKkMs0xjzI56Fx/QF1qIP6xQ/Fso4zv3 bVZSVNpEq5ZUwNwIbCrTmoD/33IdK3r4L/S/TYlaSSmqxXZZU/V9L9sKkk92qV9YF3fHPkrOfuKq 72xBYYxbec9V0UMsjY05u844iKLfzM+uv1A+4xVYPD6WrX6/oW6PnWZBqZ+ixCUnkmNIptOMV0xy m9eL+xmPs005Ax1v+hwnZqbwxubak9p0nQd7LS9ua/78PFBMTheADHYdPpTM+cRaiDpizNIU8zyr yyzNo5nQnOaWnuCw25BzRL7D1tZhL57qJ5tTdXQ72wl+nsAHjD3pl3x4RgxHXb/YX3OPf7/RVEU1 7p7eDp4kk7NXZlyyn75kOnjA/2LQCaFj7qlvh/dub3k1dJCtnQBJPIQ7e4qlDF1d2jY22Scylr/P cUxFZ+ud5ZSIDE0AR+TUD7XLdzIY63bPDzBrNR7DGPGjhKnnCx4lffkF8+XTpOsRpEyAdDHypyyS 6Z/9T/Dfj8nCruXCTxfQBrZRNCjqUWqrCj/Pr/3QKz8fd1eaVH7leSx+8jQA0OIfjH0FekFovKoS 1QG0AM1vlSgsSnGl36CgoJ/1S/T9sUP/n9WEqt3jyarn7M5y25t7ufbBGodLFzpuGxbJF0SYs/Uo VHx0G2JbEBEI0shxCS1LDj9uN6XTcOQc8XCMiWkYmXv2iN/TrBq7ZpjPQwmPtbfw3DmxddcHMlsy Ay6cObgVU2cJsSz/eFSix0FxoUs81CG959LCzJSWQKGFXpHB8zOqaGumHZPTuOh1txCnbLmI8Dcs pm2ZrMfTqrvr89oYecRFyiusYgXbbaOUc5q/XI4ezVfRvK7j3o+d3H4rvPjNpMW1TINbxBozpe6m ERQBgQr2MlkyqDr3VscmureIOXJ2z12ZgcEI252DCiFjoscSWGVLTWzv3d5mbV3wuLVfvr511DND JQRHRjwAafM+DAoFSOX/GnL8E8F/X8amkEYA7m8T6gYojgGOpH9xQZtmV249ExzHunrlHHT9e4sF twZYreUB1n8/EYEDcWscB7tx9LrAppg1GOzIlojM16glB8B31SmsuP2AE0U1ctNPnkiGheh9e0rU L55NlikRKfbL2PYP8fE+4Ovo4xLy12wSQYZCTJAivNXn8OPOD8KMTd5duiNMCh7jw2trQ7agpQh5 6Jqeitxz5Lj36yAuEiOJL4o/LXlqx5M3GlBlkj6XKdbMZKvtcPIXKhjQeDpQqT/8YTPe0/LOkLlS AVq2/0yikvi9+fYkQqHYx2wjJTlB5xqPYIdpw3Q1pt3GfyRo68rdHcNShcUIljp9B05DN5UUzenu 3vtCnTPEvqAI4/ug+mLcKeoF2cypj+z5UCL3uxfu8qYMvAVJkVecws+c/1i13WahfCCBK66FnIBS sHh14UZc2KPx05TJCkl2Vkk2yEQdSXlNkV/iQrCZ2YTvH0Opc3kfzAr1TtUbN9e+E8vInnk/3c4h gM8kg2kRGbrw/Y6hcGToKCgaoYX3gb9lUfMnS6msKMZlB2Agy1D2AHyrY4/l+1c7UDD0vmmQOHba fA9O8Aq0JQ9lJRuQf1eFHheCg/pZ7cFUsKLak31M7Ubv9M1/EgLuZ6PsipLyzOWNDM1dfYYsCCFF d8vIOjHDwcFsETZPgo5ySBxI6nscg8JHtM5JFJ0ivn6woBDEU+9yXygh2xv9hvJW3yKYfY9ybbfz k1Gh59zyakoLOgmB05qCiSeS3g1ft3slU2mTUCWmx448aMCpOYqMcA62WDtKCbHOU4pvH/goV3mE W5gxpLfaZVS502L92bDsMowb06DVAKbV1Kgzi7zbaTdXgwLxmUKHRsMAQfzBTkxO2ezo+gPxmu6y gwwR7VqerOZ1xfXK+/qbIi/DBOQ9qq583nWLAyO49ZOQy0Vng+eHc1ktnJ6yP0lEI0fWiqNTk2uq OyeomVObNde91Wei/gfdFenVDQplbmRzdHJlYW0NCmVuZG9iag0KMTM3NyAwIG9iag0KWyAwWyA2 MDBdICAzWyA2MDAgNjAwIDYwMF0gIDI5WyA2MDBdICA0NVsgNjAwXSAgNTRbIDYwMF0gIDc1WyA2 MDAgNjAwXSAgODBbIDYwMCA2MDAgNjAwXSAgODdbIDYwMF0gIDE3OVsgNjAwXSBdIA0KZW5kb2Jq DQoxMzc4IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSAxMzc4L1dbIDEgNCAyXSAvUm9vdCAxIDAg Ui9JbmZvIDIwOCAwIFIvSURbPDkyRTkzNzRFMTk4MTU0NEFCNTdBNkI1MTdCNTY3MjVBPjw5MkU5 Mzc0RTE5ODE1NDRBQjU3QTZCNTE3QjU2NzI1QT5dIC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDI5ODI+Pg0Kc3RyZWFtDQp4nDXaddyV5R3Hcb7noVEsMLBAAUGxsbu7JS3snK0YU0GxW4xN3Wzd DHTq1NmzNrtmT2fXUDCm2wx2+L3v+Yfv183rec5d1319zvWc06lT+78ZM9L+/xydOs3k+CLPFK3b i853F112LbpuW3TbrOi5ER7Fe0WvY/BYMcs9xaxrYkf8XPTeuJht1WL2FYo+w4u+KxZzX1KssE2x 4hXFiGnFqDWKI88txnuVo4YVxz1ZTJhYTNq9OPnw4pRzilO99JnLFWc5lrO3K87pWZzbvThvoeL8 IcUF6xaTtywudEiX3lZcZ+83LFDcukox9YTiCzv6cklMLabdXEw/uvjK9fx6VrxSfHNc8e27xY91 ddO1Tiy9xhZ9xxX9an8ZiKHzFMsvWKz0XbHOT8WGrxZbY8Sdxch7i7ETih1qtxnXGw8Xu95V7PZE sfcQvFHs80Kx7w6oM8p+/bFfsX8NohxQFzkH1sXKQYcVh35fHFYXMofvXxwxGDWycuTlxfhRxVFz 4rni6DOKYy4ojq2x2zpu8+L4tYsJpxcTa5S3zqgx0Tpzj+KC4XgE7xeTz8brxYXPFxfVuG5ddn9x +Y/FlYui7ljrKju6eg18VVxzXXHtmOK6usWt61crbqx727rJ7928Mj4pbrm4mLIeZhS31m1s3VGD tnVnDZvWveOL+04rHnMqj9eVbz2xS/GU/T1dz0rrpQ+Kl53fGx8Xb75VvHto8V4Nt9aHnxYffVl8 WmO+9dlWxeeObOqU4ouri2kOfroX+2a34tu6ca0fHNKPOxc/ec0Zq8+ko/VZ0XFp0Xlk0aUPXiq6 nld026Lo3hM1Ijt6TCp61iPa0avmkI5ZXyx6e+k5a4B1zFW3v6OPl+5bY6lj3ppYOvrV+XUsVOfQ sXCdWEf/I4oBdVM7FumCZ4tFLyoG7lQMGoRvi8E1OXYsNrkYYrdDly8W74ATW6IuXcewQ4ol10YN xY6lTimWXqY9L7fn5I877YW9sU+bTq916obmR/Zt/8Iyp9dW+x9bCLqiA53RBYuiu1fZz1ZP9MAi GIBZ0AtzoTdmxeyYDXNiDvRFHyyEeTA35sO8mB/9sCAWQH8sjNUw0Knsb2swBmFlrIQhWAxLY3EM xTAsgaWwJJbFMlgRy2M5rIDhWBWrYF2s7nAPsLUm1sDaWAvr4CCs5/d+YWsDrI+NsCE2xoHYBJti M2yDzbE1tsCW2AqjsC1GYjtsjxHYCaOxI8ZgLHbAztgF47ArdsPu2AN7orlme2Ff7I3mIWkGdDMY mot1Cw52BZvrcigOwWH4NQ7H8TgCR+IojMcxOBrH4Vj8EhMxASdgEk7CiTgNp+JknIIzcQZOx/k4 C+fgbJyHc/ErTMYFuAgX4hJcjEtxOS7Db/EbXIkrcDWuwrW4BtfjOvwON+BG/B434yY8iSluXPMg 3IZb8Vf8BbfjD7gTd+A+3IU/4h7cjXvxJzyA+/EIHsKD+DMexmN4FE/gcbyNp5zKwbaewdP4O57F c3geL+BFvISX8Te8glfxGl7HG3gTb+EbvOOQmgfhXfwDX+MrvI/38CE+wMf4CJ/iE3yOzzAV/8SX +ALTMa1IE7BvHWDzwH6Hf/kR4UsTvn/je/wX/8GP+AE/4ye/3lR0hq2B6Gy3ZoZoalQ0KhqlTHcI dMQ0Yhr5jHxGFCOfkc/IZ+Qzshupi5hGBqO+EdNIa1Q0mhoVjaZGRaOpUdGIcFQ0wpdBztbMF4mM mEY3I1JZ3E+aFSOYEcysDmWOfEY+o5SRz6hvdDPSGvmMfEY+I97R24hphD1SkDUdkhk6KhoVjR5F TCPCWQ/yGTGNfEZMo6KRz8hn5DO6GcGMYEYwI6ZR2OhmBDOCGcGMmEZho5RRyshnBDPSGt2MbkYw I5/RzShl5DPyGXlJ83ZSuSKf0c1oVeQz8hm9jYpGN2MWjhksZo14NtM8K80gakZIc1ea3cpnBDPy GcGMfEZ2I5gRzKhoFCgnOZXmxZQymhodi25GTCOt0c2oaDQ18hndjIpGN6OiEdroZlQ0uhkVjW5G aOONROQzYhoVjXxGQnKFU2kuiHxGWqNAUaCoaDQ1ehtNjd5GWiOtkdZIa6Q10ho1jOLFO6RoY6ZA YaO30dQobDQ1ChsxjYpGUzOzoq13mqVJHnKazQ3XzTzsR8zeEYaIfoQ9shsVjbRGaKOw0f5oY5Qy T0FMo7DR20hrpDXaGKWMtEZMo7BR2EhrpDUyGMGMtEbmo7BR9LwDTY0MRiKjqdHNiGmkNZoaFY1g RkzzhUunXJHyyHU0NaqdJqbT2wvGjd+sX2j/3sLocFeOtdUFnbEQFkQ3dEVP9EB3zIJeWAC9MSvm wOyYDXNhTsyNvuiDeTEP5kc/zIe10N8Z/dLWIhiAZbAoBmIQBmMxDMFQLI4lMAxLYiksjWWxPJbD cKyIFbASVsYqWA2rYnWsiTUwBWs7zeNsrYt1cDXWw4ZYHxtgI2yMTbApNsPm2AJbYitsjW2wLbbD 9hiBkRiF0RiDsdgBO2In7IxdMA67Yjfsjj2wJ/bC3tgH+2I/7I8D8AsciINwMA7BoTgMh+MIHInx OApH4xg0D1czIps7djxOwARMxIk4CZNwMk7BqTgNp+MMnImzcDbOwbk4D+fjAkzGhbgIF+MS/Aq/ xqW4DJfjN/gtrsCVuArX4Dpci+vxO9yA3+NG3IRbcDP+jFs9D81l/QNuwx9xO+7AnbgLd+Me3Ism YPfhAdyPB9EE7CG8iEccS3NvH8OjeBxP4K/4C57E03gKz+A5PIvn8QKm4SW7bcbS3/Ay3sEreBWv 4XW8gTfxFv6Ot/EPvIv38AHex4f4GB/hE3yGT/E5/omp+BLiliYo051Y83R8ja/8SIetb/At/oXv 8D3+jf/gv/gBP+In/IwZ9iCYtcJs04JERg2jm5HIqGG0MWoYwYwe1cKvfUYe9MhglDJalf4QzAhm tDGCGcGMUkYpo5RRyoh3lDJKGWWOisY7gah9pKfWt+0DNAVFIiOY0aooVwQz8hmFjRpGGyOmkc9o ajQ1YhoxjWBGRSORkc9oalQ0KhpZqvVm+3BNlVHKyGcELHIW7xKiqZG66GatG9uIYuQz0hrdjIpG PiOt0c2oaASsVoPtQzJtRymjm5G6CF90Myoa3YyKRjejohHMyGfENHJWa8P2/vQhghn5jPBFBiOf EdPIZ8Q08hkxjXxGTCMTtShs70iBoptR0QhRVDQqGhWNikZFo6JR0ahoVDQqGhWNikZFo6JR0Zju Y6aNmS/miTQPVzOEm6HR3I7mKjXnoKKRz+hmVDTyGfmMfEY3o6KRuloUtq9L82LyGTGNKEYiI6aR 1ohppDViGmmNaPx/idhcXRWNptb6qI0MRlrjHWAUNgob7xwjn5HPyG6ENrIbEY7sRnYjprUobCN8 Eb7obbQxQhuhjdBGhKO30dvobbNSjOxGb6O3EdrIWS382leiuVUqGk2N1NUCro20RlojplHYqGik NXobTY3QRsprMdneXzPPv2KrGRryWYvC9j92QRMGMY20RhsjmJHPCG2kNXobvY1cR2+jqRHaSGuk NWIahY2m1gqzfSzN4q4JmERGbyO0kd1mMRlvJDIdTWG/bq8bx93XqfnYsYVgALrhLPRA8wljsx6b Db3QE73R1HAWzI6FMSfmQB/MhXkwN/piPsyLBTA/+mEhLIg9sQjORvOZYpPBPbA7BqP5g+lmWAkr YjE0fykdgqFYHktgGJbEUlgay2BZLIfhWAGbYhOsjKaGq2BVbIjm08c10PzddC00a8p1sC6ajx3X xwbYCBtjJEZgczT92wJbYltsjW2wHbbHGIzGKOyGXTEWO2EH7Igmg7tgXHvsHuwz/UNum0nnB+Yt HqxvN3QZuTXOL0bXFzy6jqyvHHUdfWgx5u2ZdJv4UHHi5zPpvulQ1DedevSq7xr1mMXWzfVVkB63 XDmTnieNKCadPJNeA85HfX+p16L1VZBeJ6zSqdP/AHXA1JsNCmVuZHN0cmVhbQ0KZW5kb2JqDQp4 cmVmDQowIDEzNzkNCjAwMDAwMDAyMDkgNjU1MzUgZg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAw MDAwMTI2IDAwMDAwIG4NCjAwMDAwMDA0NjAgMDAwMDAgbg0KMDAwMDAwMDY5MCAwMDAwMCBuDQow MDAwMDAxMjA3IDAwMDAwIG4NCjAwMDAwMDEzNzcgMDAwMDAgbg0KMDAwMDAwMTYxOCAwMDAwMCBu DQowMDAwMDAxODY3IDAwMDAwIG4NCjAwMDAwMDI2MzEgMDAwMDAgbg0KMDAwMDAwMjc1NSAwMDAw MCBuDQowMDAwMDAyNzg1IDAwMDAwIG4NCjAwMDAwMDI5MzggMDAwMDAgbg0KMDAwMDAwMzAxMiAw MDAwMCBuDQowMDAwMDAzMjU2IDAwMDAwIG4NCjAwMDAwMDMzOTAgMDAwMDAgbg0KMDAwMDAwMzQy MCAwMDAwMCBuDQowMDAwMDAzNTgyIDAwMDAwIG4NCjAwMDAwMDM2NTYgMDAwMDAgbg0KMDAwMDAw Mzg5OCAwMDAwMCBuDQowMDAwMDA0MTQ5IDAwMDAwIG4NCjAwMDAwMDUxNzIgMDAwMDAgbg0KMDAw MDAwNTQzMCAwMDAwMCBuDQowMDAwMDA1NzgzIDAwMDAwIG4NCjAwMDAwMTM2NDkgMDAwMDAgbg0K MDAwMDAxMzk4MyAwMDAwMCBuDQowMDAwMDIxOTk5IDAwMDAwIG4NCjAwMDAwMjIzMzMgMDAwMDAg bg0KMDAwMDAzMDM1MSAwMDAwMCBuDQowMDAwMDMwNTIyIDAwMDAwIG4NCjAwMDAwMzA3NjQgMDAw MDAgbg0KMDAwMDAzMjIwMSAwMDAwMCBuDQowMDAwMDMyODk3IDAwMDAwIG4NCjAwMDAwMzM4OTEg MDAwMDAgbg0KMDAwMDAzNDE2NCAwMDAwMCBuDQowMDAwMDM0NDQ2IDAwMDAwIG4NCjAwMDAwMzQ3 MTEgMDAwMDAgbg0KMDAwMDAzNTYzNCAwMDAwMCBuDQowMDAwMDM1OTEyIDAwMDAwIG4NCjAwMDAw MzYxNzkgMDAwMDAgbg0KMDAwMDAzNjM2MiAwMDAwMCBuDQowMDAwMDM2NjE2IDAwMDAwIG4NCjAw MDAwMzY4OTQgMDAwMDAgbg0KMDAwMDAzNzE2MCAwMDAwMCBuDQowMDAwMDM3NDQyIDAwMDAwIG4N CjAwMDAwMzc3MTAgMDAwMDAgbg0KMDAwMDAzODA0NyAwMDAwMCBuDQowMDAwMDM5NjAwIDAwMDAw IG4NCjAwMDAwNDIyODQgMDAwMDAgbg0KMDAwMDA0Mjc4MCAwMDAwMCBuDQowMDAwMDQ0ODU3IDAw MDAwIG4NCjAwMDAwNjA1NDMgMDAwMDAgbg0KMDAwMDA2MDcyMiAwMDAwMCBuDQowMDAwMDYwOTcz IDAwMDAwIG4NCjAwMDAwNjExNjQgMDAwMDAgbg0KMDAwMDA2MTM1NiAwMDAwMCBuDQowMDAwMDYx NTYxIDAwMDAwIG4NCjAwMDAwNjE3NjcgMDAwMDAgbg0KMDAwMDA2MTk2NSAwMDAwMCBuDQowMDAw MDYyMTY1IDAwMDAwIG4NCjAwMDAwNjIzMzMgMDAwMDAgbg0KMDAwMDA2MjY4OCAwMDAwMCBuDQow MDAwMDY0NjM0IDAwMDAwIG4NCjAwMDAwNjcyMDEgMDAwMDAgbg0KMDAwMDA2ODQ0MiAwMDAwMCBu DQowMDAwMDcxMDA4IDAwMDAwIG4NCjAwMDAwNzIyNDkgMDAwMDAgbg0KMDAwMDA3NDgwOSAwMDAw MCBuDQowMDAwMDc2MDU1IDAwMDAwIG4NCjAwMDAwNzg2MjEgMDAwMDAgbg0KMDAwMDA3OTg2MiAw MDAwMCBuDQowMDAwMDgyNDI5IDAwMDAwIG4NCjAwMDAwODM2NzAgMDAwMDAgbg0KMDAwMDA4NjIz MCAwMDAwMCBuDQowMDAwMDg3NDc2IDAwMDAwIG4NCjAwMDAwODc3MzggMDAwMDAgbg0KMDAwMDA4 ODcwNCAwMDAwMCBuDQowMDAwMDg4OTU3IDAwMDAwIG4NCjAwMDAwOTAxMjYgMDAwMDAgbg0KMDAw MDA5MDMwNCAwMDAwMCBuDQowMDAwMDkwNTUwIDAwMDAwIG4NCjAwMDAwOTA4MjIgMDAwMDAgbg0K MDAwMDA5MTk0NCAwMDAwMCBuDQowMDAwMDkyMTIxIDAwMDAwIG4NCjAwMDAwOTIzNjggMDAwMDAg bg0KMDAwMDA5MjUwNyAwMDAwMCBuDQowMDAwMDkyNTM3IDAwMDAwIG4NCjAwMDAwOTI3MDQgMDAw MDAgbg0KMDAwMDA5Mjc3OCAwMDAwMCBuDQowMDAwMDkzMDI1IDAwMDAwIG4NCjAwMDAwOTMyNjcg MDAwMDAgbg0KMDAwMDA5Mzc0MCAwMDAwMCBuDQowMDAwMDk0MDY3IDAwMDAwIG4NCjAwMDAwOTQ5 NjcgMDAwMDAgbg0KMDAwMDA5NTE1MiAwMDAwMCBuDQowMDAwMDk1MzM5IDAwMDAwIG4NCjAwMDAw OTU1MjYgMDAwMDAgbg0KMDAwMDA5NTcxMyAwMDAwMCBuDQowMDAwMDk1OTAwIDAwMDAwIG4NCjAw MDAwOTYwODcgMDAwMDAgbg0KMDAwMDA5NjI3NCAwMDAwMCBuDQowMDAwMDk2NDYyIDAwMDAwIG4N CjAwMDAwOTY2NTAgMDAwMDAgbg0KMDAwMDA5NjkxNCAwMDAwMCBuDQowMDAwMDk3MjAyIDAwMDAw IG4NCjAwMDAxNjMxNDggMDAwMDAgbg0KMDAwMDE2MzM5MiAwMDAwMCBuDQowMDAwMTYzOTc3IDAw MDAwIG4NCjAwMDAxNjQyMjIgMDAwMDAgbg0KMDAwMDE2NjQ5OSAwMDAwMCBuDQowMDAwMTY2NzU2 IDAwMDAwIG4NCjAwMDAxNjg1MDAgMDAwMDAgbg0KMDAwMDE2ODY0MiAwMDAwMCBuDQowMDAwMTY4 Njc0IDAwMDAwIG4NCjAwMDAxNjg4NDUgMDAwMDAgbg0KMDAwMDE2ODkyMCAwMDAwMCBuDQowMDAw MTY5MTY3IDAwMDAwIG4NCjAwMDAxNjk0MTIgMDAwMDAgbg0KMDAwMDE3MDk0MCAwMDAwMCBuDQow MDAwMTcxMjYwIDAwMDAwIG4NCjAwMDAxNzIwNjcgMDAwMDAgbg0KMDAwMDE3MjI0NSAwMDAwMCBu DQowMDAwMTcyNDI1IDAwMDAwIG4NCjAwMDAxNzI2MDUgMDAwMDAgbg0KMDAwMDE3Mjc4NSAwMDAw MCBuDQowMDAwMTcyOTY1IDAwMDAwIG4NCjAwMDAxNzMxNDUgMDAwMDAgbg0KMDAwMDE3MzMyNSAw MDAwMCBuDQowMDAwMTczNjI3IDAwMDAwIG4NCjAwMDAxNzQ4MTYgMDAwMDAgbg0KMDAwMDE3NDk4 NSAwMDAwMCBuDQowMDAwMTc1MTYwIDAwMDAwIG4NCjAwMDAxNzUzMzUgMDAwMDAgbg0KMDAwMDE3 NTUxMCAwMDAwMCBuDQowMDAwMTc1NjgzIDAwMDAwIG4NCjAwMDAxNzU4NzEgMDAwMDAgbg0KMDAw MDE3NjEyNSAwMDAwMCBuDQowMDAwMTc2OTY4IDAwMDAwIG4NCjAwMDAxNzcyMjMgMDAwMDAgbg0K MDAwMDE3ODgwNyAwMDAwMCBuDQowMDAwMTc5MDgwIDAwMDAwIG4NCjAwMDAxODE0NDIgMDAwMDAg bg0KMDAwMDE4MTYxMCAwMDAwMCBuDQowMDAwMTgxODU1IDAwMDAwIG4NCjAwMDAxODI4NDMgMDAw MDAgbg0KMDAwMDE4MzA5OCAwMDAwMCBuDQowMDAwMTg1MDU5IDAwMDAwIG4NCjAwMDAxODUzMDQg MDAwMDAgbg0KMDAwMDE4Njg1NCAwMDAwMCBuDQowMDAwMTg3MDk5IDAwMDAwIG4NCjAwMDAxODg1 MzAgMDAwMDAgbg0KMDAwMDE4ODc5NCAwMDAwMCBuDQowMDAwMTg5NjcyIDAwMDAwIG4NCjAwMDAx ODk5MzQgMDAwMDAgbg0KMDAwMDE5MDYyMyAwMDAwMCBuDQowMDAwMTkwNzk5IDAwMDAwIG4NCjAw MDAxOTEwNDMgMDAwMDAgbg0KMDAwMDE5MTY2MiAwMDAwMCBuDQowMDAwMTkxOTA2IDAwMDAwIG4N CjAwMDAxOTI0ODcgMDAwMDAgbg0KMDAwMDE5MjczMSAwMDAwMCBuDQowMDAwMTkzMzc4IDAwMDAw IG4NCjAwMDAxOTM2MjMgMDAwMDAgbg0KMDAwMDE5NTQzNCAwMDAwMCBuDQowMDAwMTk1Njc4IDAw MDAwIG4NCjAwMDAxOTYwNzggMDAwMDAgbg0KMDAwMDE5NjQxMiAwMDAwMCBuDQowMDAwMTk3MzUz IDAwMDAwIG4NCjAwMDAxOTc1MzAgMDAwMDAgbg0KMDAwMDE5NzcxOCAwMDAwMCBuDQowMDAwMTk3 OTA4IDAwMDAwIG4NCjAwMDAxOTgwOTggMDAwMDAgbg0KMDAwMDE5ODI4OCAwMDAwMCBuDQowMDAw MTk4NDc3IDAwMDAwIG4NCjAwMDAxOTg2NjYgMDAwMDAgbg0KMDAwMDE5ODg1NCAwMDAwMCBuDQow MDAwMTk5MDQ0IDAwMDAwIG4NCjAwMDAxOTkyMzQgMDAwMDAgbg0KMDAwMDE5OTQ3OCAwMDAwMCBu DQowMDAwMjAwMTQ1IDAwMDAwIG4NCjAwMDAyMDA0MjUgMDAwMDAgbg0KMDAwMDIwMTM5MiAwMDAw MCBuDQowMDAwMjAxNTcxIDAwMDAwIG4NCjAwMDAyMDE3NDggMDAwMDAgbg0KMDAwMDIwMjAwMiAw MDAwMCBuDQowMDAwMjAyOTkxIDAwMDAwIG4NCjAwMDAyMDM0MjMgMDAwMDAgbg0KMDAwMDIwNDUx OSAwMDAwMCBuDQowMDAwMjA0NzE4IDAwMDAwIG4NCjAwMDAyMDQ5MTcgMDAwMDAgbg0KMDAwMDIw NTExNyAwMDAwMCBuDQowMDAwMjA1MzE3IDAwMDAwIG4NCjAwMDAyMDU1MTcgMDAwMDAgbg0KMDAw MDIwNTcxNyAwMDAwMCBuDQowMDAwMjA1OTE3IDAwMDAwIG4NCjAwMDAyMDYxMTcgMDAwMDAgbg0K MDAwMDIwNjMyNCAwMDAwMCBuDQowMDAwMjA2NTMxIDAwMDAwIG4NCjAwMDAyMDY3MzkgMDAwMDAg bg0KMDAwMDIwNjk0NyAwMDAwMCBuDQowMDAwMjA3MTU1IDAwMDAwIG4NCjAwMDAyMDczNjMgMDAw MDAgbg0KMDAwMDIwNzU3MCAwMDAwMCBuDQowMDAwMjA3Nzc4IDAwMDAwIG4NCjAwMDAyMDc5ODUg MDAwMDAgbg0KMDAwMDIwODE5MiAwMDAwMCBuDQowMDAwMjA4MzU0IDAwMDAwIG4NCjAwMDAyMDg1 MTggMDAwMDAgbg0KMDAwMDIwODY4OCAwMDAwMCBuDQowMDAwMDAwMjEwIDY1NTM1IGYNCjAwMDAw MDAyMTEgNjU1MzUgZg0KMDAwMDAwMDIxMiA2NTUzNSBmDQowMDAwMDAwMjEzIDY1NTM1IGYNCjAw MDAwMDAyMTQgNjU1MzUgZg0KMDAwMDAwMDIxNSA2NTUzNSBmDQowMDAwMDAwMjE2IDY1NTM1IGYN CjAwMDAwMDAyMTcgNjU1MzUgZg0KMDAwMDAwMDIxOCA2NTUzNSBmDQowMDAwMDAwMjE5IDY1NTM1 IGYNCjAwMDAwMDAyMjAgNjU1MzUgZg0KMDAwMDAwMDIyMSA2NTUzNSBmDQowMDAwMDAwMjIyIDY1 NTM1IGYNCjAwMDAwMDAyMjMgNjU1MzUgZg0KMDAwMDAwMDIyNCA2NTUzNSBmDQowMDAwMDAwMjI1 IDY1NTM1IGYNCjAwMDAwMDAyMjYgNjU1MzUgZg0KMDAwMDAwMDIyNyA2NTUzNSBmDQowMDAwMDAw MjI4IDY1NTM1IGYNCjAwMDAwMDAyMjkgNjU1MzUgZg0KMDAwMDAwMDIzMCA2NTUzNSBmDQowMDAw MDAwMjMxIDY1NTM1IGYNCjAwMDAwMDAyMzIgNjU1MzUgZg0KMDAwMDAwMDIzMyA2NTUzNSBmDQow MDAwMDAwMjM0IDY1NTM1IGYNCjAwMDAwMDAyMzUgNjU1MzUgZg0KMDAwMDAwMDIzNiA2NTUzNSBm DQowMDAwMDAwMjM3IDY1NTM1IGYNCjAwMDAwMDAyMzggNjU1MzUgZg0KMDAwMDAwMDIzOSA2NTUz NSBmDQowMDAwMDAwMjQwIDY1NTM1IGYNCjAwMDAwMDAyNDEgNjU1MzUgZg0KMDAwMDAwMDI0MiA2 NTUzNSBmDQowMDAwMDAwMjQzIDY1NTM1IGYNCjAwMDAwMDAyNDQgNjU1MzUgZg0KMDAwMDAwMDI0 NSA2NTUzNSBmDQowMDAwMDAwMjQ2IDY1NTM1IGYNCjAwMDAwMDAyNDcgNjU1MzUgZg0KMDAwMDAw MDI0OCA2NTUzNSBmDQowMDAwMDAwMjQ5IDY1NTM1IGYNCjAwMDAwMDAyNTAgNjU1MzUgZg0KMDAw MDAwMDI1MSA2NTUzNSBmDQowMDAwMDAwMjUyIDY1NTM1IGYNCjAwMDAwMDAyNTMgNjU1MzUgZg0K MDAwMDAwMDI1NCA2NTUzNSBmDQowMDAwMDAwMjU1IDY1NTM1IGYNCjAwMDAwMDAyNTYgNjU1MzUg Zg0KMDAwMDAwMDI1NyA2NTUzNSBmDQowMDAwMDAwMjU4IDY1NTM1IGYNCjAwMDAwMDAyNTkgNjU1 MzUgZg0KMDAwMDAwMDI2MCA2NTUzNSBmDQowMDAwMDAwMjYxIDY1NTM1IGYNCjAwMDAwMDAyNjIg NjU1MzUgZg0KMDAwMDAwMDI2MyA2NTUzNSBmDQowMDAwMDAwMjY0IDY1NTM1IGYNCjAwMDAwMDAy NjUgNjU1MzUgZg0KMDAwMDAwMDI2NiA2NTUzNSBmDQowMDAwMDAwMjY3IDY1NTM1IGYNCjAwMDAw MDAyNjggNjU1MzUgZg0KMDAwMDAwMDI2OSA2NTUzNSBmDQowMDAwMDAwMjcwIDY1NTM1IGYNCjAw MDAwMDAyNzEgNjU1MzUgZg0KMDAwMDAwMDI3MiA2NTUzNSBmDQowMDAwMDAwMjczIDY1NTM1IGYN CjAwMDAwMDAyNzQgNjU1MzUgZg0KMDAwMDAwMDI3NSA2NTUzNSBmDQowMDAwMDAwMjc2IDY1NTM1 IGYNCjAwMDAwMDAyNzcgNjU1MzUgZg0KMDAwMDAwMDI3OCA2NTUzNSBmDQowMDAwMDAwMjc5IDY1 NTM1IGYNCjAwMDAwMDAyODAgNjU1MzUgZg0KMDAwMDAwMDI4MSA2NTUzNSBmDQowMDAwMDAwMjgy IDY1NTM1IGYNCjAwMDAwMDAyODMgNjU1MzUgZg0KMDAwMDAwMDI4NCA2NTUzNSBmDQowMDAwMDAw Mjg1IDY1NTM1IGYNCjAwMDAwMDAyODYgNjU1MzUgZg0KMDAwMDAwMDI4NyA2NTUzNSBmDQowMDAw MDAwMjg4IDY1NTM1IGYNCjAwMDAwMDAyODkgNjU1MzUgZg0KMDAwMDAwMDI5MCA2NTUzNSBmDQow MDAwMDAwMjkxIDY1NTM1IGYNCjAwMDAwMDAyOTIgNjU1MzUgZg0KMDAwMDAwMDI5MyA2NTUzNSBm DQowMDAwMDAwMjk0IDY1NTM1IGYNCjAwMDAwMDAyOTUgNjU1MzUgZg0KMDAwMDAwMDI5NiA2NTUz NSBmDQowMDAwMDAwMjk3IDY1NTM1IGYNCjAwMDAwMDAyOTggNjU1MzUgZg0KMDAwMDAwMDI5OSA2 NTUzNSBmDQowMDAwMDAwMzAwIDY1NTM1IGYNCjAwMDAwMDAzMDEgNjU1MzUgZg0KMDAwMDAwMDMw MiA2NTUzNSBmDQowMDAwMDAwMzAzIDY1NTM1IGYNCjAwMDAwMDAzMDQgNjU1MzUgZg0KMDAwMDAw MDMwNSA2NTUzNSBmDQowMDAwMDAwMzA2IDY1NTM1IGYNCjAwMDAwMDAzMDcgNjU1MzUgZg0KMDAw MDAwMDMwOCA2NTUzNSBmDQowMDAwMDAwMzA5IDY1NTM1IGYNCjAwMDAwMDAzMTAgNjU1MzUgZg0K MDAwMDAwMDMxMSA2NTUzNSBmDQowMDAwMDAwMzEyIDY1NTM1IGYNCjAwMDAwMDAzMTMgNjU1MzUg Zg0KMDAwMDAwMDMxNCA2NTUzNSBmDQowMDAwMDAwMzE1IDY1NTM1IGYNCjAwMDAwMDAzMTYgNjU1 MzUgZg0KMDAwMDAwMDMxNyA2NTUzNSBmDQowMDAwMDAwMzE4IDY1NTM1IGYNCjAwMDAwMDAzMTkg NjU1MzUgZg0KMDAwMDAwMDMyMCA2NTUzNSBmDQowMDAwMDAwMzIxIDY1NTM1IGYNCjAwMDAwMDAz MjIgNjU1MzUgZg0KMDAwMDAwMDMyMyA2NTUzNSBmDQowMDAwMDAwMzI0IDY1NTM1IGYNCjAwMDAw MDAzMjUgNjU1MzUgZg0KMDAwMDAwMDMyNiA2NTUzNSBmDQowMDAwMDAwMzI3IDY1NTM1IGYNCjAw MDAwMDAzMjggNjU1MzUgZg0KMDAwMDAwMDMyOSA2NTUzNSBmDQowMDAwMDAwMzMwIDY1NTM1IGYN CjAwMDAwMDAzMzEgNjU1MzUgZg0KMDAwMDAwMDMzMiA2NTUzNSBmDQowMDAwMDAwMzMzIDY1NTM1 IGYNCjAwMDAwMDAzMzQgNjU1MzUgZg0KMDAwMDAwMDMzNSA2NTUzNSBmDQowMDAwMDAwMzM2IDY1 NTM1IGYNCjAwMDAwMDAzMzcgNjU1MzUgZg0KMDAwMDAwMDMzOCA2NTUzNSBmDQowMDAwMDAwMzM5 IDY1NTM1IGYNCjAwMDAwMDAzNDAgNjU1MzUgZg0KMDAwMDAwMDM0MSA2NTUzNSBmDQowMDAwMDAw MzQyIDY1NTM1IGYNCjAwMDAwMDAzNDMgNjU1MzUgZg0KMDAwMDAwMDM0NCA2NTUzNSBmDQowMDAw MDAwMzQ1IDY1NTM1IGYNCjAwMDAwMDAzNDYgNjU1MzUgZg0KMDAwMDAwMDM0NyA2NTUzNSBmDQow MDAwMDAwMzQ4IDY1NTM1IGYNCjAwMDAwMDAzNDkgNjU1MzUgZg0KMDAwMDAwMDM1MCA2NTUzNSBm DQowMDAwMDAwMzUxIDY1NTM1IGYNCjAwMDAwMDAzNTIgNjU1MzUgZg0KMDAwMDAwMDM1MyA2NTUz NSBmDQowMDAwMDAwMzU0IDY1NTM1IGYNCjAwMDAwMDAzNTUgNjU1MzUgZg0KMDAwMDAwMDM1NiA2 NTUzNSBmDQowMDAwMDAwMzU3IDY1NTM1IGYNCjAwMDAwMDAzNTggNjU1MzUgZg0KMDAwMDAwMDM1 OSA2NTUzNSBmDQowMDAwMDAwMzYwIDY1NTM1IGYNCjAwMDAwMDAzNjEgNjU1MzUgZg0KMDAwMDAw MDM2MiA2NTUzNSBmDQowMDAwMDAwMzYzIDY1NTM1IGYNCjAwMDAwMDAzNjQgNjU1MzUgZg0KMDAw MDAwMDM2NSA2NTUzNSBmDQowMDAwMDAwMzY2IDY1NTM1IGYNCjAwMDAwMDAzNjcgNjU1MzUgZg0K MDAwMDAwMDM2OCA2NTUzNSBmDQowMDAwMDAwMzY5IDY1NTM1IGYNCjAwMDAwMDAzNzAgNjU1MzUg Zg0KMDAwMDAwMDM3MSA2NTUzNSBmDQowMDAwMDAwMzcyIDY1NTM1IGYNCjAwMDAwMDAzNzMgNjU1 MzUgZg0KMDAwMDAwMDM3NCA2NTUzNSBmDQowMDAwMDAwMzc1IDY1NTM1IGYNCjAwMDAwMDAzNzYg NjU1MzUgZg0KMDAwMDAwMDM3NyA2NTUzNSBmDQowMDAwMDAwMzc4IDY1NTM1IGYNCjAwMDAwMDAz NzkgNjU1MzUgZg0KMDAwMDAwMDM4MCA2NTUzNSBmDQowMDAwMDAwMzgxIDY1NTM1IGYNCjAwMDAw MDAzODIgNjU1MzUgZg0KMDAwMDAwMDM4MyA2NTUzNSBmDQowMDAwMDAwMzg0IDY1NTM1IGYNCjAw MDAwMDAzODUgNjU1MzUgZg0KMDAwMDAwMDM4NiA2NTUzNSBmDQowMDAwMDAwMzg3IDY1NTM1IGYN CjAwMDAwMDAzODggNjU1MzUgZg0KMDAwMDAwMDM4OSA2NTUzNSBmDQowMDAwMDAwMzkwIDY1NTM1 IGYNCjAwMDAwMDAzOTEgNjU1MzUgZg0KMDAwMDAwMDM5MiA2NTUzNSBmDQowMDAwMDAwMzkzIDY1 NTM1IGYNCjAwMDAwMDAzOTQgNjU1MzUgZg0KMDAwMDAwMDM5NSA2NTUzNSBmDQowMDAwMDAwMzk2 IDY1NTM1IGYNCjAwMDAwMDAzOTcgNjU1MzUgZg0KMDAwMDAwMDM5OCA2NTUzNSBmDQowMDAwMDAw Mzk5IDY1NTM1IGYNCjAwMDAwMDA0MDAgNjU1MzUgZg0KMDAwMDAwMDQwMSA2NTUzNSBmDQowMDAw MDAwNDAyIDY1NTM1IGYNCjAwMDAwMDA0MDMgNjU1MzUgZg0KMDAwMDAwMDQwNCA2NTUzNSBmDQow MDAwMDAwNDA1IDY1NTM1IGYNCjAwMDAwMDA0MDYgNjU1MzUgZg0KMDAwMDAwMDQwNyA2NTUzNSBm DQowMDAwMDAwNDA4IDY1NTM1IGYNCjAwMDAwMDA0MDkgNjU1MzUgZg0KMDAwMDAwMDQxMCA2NTUz NSBmDQowMDAwMDAwNDExIDY1NTM1IGYNCjAwMDAwMDA0MTIgNjU1MzUgZg0KMDAwMDAwMDQxMyA2 NTUzNSBmDQowMDAwMDAwNDE0IDY1NTM1IGYNCjAwMDAwMDA0MTUgNjU1MzUgZg0KMDAwMDAwMDQx NiA2NTUzNSBmDQowMDAwMDAwNDE3IDY1NTM1IGYNCjAwMDAwMDA0MTggNjU1MzUgZg0KMDAwMDAw MDQxOSA2NTUzNSBmDQowMDAwMDAwNDIwIDY1NTM1IGYNCjAwMDAwMDA0MjEgNjU1MzUgZg0KMDAw MDAwMDQyMiA2NTUzNSBmDQowMDAwMDAwNDIzIDY1NTM1IGYNCjAwMDAwMDA0MjQgNjU1MzUgZg0K MDAwMDAwMDQyNSA2NTUzNSBmDQowMDAwMDAwNDI2IDY1NTM1IGYNCjAwMDAwMDA0MjcgNjU1MzUg Zg0KMDAwMDAwMDQyOCA2NTUzNSBmDQowMDAwMDAwNDI5IDY1NTM1IGYNCjAwMDAwMDA0MzAgNjU1 MzUgZg0KMDAwMDAwMDQzMSA2NTUzNSBmDQowMDAwMDAwNDMyIDY1NTM1IGYNCjAwMDAwMDA0MzMg NjU1MzUgZg0KMDAwMDAwMDQzNCA2NTUzNSBmDQowMDAwMDAwNDM1IDY1NTM1IGYNCjAwMDAwMDA0 MzYgNjU1MzUgZg0KMDAwMDAwMDQzNyA2NTUzNSBmDQowMDAwMDAwNDM4IDY1NTM1IGYNCjAwMDAw MDA0MzkgNjU1MzUgZg0KMDAwMDAwMDQ0MCA2NTUzNSBmDQowMDAwMDAwNDQxIDY1NTM1IGYNCjAw MDAwMDA0NDIgNjU1MzUgZg0KMDAwMDAwMDQ0MyA2NTUzNSBmDQowMDAwMDAwNDQ0IDY1NTM1IGYN CjAwMDAwMDA0NDUgNjU1MzUgZg0KMDAwMDAwMDQ0NiA2NTUzNSBmDQowMDAwMDAwNDQ3IDY1NTM1 IGYNCjAwMDAwMDA0NDggNjU1MzUgZg0KMDAwMDAwMDQ0OSA2NTUzNSBmDQowMDAwMDAwNDUwIDY1 NTM1IGYNCjAwMDAwMDA0NTEgNjU1MzUgZg0KMDAwMDAwMDQ1MiA2NTUzNSBmDQowMDAwMDAwNDUz IDY1NTM1IGYNCjAwMDAwMDA0NTQgNjU1MzUgZg0KMDAwMDAwMDQ1NSA2NTUzNSBmDQowMDAwMDAw NDU2IDY1NTM1IGYNCjAwMDAwMDA0NTcgNjU1MzUgZg0KMDAwMDAwMDQ1OCA2NTUzNSBmDQowMDAw MDAwNDU5IDY1NTM1IGYNCjAwMDAwMDA0NjAgNjU1MzUgZg0KMDAwMDAwMDQ2MSA2NTUzNSBmDQow MDAwMDAwNDYyIDY1NTM1IGYNCjAwMDAwMDA0NjMgNjU1MzUgZg0KMDAwMDAwMDQ2NCA2NTUzNSBm DQowMDAwMDAwNDY1IDY1NTM1IGYNCjAwMDAwMDA0NjYgNjU1MzUgZg0KMDAwMDAwMDQ2NyA2NTUz NSBmDQowMDAwMDAwNDY4IDY1NTM1IGYNCjAwMDAwMDA0NjkgNjU1MzUgZg0KMDAwMDAwMDQ3MCA2 NTUzNSBmDQowMDAwMDAwNDcxIDY1NTM1IGYNCjAwMDAwMDA0NzIgNjU1MzUgZg0KMDAwMDAwMDQ3 MyA2NTUzNSBmDQowMDAwMDAwNDc0IDY1NTM1IGYNCjAwMDAwMDA0NzUgNjU1MzUgZg0KMDAwMDAw MDQ3NiA2NTUzNSBmDQowMDAwMDAwNDc3IDY1NTM1IGYNCjAwMDAwMDA0NzggNjU1MzUgZg0KMDAw MDAwMDQ3OSA2NTUzNSBmDQowMDAwMDAwNDgwIDY1NTM1IGYNCjAwMDAwMDA0ODEgNjU1MzUgZg0K MDAwMDAwMDQ4MiA2NTUzNSBmDQowMDAwMDAwNDgzIDY1NTM1IGYNCjAwMDAwMDA0ODQgNjU1MzUg Zg0KMDAwMDAwMDQ4NSA2NTUzNSBmDQowMDAwMDAwNDg2IDY1NTM1IGYNCjAwMDAwMDA0ODcgNjU1 MzUgZg0KMDAwMDAwMDQ4OCA2NTUzNSBmDQowMDAwMDAwNDg5IDY1NTM1IGYNCjAwMDAwMDA0OTAg NjU1MzUgZg0KMDAwMDAwMDQ5MSA2NTUzNSBmDQowMDAwMDAwNDkyIDY1NTM1IGYNCjAwMDAwMDA0 OTMgNjU1MzUgZg0KMDAwMDAwMDQ5NCA2NTUzNSBmDQowMDAwMDAwNDk1IDY1NTM1IGYNCjAwMDAw MDA0OTYgNjU1MzUgZg0KMDAwMDAwMDQ5NyA2NTUzNSBmDQowMDAwMDAwNDk4IDY1NTM1IGYNCjAw MDAwMDA0OTkgNjU1MzUgZg0KMDAwMDAwMDUwMCA2NTUzNSBmDQowMDAwMDAwNTAxIDY1NTM1IGYN CjAwMDAwMDA1MDIgNjU1MzUgZg0KMDAwMDAwMDUwMyA2NTUzNSBmDQowMDAwMDAwNTA0IDY1NTM1 IGYNCjAwMDAwMDA1MDUgNjU1MzUgZg0KMDAwMDAwMDUwNiA2NTUzNSBmDQowMDAwMDAwNTA3IDY1 NTM1IGYNCjAwMDAwMDA1MDggNjU1MzUgZg0KMDAwMDAwMDUwOSA2NTUzNSBmDQowMDAwMDAwNTEw IDY1NTM1IGYNCjAwMDAwMDA1MTEgNjU1MzUgZg0KMDAwMDAwMDUxMiA2NTUzNSBmDQowMDAwMDAw NTEzIDY1NTM1IGYNCjAwMDAwMDA1MTQgNjU1MzUgZg0KMDAwMDAwMDUxNSA2NTUzNSBmDQowMDAw MDAwNTE2IDY1NTM1IGYNCjAwMDAwMDA1MTcgNjU1MzUgZg0KMDAwMDAwMDUxOCA2NTUzNSBmDQow MDAwMDAwNTE5IDY1NTM1IGYNCjAwMDAwMDA1MjAgNjU1MzUgZg0KMDAwMDAwMDUyMSA2NTUzNSBm DQowMDAwMDAwNTIyIDY1NTM1IGYNCjAwMDAwMDA1MjMgNjU1MzUgZg0KMDAwMDAwMDUyNCA2NTUz NSBmDQowMDAwMDAwNTI1IDY1NTM1IGYNCjAwMDAwMDA1MjYgNjU1MzUgZg0KMDAwMDAwMDUyNyA2 NTUzNSBmDQowMDAwMDAwNTI4IDY1NTM1IGYNCjAwMDAwMDA1MjkgNjU1MzUgZg0KMDAwMDAwMDUz MCA2NTUzNSBmDQowMDAwMDAwNTMxIDY1NTM1IGYNCjAwMDAwMDA1MzIgNjU1MzUgZg0KMDAwMDAw MDUzMyA2NTUzNSBmDQowMDAwMDAwNTM0IDY1NTM1IGYNCjAwMDAwMDA1MzUgNjU1MzUgZg0KMDAw MDAwMDUzNiA2NTUzNSBmDQowMDAwMDAwNTM3IDY1NTM1IGYNCjAwMDAwMDA1MzggNjU1MzUgZg0K MDAwMDAwMDUzOSA2NTUzNSBmDQowMDAwMDAwNTQwIDY1NTM1IGYNCjAwMDAwMDA1NDEgNjU1MzUg Zg0KMDAwMDAwMDU0MiA2NTUzNSBmDQowMDAwMDAwNTQzIDY1NTM1IGYNCjAwMDAwMDA1NDQgNjU1 MzUgZg0KMDAwMDAwMDU0NSA2NTUzNSBmDQowMDAwMDAwNTQ2IDY1NTM1IGYNCjAwMDAwMDA1NDcg NjU1MzUgZg0KMDAwMDAwMDU0OCA2NTUzNSBmDQowMDAwMDAwNTQ5IDY1NTM1IGYNCjAwMDAwMDA1 NTAgNjU1MzUgZg0KMDAwMDAwMDU1MSA2NTUzNSBmDQowMDAwMDAwNTUyIDY1NTM1IGYNCjAwMDAw MDA1NTMgNjU1MzUgZg0KMDAwMDAwMDU1NCA2NTUzNSBmDQowMDAwMDAwNTU1IDY1NTM1IGYNCjAw MDAwMDA1NTYgNjU1MzUgZg0KMDAwMDAwMDU1NyA2NTUzNSBmDQowMDAwMDAwNTU4IDY1NTM1IGYN CjAwMDAwMDA1NTkgNjU1MzUgZg0KMDAwMDAwMDU2MCA2NTUzNSBmDQowMDAwMDAwNTYxIDY1NTM1 IGYNCjAwMDAwMDA1NjIgNjU1MzUgZg0KMDAwMDAwMDU2MyA2NTUzNSBmDQowMDAwMDAwNTY0IDY1 NTM1IGYNCjAwMDAwMDA1NjUgNjU1MzUgZg0KMDAwMDAwMDU2NiA2NTUzNSBmDQowMDAwMDAwNTY3 IDY1NTM1IGYNCjAwMDAwMDA1NjggNjU1MzUgZg0KMDAwMDAwMDU2OSA2NTUzNSBmDQowMDAwMDAw NTcwIDY1NTM1IGYNCjAwMDAwMDA1NzEgNjU1MzUgZg0KMDAwMDAwMDU3MiA2NTUzNSBmDQowMDAw MDAwNTczIDY1NTM1IGYNCjAwMDAwMDA1NzQgNjU1MzUgZg0KMDAwMDAwMDU3NSA2NTUzNSBmDQow MDAwMDAwNTc2IDY1NTM1IGYNCjAwMDAwMDA1NzcgNjU1MzUgZg0KMDAwMDAwMDU3OCA2NTUzNSBm DQowMDAwMDAwNTc5IDY1NTM1IGYNCjAwMDAwMDA1ODAgNjU1MzUgZg0KMDAwMDAwMDU4MSA2NTUz NSBmDQowMDAwMDAwNTgyIDY1NTM1IGYNCjAwMDAwMDA1ODMgNjU1MzUgZg0KMDAwMDAwMDU4NCA2 NTUzNSBmDQowMDAwMDAwNTg1IDY1NTM1IGYNCjAwMDAwMDA1ODYgNjU1MzUgZg0KMDAwMDAwMDU4 NyA2NTUzNSBmDQowMDAwMDAwNTg4IDY1NTM1IGYNCjAwMDAwMDA1ODkgNjU1MzUgZg0KMDAwMDAw MDU5MCA2NTUzNSBmDQowMDAwMDAwNTkxIDY1NTM1IGYNCjAwMDAwMDA1OTIgNjU1MzUgZg0KMDAw MDAwMDU5MyA2NTUzNSBmDQowMDAwMDAwNTk0IDY1NTM1IGYNCjAwMDAwMDA1OTUgNjU1MzUgZg0K MDAwMDAwMDU5NiA2NTUzNSBmDQowMDAwMDAwNTk3IDY1NTM1IGYNCjAwMDAwMDA1OTggNjU1MzUg Zg0KMDAwMDAwMDU5OSA2NTUzNSBmDQowMDAwMDAwNjAwIDY1NTM1IGYNCjAwMDAwMDA2MDEgNjU1 MzUgZg0KMDAwMDAwMDYwMiA2NTUzNSBmDQowMDAwMDAwNjAzIDY1NTM1IGYNCjAwMDAwMDA2MDQg NjU1MzUgZg0KMDAwMDAwMDYwNSA2NTUzNSBmDQowMDAwMDAwNjA2IDY1NTM1IGYNCjAwMDAwMDA2 MDcgNjU1MzUgZg0KMDAwMDAwMDYwOCA2NTUzNSBmDQowMDAwMDAwNjA5IDY1NTM1IGYNCjAwMDAw MDA2MTAgNjU1MzUgZg0KMDAwMDAwMDYxMSA2NTUzNSBmDQowMDAwMDAwNjEyIDY1NTM1IGYNCjAw MDAwMDA2MTMgNjU1MzUgZg0KMDAwMDAwMDYxNCA2NTUzNSBmDQowMDAwMDAwNjE1IDY1NTM1IGYN CjAwMDAwMDA2MTYgNjU1MzUgZg0KMDAwMDAwMDYxNyA2NTUzNSBmDQowMDAwMDAwNjE4IDY1NTM1 IGYNCjAwMDAwMDA2MTkgNjU1MzUgZg0KMDAwMDAwMDYyMCA2NTUzNSBmDQowMDAwMDAwNjIxIDY1 NTM1IGYNCjAwMDAwMDA2MjIgNjU1MzUgZg0KMDAwMDAwMDYyMyA2NTUzNSBmDQowMDAwMDAwNjI0 IDY1NTM1IGYNCjAwMDAwMDA2MjUgNjU1MzUgZg0KMDAwMDAwMDYyNiA2NTUzNSBmDQowMDAwMDAw NjI3IDY1NTM1IGYNCjAwMDAwMDA2MjggNjU1MzUgZg0KMDAwMDAwMDYyOSA2NTUzNSBmDQowMDAw MDAwNjMwIDY1NTM1IGYNCjAwMDAwMDA2MzEgNjU1MzUgZg0KMDAwMDAwMDYzMiA2NTUzNSBmDQow MDAwMDAwNjMzIDY1NTM1IGYNCjAwMDAwMDA2MzQgNjU1MzUgZg0KMDAwMDAwMDYzNSA2NTUzNSBm DQowMDAwMDAwNjM2IDY1NTM1IGYNCjAwMDAwMDA2MzcgNjU1MzUgZg0KMDAwMDAwMDYzOCA2NTUz NSBmDQowMDAwMDAwNjM5IDY1NTM1IGYNCjAwMDAwMDA2NDAgNjU1MzUgZg0KMDAwMDAwMDY0MSA2 NTUzNSBmDQowMDAwMDAwNjQyIDY1NTM1IGYNCjAwMDAwMDA2NDMgNjU1MzUgZg0KMDAwMDAwMDY0 NCA2NTUzNSBmDQowMDAwMDAwNjQ1IDY1NTM1IGYNCjAwMDAwMDA2NDYgNjU1MzUgZg0KMDAwMDAw MDY0NyA2NTUzNSBmDQowMDAwMDAwNjQ4IDY1NTM1IGYNCjAwMDAwMDA2NDkgNjU1MzUgZg0KMDAw MDAwMDY1MCA2NTUzNSBmDQowMDAwMDAwNjUxIDY1NTM1IGYNCjAwMDAwMDA2NTIgNjU1MzUgZg0K MDAwMDAwMDY1MyA2NTUzNSBmDQowMDAwMDAwNjU0IDY1NTM1IGYNCjAwMDAwMDA2NTUgNjU1MzUg Zg0KMDAwMDAwMDY1NiA2NTUzNSBmDQowMDAwMDAwNjU3IDY1NTM1IGYNCjAwMDAwMDA2NTggNjU1 MzUgZg0KMDAwMDAwMDY1OSA2NTUzNSBmDQowMDAwMDAwNjYwIDY1NTM1IGYNCjAwMDAwMDA2NjEg NjU1MzUgZg0KMDAwMDAwMDY2MiA2NTUzNSBmDQowMDAwMDAwNjYzIDY1NTM1IGYNCjAwMDAwMDA2 NjQgNjU1MzUgZg0KMDAwMDAwMDY2NSA2NTUzNSBmDQowMDAwMDAwNjY2IDY1NTM1IGYNCjAwMDAw MDA2NjcgNjU1MzUgZg0KMDAwMDAwMDY2OCA2NTUzNSBmDQowMDAwMDAwNjY5IDY1NTM1IGYNCjAw MDAwMDA2NzAgNjU1MzUgZg0KMDAwMDAwMDY3MSA2NTUzNSBmDQowMDAwMDAwNjcyIDY1NTM1IGYN CjAwMDAwMDA2NzMgNjU1MzUgZg0KMDAwMDAwMDY3NCA2NTUzNSBmDQowMDAwMDAwNjc1IDY1NTM1 IGYNCjAwMDAwMDA2NzYgNjU1MzUgZg0KMDAwMDAwMDY3NyA2NTUzNSBmDQowMDAwMDAwNjc4IDY1 NTM1IGYNCjAwMDAwMDA2NzkgNjU1MzUgZg0KMDAwMDAwMDY4MCA2NTUzNSBmDQowMDAwMDAwNjgx IDY1NTM1IGYNCjAwMDAwMDA2ODIgNjU1MzUgZg0KMDAwMDAwMDY4MyA2NTUzNSBmDQowMDAwMDAw Njg0IDY1NTM1IGYNCjAwMDAwMDA2ODUgNjU1MzUgZg0KMDAwMDAwMDY4NiA2NTUzNSBmDQowMDAw MDAwNjg3IDY1NTM1IGYNCjAwMDAwMDA2ODggNjU1MzUgZg0KMDAwMDAwMDY4OSA2NTUzNSBmDQow MDAwMDAwNjkwIDY1NTM1IGYNCjAwMDAwMDA2OTEgNjU1MzUgZg0KMDAwMDAwMDY5MiA2NTUzNSBm DQowMDAwMDAwNjkzIDY1NTM1IGYNCjAwMDAwMDA2OTQgNjU1MzUgZg0KMDAwMDAwMDY5NSA2NTUz NSBmDQowMDAwMDAwNjk2IDY1NTM1IGYNCjAwMDAwMDA2OTcgNjU1MzUgZg0KMDAwMDAwMDY5OCA2 NTUzNSBmDQowMDAwMDAwNjk5IDY1NTM1IGYNCjAwMDAwMDA3MDAgNjU1MzUgZg0KMDAwMDAwMDcw MSA2NTUzNSBmDQowMDAwMDAwNzAyIDY1NTM1IGYNCjAwMDAwMDA3MDMgNjU1MzUgZg0KMDAwMDAw MDcwNCA2NTUzNSBmDQowMDAwMDAwNzA1IDY1NTM1IGYNCjAwMDAwMDA3MDYgNjU1MzUgZg0KMDAw MDAwMDcwNyA2NTUzNSBmDQowMDAwMDAwNzA4IDY1NTM1IGYNCjAwMDAwMDA3MDkgNjU1MzUgZg0K MDAwMDAwMDcxMCA2NTUzNSBmDQowMDAwMDAwNzExIDY1NTM1IGYNCjAwMDAwMDA3MTIgNjU1MzUg Zg0KMDAwMDAwMDcxMyA2NTUzNSBmDQowMDAwMDAwNzE0IDY1NTM1IGYNCjAwMDAwMDA3MTUgNjU1 MzUgZg0KMDAwMDAwMDcxNiA2NTUzNSBmDQowMDAwMDAwNzE3IDY1NTM1IGYNCjAwMDAwMDA3MTgg NjU1MzUgZg0KMDAwMDAwMDcxOSA2NTUzNSBmDQowMDAwMDAwNzIwIDY1NTM1IGYNCjAwMDAwMDA3 MjEgNjU1MzUgZg0KMDAwMDAwMDcyMiA2NTUzNSBmDQowMDAwMDAwNzIzIDY1NTM1IGYNCjAwMDAw MDA3MjQgNjU1MzUgZg0KMDAwMDAwMDcyNSA2NTUzNSBmDQowMDAwMDAwNzI2IDY1NTM1IGYNCjAw MDAwMDA3MjcgNjU1MzUgZg0KMDAwMDAwMDcyOCA2NTUzNSBmDQowMDAwMDAwNzI5IDY1NTM1IGYN CjAwMDAwMDA3MzAgNjU1MzUgZg0KMDAwMDAwMDczMSA2NTUzNSBmDQowMDAwMDAwNzMyIDY1NTM1 IGYNCjAwMDAwMDA3MzMgNjU1MzUgZg0KMDAwMDAwMDczNCA2NTUzNSBmDQowMDAwMDAwNzM1IDY1 NTM1IGYNCjAwMDAwMDA3MzYgNjU1MzUgZg0KMDAwMDAwMDczNyA2NTUzNSBmDQowMDAwMDAwNzM4 IDY1NTM1IGYNCjAwMDAwMDA3MzkgNjU1MzUgZg0KMDAwMDAwMDc0MCA2NTUzNSBmDQowMDAwMDAw NzQxIDY1NTM1IGYNCjAwMDAwMDA3NDIgNjU1MzUgZg0KMDAwMDAwMDc0MyA2NTUzNSBmDQowMDAw MDAwNzQ0IDY1NTM1IGYNCjAwMDAwMDA3NDUgNjU1MzUgZg0KMDAwMDAwMDc0NiA2NTUzNSBmDQow MDAwMDAwNzQ3IDY1NTM1IGYNCjAwMDAwMDA3NDggNjU1MzUgZg0KMDAwMDAwMDc0OSA2NTUzNSBm DQowMDAwMDAwNzUwIDY1NTM1IGYNCjAwMDAwMDA3NTEgNjU1MzUgZg0KMDAwMDAwMDc1MiA2NTUz NSBmDQowMDAwMDAwNzUzIDY1NTM1IGYNCjAwMDAwMDA3NTQgNjU1MzUgZg0KMDAwMDAwMDc1NSA2 NTUzNSBmDQowMDAwMDAwNzU2IDY1NTM1IGYNCjAwMDAwMDA3NTcgNjU1MzUgZg0KMDAwMDAwMDc1 OCA2NTUzNSBmDQowMDAwMDAwNzU5IDY1NTM1IGYNCjAwMDAwMDA3NjAgNjU1MzUgZg0KMDAwMDAw MDc2MSA2NTUzNSBmDQowMDAwMDAwNzYyIDY1NTM1IGYNCjAwMDAwMDA3NjMgNjU1MzUgZg0KMDAw MDAwMDc2NCA2NTUzNSBmDQowMDAwMDAwNzY1IDY1NTM1IGYNCjAwMDAwMDA3NjYgNjU1MzUgZg0K MDAwMDAwMDc2NyA2NTUzNSBmDQowMDAwMDAwNzY4IDY1NTM1IGYNCjAwMDAwMDA3NjkgNjU1MzUg Zg0KMDAwMDAwMDc3MCA2NTUzNSBmDQowMDAwMDAwNzcxIDY1NTM1IGYNCjAwMDAwMDA3NzIgNjU1 MzUgZg0KMDAwMDAwMDc3MyA2NTUzNSBmDQowMDAwMDAwNzc0IDY1NTM1IGYNCjAwMDAwMDA3NzUg NjU1MzUgZg0KMDAwMDAwMDc3NiA2NTUzNSBmDQowMDAwMDAwNzc3IDY1NTM1IGYNCjAwMDAwMDA3 NzggNjU1MzUgZg0KMDAwMDAwMDc3OSA2NTUzNSBmDQowMDAwMDAwNzgwIDY1NTM1IGYNCjAwMDAw MDA3ODEgNjU1MzUgZg0KMDAwMDAwMDc4MiA2NTUzNSBmDQowMDAwMDAwNzgzIDY1NTM1IGYNCjAw MDAwMDA3ODQgNjU1MzUgZg0KMDAwMDAwMDc4NSA2NTUzNSBmDQowMDAwMDAwNzg2IDY1NTM1IGYN CjAwMDAwMDA3ODcgNjU1MzUgZg0KMDAwMDAwMDc4OCA2NTUzNSBmDQowMDAwMDAwNzg5IDY1NTM1 IGYNCjAwMDAwMDA3OTAgNjU1MzUgZg0KMDAwMDAwMDc5MSA2NTUzNSBmDQowMDAwMDAwNzkyIDY1 NTM1IGYNCjAwMDAwMDA3OTMgNjU1MzUgZg0KMDAwMDAwMDc5NCA2NTUzNSBmDQowMDAwMDAwNzk1 IDY1NTM1IGYNCjAwMDAwMDA3OTYgNjU1MzUgZg0KMDAwMDAwMDc5NyA2NTUzNSBmDQowMDAwMDAw Nzk4IDY1NTM1IGYNCjAwMDAwMDA3OTkgNjU1MzUgZg0KMDAwMDAwMDgwMCA2NTUzNSBmDQowMDAw MDAwODAxIDY1NTM1IGYNCjAwMDAwMDA4MDIgNjU1MzUgZg0KMDAwMDAwMDgwMyA2NTUzNSBmDQow MDAwMDAwODA0IDY1NTM1IGYNCjAwMDAwMDA4MDUgNjU1MzUgZg0KMDAwMDAwMDgwNiA2NTUzNSBm DQowMDAwMDAwODA3IDY1NTM1IGYNCjAwMDAwMDA4MDggNjU1MzUgZg0KMDAwMDAwMDgwOSA2NTUz NSBmDQowMDAwMDAwODEwIDY1NTM1IGYNCjAwMDAwMDA4MTEgNjU1MzUgZg0KMDAwMDAwMDgxMiA2 NTUzNSBmDQowMDAwMDAwODEzIDY1NTM1IGYNCjAwMDAwMDA4MTQgNjU1MzUgZg0KMDAwMDAwMDgx NSA2NTUzNSBmDQowMDAwMDAwODE2IDY1NTM1IGYNCjAwMDAwMDA4MTcgNjU1MzUgZg0KMDAwMDAw MDgxOCA2NTUzNSBmDQowMDAwMDAwODE5IDY1NTM1IGYNCjAwMDAwMDA4MjAgNjU1MzUgZg0KMDAw MDAwMDgyMSA2NTUzNSBmDQowMDAwMDAwODIyIDY1NTM1IGYNCjAwMDAwMDA4MjMgNjU1MzUgZg0K MDAwMDAwMDgyNCA2NTUzNSBmDQowMDAwMDAwODI1IDY1NTM1IGYNCjAwMDAwMDA4MjYgNjU1MzUg Zg0KMDAwMDAwMDgyNyA2NTUzNSBmDQowMDAwMDAwODI4IDY1NTM1IGYNCjAwMDAwMDA4MjkgNjU1 MzUgZg0KMDAwMDAwMDgzMCA2NTUzNSBmDQowMDAwMDAwODMxIDY1NTM1IGYNCjAwMDAwMDA4MzIg NjU1MzUgZg0KMDAwMDAwMDgzMyA2NTUzNSBmDQowMDAwMDAwODM0IDY1NTM1IGYNCjAwMDAwMDA4 MzUgNjU1MzUgZg0KMDAwMDAwMDgzNiA2NTUzNSBmDQowMDAwMDAwODM3IDY1NTM1IGYNCjAwMDAw MDA4MzggNjU1MzUgZg0KMDAwMDAwMDgzOSA2NTUzNSBmDQowMDAwMDAwODQwIDY1NTM1IGYNCjAw MDAwMDA4NDEgNjU1MzUgZg0KMDAwMDAwMDg0MiA2NTUzNSBmDQowMDAwMDAwODQzIDY1NTM1IGYN CjAwMDAwMDA4NDQgNjU1MzUgZg0KMDAwMDAwMDg0NSA2NTUzNSBmDQowMDAwMDAwODQ2IDY1NTM1 IGYNCjAwMDAwMDA4NDcgNjU1MzUgZg0KMDAwMDAwMDg0OCA2NTUzNSBmDQowMDAwMDAwODQ5IDY1 NTM1IGYNCjAwMDAwMDA4NTAgNjU1MzUgZg0KMDAwMDAwMDg1MSA2NTUzNSBmDQowMDAwMDAwODUy IDY1NTM1IGYNCjAwMDAwMDA4NTMgNjU1MzUgZg0KMDAwMDAwMDg1NCA2NTUzNSBmDQowMDAwMDAw ODU1IDY1NTM1IGYNCjAwMDAwMDA4NTYgNjU1MzUgZg0KMDAwMDAwMDg1NyA2NTUzNSBmDQowMDAw MDAwODU4IDY1NTM1IGYNCjAwMDAwMDA4NTkgNjU1MzUgZg0KMDAwMDAwMDg2MCA2NTUzNSBmDQow MDAwMDAwODYxIDY1NTM1IGYNCjAwMDAwMDA4NjIgNjU1MzUgZg0KMDAwMDAwMDg2MyA2NTUzNSBm DQowMDAwMDAwODY0IDY1NTM1IGYNCjAwMDAwMDA4NjUgNjU1MzUgZg0KMDAwMDAwMDg2NiA2NTUz NSBmDQowMDAwMDAwODY3IDY1NTM1IGYNCjAwMDAwMDA4NjggNjU1MzUgZg0KMDAwMDAwMDg2OSA2 NTUzNSBmDQowMDAwMDAwODcwIDY1NTM1IGYNCjAwMDAwMDA4NzEgNjU1MzUgZg0KMDAwMDAwMDg3 MiA2NTUzNSBmDQowMDAwMDAwODczIDY1NTM1IGYNCjAwMDAwMDA4NzQgNjU1MzUgZg0KMDAwMDAw MDg3NSA2NTUzNSBmDQowMDAwMDAwODc2IDY1NTM1IGYNCjAwMDAwMDA4NzcgNjU1MzUgZg0KMDAw MDAwMDg3OCA2NTUzNSBmDQowMDAwMDAwODc5IDY1NTM1IGYNCjAwMDAwMDA4ODAgNjU1MzUgZg0K MDAwMDAwMDg4MSA2NTUzNSBmDQowMDAwMDAwODgyIDY1NTM1IGYNCjAwMDAwMDA4ODMgNjU1MzUg Zg0KMDAwMDAwMDg4NCA2NTUzNSBmDQowMDAwMDAwODg1IDY1NTM1IGYNCjAwMDAwMDA4ODYgNjU1 MzUgZg0KMDAwMDAwMDg4NyA2NTUzNSBmDQowMDAwMDAwODg4IDY1NTM1IGYNCjAwMDAwMDA4ODkg NjU1MzUgZg0KMDAwMDAwMDg5MCA2NTUzNSBmDQowMDAwMDAwODkxIDY1NTM1IGYNCjAwMDAwMDA4 OTIgNjU1MzUgZg0KMDAwMDAwMDg5MyA2NTUzNSBmDQowMDAwMDAwODk0IDY1NTM1IGYNCjAwMDAw MDA4OTUgNjU1MzUgZg0KMDAwMDAwMDg5NiA2NTUzNSBmDQowMDAwMDAwODk3IDY1NTM1IGYNCjAw MDAwMDA4OTggNjU1MzUgZg0KMDAwMDAwMDg5OSA2NTUzNSBmDQowMDAwMDAwOTAwIDY1NTM1IGYN CjAwMDAwMDA5MDEgNjU1MzUgZg0KMDAwMDAwMDkwMiA2NTUzNSBmDQowMDAwMDAwOTAzIDY1NTM1 IGYNCjAwMDAwMDA5MDQgNjU1MzUgZg0KMDAwMDAwMDkwNSA2NTUzNSBmDQowMDAwMDAwOTA2IDY1 NTM1IGYNCjAwMDAwMDA5MDcgNjU1MzUgZg0KMDAwMDAwMDkwOCA2NTUzNSBmDQowMDAwMDAwOTA5 IDY1NTM1IGYNCjAwMDAwMDA5MTAgNjU1MzUgZg0KMDAwMDAwMDkxMSA2NTUzNSBmDQowMDAwMDAw OTEyIDY1NTM1IGYNCjAwMDAwMDA5MTMgNjU1MzUgZg0KMDAwMDAwMDkxNCA2NTUzNSBmDQowMDAw MDAwOTE1IDY1NTM1IGYNCjAwMDAwMDA5MTYgNjU1MzUgZg0KMDAwMDAwMDkxNyA2NTUzNSBmDQow MDAwMDAwOTE4IDY1NTM1IGYNCjAwMDAwMDA5MTkgNjU1MzUgZg0KMDAwMDAwMDkyMCA2NTUzNSBm DQowMDAwMDAwOTIxIDY1NTM1IGYNCjAwMDAwMDA5MjIgNjU1MzUgZg0KMDAwMDAwMDkyMyA2NTUz NSBmDQowMDAwMDAwOTI0IDY1NTM1IGYNCjAwMDAwMDA5MjUgNjU1MzUgZg0KMDAwMDAwMDkyNiA2 NTUzNSBmDQowMDAwMDAwOTI3IDY1NTM1IGYNCjAwMDAwMDA5MjggNjU1MzUgZg0KMDAwMDAwMDky OSA2NTUzNSBmDQowMDAwMDAwOTMwIDY1NTM1IGYNCjAwMDAwMDA5MzEgNjU1MzUgZg0KMDAwMDAw MDkzMiA2NTUzNSBmDQowMDAwMDAwOTMzIDY1NTM1IGYNCjAwMDAwMDA5MzQgNjU1MzUgZg0KMDAw MDAwMDkzNSA2NTUzNSBmDQowMDAwMDAwOTM2IDY1NTM1IGYNCjAwMDAwMDA5MzcgNjU1MzUgZg0K MDAwMDAwMDkzOCA2NTUzNSBmDQowMDAwMDAwOTM5IDY1NTM1IGYNCjAwMDAwMDA5NDAgNjU1MzUg Zg0KMDAwMDAwMDk0MSA2NTUzNSBmDQowMDAwMDAwOTQyIDY1NTM1IGYNCjAwMDAwMDA5NDMgNjU1 MzUgZg0KMDAwMDAwMDk0NCA2NTUzNSBmDQowMDAwMDAwOTQ1IDY1NTM1IGYNCjAwMDAwMDA5NDYg NjU1MzUgZg0KMDAwMDAwMDk0NyA2NTUzNSBmDQowMDAwMDAwOTQ4IDY1NTM1IGYNCjAwMDAwMDA5 NDkgNjU1MzUgZg0KMDAwMDAwMDk1MCA2NTUzNSBmDQowMDAwMDAwOTUxIDY1NTM1IGYNCjAwMDAw MDA5NTIgNjU1MzUgZg0KMDAwMDAwMDk1MyA2NTUzNSBmDQowMDAwMDAwOTU0IDY1NTM1IGYNCjAw MDAwMDA5NTUgNjU1MzUgZg0KMDAwMDAwMDk1NiA2NTUzNSBmDQowMDAwMDAwOTU3IDY1NTM1IGYN CjAwMDAwMDA5NTggNjU1MzUgZg0KMDAwMDAwMDk1OSA2NTUzNSBmDQowMDAwMDAwOTYwIDY1NTM1 IGYNCjAwMDAwMDA5NjEgNjU1MzUgZg0KMDAwMDAwMDk2MiA2NTUzNSBmDQowMDAwMDAwOTYzIDY1 NTM1IGYNCjAwMDAwMDA5NjQgNjU1MzUgZg0KMDAwMDAwMDk2NSA2NTUzNSBmDQowMDAwMDAwOTY2 IDY1NTM1IGYNCjAwMDAwMDA5NjcgNjU1MzUgZg0KMDAwMDAwMDk2OCA2NTUzNSBmDQowMDAwMDAw OTY5IDY1NTM1IGYNCjAwMDAwMDA5NzAgNjU1MzUgZg0KMDAwMDAwMDk3MSA2NTUzNSBmDQowMDAw MDAwOTcyIDY1NTM1IGYNCjAwMDAwMDA5NzMgNjU1MzUgZg0KMDAwMDAwMDk3NCA2NTUzNSBmDQow MDAwMDAwOTc1IDY1NTM1IGYNCjAwMDAwMDA5NzYgNjU1MzUgZg0KMDAwMDAwMDk3NyA2NTUzNSBm DQowMDAwMDAwOTc4IDY1NTM1IGYNCjAwMDAwMDA5NzkgNjU1MzUgZg0KMDAwMDAwMDk4MCA2NTUz NSBmDQowMDAwMDAwOTgxIDY1NTM1IGYNCjAwMDAwMDA5ODIgNjU1MzUgZg0KMDAwMDAwMDk4MyA2 NTUzNSBmDQowMDAwMDAwOTg0IDY1NTM1IGYNCjAwMDAwMDA5ODUgNjU1MzUgZg0KMDAwMDAwMDk4 NiA2NTUzNSBmDQowMDAwMDAwOTg3IDY1NTM1IGYNCjAwMDAwMDA5ODggNjU1MzUgZg0KMDAwMDAw MDk4OSA2NTUzNSBmDQowMDAwMDAwOTkwIDY1NTM1IGYNCjAwMDAwMDA5OTEgNjU1MzUgZg0KMDAw MDAwMDk5MiA2NTUzNSBmDQowMDAwMDAwOTkzIDY1NTM1IGYNCjAwMDAwMDA5OTQgNjU1MzUgZg0K MDAwMDAwMDk5NSA2NTUzNSBmDQowMDAwMDAwOTk2IDY1NTM1IGYNCjAwMDAwMDA5OTcgNjU1MzUg Zg0KMDAwMDAwMDk5OCA2NTUzNSBmDQowMDAwMDAwOTk5IDY1NTM1IGYNCjAwMDAwMDEwMDAgNjU1 MzUgZg0KMDAwMDAwMTAwMSA2NTUzNSBmDQowMDAwMDAxMDAyIDY1NTM1IGYNCjAwMDAwMDEwMDMg NjU1MzUgZg0KMDAwMDAwMTAwNCA2NTUzNSBmDQowMDAwMDAxMDA1IDY1NTM1IGYNCjAwMDAwMDEw MDYgNjU1MzUgZg0KMDAwMDAwMTAwNyA2NTUzNSBmDQowMDAwMDAxMDA4IDY1NTM1IGYNCjAwMDAw MDEwMDkgNjU1MzUgZg0KMDAwMDAwMTAxMCA2NTUzNSBmDQowMDAwMDAxMDExIDY1NTM1IGYNCjAw MDAwMDEwMTIgNjU1MzUgZg0KMDAwMDAwMTAxMyA2NTUzNSBmDQowMDAwMDAxMDE0IDY1NTM1IGYN CjAwMDAwMDEwMTUgNjU1MzUgZg0KMDAwMDAwMTAxNiA2NTUzNSBmDQowMDAwMDAxMDE3IDY1NTM1 IGYNCjAwMDAwMDEwMTggNjU1MzUgZg0KMDAwMDAwMTAxOSA2NTUzNSBmDQowMDAwMDAxMDIwIDY1 NTM1IGYNCjAwMDAwMDEwMjEgNjU1MzUgZg0KMDAwMDAwMTAyMiA2NTUzNSBmDQowMDAwMDAxMDIz IDY1NTM1IGYNCjAwMDAwMDEwMjQgNjU1MzUgZg0KMDAwMDAwMTAyNSA2NTUzNSBmDQowMDAwMDAx MDI2IDY1NTM1IGYNCjAwMDAwMDEwMjcgNjU1MzUgZg0KMDAwMDAwMTAyOCA2NTUzNSBmDQowMDAw MDAxMDI5IDY1NTM1IGYNCjAwMDAwMDEwMzAgNjU1MzUgZg0KMDAwMDAwMTAzMSA2NTUzNSBmDQow MDAwMDAxMDMyIDY1NTM1IGYNCjAwMDAwMDEwMzMgNjU1MzUgZg0KMDAwMDAwMTAzNCA2NTUzNSBm DQowMDAwMDAxMDM1IDY1NTM1IGYNCjAwMDAwMDEwMzYgNjU1MzUgZg0KMDAwMDAwMTAzNyA2NTUz NSBmDQowMDAwMDAxMDM4IDY1NTM1IGYNCjAwMDAwMDEwMzkgNjU1MzUgZg0KMDAwMDAwMTA0MCA2 NTUzNSBmDQowMDAwMDAxMDQxIDY1NTM1IGYNCjAwMDAwMDEwNDIgNjU1MzUgZg0KMDAwMDAwMTA0 MyA2NTUzNSBmDQowMDAwMDAxMDQ0IDY1NTM1IGYNCjAwMDAwMDEwNDUgNjU1MzUgZg0KMDAwMDAw MTA0NiA2NTUzNSBmDQowMDAwMDAxMDQ3IDY1NTM1IGYNCjAwMDAwMDEwNDggNjU1MzUgZg0KMDAw MDAwMTA0OSA2NTUzNSBmDQowMDAwMDAxMDUwIDY1NTM1IGYNCjAwMDAwMDEwNTEgNjU1MzUgZg0K MDAwMDAwMTA1MiA2NTUzNSBmDQowMDAwMDAxMDUzIDY1NTM1IGYNCjAwMDAwMDEwNTQgNjU1MzUg Zg0KMDAwMDAwMTA1NSA2NTUzNSBmDQowMDAwMDAxMDU2IDY1NTM1IGYNCjAwMDAwMDEwNTcgNjU1 MzUgZg0KMDAwMDAwMTA1OCA2NTUzNSBmDQowMDAwMDAxMDU5IDY1NTM1IGYNCjAwMDAwMDEwNjAg NjU1MzUgZg0KMDAwMDAwMTA2MSA2NTUzNSBmDQowMDAwMDAxMDYyIDY1NTM1IGYNCjAwMDAwMDEw NjMgNjU1MzUgZg0KMDAwMDAwMTA2NCA2NTUzNSBmDQowMDAwMDAxMDY1IDY1NTM1IGYNCjAwMDAw MDEwNjYgNjU1MzUgZg0KMDAwMDAwMTA2NyA2NTUzNSBmDQowMDAwMDAxMDY4IDY1NTM1IGYNCjAw MDAwMDEwNjkgNjU1MzUgZg0KMDAwMDAwMTA3MCA2NTUzNSBmDQowMDAwMDAxMDcxIDY1NTM1IGYN CjAwMDAwMDEwNzIgNjU1MzUgZg0KMDAwMDAwMTA3MyA2NTUzNSBmDQowMDAwMDAxMDc0IDY1NTM1 IGYNCjAwMDAwMDEwNzUgNjU1MzUgZg0KMDAwMDAwMTA3NiA2NTUzNSBmDQowMDAwMDAxMDc3IDY1 NTM1IGYNCjAwMDAwMDEwNzggNjU1MzUgZg0KMDAwMDAwMTA3OSA2NTUzNSBmDQowMDAwMDAxMDgw IDY1NTM1IGYNCjAwMDAwMDEwODEgNjU1MzUgZg0KMDAwMDAwMTA4MiA2NTUzNSBmDQowMDAwMDAx MDgzIDY1NTM1IGYNCjAwMDAwMDEwODQgNjU1MzUgZg0KMDAwMDAwMTA4NSA2NTUzNSBmDQowMDAw MDAxMDg2IDY1NTM1IGYNCjAwMDAwMDEwODcgNjU1MzUgZg0KMDAwMDAwMTA4OCA2NTUzNSBmDQow MDAwMDAxMDg5IDY1NTM1IGYNCjAwMDAwMDEwOTAgNjU1MzUgZg0KMDAwMDAwMTA5MSA2NTUzNSBm DQowMDAwMDAxMDkyIDY1NTM1IGYNCjAwMDAwMDEwOTMgNjU1MzUgZg0KMDAwMDAwMTA5NCA2NTUz NSBmDQowMDAwMDAxMDk1IDY1NTM1IGYNCjAwMDAwMDEwOTYgNjU1MzUgZg0KMDAwMDAwMTA5NyA2 NTUzNSBmDQowMDAwMDAxMDk4IDY1NTM1IGYNCjAwMDAwMDEwOTkgNjU1MzUgZg0KMDAwMDAwMTEw MCA2NTUzNSBmDQowMDAwMDAxMTAxIDY1NTM1IGYNCjAwMDAwMDExMDIgNjU1MzUgZg0KMDAwMDAw MTEwMyA2NTUzNSBmDQowMDAwMDAxMTA0IDY1NTM1IGYNCjAwMDAwMDExMDUgNjU1MzUgZg0KMDAw MDAwMTEwNiA2NTUzNSBmDQowMDAwMDAxMTA3IDY1NTM1IGYNCjAwMDAwMDExMDggNjU1MzUgZg0K MDAwMDAwMTEwOSA2NTUzNSBmDQowMDAwMDAxMTEwIDY1NTM1IGYNCjAwMDAwMDExMTEgNjU1MzUg Zg0KMDAwMDAwMTExMiA2NTUzNSBmDQowMDAwMDAxMTEzIDY1NTM1IGYNCjAwMDAwMDExMTQgNjU1 MzUgZg0KMDAwMDAwMTExNSA2NTUzNSBmDQowMDAwMDAxMTE2IDY1NTM1IGYNCjAwMDAwMDExMTcg NjU1MzUgZg0KMDAwMDAwMTExOCA2NTUzNSBmDQowMDAwMDAxMTE5IDY1NTM1IGYNCjAwMDAwMDEx MjAgNjU1MzUgZg0KMDAwMDAwMTEyMSA2NTUzNSBmDQowMDAwMDAxMTIyIDY1NTM1IGYNCjAwMDAw MDExMjMgNjU1MzUgZg0KMDAwMDAwMTEyNCA2NTUzNSBmDQowMDAwMDAxMTI1IDY1NTM1IGYNCjAw MDAwMDExMjYgNjU1MzUgZg0KMDAwMDAwMTEyNyA2NTUzNSBmDQowMDAwMDAxMTI4IDY1NTM1IGYN CjAwMDAwMDExMjkgNjU1MzUgZg0KMDAwMDAwMTEzMCA2NTUzNSBmDQowMDAwMDAxMTMxIDY1NTM1 IGYNCjAwMDAwMDExMzIgNjU1MzUgZg0KMDAwMDAwMTEzMyA2NTUzNSBmDQowMDAwMDAxMTM0IDY1 NTM1IGYNCjAwMDAwMDExMzUgNjU1MzUgZg0KMDAwMDAwMTEzNiA2NTUzNSBmDQowMDAwMDAxMTM3 IDY1NTM1IGYNCjAwMDAwMDExMzggNjU1MzUgZg0KMDAwMDAwMTEzOSA2NTUzNSBmDQowMDAwMDAx MTQwIDY1NTM1IGYNCjAwMDAwMDExNDEgNjU1MzUgZg0KMDAwMDAwMTE0MiA2NTUzNSBmDQowMDAw MDAxMTQzIDY1NTM1IGYNCjAwMDAwMDExNDQgNjU1MzUgZg0KMDAwMDAwMTE0NSA2NTUzNSBmDQow MDAwMDAxMTQ2IDY1NTM1IGYNCjAwMDAwMDExNDcgNjU1MzUgZg0KMDAwMDAwMTE0OCA2NTUzNSBm DQowMDAwMDAxMTQ5IDY1NTM1IGYNCjAwMDAwMDExNTAgNjU1MzUgZg0KMDAwMDAwMTE1MSA2NTUz NSBmDQowMDAwMDAxMTUyIDY1NTM1IGYNCjAwMDAwMDExNTMgNjU1MzUgZg0KMDAwMDAwMTE1NCA2 NTUzNSBmDQowMDAwMDAxMTU1IDY1NTM1IGYNCjAwMDAwMDExNTYgNjU1MzUgZg0KMDAwMDAwMTE1 NyA2NTUzNSBmDQowMDAwMDAxMTU4IDY1NTM1IGYNCjAwMDAwMDExNTkgNjU1MzUgZg0KMDAwMDAw MTE2MCA2NTUzNSBmDQowMDAwMDAxMTYxIDY1NTM1IGYNCjAwMDAwMDExNjIgNjU1MzUgZg0KMDAw MDAwMTE2MyA2NTUzNSBmDQowMDAwMDAxMTY0IDY1NTM1IGYNCjAwMDAwMDExNjUgNjU1MzUgZg0K MDAwMDAwMTE2NiA2NTUzNSBmDQowMDAwMDAxMTY3IDY1NTM1IGYNCjAwMDAwMDExNjggNjU1MzUg Zg0KMDAwMDAwMTE2OSA2NTUzNSBmDQowMDAwMDAxMTcwIDY1NTM1IGYNCjAwMDAwMDExNzEgNjU1 MzUgZg0KMDAwMDAwMTE3MiA2NTUzNSBmDQowMDAwMDAxMTczIDY1NTM1IGYNCjAwMDAwMDExNzQg NjU1MzUgZg0KMDAwMDAwMTE3NSA2NTUzNSBmDQowMDAwMDAxMTc2IDY1NTM1IGYNCjAwMDAwMDEx NzcgNjU1MzUgZg0KMDAwMDAwMTE3OCA2NTUzNSBmDQowMDAwMDAxMTc5IDY1NTM1IGYNCjAwMDAw MDExODAgNjU1MzUgZg0KMDAwMDAwMTE4MSA2NTUzNSBmDQowMDAwMDAxMTgyIDY1NTM1IGYNCjAw MDAwMDExODMgNjU1MzUgZg0KMDAwMDAwMTE4NCA2NTUzNSBmDQowMDAwMDAxMTg1IDY1NTM1IGYN CjAwMDAwMDExODYgNjU1MzUgZg0KMDAwMDAwMTE4NyA2NTUzNSBmDQowMDAwMDAxMTg4IDY1NTM1 IGYNCjAwMDAwMDExODkgNjU1MzUgZg0KMDAwMDAwMTE5MCA2NTUzNSBmDQowMDAwMDAxMTkxIDY1 NTM1IGYNCjAwMDAwMDExOTIgNjU1MzUgZg0KMDAwMDAwMTE5MyA2NTUzNSBmDQowMDAwMDAxMTk0 IDY1NTM1IGYNCjAwMDAwMDExOTUgNjU1MzUgZg0KMDAwMDAwMTE5NiA2NTUzNSBmDQowMDAwMDAx MTk3IDY1NTM1IGYNCjAwMDAwMDExOTggNjU1MzUgZg0KMDAwMDAwMTE5OSA2NTUzNSBmDQowMDAw MDAxMjAwIDY1NTM1IGYNCjAwMDAwMDEyMDEgNjU1MzUgZg0KMDAwMDAwMTIwMiA2NTUzNSBmDQow MDAwMDAxMjAzIDY1NTM1IGYNCjAwMDAwMDEyMDQgNjU1MzUgZg0KMDAwMDAwMTIwNSA2NTUzNSBm DQowMDAwMDAxMjA2IDY1NTM1IGYNCjAwMDAwMDEyMDcgNjU1MzUgZg0KMDAwMDAwMTIwOCA2NTUz NSBmDQowMDAwMDAxMjA5IDY1NTM1IGYNCjAwMDAwMDEyMTAgNjU1MzUgZg0KMDAwMDAwMTIxMSA2 NTUzNSBmDQowMDAwMDAxMjEyIDY1NTM1IGYNCjAwMDAwMDEyMTMgNjU1MzUgZg0KMDAwMDAwMTIx NCA2NTUzNSBmDQowMDAwMDAxMjE1IDY1NTM1IGYNCjAwMDAwMDEyMTYgNjU1MzUgZg0KMDAwMDAw MTIxNyA2NTUzNSBmDQowMDAwMDAxMjE4IDY1NTM1IGYNCjAwMDAwMDEyMTkgNjU1MzUgZg0KMDAw MDAwMTIyMCA2NTUzNSBmDQowMDAwMDAxMjIxIDY1NTM1IGYNCjAwMDAwMDEyMjIgNjU1MzUgZg0K MDAwMDAwMTIyMyA2NTUzNSBmDQowMDAwMDAxMjI0IDY1NTM1IGYNCjAwMDAwMDEyMjUgNjU1MzUg Zg0KMDAwMDAwMTIyNiA2NTUzNSBmDQowMDAwMDAxMjI3IDY1NTM1IGYNCjAwMDAwMDEyMjggNjU1 MzUgZg0KMDAwMDAwMTIyOSA2NTUzNSBmDQowMDAwMDAxMjMwIDY1NTM1IGYNCjAwMDAwMDEyMzEg NjU1MzUgZg0KMDAwMDAwMTIzMiA2NTUzNSBmDQowMDAwMDAxMjMzIDY1NTM1IGYNCjAwMDAwMDEy MzQgNjU1MzUgZg0KMDAwMDAwMTIzNSA2NTUzNSBmDQowMDAwMDAxMjM2IDY1NTM1IGYNCjAwMDAw MDEyMzcgNjU1MzUgZg0KMDAwMDAwMTIzOCA2NTUzNSBmDQowMDAwMDAxMjM5IDY1NTM1IGYNCjAw MDAwMDEyNDAgNjU1MzUgZg0KMDAwMDAwMTI0MSA2NTUzNSBmDQowMDAwMDAxMjQyIDY1NTM1IGYN CjAwMDAwMDEyNDMgNjU1MzUgZg0KMDAwMDAwMTI0NCA2NTUzNSBmDQowMDAwMDAxMjQ1IDY1NTM1 IGYNCjAwMDAwMDEyNDYgNjU1MzUgZg0KMDAwMDAwMTI0NyA2NTUzNSBmDQowMDAwMDAxMjQ4IDY1 NTM1IGYNCjAwMDAwMDEyNDkgNjU1MzUgZg0KMDAwMDAwMTI1MCA2NTUzNSBmDQowMDAwMDAxMjUx IDY1NTM1IGYNCjAwMDAwMDEyNTIgNjU1MzUgZg0KMDAwMDAwMTI1MyA2NTUzNSBmDQowMDAwMDAx MjU0IDY1NTM1IGYNCjAwMDAwMDEyNTUgNjU1MzUgZg0KMDAwMDAwMTI1NiA2NTUzNSBmDQowMDAw MDAxMjU3IDY1NTM1IGYNCjAwMDAwMDEyNTggNjU1MzUgZg0KMDAwMDAwMTI1OSA2NTUzNSBmDQow MDAwMDAxMjYwIDY1NTM1IGYNCjAwMDAwMDEyNjEgNjU1MzUgZg0KMDAwMDAwMTI2MiA2NTUzNSBm DQowMDAwMDAxMjYzIDY1NTM1IGYNCjAwMDAwMDEyNjQgNjU1MzUgZg0KMDAwMDAwMTI2NSA2NTUz NSBmDQowMDAwMDAxMjY2IDY1NTM1IGYNCjAwMDAwMDEyNjcgNjU1MzUgZg0KMDAwMDAwMTI2OCA2 NTUzNSBmDQowMDAwMDAxMjY5IDY1NTM1IGYNCjAwMDAwMDEyNzAgNjU1MzUgZg0KMDAwMDAwMTI3 MSA2NTUzNSBmDQowMDAwMDAxMjcyIDY1NTM1IGYNCjAwMDAwMDEyNzMgNjU1MzUgZg0KMDAwMDAw MTI3NCA2NTUzNSBmDQowMDAwMDAxMjc1IDY1NTM1IGYNCjAwMDAwMDEyNzYgNjU1MzUgZg0KMDAw MDAwMTI3NyA2NTUzNSBmDQowMDAwMDAxMjc4IDY1NTM1IGYNCjAwMDAwMDEyNzkgNjU1MzUgZg0K MDAwMDAwMTI4MCA2NTUzNSBmDQowMDAwMDAxMjgxIDY1NTM1IGYNCjAwMDAwMDEyODIgNjU1MzUg Zg0KMDAwMDAwMTI4MyA2NTUzNSBmDQowMDAwMDAxMjg0IDY1NTM1IGYNCjAwMDAwMDEyODUgNjU1 MzUgZg0KMDAwMDAwMTI4NiA2NTUzNSBmDQowMDAwMDAxMjg3IDY1NTM1IGYNCjAwMDAwMDEyODgg NjU1MzUgZg0KMDAwMDAwMTI4OSA2NTUzNSBmDQowMDAwMDAxMjkwIDY1NTM1IGYNCjAwMDAwMDEy OTEgNjU1MzUgZg0KMDAwMDAwMTI5MiA2NTUzNSBmDQowMDAwMDAxMjkzIDY1NTM1IGYNCjAwMDAw MDEyOTQgNjU1MzUgZg0KMDAwMDAwMTI5NSA2NTUzNSBmDQowMDAwMDAxMjk2IDY1NTM1IGYNCjAw MDAwMDEyOTcgNjU1MzUgZg0KMDAwMDAwMTI5OCA2NTUzNSBmDQowMDAwMDAxMjk5IDY1NTM1IGYN CjAwMDAwMDEzMDAgNjU1MzUgZg0KMDAwMDAwMTMwMSA2NTUzNSBmDQowMDAwMDAxMzAyIDY1NTM1 IGYNCjAwMDAwMDEzMDMgNjU1MzUgZg0KMDAwMDAwMTMwNCA2NTUzNSBmDQowMDAwMDAxMzA1IDY1 NTM1IGYNCjAwMDAwMDEzMDYgNjU1MzUgZg0KMDAwMDAwMTMwNyA2NTUzNSBmDQowMDAwMDAxMzA4 IDY1NTM1IGYNCjAwMDAwMDEzMDkgNjU1MzUgZg0KMDAwMDAwMTMxMCA2NTUzNSBmDQowMDAwMDAx MzExIDY1NTM1IGYNCjAwMDAwMDEzMTIgNjU1MzUgZg0KMDAwMDAwMTMxMyA2NTUzNSBmDQowMDAw MDAxMzE0IDY1NTM1IGYNCjAwMDAwMDEzMTUgNjU1MzUgZg0KMDAwMDAwMTMxNiA2NTUzNSBmDQow MDAwMDAxMzE3IDY1NTM1IGYNCjAwMDAwMDEzMTggNjU1MzUgZg0KMDAwMDAwMTMxOSA2NTUzNSBm DQowMDAwMDAxMzIwIDY1NTM1IGYNCjAwMDAwMDEzMjEgNjU1MzUgZg0KMDAwMDAwMTMyMiA2NTUz NSBmDQowMDAwMDAxMzIzIDY1NTM1IGYNCjAwMDAwMDEzMjQgNjU1MzUgZg0KMDAwMDAwMTMyNSA2 NTUzNSBmDQowMDAwMDAxMzI2IDY1NTM1IGYNCjAwMDAwMDEzMjcgNjU1MzUgZg0KMDAwMDAwMTMy OCA2NTUzNSBmDQowMDAwMDAxMzI5IDY1NTM1IGYNCjAwMDAwMDEzMzAgNjU1MzUgZg0KMDAwMDAw MTMzMSA2NTUzNSBmDQowMDAwMDAxMzMyIDY1NTM1IGYNCjAwMDAwMDEzMzMgNjU1MzUgZg0KMDAw MDAwMTMzNCA2NTUzNSBmDQowMDAwMDAxMzM1IDY1NTM1IGYNCjAwMDAwMDEzMzYgNjU1MzUgZg0K MDAwMDAwMTMzNyA2NTUzNSBmDQowMDAwMDAxMzM4IDY1NTM1IGYNCjAwMDAwMDEzMzkgNjU1MzUg Zg0KMDAwMDAwMTM0MCA2NTUzNSBmDQowMDAwMDAxMzQxIDY1NTM1IGYNCjAwMDAwMDEzNDIgNjU1 MzUgZg0KMDAwMDAwMTM0MyA2NTUzNSBmDQowMDAwMDAxMzQ0IDY1NTM1IGYNCjAwMDAwMDEzNDUg NjU1MzUgZg0KMDAwMDAwMTM0NiA2NTUzNSBmDQowMDAwMDAxMzQ3IDY1NTM1IGYNCjAwMDAwMDEz NDggNjU1MzUgZg0KMDAwMDAwMTM0OSA2NTUzNSBmDQowMDAwMDAxMzUwIDY1NTM1IGYNCjAwMDAw MDEzNTEgNjU1MzUgZg0KMDAwMDAwMTM1MiA2NTUzNSBmDQowMDAwMDAxMzUzIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDIyNTM0MSAwMDAwMCBuDQowMDAwMjI1NzEyIDAwMDAwIG4N CjAwMDAzMTA1NTIgMDAwMDAgbg0KMDAwMDMxMDg2MyAwMDAwMCBuDQowMDAwMzQ5Nzc2IDAwMDAw IG4NCjAwMDAzNDk4NDEgMDAwMDAgbg0KMDAwMDM1MDQyMSAwMDAwMCBuDQowMDAwNDE1Mzc1IDAw MDAwIG4NCjAwMDA0MTU4NTggMDAwMDAgbg0KMDAwMDQxNjIyMSAwMDAwMCBuDQowMDAwNDkxOTY3 IDAwMDAwIG4NCjAwMDA0OTIyNjYgMDAwMDAgbg0KMDAwMDU0MzI3MyAwMDAwMCBuDQowMDAwNTQz NDg2IDAwMDAwIG4NCjAwMDA1OTI3OTEgMDAwMDAgbg0KMDAwMDU5MzE1MCAwMDAwMCBuDQowMDAw NjM0MDIxIDAwMDAwIG4NCjAwMDA2MzQyNzIgMDAwMDAgbg0KMDAwMDY4ODk4MSAwMDAwMCBuDQow MDAwNjg5Mjg1IDAwMDAwIG4NCjAwMDA3Mjk0ODkgMDAwMDAgbg0KMDAwMDcyOTU0NSAwMDAwMCBu DQowMDAwNzI5OTEyIDAwMDAwIG4NCjAwMDA3NTM0NjUgMDAwMDAgbg0KMDAwMDc1MzU5OSAwMDAw MCBuDQp0cmFpbGVyDQo8PC9TaXplIDEzNzkvUm9vdCAxIDAgUi9JbmZvIDIwOCAwIFIvSURbPDky RTkzNzRFMTk4MTU0NEFCNTdBNkI1MTdCNTY3MjVBPjw5MkU5Mzc0RTE5ODE1NDRBQjU3QTZCNTE3 QjU2NzI1QT5dID4+DQpzdGFydHhyZWYNCjc1Njc4OA0KJSVFT0YNCnhyZWYNCjAgMA0KdHJhaWxl cg0KPDwvU2l6ZSAxMzc5L1Jvb3QgMSAwIFIvSW5mbyAyMDggMCBSL0lEWzw5MkU5Mzc0RTE5ODE1 NDRBQjU3QTZCNTE3QjU2NzI1QT48OTJFOTM3NEUxOTgxNTQ0QUI1N0E2QjUxN0I1NjcyNUE+XSAv UHJldiA3NTY3ODgvWFJlZlN0bSA3NTM1OTk+Pg0Kc3RhcnR4cmVmDQo3ODQ1MzENCiUlRU9G --_002_56C3C758F9D6534CA3778EAA1E0C34373301E78EBY2PRD0410MB354_-- From leifj@mnt.se Fri Aug 3 08:25:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA64721F8CA7 for ; Fri, 3 Aug 2012 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfrm6fgYDRun for ; Fri, 3 Aug 2012 08:25:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F321821F87B0 for ; Fri, 3 Aug 2012 08:25:04 -0700 (PDT) Received: by yenm6 with SMTP id m6so633164yen.31 for ; Fri, 03 Aug 2012 08:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=cgovNDlDE9ontx41PeHWQPOsHC20jS+nDn+q4P4h+cA=; b=O86gSIe+Q4QQFBj4ZBnI14Q8r48rvWY68UHONeM6wqNCjO3tGCsS/NJ1IX1A9JV0Qf KtjKqoYSECF0g0TneJi7As+hlVc1L09g8j+HXPGVw8FBFhrazgg3AamKwPGBk7GfMVdt qBuBQZA9v30xwzrn90h2HVbKVj/frJccdpcLQEzEzBjvIO80ZpzvFDbJM+pl4AtqzN/z veeIIalLlMdT3xZxc2b2OWzqHLCKOOTR75rGVwgLBSys69/bVlMRcNmJSPCAM0nw37xe p+e/cHUD2Ytq/sN7vKpM2UsC66K6zFk/N9MBwWGHmQFPBPK+xUmmLwXOuay4eAN3B6jX 9Aew== Received: by 10.50.10.164 with SMTP id j4mr11571957igb.13.1344007503868; Fri, 03 Aug 2012 08:25:03 -0700 (PDT) Received: from ?IPv6:2001:df8::64:11b4:4247:141:d80b? ([2001:df8:0:64:11b4:4247:141:d80b]) by mx.google.com with ESMTPS id o1sm22801549igm.16.2012.08.03.08.24.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 08:25:03 -0700 (PDT) References: <501BE72D.2030409@stpeter.im> In-Reply-To: <501BE72D.2030409@stpeter.im> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Leif Johansson Date: Fri, 3 Aug 2012 08:24:48 -0700 To: Peter Saint-Andre X-Gm-Message-State: ALoCoQnBAJGz9HqY+/G/3cAgFzYepKA76EfNIOQiPalatCPhSj7bONQeqIALi17F6hpgn43mkumJ Cc: "scim@ietf.org" Subject: Re: [scim] slides for today? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 15:25:06 -0000 As soon as I can resurrect my laptop I will upload - had a bad crash last ni= ght. 3 aug 2012 kl. 07:58 skrev Peter Saint-Andre : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > I see no slides uploaded to > https://datatracker.ietf.org/meeting/84/materials.html#wg-scim >=20 > Peter >=20 > - -- > Peter Saint-Andre > https://stpeter.im/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAlAb5y0ACgkQNL8k5A2w/vxrggCgq9iiiokdJeCi3suxDe2joy00 > H5sAnAnmthEhOsSMEc16c37YTl9YTLwM > =3DcUlG > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From ietf@meetecho.com Tue Aug 7 15:55:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC2F21F8473 for ; Tue, 7 Aug 2012 15:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.628 X-Spam-Level: X-Spam-Status: No, score=0.628 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG3D1z8o0XbL for ; Tue, 7 Aug 2012 15:55:37 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out18.aruba.it [62.149.158.58]) by ietfa.amsl.com (Postfix) with SMTP id D861721F847B for ; Tue, 7 Aug 2012 15:55:36 -0700 (PDT) Received: (qmail 14681 invoked by uid 89); 7 Aug 2012 22:55:35 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq04.aruba.it with SMTP; 7 Aug 2012 22:55:35 -0000 Received: (qmail 10377 invoked by uid 89); 7 Aug 2012 22:55:35 -0000 Received: from unknown (HELO ?192.168.1.154?) (alex@meetecho.com@87.11.150.210) by smtp7.ad.aruba.it with ESMTPA; 7 Aug 2012 22:55:35 -0000 Message-ID: <50219CD8.6020506@meetecho.com> Date: Wed, 08 Aug 2012 00:55:20 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [scim] Meetecho session recording available X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:55:38 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of SCIM session at IETF-84 is available. You can watch it by accessing the following URL: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#IETF84_SCIM For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From kelly.grizzle@sailpoint.com Wed Aug 8 11:55:48 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADD621F86A8 for ; Wed, 8 Aug 2012 11:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV+Iw69NwcuR for ; Wed, 8 Aug 2012 11:55:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5818821F86A1 for ; Wed, 8 Aug 2012 11:55:40 -0700 (PDT) Received: from mail22-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 18:55:39 +0000 Received: from mail22-ch1 (localhost [127.0.0.1]) by mail22-ch1-R.bigfish.com (Postfix) with ESMTP id 9BB4D4601F0; Wed, 8 Aug 2012 18:55:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz9371Ic85fh1432I111aI1447Izz1202hzz1033IL122ac1I8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail22-ch1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail22-ch1 (localhost.localdomain [127.0.0.1]) by mail22-ch1 (MessageSwitch) id 1344452137603933_29578; Wed, 8 Aug 2012 18:55:37 +0000 (UTC) Received: from CH1EHSMHS010.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail22-ch1.bigfish.com (Postfix) with ESMTP id 9138C2C0047; Wed, 8 Aug 2012 18:55:37 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by CH1EHSMHS010.bigfish.com (10.43.70.10) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 18:55:36 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0175.005; Wed, 8 Aug 2012 18:55:35 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad , "scim@ietf.org" Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNcCv7gNwjoPnr4E2VDZsFNg+dnpdQQ4bA Date: Wed, 8 Aug 2012 18:55:34 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373302493FBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 18:55:49 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373302493FBY2PRD0410MB354_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Gan= esh and Sashi Prasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" ] then on successful creation, the server response should include the represe= ntation of the resource, and this attribute should look like this: "email-addrs" : [ { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" }, { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" }, { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com<= mailto:jsmith1970@hotmail.com>" } ] The client now knows what each value is labelled. This now provides an unam= biguous way to reference a value to add, modify and delete it: Add: POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs value=3D"js70@easy.com.au" Modify: PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-4= 3b9-9cda-8646c3085bbf value=3D"john.r.smith@gmail.com" Delete: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e= 1-4cca-9db7-7a6d1de664e1 One can even delete all email addresses like this: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs I believe this is more elegant than what the spec recommends. 3. It's possible to think of the operations POST, PUT and DELETE as nested = operations inside a PATCH. PATCH itself need not be nested because its sema= ntics apply throughout the "tree" of a resource. However, the semantics of PUT are a little messy. Also, the use of HTTP ver= bs at a different level could be confusing. That's why I would recommend 6 = separate verbs that are a little more unambiguous in their meaning: 1. INCLUDE (equivalent to POST): Add this resource to a collection and retu= rn a generated URI 2. PLACE (equivalent to one form of PUT): Add this resource at the location= specified by the accompanying URI. (If there's already a value at that loc= ation, return an error status.) 3. REPLACE (equivalent to another form of PUT): Replace the value at the lo= cation specified by the accompanying URI with this value. (If there's no su= ch URI, return an error status.) 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. = (At the end of this operation, we want the specified URI to hold the accomp= anying value whether the URI already existed or not.) 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render in= accessible the resource at the specified URI. 6. AMEND (equivalent to PATCH): (This verb is just listed for completeness.= We probably don't need a nested PATCH since PATCH cascades to every level = of the tree.) A PATCH request could therefore look like this: PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Content-length: ... { REPLACE: { "key" : "first-name", "value" : "Jack" }, PLACE : { "key" : "middle-name", "value" : "Richard" }, FORCE : { "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "key" : "address.unit-number", "value" : "12" }, PLACE : { "key" : "address.state", "value" : "SA" }, FORCE : { "key" : "address.country", "value" : "Australia" }, INCLUDE : { "key" : "email-addrs", "value" : "js70@easy.com.au" }, REPLACE : { "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } } The PATCH response should utilise the status code "207 Multi-Status" becaus= e the nested operations could have varying status codes. A sample response = is below: HTTP/1.1 207 Multi-Status Content-Type: application/json ETag: W/"b431af54f0671a2" Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646= " { "schemas":["urn:scim:schemas:core:1.0"], "external-id":"2819c223-7f76-453a-919d-413861904646", REPLACE: { "status" : "200 OK", "key" : "first-name", "value" : "Jack" }, PLACE : { "status" : "200 OK", "key" : "middle-name", "value" : "Richard" }, FORCE : { "status" : "200 OK", "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "status" : "200 OK", "key" : "address.unit-number", "value" : "12" }, PLACE : { "status" : "200 OK", "key" : "address.state", "value" : "SA" }, FORCE : { "status" : "200 OK", "key" : "address.country", "value" : "Australia" }, INCLUDE : { "status" : "201 Created", "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", "value" : "js70@easy.com.au" }, REPLACE : { "status" : "200 OK", "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "status" : "200 OK", "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41= 3861904646", "version":"W\/\"b431af54f0671a2\"" } } If there are errors, they will take the place of the "200 OK" or "201 Creat= ed" status codes in the above successful case. But the outer status will re= main "207 Multi-Status". The same scheme can be used to deal with operations on members of a group, = and for bulk operations. I hope you find these suggestions useful. I read the SCIM spec afresh last week and these ideas came flooding into my= head because I have been working at another organisation (a telco) for the= last 5 months, also in Identity and Access Management, and my thoughts hav= e moved further along the direction of evolving a specialised data model ba= sed on specific principles, especially for IAM. I am planning to write about this and also the data-related principles soon= and am in negotiations with InfoQ regarding publication. Regards, Ganesh Prasad --_000_56C3C758F9D6534CA3778EAA1E0C34373302493FBY2PRD0410MB354_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, = Ganesh.  I read through this and your InfoQ article (http://www.info= q.com/articles/scim-data-model-limitations) and have some thoughts.

 <= /p>

> The rest of the protocol do= es not meaningfully use the enterprise client’s identifier, the "= ;external ID"

> at all= , even though it was ostensibly introduced to make things friendlier for th= e client.

 <= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of t= he returned user in any desired operation.  For example:

 <= /p>

GET /Users?filter=3Dexter= nalId eq “bjensen”&attributes=3Did

 <= /p>

{

  “totalResults”: 1,

  “Resources”: [<= /span>

    {

      “id̶= 1;: “2819c223-7f76-453a-919d-413861904646”

    }

  ]

}

 <= /p>

Retrieve the ID from the = response and use it.

 <= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

 <= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server’s= id.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One main point of contenti= on is that much of the rest of the spec (eg – group membership refere= nces, manager references, etc…) require knowledge of the server’= ;s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 <= /p>

 <= /p>

> the cloud provider's ID and= the enterprise client's ID are both "Internal IDs" with respect = to their domains

 <= /p>

I think this comes down t= o a nomenclature problem.  The server’s ID does not necessarily = have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the underl= ying identity store will provide identifiers with these properties already = (eg – a uuid) and it can be used by the SCIM interface.  The = 220;externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server’= s identifiers are stable and unique (which is mandated by the spec), I don&= #8217;t see a problem.

 <= /p>

 <= /p>

> The secret is that every value needs a key, a= nd multi-valued attributes lack that. So our solution is quite

> simple= - turn every list or array (of values) into a dictionary (of key-value pai= rs) by providing each value

> with a= unique and meaning-free identifier.=

 <= /p>

I agree that this would b= e useful, especially in the PATCH operation.  One reason that this was= n’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg – direc= tory servers, SaaS application databases, etc…).  Many of these = do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I believe t= his would be a roadblock for many implementers.

 <= /p>

 <= /p>

> When the SCIM protocol uses= PATCH, there are areas where it seems a bit clumsy.

 <= /p>

I like the thoughts here.=   Your example reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff= #Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk= -resources), however.

 <= /p>

 <= /p>

> There are other, non-data a= spects of SCIM which may require review, such as its synchronous request-re= sponse

> intera= ction model, which is a form of tight coupling and could prove to be a sour= ce of brittleness.

 <= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

 <= /p>

Thanks again for your tho= ughts.  I hope you stay involved in the discussion as work on SCIM 2.0= goes forward.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for improvement

 

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on Info= Q (http://www.infoq.com/minibooks/Identity-Management-Shoestring).<= /o:p>

 

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared = External ID, and this is the only ID that should be exposed through the API. The current specification's pro= vision of an id (which is the external ID and the only one to be transferre= d through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider w= hen the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will = be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.= e., when a resource is discovered to be more than one, or when multiple resources are detected to be the sam= e. If internal identifiers are revealed to external domains, such clean-ups= become difficult, hence every domain that wants to expose references to a = resource must map its internal ID to and external one created for this explicit purpose, and only reveal thi= s.

 

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the = external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated i= nternal ID of its own. In case the resource already has an identifier withi= n the enterprise client's domain, then this is the internal ID that must be= mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

    ]

 

then on successful creation, the server response sho= uld include the representation of the resource, and this attribute should l= ook like this:

 

    "email-addrs" : 

    [

        { "7dfcb444-74d8-4f= 17-aa66-daf9ea3bd902" : "= john_smith@yahoo.com" },

        { "3bd10085-c474-43= b9-9cda-8646c3085bbf" : "= john.smith@gmail.com" },

        { "581da5c7-c6e1-4c= ca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com" }

    ]

 

The client now knows what each value is labelled. Th= is now provides an unambiguous way to reference a value to add, modify and = delete it:

 

Add:

 

POST /Users/2819c223-7f76-453a-919d-413861904646/ema= il-addrs

value=3D"js= 70@easy.com.au"

 

Modify:

 

PUT /Users/2819c223-7f76-453a-919d-413861904646/emai= l-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

 

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

 

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs

 

I believe this is more elegant than what the spec re= commends.

 

3. It's possible to think of the operations POST, PU= T and DELETE as nested operations inside a PATCH. PATCH itself need not be = nested because its semantics apply throughout the "tree" of a res= ource.

 

However, the semantics of PUT are a little messy. Al= so, the use of HTTP verbs at a different level could be confusing. That's w= hy I would recommend 6 separate verbs that are a little more unambiguous in= their meaning:

 

1. INCLUDE (equivalent to POST): Add this resource t= o a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this r= esource at the location specified by the accompanying URI. (If there’= s already a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Repl= ace the value at the location specified by the accompanying URI with this v= alue. (If there’s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This m= eans PLACE or REPLACE. (At the end of this operation, we want the specified= URI to hold the accompanying value whether the URI already existed or not.= )

5. RETIRE (equivalent to DELETE): Delete, deactivate= or otherwise render inaccessible the resource at the specified URI.

6. AMEND (equivalent to PATCH): (This verb is just l= isted for completeness. We probably don’t need a nested PATCH since P= ATCH cascades to every level of the tree.)

 

A PATCH request could therefore look like this:=

 

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HT= TP/1.1

Host: example.com=

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

 

{

    REPLACE: {

        "key" : "= first-name",

        "value" : &quo= t;Jack"

    },

    PLACE : {

        "key" : "= middle-name",

        "value" : &quo= t;Richard"

    },

    FORCE : {

        "key" : "= dob",

        "value" : &quo= t;01-Jan-1971"

    },

    REPLACE : {

        "key" : "= address.unit-number",

        "value" : &quo= t;12"

    },

    PLACE : {

        "key" : "= address.state",

        "value" : &quo= t;SA"

    },

    FORCE : {

        "key" : "= address.country",

        "value" : &quo= t;Australia"

    },

    INCLUDE : {

        "key" : "= email-addrs",

        "value" : &quo= t;js70@easy.com.au"=

    },

    REPLACE : {

        "key" : "= email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value" : &quo= t;john.r.smith@gmail.com"= ;

    },

    RETIRE : {

        "key" : "= email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

}

 

The PATCH response should utilise the status code &q= uot;207 Multi-Status" because the nested operations could have varying= status codes. A sample response is below:

 

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

 

{

    "schemas":["urn:scim:sc= hemas:core:1.0"],

    "external-id":"2819c223= -7f76-453a-919d-413861904646",

    REPLACE: {

        "status" : &qu= ot;200 OK",

        "key" : "= first-name",

        "value" : &quo= t;Jack"

    },

    PLACE : {

        "status" : &qu= ot;200 OK",

        "key" : "= middle-name",

        "value" : &quo= t;Richard"

    },

    FORCE : {

        "status" : &qu= ot;200 OK",

        "key" : "= dob",

        "value" : &quo= t;01-Jan-1971"

    },

    REPLACE : {

        "status" : &qu= ot;200 OK",

        "key" : "= address.unit-number",

        "value" : &quo= t;12"

    },

    PLACE : {

        "status" : &qu= ot;200 OK",

        "key" : "= address.state",

        "value" : &quo= t;SA"

    },

    FORCE : {

        "status" : &qu= ot;200 OK",

        "key" : "= address.country",

        "value" : &quo= t;Australia"

    },

    INCLUDE : {

        "status" : &qu= ot;201 Created",

        "key" : "= email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",

        "value" : &quo= t;js70@easy.com.au"=

    },

    REPLACE : {

        "status" : &qu= ot;200 OK",

        "key" : "= email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value" : &quo= t;john.r.smith@gmail.com"= ;

    },

    RETIRE : {

        "status" : &qu= ot;200 OK",

        "key" : "= email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

    "meta": {

        "created":&quo= t;2011-08-08T04:56:22Z",

        "lastModified"= :"2011-08-08T08:00:12Z",

        "version":&quo= t;W\/\"b431af54f0671a2\""

    }

}

 

If there are errors, they will take the place of the= "200 OK" or "201 Created" status codes in the above su= ccessful case. But the outer status will remain "207 Multi-Status"= ;.

 

The same scheme can be used to deal with operations = on members of a group, and for bulk operations.

 

I hope you find these suggestions useful.=

 

I read the SCIM spec afresh last week and these idea= s came flooding into my head because I have been working at another organis= ation (a telco) for the last 5 months, also in Identity and Access Manageme= nt, and my thoughts have moved further along the direction of evolving a specialised data model based on specific= principles, especially for IAM.

 

I am planning to write about this and also the data-= related principles soon and am in negotiations with InfoQ regarding publica= tion.

 

Regards,

Ganesh Prasad

--_000_56C3C758F9D6534CA3778EAA1E0C34373302493FBY2PRD0410MB354_-- From g.c.prasad@gmail.com Wed Aug 8 18:35:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61D021F8541 for ; Wed, 8 Aug 2012 18:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N333ZDfPty+c for ; Wed, 8 Aug 2012 18:35:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FB21F8540 for ; Wed, 8 Aug 2012 18:35:15 -0700 (PDT) Received: by bkty7 with SMTP id y7so600259bkt.31 for ; Wed, 08 Aug 2012 18:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0tHp7hS9+hG3ZEQ4A8dL9VE4qKZG757kAC8fDSoUwN8=; b=Y3Ifwq64dA4c/j6Q5IE03vOSlwpqnQLJlOVVr8JXYfOCNbnB+ab+AFVJpPRxQztA4p LTjFTM9Za+7KkaxHspU7nTEBMVGiTnLCJpEcfBGvnkcTTcc+h7yiTwfEieObh5dMryL8 XNYCdRhImqnoHa0HSHF8gPaEjj+5Etml7otqldH/gI4f2cXM3qx5X7gtPFxucaWakZwJ OOME2qqvIOFJsRO8VAQGqRnoLiZDndqvuVnrRNGeVgQYVX8v2BMGzvrOyeQkFMNeLBDi gWCLPjPouRsvKWTz0eOcbZp4d3zzSheuJ7NJ5cHT3uWNm/vg6KIsIACzbEHVu9Mcm5my 8oBA== Received: by 10.204.154.211 with SMTP id p19mr8675459bkw.12.1344476114937; Wed, 08 Aug 2012 18:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Wed, 8 Aug 2012 18:34:54 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Thu, 9 Aug 2012 11:34:54 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015175cd1303d697504c6cb3d3d Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 01:35:21 -0000 --0015175cd1303d697504c6cb3d3d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Kelly, Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other domains? a. We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data. b. In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when =93false negatives=94 and =93false positives=94 are discovered. A domain should be able to handle this interna= l housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains. c. Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-complia= nt=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be supported using a =93non-SCIM-compliant=94 API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience. A key set of lifecycle events for an entity is the merging and splitting of identity that is often required. The question =93Is this one entity?=94 can be answered either yes (positive= ) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores. Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as =93John Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names =93JSmith=94 and =93J= ohnS=94. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary flag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information. Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} Internal ID: a99a5feba839 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vic= e-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of =937a87f27c1dd8=94, this can go = into the mapping table as a new record associated with the second entity's internal identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary flag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1. (What is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinct customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} Internal ID: 273d36e30d09 Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary flag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary flag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambiguously translated to the same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to determine the =93primary=94 external ID for thi= s entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's wher= e the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b=94 = is never used thereafter in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domain 2 can be requested to delete the customer record identified by =93 41206cc97c8b=94, and the second entry in the mapping table can be removed once this is acknowledged. This scheme will scale up to multiple domains, because the =93External Doma= in ID=94 column helps to keep track of which external ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling again. Just as OAuth allows an access token given to a third party to be invalidated without affecting the access of other third parties, the use of separate external identifiers for different domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entities, and the merging of more than two entities into a single one. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide internal identifiers from other domains, and why mappings need to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of identity events, since there is no consistency requirement to update multiple domains concurrently= . Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle wrote: > Thanks for the feedback, Ganesh. I read through this and your InfoQ > article (http://www.infoq.com/articles/scim-data-model-limitations) and > have some thoughts.**** > > ** ** > > > The rest of the protocol does not meaningfully use the enterprise > client=92s identifier, the "external ID"**** > > > at all, even though it was ostensibly introduced to make things > friendlier for the client.**** > > ** ** > > The usage pattern for an external ID would be to search for a user by > externalId and use the ID of the returned user in any desired operation. > For example:**** > > ** ** > > GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** > > ** ** > > {**** > > =93totalResults=94: 1,**** > > =93Resources=94: [**** > > {**** > > =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** > > }**** > > ]**** > > }**** > > ** ** > > Retrieve the ID from the response and use it.**** > > ** ** > > DELETE /Users/2819c223-7f76-453a-919d-413861904646**** > > ** ** > > This does introduce an additional HTTP request if the client chooses not > to store the server=92s id. An issue was created to consider allowing > operations to use the externalId ( > http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the > general consensus has been to not include this in the spec. One main poi= nt > of contention is that much of the rest of the spec (eg =96 group membersh= ip > references, manager references, etc=85) require knowledge of the server= =92s > identifier. Continuing this discussion on the IETF list would be a good > thing, though.**** > > ** ** > > ** ** > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains**** > > ** ** > > I think this comes down to a nomenclature problem. The server=92s ID doe= s > not necessarily have to be the unique identifier that the underlying > identity store uses, it just has to be stable and unique. In many cases, > the underlying identity store will provide identifiers with these > properties already (eg =96 a uuid) and it can be used by the SCIM interfa= ce. > The =93externalId=94 is referring to the fact that the id is maintained > external to the SCIM server. As long as the server=92s identifiers are > stable and unique (which is mandated by the spec), I don=92t see a proble= m.* > *** > > ** ** > > ** ** > > > The secret is that *every value needs a key*, and multi-valued > attributes lack that. So our solution is quite**** > > > simple - turn every list or array (of values) into a dictionary (of > key-value pairs) by providing each value**** > > > with a unique and meaning-free identifier.**** > > ** ** > > I agree that this would be useful, especially in the PATCH operation. On= e > reason that this wasn=92t included in the spec originally is that it can = put > undue burden on the service provider. Many service providers are putting > SCIM interfaces in front of their existing identity stores (eg =96 direct= ory > servers, SaaS application databases, etc=85). Many of these do not have = a > unique identifier for multi-valued attributes. By requiring this, a > majority of the server providers would have to start maintaining a unique > key for each multi-valued attribute. I believe this would be a roadblock > for many implementers.**** > > ** ** > > ** ** > > > When the SCIM protocol uses PATCH, there are areas where it seems a bit > clumsy.**** > > ** ** > > I like the thoughts here. Your example reminds me of unified diffs ( > http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly > used with a patch program (pretty much the equivalent of the PATCH verb). > However, the three proposals seem to largely hinge on being able to > uniquely address each element within an object. Without these it is not = so > easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or > provide a multi-status.**** > > > The 207 response would be interesting to consider for the bulk endpoint ( > http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however.**** > > ** ** > > ** ** > > > There are other, non-data aspects of SCIM which may require review, > such as its synchronous request-response**** > > > interaction model, which is a form of tight coupling and could prove to > be a source of brittleness.**** > > ** ** > > I agree that we should explore optional asynchronous requests in 2.0.**** > > ** ** > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward.**** > > ** ** > > --Kelly**** > > ** ** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** > > ** ** > > (I posted this on the SCIM Google Group, and I was advised to subscribe t= o > the mailing list and post it here instead, so here goes.)**** > > ** ** > > Hi,**** > > ** ** > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian insurance > company, an experience I have written about as a eBook on InfoQ ( > http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** > > ** ** > > I have been following the SCIM spec off and on, and based on my experienc= e > with a loosely-coupled architecture that I found to be successful, I have > the following 3 suggestions to make.**** > > ** ** > > 1. The enterprise client and the cloud provider should maintain their own > internal IDs for a resource, which they should not reveal to each other. > Both of them should map their internal IDs to a shared External ID, and > this is the only ID that should be exposed through the API. The current > specification's provision of an id (which is the external ID and the only > one to be transferred through the API) and an "external ID" (which is the > client's internal ID and should be hidden) is diametrically opposite to > this.**** > > ** ** > > 2. When dealing with multi-valued attributes of a resource (expressed as > arrays in JSON), they must be converted from an array into a dictionary > with unique keys (UUIDs generated by the cloud provider when the attribut= e > is created). Without unique keys for every attribute value of a resource, > manipulating it will be clumsy and inelegant.**** > > ** ** > > 3. The PATCH command can be improved in 3 significant ways:**** > > 3a. Leverage the fact (from 2 above) that every value has a key, to > greatly simplify the API**** > > 3b. Use special verbs as nested operations of the PATCH command to add, > modify and delete attributes at any level**** > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" > as the response to a PATCH (or BULK) command.**** > > ** ** > > To elaborate,**** > > ** ** > > 1. Revealing private IDs externally is a form of tight coupling. A major > requirement with Identity Management is to split (or merge) identities wh= en > false positives (or false negatives) are detected, i.e., when a resource = is > discovered to be more than one, or when multiple resources are detected t= o > be the same. If internal identifiers are revealed to external domains, su= ch > clean-ups become difficult, hence every domain that wants to expose > references to a resource must map its internal ID to and external one > created for this explicit purpose, and only reveal this.**** > > ** ** > > In the SCIM case, when an enterprise client POSTs a resource creation > request, the cloud provider must generate its own internal UUID as well a= s > an external UUID, map them together, and only return the external UUID in > the "Location:" header. The enterprise client should map this external UU= ID > to a newly-generated internal ID of its own. In case the resource already > has an identifier within the enterprise client's domain, then this is the > internal ID that must be mapped to the external UUID returned through the > POST response.**** > > ** ** > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g.,**** > > ** ** > > "email-addrs" : **** > > [**** > > "john_smith@yahoo.com",**** > > "john.smith@gmail.com",**** > > "jsmith1970@hotmail.com"**** > > ]**** > > ** ** > > then on successful creation, the server response should include the > representation of the resource, and this attribute should look like this:= * > *** > > ** ** > > "email-addrs" : **** > > [**** > > { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" > },**** > > { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" > },**** > > { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.co= m" > }**** > > ]**** > > ** ** > > The client now knows what each value is labelled. This now provides an > unambiguous way to reference a value to add, modify and delete it:**** > > ** ** > > Add:**** > > ** ** > > POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** > > value=3D"js70@easy.com.au"**** > > ** ** > > Modify:**** > > ** ** > > PUT > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43b= 9-9cda-8646c3085bbf > **** > > value=3D"john.r.smith@gmail.com"**** > > ** ** > > Delete:**** > > DELETE > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4cc= a-9db7-7a6d1de664e1 > **** > > ** ** > > One can even delete all email addresses like this:**** > > DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** > > ** ** > > I believe this is more elegant than what the spec recommends.**** > > ** ** > > 3. It's possible to think of the operations POST, PUT and DELETE as neste= d > operations inside a PATCH. PATCH itself need not be nested because its > semantics apply throughout the "tree" of a resource.**** > > ** ** > > However, the semantics of PUT are a little messy. Also, the use of HTTP > verbs at a different level could be confusing. That's why I would recomme= nd > 6 separate verbs that are a little more unambiguous in their meaning:**** > > ** ** > > 1. INCLUDE (equivalent to POST): Add this resource to a collection and > return a generated URI**** > > 2. PLACE (equivalent to one form of PUT): Add this resource at the > location specified by the accompanying URI. (If there=92s already a value= at > that location, return an error status.)**** > > 3. REPLACE (equivalent to another form of PUT): Replace the value at the > location specified by the accompanying URI with this value. (If there=92s= no > such URI, return an error status.)**** > > 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE= . > (At the end of this operation, we want the specified URI to hold the > accompanying value whether the URI already existed or not.)**** > > 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render > inaccessible the resource at the specified URI.**** > > 6. AMEND (equivalent to PATCH): (This verb is just listed for > completeness. We probably don=92t need a nested PATCH since PATCH cascade= s to > every level of the tree.)**** > > ** ** > > A PATCH request could therefore look like this:**** > > ** ** > > PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > Content-length: ...**** > > ** ** > > {**** > > REPLACE: {**** > > "key" : "first-name",**** > > "value" : "Jack"**** > > },**** > > PLACE : {**** > > "key" : "middle-name",**** > > "value" : "Richard"**** > > },**** > > FORCE : {**** > > "key" : "dob",**** > > "value" : "01-Jan-1971"**** > > },**** > > REPLACE : {**** > > "key" : "address.unit-number",**** > > "value" : "12"**** > > },**** > > PLACE : {**** > > "key" : "address.state",**** > > "value" : "SA"**** > > },**** > > FORCE : {**** > > "key" : "address.country",**** > > "value" : "Australia"**** > > },**** > > INCLUDE : {**** > > "key" : "email-addrs",**** > > "value" : "js70@easy.com.au"**** > > },**** > > REPLACE : {**** > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** > > "value" : "john.r.smith@gmail.com"**** > > },**** > > RETIRE : {**** > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** > > }**** > > }**** > > ** ** > > The PATCH response should utilise the status code "207 Multi-Status" > because the nested operations could have varying status codes. A sample > response is below:**** > > ** ** > > HTTP/1.1 207 Multi-Status**** > > Content-Type: application/json**** > > ETag: W/"b431af54f0671a2"**** > > Location:" > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646"**** > > ** ** > > {**** > > "schemas":["urn:scim:schemas:core:1.0"],**** > > "external-id":"2819c223-7f76-453a-919d-413861904646",**** > > REPLACE: {**** > > "status" : "200 OK",**** > > "key" : "first-name",**** > > "value" : "Jack"**** > > },**** > > PLACE : {**** > > "status" : "200 OK",**** > > "key" : "middle-name",**** > > "value" : "Richard"**** > > },**** > > FORCE : {**** > > "status" : "200 OK",**** > > "key" : "dob",**** > > "value" : "01-Jan-1971"**** > > },**** > > REPLACE : {**** > > "status" : "200 OK",**** > > "key" : "address.unit-number",**** > > "value" : "12"**** > > },**** > > PLACE : {**** > > "status" : "200 OK",**** > > "key" : "address.state",**** > > "value" : "SA"**** > > },**** > > FORCE : {**** > > "status" : "200 OK",**** > > "key" : "address.country",**** > > "value" : "Australia"**** > > },**** > > INCLUDE : {**** > > "status" : "201 Created",**** > > "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",**** > > "value" : "js70@easy.com.au"**** > > },**** > > REPLACE : {**** > > "status" : "200 OK",**** > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** > > "value" : "john.r.smith@gmail.com"**** > > },**** > > RETIRE : {**** > > "status" : "200 OK",**** > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** > > }**** > > "meta": {**** > > "created":"2011-08-08T04:56:22Z",**** > > "lastModified":"2011-08-08T08:00:12Z",**** > > "location":" > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",**** > > "version":"W\/\"b431af54f0671a2\""**** > > }**** > > }**** > > ** ** > > If there are errors, they will take the place of the "200 OK" or "201 > Created" status codes in the above successful case. But the outer status > will remain "207 Multi-Status".**** > > ** ** > > The same scheme can be used to deal with operations on members of a group= , > and for bulk operations.**** > > ** ** > > I hope you find these suggestions useful.**** > > ** ** > > I read the SCIM spec afresh last week and these ideas came flooding into > my head because I have been working at another organisation (a telco) for > the last 5 months, also in Identity and Access Management, and my thought= s > have moved further along the direction of evolving a specialised data mod= el > based on specific principles, especially for IAM.**** > > ** ** > > I am planning to write about this and also the data-related principles > soon and am in negotiations with InfoQ regarding publication.**** > > ** ** > > Regards,**** > > Ganesh Prasad**** > --0015175cd1303d697504c6cb3d3d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =09 =09 =09

Hi Kelly,

Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first.

  1. Why should domains not expose their internal identifiers to other domains?

a.

<= p class=3D"western" style=3D"margin-left:0.61cm;margin-bottom:0cm">We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data.

b.=20

In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when =93false negatives=94 and =93false positives=94 are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling.

2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be supported using a =93non-SCIM-compliant=94 API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is the merging and splitting of identity that is often required.

The question =93Is this one entity?=94 can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as =93John Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.

a. False positives:

Domain 1 has the following information about a customer in its data store:

Internal ID: 9caf78aac3d6

Attributes= : {name: =93John Smith=94, dob: =9301-Jan-1970=94}

When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true =20 |

When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping =939caf7= 8aac3d6=94 to =93ff487230b3a0<= /font>=94 and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of =937a87f27c1dd8<= /font>=94, this can go into the mapping table as a new record associated with the second entity's internal identifier.

The mapping table now contains the following entries:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true =20 |

| a99a5feba839 | D2 | 7a87f27c1dd8 | true =20 |

Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1.

(What is the =93Primary flag=94 used for? We'll see when we cover the treatment of false negatives.)

b. False negatives:

Domain 1 has the following information about what it thinks are two distinct customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true =20 |

| 273d36e30d09 | D2 | 41206cc97c8b | true =20 |

When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.

The mapping table now looks like this:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true =20 |

| 9caf78aac3d6 | D2 | 41206cc97c8b | false=20 |

Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambiguously translated to the same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to determine the =93primary=94 external ID for this entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound communication.

At some stage (importantly, not in lockstep with the identity merge), Domain 2 can be requested to delete the customer record identified by =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is acknowledged.

This scheme will scale up to multiple domains, because the =93External Domain ID=94 column helps to keep track of which external ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling again. Just as OAuth allows an access token given to a third party to be invalidated without affecting the access of other third parties, the use of separate external identifiers for different domains allows fine-grained control of identity federation.)

The scheme also allows the splitting of an entity into more than two entities, and the merging of more than two entities into a single one. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This is a fairly long-winded explanation, but this is why we need to hide internal identifiers from other domains, and why mappings need to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of identity events, since there is no consistency requirement to update multiple domains concurrently.

Regards,

Ganesh Prasad


<= div class=3D"gmail_quote">On 9 August 2012 04:55, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, = Ganesh.=A0 I read through this and your InfoQ article (= http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

=A0<= /p>

> The rest of the protocol does not meani= ngfully use the enterprise client=92s identifier, the "external ID&quo= t;

> at all, even thoug= h it was ostensibly introduced to make things friendlier for the client.

=A0<= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of t= he returned user in any desired operation.=A0 For example:

=A0<= /p>

GET /Users?filter=3Dexter= nalId eq =93bjensen=94&attributes=3Did

=A0<= /p>

{

=A0 =93totalResults=94: 1,

=A0 =93Resources=94: [

=A0=A0=A0 {

=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45= 3a-919d-413861904646=94

=A0=A0=A0 }

=A0 ]

}=

=A0<= /p>

Retrieve the ID from the = response and use it.

=A0<= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

=A0<= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server=92s id.= =A0 An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/det= ail?id=3D35), but I believe the general cons= ensus has been to not include this in the spec.=A0 One main point of contention = is that much of the rest of the spec (eg =96 group membership references, m= anager references, etc=85) require knowledge of the server=92s identifier.= =A0 Continuing this discussion on the IETF list would be a good thing, though.

=A0<= /p>

=A0<= /p>

> the cloud provider's ID and the ent= erprise client's ID are both "Internal IDs" with respect to t= heir domains

=A0<= /p>

I think this comes down t= o a nomenclature problem.=A0 The server=92s ID does not necessarily have to= be the unique identifier that the underlying identity store uses, it just has to be stable and unique.=A0 In many cases, the underlyin= g identity store will provide identifiers with these properties already (eg= =96 a uuid) and it can be used by the SCIM interface.=A0 The =93externalId= =94 is referring to the fact that the id is maintained external to the SCIM server.=A0 As long as the server=92s ident= ifiers are stable and unique (which is mandated by the spec), I don=92t see= a problem.

=A0<= /p>

=A0<= /p>

> The secret is that=A0ev= ery value needs a key, and multi-valued attributes lack that. So our so= lution is quite

> simple - turn ever= y list or array (of values) into a dictionary (of key-value pairs) by provi= ding each value

> with a unique and = meaning-free identifier.

=A0<= /p>

I agree that this would b= e useful, especially in the PATCH operation.=A0 One reason that this wasn= =92t included in the spec originally is that it can put undue burden on the service provider.=A0 Many service providers are putting SCIM= interfaces in front of their existing identity stores (eg =96 directory se= rvers, SaaS application databases, etc=85).=A0 Many of these do not have a = unique identifier for multi-valued attributes.=A0 By requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.=A0 I believe this= would be a roadblock for many implementers.

=A0<= /p>

=A0<= /p>

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.<= u>

=A0<= /p>

I like the thoughts here.= =A0 Your example reminds me of unified diffs (http://en.wikipedi= a.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb). =A0However, the three proposals seem to largely hinge on= being able to uniquely address each element within an object.=A0 Without t= hese it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<= u>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

=A0<= /p>

=A0<= /p>

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model,= which is a form of tight coupling and could prove to be a source of brittl= eness.

=A0<= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

=A0<= /p>

Thanks again for your tho= ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

=A0

Hi,

=A0

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on Info= Q (http://www.infoq.com/minibooks/Identity-Management-Shoe= string).

=A0

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

=A0

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared = External ID, and this is the only ID that should be exposed through the API. The current specification's= provision of an id (which is the external ID and the only one to be transf= erred through the API) and an "external ID" (which is the client&= #39;s internal ID and should be hidden) is diametrically opposite to this.

=A0

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider w= hen the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will = be clumsy and inelegant.

=A0

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level=

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

=A0

To elaborate,

=A0

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.= e., when a resource is discovered to be more than one, or when multiple resources are detected to be the sam= e. If internal identifiers are revealed to external domains, such clean-ups= become difficult, hence every domain that wants to expose references to a = resource must map its internal ID to and external one created for this explicit purpose, and only reveal thi= s.

=A0

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the = external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated i= nternal ID of its own. In case the resource already has an identifier withi= n the enterprise client's domain, then this is the internal ID that mus= t be mapped to the external UUID returned through the POST response.

=A0

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 "john_smith@yahoo.com",

=A0 =A0 =A0 =A0 "john.smith@gmail.com",

=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"

=A0 =A0 ]

=A0

then on successful creation, the server response sho= uld include the representation of the resource, and this attribute should l= ook like this:

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 { "7dfcb444-74d8-4f17-aa66-daf9= ea3bd902" : "john_smith@yahoo.com" },

=A0 =A0 =A0 =A0 { "3bd10085-c474-43b9-9cda-8646= c3085bbf" : "john.smith@gmail.com" },

=A0 =A0 =A0 =A0 { "581da5c7-c6e1-4cca-9db7-7a6d= 1de664e1" : "jsmith1970@hotmail.com" }

=A0 =A0 ]

=A0

The client now knows what each value is labelled. Th= is now provides an unambiguous way to reference a value to add, modify and = delete it:

=A0

Add:

=A0

POST /Users/2819c223-7f76-453a-919d-413861904646/ema= il-addrs

value=3D"js70@easy.com.au"

=A0

Modify:

=A0

PUT /Users/2819c223-7f76-453a-919d-413861904646/emai= l-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

=A0

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

=A0

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs

=A0

I believe this is more elegant than what the spec re= commends.

=A0

3. It's possible to think of the operations POST= , PUT and DELETE as nested operations inside a PATCH. PATCH itself need not= be nested because its semantics apply throughout the "tree" of a= resource.

=A0

However, the semantics of PUT are a little messy. Al= so, the use of HTTP verbs at a different level could be confusing. That'= ;s why I would recommend 6 separate verbs that are a little more unambiguou= s in their meaning:

=A0

1. INCLUDE (equivalent to POST): Add this resource t= o a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this r= esource at the location specified by the accompanying URI. (If there=92s al= ready a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Repl= ace the value at the location specified by the accompanying URI with this v= alue. (If there=92s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This m= eans PLACE or REPLACE. (At the end of this operation, we want the specified= URI to hold the accompanying value whether the URI already existed or not.= )

5. RETIRE (equivalent to DELETE): Delete, deactivate= or otherwise render inaccessible the resource at the specified URI.=

6. AMEND (equivalent to PATCH): (This verb is just l= isted for completeness. We probably don=92t need a nested PATCH since PATCH= cascades to every level of the tree.)

=A0

A PATCH request could therefore look like this:

=A0

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HT= TP/1.1

Host: example.com

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

=A0

{

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs&= quot;,

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

}

=A0

The PATCH response should utilise the status code &q= uot;207 Multi-Status" because the nested operations could have varying= status codes. A sample response is below:

=A0

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

=A0

{

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

=A0 =A0 "external-id":"2819c223-7f76-= 453a-919d-413861904646",

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "status" : "201 Creat= ed",

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 11f664ec-898b-4f6f-8948-ecfda74deff0",

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

=A0 =A0 "meta": {

=A0 =A0 =A0 =A0 "created":"2011-08-08= T04:56:22Z",

=A0 =A0 =A0 =A0 "lastModified":"2011-= 08-08T08:00:12Z",

=A0 =A0 =A0 =A0 "version":"W\/\"= b431af54f0671a2\""

=A0 =A0 }

}

=A0

If there are errors, they will take the place of the= "200 OK" or "201 Created" status codes in the above su= ccessful case. But the outer status will remain "207 Multi-Status"= ;.

=A0

The same scheme can be used to deal with operations = on members of a group, and for bulk operations.

=A0

I hope you find these suggestions useful.<= /u>

=A0

I read the SCIM spec afresh last week and these idea= s came flooding into my head because I have been working at another organis= ation (a telco) for the last 5 months, also in Identity and Access Manageme= nt, and my thoughts have moved further along the direction of evolving a specialised data model based on specific= principles, especially for IAM.

=A0

I am planning to write about this and also the data-= related principles soon and am in negotiations with InfoQ regarding publica= tion.

=A0

Regards,

Ganesh Prasad


--0015175cd1303d697504c6cb3d3d-- From edreux@cloudiway.com Thu Aug 9 01:18:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CFF21F875C for ; Thu, 9 Aug 2012 01:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fzy1Xgn+eqA for ; Thu, 9 Aug 2012 01:18:29 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE721F8762 for ; Thu, 9 Aug 2012 01:18:28 -0700 (PDT) Received: from mail186-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 08:18:27 +0000 Received: from mail186-tx2 (localhost [127.0.0.1]) by mail186-tx2-R.bigfish.com (Postfix) with ESMTP id 3C3F24C0074; Thu, 9 Aug 2012 08:18:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT002.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bhc430Ic85dh1432I111aI1447Izz1202hzz1033IL122ac1I8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail186-tx2: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT002.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail186-tx2 (localhost.localdomain [127.0.0.1]) by mail186-tx2 (MessageSwitch) id 1344500294809456_12939; Thu, 9 Aug 2012 08:18:14 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.251]) by mail186-tx2.bigfish.com (Postfix) with ESMTP id BFAAC2C0278; Thu, 9 Aug 2012 08:18:14 +0000 (UTC) Received: from AMXPRD0610HT002.eurprd06.prod.outlook.com (157.56.248.213) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 08:18:13 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.209]) by AMXPRD0610HT002.eurprd06.prod.outlook.com ([10.255.58.37]) with mapi id 14.16.0175.005; Thu, 9 Aug 2012 08:18:09 +0000 From: Emmanuel Dreux To: Ganesh and Sashi Prasad , Kelly Grizzle Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNdc9EEa1zsm+4hki7VDEMm1eKgZdRIEpg Date: Thu, 9 Aug 2012 08:18:08 +0000 Message-ID: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.14.240.38] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD27416E0BAMXPRD0610MB353_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.248.213$sailpoint.com%0%1%cloudiway.com%False%False%0$ X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 08:18:48 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD27416E0BAMXPRD0610MB353_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the = translation table to determine the "primary" external ID for this entity in= Domain 2, which was decided to be "ff487230b3a0". That's where the "Primar= y flag" comes in. The second external ID "41206cc97c8b" is never used there= after in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domai= n 2 can be requested to delete the customer record identified by "41206cc97= c8b", and the second entry in the mapping table can be removed once this is= acknowledged. This scheme will scale up to multiple domains, because the "External Domain= ID" column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it wi= th all external domains? Tight coupling again. Just as OAuth allows an acce= ss token given to a third party to be invalidated without affecting the acc= ess of other third parties, the use of separate external identifiers for di= fferent domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entiti= es, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed= internally in each domain. Such a data model also allows us to choose asyn= chronous protocols for propagation of identity events, since there is no co= nsistency requirement to update multiple domains concurrently. Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle > wrote: Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" ] then on successful creation, the server response should include the represe= ntation of the resource, and this attribute should look like this: "email-addrs" : [ { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" }, { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" }, { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com<= mailto:jsmith1970@hotmail.com>" } ] The client now knows what each value is labelled. This now provides an unam= biguous way to reference a value to add, modify and delete it: Add: POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs value=3D"js70@easy.com.au" Modify: PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-4= 3b9-9cda-8646c3085bbf value=3D"john.r.smith@gmail.com" Delete: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e= 1-4cca-9db7-7a6d1de664e1 One can even delete all email addresses like this: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs I believe this is more elegant than what the spec recommends. 3. It's possible to think of the operations POST, PUT and DELETE as nested = operations inside a PATCH. PATCH itself need not be nested because its sema= ntics apply throughout the "tree" of a resource. However, the semantics of PUT are a little messy. Also, the use of HTTP ver= bs at a different level could be confusing. That's why I would recommend 6 = separate verbs that are a little more unambiguous in their meaning: 1. INCLUDE (equivalent to POST): Add this resource to a collection and retu= rn a generated URI 2. PLACE (equivalent to one form of PUT): Add this resource at the location= specified by the accompanying URI. (If there's already a value at that loc= ation, return an error status.) 3. REPLACE (equivalent to another form of PUT): Replace the value at the lo= cation specified by the accompanying URI with this value. (If there's no su= ch URI, return an error status.) 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. = (At the end of this operation, we want the specified URI to hold the accomp= anying value whether the URI already existed or not.) 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render in= accessible the resource at the specified URI. 6. AMEND (equivalent to PATCH): (This verb is just listed for completeness.= We probably don't need a nested PATCH since PATCH cascades to every level = of the tree.) A PATCH request could therefore look like this: PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Content-length: ... { REPLACE: { "key" : "first-name", "value" : "Jack" }, PLACE : { "key" : "middle-name", "value" : "Richard" }, FORCE : { "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "key" : "address.unit-number", "value" : "12" }, PLACE : { "key" : "address.state", "value" : "SA" }, FORCE : { "key" : "address.country", "value" : "Australia" }, INCLUDE : { "key" : "email-addrs", "value" : "js70@easy.com.au" }, REPLACE : { "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } } The PATCH response should utilise the status code "207 Multi-Status" becaus= e the nested operations could have varying status codes. A sample response = is below: HTTP/1.1 207 Multi-Status Content-Type: application/json ETag: W/"b431af54f0671a2" Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646= " { "schemas":["urn:scim:schemas:core:1.0"], "external-id":"2819c223-7f76-453a-919d-413861904646", REPLACE: { "status" : "200 OK", "key" : "first-name", "value" : "Jack" }, PLACE : { "status" : "200 OK", "key" : "middle-name", "value" : "Richard" }, FORCE : { "status" : "200 OK", "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "status" : "200 OK", "key" : "address.unit-number", "value" : "12" }, PLACE : { "status" : "200 OK", "key" : "address.state", "value" : "SA" }, FORCE : { "status" : "200 OK", "key" : "address.country", "value" : "Australia" }, INCLUDE : { "status" : "201 Created", "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", "value" : "js70@easy.com.au" }, REPLACE : { "status" : "200 OK", "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "status" : "200 OK", "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41= 3861904646", "version":"W\/\"b431af54f0671a2\"" } } If there are errors, they will take the place of the "200 OK" or "201 Creat= ed" status codes in the above successful case. But the outer status will re= main "207 Multi-Status". The same scheme can be used to deal with operations on members of a group, = and for bulk operations. I hope you find these suggestions useful. I read the SCIM spec afresh last week and these ideas came flooding into my= head because I have been working at another organisation (a telco) for the= last 5 months, also in Identity and Access Management, and my thoughts hav= e moved further along the direction of evolving a specialised data model ba= sed on specific principles, especially for IAM. I am planning to write about this and also the data-related principles soon= and am in negotiations with InfoQ regarding publication. Regards, Ganesh Prasad --_000_DF63ACC82673DB40A7AAC08FFA71DFBD27416E0BAMXPRD0610MB353_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ganesh,

 <= /p>

Nothing pr= events you in your SCIM implementation (client or server) to generate a uni= que identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).<= o:p>

 = ;

This is wh= at we are doing with Active Directory sources or targets:=

As we didn= ’t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) = are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids= . This fits your requirements as it hides internal ids.

 = ;

This was w= ritten in dotnet and we have started a project to rewrite our SCIM stack in= PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will = give the choice of “hiding” internalIDs or use them as unique I= D.

 = ;

You can al= so implement such feature without violating the SCIM specs, or without aski= ng to include it in the specs.

 = ;

--

Regards,

Emmanuel Dreux=

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

Tel: +33 4 26 78 17 5= 8

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 <= /p>

De : Gane= sh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi K= elly,

Than= ks for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.      Why should domains not expose their internal identi= fiers to other domains?

a.

We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notif= ication, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when “false negatives” and ̶= 0;false positives” are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones = and maintaining this mapping internally allows this loosely-coupled houseke= eping to take place. Sharing internal identifiers (or otherwise outsourcing= the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across= domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupl= ing.

2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to= provide a clean and elegant model to subsequent users of the spec, and thi= s will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both “SCIM-compliant” and “non-SCIM-com= pliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers = can be supported using a “non-SCIM-compliant” API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elab= oration of Point 1:

When= we consider federated identity across more than one domain, we have to ass= ume that domains are not necessarily master-slave in their interaction. The= most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domain= s (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate man= ner and at a time of their convenience.

A ke= y set of lifecycle events for an entity is the merging and splitting of ide= ntity that is often required.

The = question “Is this one entity?” can be answered either yes (posi= tive) or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Cons= ider a case where customers sign up online, and two customers who are priva= cy-conscious enter fake IDs such as “John Smith”, and also use = the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Cons= ider the opposite case where a customer signs up through two different port= als or in two different sessions, using the names “JSmith” and = “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can be= managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. F= alse positives:

Doma= in 1 has the following information about a customer in its data store:=

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: “John Smith”, dob: “01-Jan-1970”}

When= requesting the provisioning of this entity in Domain 2, the following ID i= s returned by Domain 2: ff487230b3a0.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag |=

| 9caf78aac= 3d6 | D2 | ff487230b3a0 | true |

When= the false positive is discovered and the entity is split, Domain 1 creates= a new internal identifier and now has the following entity information.

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: “John Smith”, dob: “01-Jan-1970”}

Inte= rnal ID: a99a5feba839

Attr= ibutes: {name: “John Smith”, dob: “01-Jan-1970”}

This= second entity with its own internal identifier is invisible to Domain 2, a= nd this is by design. Communication about the original entity takes place a= s before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (import= antly, this doesn't have to be at the time the split happens), Domain 2 can= be requested to provision a second entity, and when it responds with an id= entifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The = mapping table now contains the following entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag |=

| 9caf78aac= 3d6 | D2 | ff487230b3a0 | true |

| a99a5feba= 839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has ha= ppened, and the provisioning that it does is not in lockstep with the split= in identity that occurred in Domain 1.

(Wha= t is the “Primary flag” used for? We'll see when we cover the t= reatment of false negatives.)

b. F= alse negatives:

Doma= in 1 has the following information about what it thinks are two distinct cu= stomers in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: “JSmith”, dob: “01-Jan-1970”}

Inte= rnal ID: 273d36e30d09

Attr= ibutes: {name: “JohnS”, dob: “01-Jan-1970”}

When= requesting the provisioning of these entities in Domain 2, the following I= Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag |=

| 9caf78aac= 3d6 | D2 | ff487230b3a0 | true |

| 273d36e30= d09 | D2 | 41206cc97c8b | true |

When= the false negative is discovered and the two entities are merged, Domain 1= drops one of the internal identifiers and rationalises the name of the cus= tomer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the secon= d “273d36e30d09”.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag |=

| 9caf78aac= 3d6 | D2 | ff487230b3a0 | true |

| 9caf78aac= 3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound communica= tion from Domain 2 can be unambiguously translated to the same entity inter= nally. However, when going outwards, Domain 1 will have to look up the translation table to determine the ̶= 0;primary” external ID for this entity in Domain 2, which was decided= to be “ff487230b3a0”. That's where the “Primary flagR= 21; comes in. The second external ID “41206cc97c8b” is never us= ed thereafter in outbound communication.

At s= ome stage (importantly, not in lockstep with the identity merge), Domain 2 = can be requested to delete the customer record identified by “41206cc= 97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

This= scheme will scale up to multiple domains, because the “External Doma= in ID” column helps to keep track of which external ID is shared with= which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling ag= ain. Just as OAuth allows an access token given to a third party to be inva= lidated without affecting the access of other third parties, the use of sep= arate external identifiers for different domains allows fine-grained control of identity federation.)

The = scheme also allows the splitting of an entity into more than two entities, = and the merging of more than two entities into a single one. (Any organisat= ion with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)=

This= is a fairly long-winded explanation, but this is why we need to hide inter= nal identifiers from other domains, and why mappings need to be managed int= ernally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of i= dentity events, since there is no consistency requirement to update multipl= e domains concurrently.

Rega= rds,

Gane= sh Prasad

 

On 9 August 2012 04:55, Kelly Grizzle <kelly.grizzle@sailpo= int.com> wrote:

Thanks for the feedback,= Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limi= tations) and have some thoughts.

 

> The rest of the protocol= does not meaningfully use the enterprise client’s identifier, the &q= uot;external ID"

> at all, even thou= gh it was ostensibly introduced to make things friendlier for the client.

 

The usage pattern for an= external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.  For exampl= e:

 

GET /Users?filter=3Dexte= rnalId eq “bjensen”&attributes=3Did

 

{

  “totalResults”: 1,=

  “Resources”: [

    {

      “idR= 21;: “2819c223-7f76-453a-919d-413861904646”

    }

  ]

}

 

Retrieve the ID from the= response and use it.

 

DELETE /Users/2819c223-7= f76-453a-919d-413861904646

 

This does introduce an a= dditional HTTP request if the client chooses not to store the server’s id.  An issue was created to consider allowing operati= ons to use the externalId (http://code.g= oogle.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.  One main point of contention is that much of the rest of the spec= (eg – group membership references, manager references, etc…) r= equire knowledge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID = and the enterprise client's ID are both "Internal IDs" with respe= ct to their domains

 

I think this comes down = to a nomenclature problem.  The server’s ID does not necessarily have to be the unique identifier that the underlying identity store uses, = it just has to be stable and unique.  In many cases, the underlying id= entity store will provide identifiers with these properties already (eg = 211; a uuid) and it can be used by the SCIM interface.  The “externalId” is referring to the fact tha= t the id is maintained external to the SCIM server.  As long as the se= rver’s identifiers are stable and unique (which is mandated by the sp= ec), I don’t see a problem.

 

 

> The secret is that = every value needs a key, and multi-valued attributes lack that. So o= ur solution is quite

> simple - turn eve= ry list or array (of values) into a dictionary (of key-value pairs) by providing each value

> with a unique and= meaning-free identifier.

 

I agree that this would = be useful, especially in the PATCH operation.  One reason that this wasn’t included in the spec originally is that it can put undue= burden on the service provider.  Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg – direc= tory servers, SaaS application databases, etc…).  Many of these do not have a unique identifier for multi-valued attributes.=   By requiring this, a majority of the server providers would have to = start maintaining a unique key for each multi-valued attribute.  I bel= ieve this would be a roadblock for many implementers.

 

 

> When the SCIM protocol u= ses PATCH, there are areas where it seems a bit clumsy.

 

I like the thoughts here= .  Your example reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud= .info/specs/draft-scim-api-00.html#bulk-resources), however.

 

 

> There are other, non-dat= a aspects of SCIM which may require review, such as its synchronous request= -response

> interaction model= , which is a form of tight coupling and could prove to be a source of brittleness.

 

I agree that we should e= xplore optional asynchronous requests in 2.0.

 

Thanks again for your th= oughts.  I hope you stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, so= here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience i= n Identity and Access Management is mainly through a 3-year project at an A= ustralian insurance company, an experience I have written about as a eBook on InfoQ (http://www.info= q.com/minibooks/Identity-Management-Shoestring).

 

I have been following the SCIM spec off and o= n, and based on my experience with a loosely-coupled architecture that I fo= und to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provid= er should maintain their own internal IDs for a resource, which they should= not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the onl= y ID that should be exposed through the API. The current specification's pr= ovision of an id (which is the external ID and the only one to be transferr= ed through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diame= trically opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from an= array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Wit= hout unique keys for every attribute value of a resource, manipulating it w= ill be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 sig= nificant ways:

3a. Leverage the fact (from 2 above) that eve= ry value has a key, to greatly simplify the API

3b. Use special verbs as nested operations of= the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 M= ulti-Status" instead of "200 OK" as the response to a PATCH = (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form= of tight coupling. A major requirement with Identity Management is to spli= t (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to = be more than one, or when multiple resources are detected to be the same. I= f internal identifiers are revealed to external domains, such clean-ups bec= ome difficult, hence every domain that wants to expose references to a resource must map its internal ID to = and external one created for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client P= OSTs a resource creation request, the cloud provider must generate its own = internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location= :" header. The enterprise client should map this external UUID to a ne= wly-generated internal ID of its own. In case the resource already has an i= dentifier within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID retu= rned through the POST response.

 

2. If a resource is to be created, and one of= its attributes is multi-valued, e.g.,

 

    "email-addrs" : =

    [

        "john_smith@yahoo.com&quo= t;,

        "john.smith@gmail.com&quo= t;,

        "jsmith1970@hotmail.com= "

    ]

 

then on successful creation, the server respo= nse should include the representation of the resource, and this attribute s= hould look like this:

 

    "email-addrs" : =

    [

        { "7dfcb444-= 74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" },

        { "3bd10085-= c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" },

        { "581da5c7-= c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com" }

    ]

 

The client now knows what each value is label= led. This now provides an unambiguous way to reference a value to add, modi= fy and delete it:

 

Add:

 

POST /Users/2819c223-7f76-453a-919d-413861904= 646/email-addrs

value=3D"js70@easy.com.au"

 

Modify:

 

PUT /Users/2819c223-7f76-453a-919d-4138619046= 46/email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

 

Delete:

DELETE /Users/2819c223-7f76-453a-919d-4138619= 04646/email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

 

One can even delete all email addresses like = this:

DELETE /Users/2819c223-7f76-453a-919d-4138619= 04646/email-addrs

 

I believe this is more elegant than what the = spec recommends.

 

3. It's possible to think of the operations P= OST, PUT and DELETE as nested operations inside a PATCH. PATCH itself need = not be nested because its semantics apply throughout the "tree" of a resource.

 

However, the semantics of PUT are a little me= ssy. Also, the use of HTTP verbs at a different level could be confusing. T= hat's why I would recommend 6 separate verbs that are a little more unambiguous in their meaning:

 

1. INCLUDE (equivalent to POST): Add this res= ource to a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add= this resource at the location specified by the accompanying URI. (If there= ’s already a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT= ): Replace the value at the location specified by the accompanying URI with= this value. (If there’s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT):= This means PLACE or REPLACE. (At the end of this operation, we want the sp= ecified URI to hold the accompanying value whether the URI already existed or not.)

5. RETIRE (equivalent to DELETE): Delete, dea= ctivate or otherwise render inaccessible the resource at the specified URI.=

6. AMEND (equivalent to PATCH): (This verb is= just listed for completeness. We probably don’t need a nested PATCH = since PATCH cascades to every level of the tree.)

 

A PATCH request could therefore look like thi= s:

 

PATCH /Users/2819c223-7f76-453a-919d-41386190= 4646 HTTP/1.1

Host: example.com=

Accept: application/json

Authorization: Bearer h480djs93hd8=

Content-length: ...

 

{

    REPLACE: {

        "key" := "first-name",

        "value"= : "Jack"

    },

    PLACE : {

        "key" := "middle-name",

        "value"= : "Richard"

    },

    FORCE : {

        "key" := "dob",

        "value"= : "01-Jan-1971"

    },

    REPLACE : {

        "key" := "address.unit-number",

        "value"= : "12"

    },

    PLACE : {

        "key" := "address.state",

        "value"= : "SA"

    },

    FORCE : {

        "key" := "address.country",

        "value"= : "Australia"

    },

    INCLUDE : {

        "key" := "email-addrs",

        "value"= : "js70@easy.co= m.au"

    },

    REPLACE : {

        "key" := "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value"= : "john.r= .smith@gmail.com"

    },

    RETIRE : {

        "key" := "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

}

 

The PATCH response should utilise the status = code "207 Multi-Status" because the nested operations could have = varying status codes. A sample response is below:

 

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

 

{

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

    "external-id":"2= 819c223-7f76-453a-919d-413861904646",

    REPLACE: {

        "status"= ; : "200 OK",

        "key" := "first-name",

        "value"= : "Jack"

    },

    PLACE : {

        "status"= ; : "200 OK",

        "key" := "middle-name",

        "value"= : "Richard"

    },

    FORCE : {

        "status"= ; : "200 OK",

        "key" := "dob",

        "value"= : "01-Jan-1971"

    },

    REPLACE : {

        "status"= ; : "200 OK",

        "key" := "address.unit-number",

        "value"= : "12"

    },

    PLACE : {

        "status"= ; : "200 OK",

        "key" := "address.state",

        "value"= : "SA"

    },

    FORCE : {

        "status"= ; : "200 OK",

        "key" := "address.country",

        "value"= : "Australia"

    },

    INCLUDE : {

        "status"= ; : "201 Created",

        "key" := "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",

        "value"= : "js70@easy.co= m.au"

    },

    REPLACE : {

        "status"= ; : "200 OK",

        "key" := "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value"= : "john.r= .smith@gmail.com"

    },

    RETIRE : {

        "status"= ; : "200 OK",

        "key" := "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

    "meta": {<= /span>

        "created&quo= t;:"2011-08-08T04:56:22Z",

        "lastModifie= d":"2011-08-08T08:00:12Z",

        "version&quo= t;:"W\/\"b431af54f0671a2\""

    }

}

 

If there are errors, they will take the place= of the "200 OK" or "201 Created" status codes in the a= bove successful case. But the outer status will remain "207 Multi-Status".

 

The same scheme can be used to deal with oper= ations on members of a group, and for bulk operations.

 

I hope you find these suggestions useful.

 

I read the SCIM spec afresh last week and the= se ideas came flooding into my head because I have been working at another = organisation (a telco) for the last 5 months, also in Identity and Access Management, and my thoughts have moved= further along the direction of evolving a specialised data model based on = specific principles, especially for IAM.

 

I am planning to write about this and also th= e data-related principles soon and am in negotiations with InfoQ regarding = publication.

 

Regards,

Ganesh Prasad

 

--_000_DF63ACC82673DB40A7AAC08FFA71DFBD27416E0BAMXPRD0610MB353_-- From kelly.grizzle@sailpoint.com Thu Aug 9 07:28:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C2521F86C2 for ; Thu, 9 Aug 2012 07:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7RSc4jUWb9V for ; Thu, 9 Aug 2012 07:28:19 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADCD21F85F7 for ; Thu, 9 Aug 2012 07:28:19 -0700 (PDT) Received: from mail63-co1-R.bigfish.com (10.243.78.226) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 14:28:18 +0000 Received: from mail63-co1 (localhost [127.0.0.1]) by mail63-co1-R.bigfish.com (Postfix) with ESMTP id AA74E740088; Thu, 9 Aug 2012 14:28:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371Ic89bhc430Ic85dh1432I111aI1447Izz1202hzz1033IL122ac1I8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail63-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail63-co1 (localhost.localdomain [127.0.0.1]) by mail63-co1 (MessageSwitch) id 1344522495237811_28009; Thu, 9 Aug 2012 14:28:15 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.227]) by mail63-co1.bigfish.com (Postfix) with ESMTP id 303B0BC00DB; Thu, 9 Aug 2012 14:28:15 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 14:28:13 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0175.005; Thu, 9 Aug 2012 14:28:12 +0000 From: Kelly Grizzle To: Emmanuel Dreux , Ganesh and Sashi Prasad Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNcCv7gNwjoPnr4E2VDZsFNg+dnpdQQ4bAgAB6fACAAHCpAIAAZFlQ Date: Thu, 9 Aug 2012 14:28:11 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C343733024BFDBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:28:38 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C343733024BFDBY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can't ignore le= gacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emm= anuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the = translation table to determine the "primary" external ID for this entity in= Domain 2, which was decided to be "ff487230b3a0". That's where the "Primar= y flag" comes in. The second external ID "41206cc97c8b" is never used there= after in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domai= n 2 can be requested to delete the customer record identified by "41206cc97= c8b", and the second entry in the mapping table can be removed once this is= acknowledged. This scheme will scale up to multiple domains, because the "External Domain= ID" column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it wi= th all external domains? Tight coupling again. Just as OAuth allows an acce= ss token given to a third party to be invalidated without affecting the acc= ess of other third parties, the use of separate external identifiers for di= fferent domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entiti= es, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed= internally in each domain. Such a data model also allows us to choose asyn= chronous protocols for propagation of identity events, since there is no co= nsistency requirement to update multiple domains concurrently. Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle > wrote: Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" ] then on successful creation, the server response should include the represe= ntation of the resource, and this attribute should look like this: "email-addrs" : [ { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" }, { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" }, { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com<= mailto:jsmith1970@hotmail.com>" } ] The client now knows what each value is labelled. This now provides an unam= biguous way to reference a value to add, modify and delete it: Add: POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs value=3D"js70@easy.com.au" Modify: PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-4= 3b9-9cda-8646c3085bbf value=3D"john.r.smith@gmail.com" Delete: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e= 1-4cca-9db7-7a6d1de664e1 One can even delete all email addresses like this: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs I believe this is more elegant than what the spec recommends. 3. It's possible to think of the operations POST, PUT and DELETE as nested = operations inside a PATCH. PATCH itself need not be nested because its sema= ntics apply throughout the "tree" of a resource. However, the semantics of PUT are a little messy. Also, the use of HTTP ver= bs at a different level could be confusing. That's why I would recommend 6 = separate verbs that are a little more unambiguous in their meaning: 1. INCLUDE (equivalent to POST): Add this resource to a collection and retu= rn a generated URI 2. PLACE (equivalent to one form of PUT): Add this resource at the location= specified by the accompanying URI. (If there's already a value at that loc= ation, return an error status.) 3. REPLACE (equivalent to another form of PUT): Replace the value at the lo= cation specified by the accompanying URI with this value. (If there's no su= ch URI, return an error status.) 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. = (At the end of this operation, we want the specified URI to hold the accomp= anying value whether the URI already existed or not.) 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render in= accessible the resource at the specified URI. 6. AMEND (equivalent to PATCH): (This verb is just listed for completeness.= We probably don't need a nested PATCH since PATCH cascades to every level = of the tree.) A PATCH request could therefore look like this: PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Content-length: ... { REPLACE: { "key" : "first-name", "value" : "Jack" }, PLACE : { "key" : "middle-name", "value" : "Richard" }, FORCE : { "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "key" : "address.unit-number", "value" : "12" }, PLACE : { "key" : "address.state", "value" : "SA" }, FORCE : { "key" : "address.country", "value" : "Australia" }, INCLUDE : { "key" : "email-addrs", "value" : "js70@easy.com.au" }, REPLACE : { "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } } The PATCH response should utilise the status code "207 Multi-Status" becaus= e the nested operations could have varying status codes. A sample response = is below: HTTP/1.1 207 Multi-Status Content-Type: application/json ETag: W/"b431af54f0671a2" Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646= " { "schemas":["urn:scim:schemas:core:1.0"], "external-id":"2819c223-7f76-453a-919d-413861904646", REPLACE: { "status" : "200 OK", "key" : "first-name", "value" : "Jack" }, PLACE : { "status" : "200 OK", "key" : "middle-name", "value" : "Richard" }, FORCE : { "status" : "200 OK", "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "status" : "200 OK", "key" : "address.unit-number", "value" : "12" }, PLACE : { "status" : "200 OK", "key" : "address.state", "value" : "SA" }, FORCE : { "status" : "200 OK", "key" : "address.country", "value" : "Australia" }, INCLUDE : { "status" : "201 Created", "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", "value" : "js70@easy.com.au" }, REPLACE : { "status" : "200 OK", "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "status" : "200 OK", "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41= 3861904646", "version":"W\/\"b431af54f0671a2\"" } } If there are errors, they will take the place of the "200 OK" or "201 Creat= ed" status codes in the above successful case. But the outer status will re= main "207 Multi-Status". The same scheme can be used to deal with operations on members of a group, = and for bulk operations. I hope you find these suggestions useful. I read the SCIM spec afresh last week and these ideas came flooding into my= head because I have been working at another organisation (a telco) for the= last 5 months, also in Identity and Access Management, and my thoughts hav= e moved further along the direction of evolving a specialised data model ba= sed on specific principles, especially for IAM. I am planning to write about this and also the data-related principles soon= and am in negotiations with InfoQ regarding publication. Regards, Ganesh Prasad --_000_56C3C758F9D6534CA3778EAA1E0C343733024BFDBY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Emmanuel.  I = had started writing up a similar response.  As you suggest, storing th= is information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is ju= st a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains.

 <= /p>

You could also model thes= e ID mappings in the SCIM user as an extension but would probably not want = to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 <= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6     &= nbsp; | D2           = ;      | ff487230b3a0     = ;  | true         |=

| a99a5feba839     &= nbsp; | D2           = ;      | 7a87f27c1dd8     = ;  | true         |=

 

This could be represented= as two SCIM users that contain information about the entities on other dom= ains.

 <= /p>

{

  "schemas": ["urn:scim:s= chemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"= ;],

  "id": "9caf78aac3d6&quo= t;,

  "userName": "John Smith= ",

  "urn:scim:schemas:extension:feder= ation:1.0": {

    "linkedUsers": [=

      {

        &q= uot;domain": "D2",

        &q= uot;externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:s= chemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"= ;],

  "id": "a99a5feba839&quo= t;,

  "userName": "John Smith= ",

  "urn:scim:schemas:extension:feder= ation:1.0": {

    "linkedUsers": [=

      {

        &q= uot;domain": "D2",

        &q= uot;externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 <= /p>

In the second user, the l= inkedUsers attribute would be empty until the split user was synced to doma= in 2.

 <= /p>

 <= /p>

Similarly, the false nega= tive use case (merging two users) looked like this at the end:

 <= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6     &= nbsp; | D2           = ;      | ff487230b3a0     = ;  | true         |=

| 9caf78aac3d6     &= nbsp; | D2           = ;      | 41206cc97c8b     = ;  | false        |

 <= /p>

This could be represented= with the following SCIM user:

 <= /p>

{

  "schemas": ["urn:scim:s= chemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"= ;],

  "id": "9caf78aac3d6&quo= t;,

  "userName": "John Smith= ",

  "urn:scim:schemas:extension:feder= ation:1.0": {

    "linkedUsers": [=

      {

        &q= uot;domain": "D2",

        &q= uot;externalEntityId": "ff487230b3a0"

      },<= /span>

      {

        &q= uot;domain": "D2",

        &q= uot;externalEntityId": "41206cc97c8b",

        &q= uot;deletionRequired": true

      }

    ]

  }

}

 <= /p>

 <= /p>

Regarding unique identifi= ers for multi-valued attributes there is a trade-off involved.  On one= hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM,= a key goal has been to foster adoption by service providers by making thin= gs fit easily onto existing systems.  IMO the value gained by unique i= dentifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that v= endors that have a non-SCIM-compliant API will choose to keep things that w= ay if the spec is too hard for them to implement.  In a green field en= vironment we do have the luxury of mandating a model to make certain operations more elegant.  However, we canR= 17;t ignore legacy systems.

 <= /p>

--Kelly=

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in y= our SCIM implementation (client or server) to generate a unique identifier = for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).=

 <= /p>

This is what we are doing= with Active Directory sources or targets:

As we didn’t find a= n immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to = change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

 <= /p>

This was written in dotne= t and we have started a project to rewrite our SCIM stack in PHP and will g= ive it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice= of “hiding” internalIDs or use them as unique ID.

 <= /p>

You can also implement su= ch feature without violating the SCIM specs, or without asking to include i= t in the specs.

 <= /p>

--=

Regards,=

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 = 4 26 78 17 58

Mobile: += 33 6 47 81 26 70

skype: Emmanu= el.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi Kelly,

Thanks for your response. Let me first respond in brief to th= e two main points you have made, and then elaborate on the first.

1.   &nbs= p;  Why should domains not exp= ose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.<= /span>

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when “false negative= s” and “false positives” are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both “SCIM-compliant” and &= #8220;non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. L= egacy customers can be supported using a “non-SCIM-compliant” A= PI for an arbitrarily long period and gradually migrated to the SCIM-compli= ant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one doma= in, we have to assume that domains are not necessarily master-slave in thei= r interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are n= otified to other domains (when necessary) in an asynchronous manner (i.e., = through messaging) and the other domains are free to respond to these event= s in an appropriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is the merging an= d splitting of identity that is often required.

The question “Is this one entity?” can be answere= d either yes (positive) or no (negative). But sometimes, we can discover fa= lse positives and false negatives in our data stores.

Consider a case where customers sign up online, and two custo= mers who are privacy-conscious enter fake IDs such as “John SmithR= 21;, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelli= gent (but incorrect) guess that these two persons are the same, and re-assi= gn the same identifier to the second person. This is a false positive. They= appear to be the same entity, but they're actually different. When the error is discovered, the identities w= ill need to be split, with a new identifier generated for one of them.=

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names “= JSmith” and “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique id= entifiers. This is a false negative. They appear to be two entities, but ar= e actually the same. At a later stage, when the error is discovered, the id= entities will have to be merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's se= e how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing ext= ernal identifiers to other domains.

a. False positives:

Domain 1 has the following information about a customer in it= s data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-J= an-1970”}

When requesting the provisioning of this entity in Domain 2, = the following ID is returned by Domain 2: ff487230b3a0.

Domain 1 then maintains the following in a mapping table and = uses it for translation when talking to Domain 2, taking care never to expo= se its internal identifier:

| Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |<= /o:p>

When the false positive is discovered and the entity is split= , Domain 1 creates a new internal identifier and now has the following enti= ty information.

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-J= an-1970”}

Internal ID: a99a5feba839

Attributes: {name: “John Smith”, dob: “01-J= an-1970”}

This second entity with its own internal identifier is invisi= ble to Domain 2, and this is by design. Communication about the original en= tity takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. A= t some convenient time (importantly, this doesn't have to be at the time th= e split happens), Domain 2 can be requested to provision a second entity, a= nd when it responds with an identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the sec= ond entity's internal identifier.

The mapping table now contains the following entries:

| Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |<= /o:p>

| a99a5feba839 | D2 | 7a87f27c1dd8 | true |<= /o:p>

Domain 2 is not even aware that a = split has happened, and the provisioning that it does is not in lockstep wi= th the split in identity that occurred in Domain 1.

(What is the “Primary flag” used for? We'll see w= hen we cover the treatment of false negatives.)

b. False negatives:

Domain 1 has the following information about what it thinks a= re two distinct customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “JSmith”, dob: “01-Jan-1= 970”}

Internal ID: 273d36e30d09

Attributes: {name: “JohnS”, dob: “01-Jan-19= 70”}

When requesting the provisioning of these entities in Domain = 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8= b.

Domain 1 then maintains the following in a mapping table and = uses it for translation when talking to Domain 2, taking care never to expo= se its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |<= /o:p>

| 273d36e30d09 | D2 | 41206cc97c8b | true |<= /o:p>

When the false negative is discovered and the two entities ar= e merged, Domain 1 drops one of the internal identifiers and rationalises t= he name of the customer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6”= ; and drops the second “273d36e30d09”.

The mapping table now looks like this:

| Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |<= /o:p>

| 9caf78aac3d6 | D2 | 41206cc97c8b | false |=

Now two external identifiers map to the same internal one, so= inbound communication from Domain 2 can be unambiguously translated to the= same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to det= ermine the “primary” external ID for this entity in Domain 2, w= hich was decided to be “ff487230b3a0”. That's where the “= Primary flag” comes in. The second external ID “41206cc97c8b= 221; is never used thereafter in outbound communication.

At some stage (importantly, not in lockstep with the identity= merge), Domain 2 can be requested to delete the customer record identified= by “41206cc97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.<= /span>

This scheme will scale up to multiple domains, because the &#= 8220;External Domain ID” column helps to keep track of which external= ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains?= Tight coupling again. Just as OAuth allows an access token given to a thir= d party to be invalidated without affecting the access of other third parti= es, the use of separate external identifiers for different domains allows fine-grained control of identity = federation.)

The scheme also allows the splitting of an entity into more t= han two entities, and the merging of more than two entities into a single o= ne. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on = 1 Jan 1970!)

This is a fairly long-winded explanation, but this is why we = need to hide internal identifiers from other domains, and why mappings need= to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for prop= agation of identity events, since there is no consistency requirement to up= date multiple domains concurrently.

Regards,

Ganesh Prasad

 

On 9 August 2012 04:55, Kelly Griz= zle <ke= lly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ganesh.  = I read through this and your InfoQ article (http://www.= infoq.com/articles/scim-data-model-limitations 

> The rest of the protocol does not meani= ngfully use the enterprise client’s identifier, the "external ID= "

> at all, even though it was osten= sibly introduced to make things friendlier for the client.

 

The usage pattern for an external ID wo= uld be to search for a user by externalId and use the ID of the returned user in any desired operation.  For example:=

 

GET /Users?filter=3DexternalId eq ̶= 0;bjensen”&attributes=3Did

 

{

  “totalResults”: 1,

  “Resources”: [

    {

      “id”: “281= 9c223-7f76-453a-919d-413861904646”

    }

  ]

}

 

Retrieve the ID from the response and u= se it.

 

DELETE /Users/2819c223-7f76-453a-919d-4= 13861904646

 

This does introduce an additional HTTP = request if the client chooses not to store the server’s id.  An issue was created to consider allowing operations to use the externalId= (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.  One main point of contention is that much of the rest of the spec= (eg – group membership references, manager references, etc…) r= equire knowledge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterpr= ise client's ID are both "Internal IDs" with respect to their dom= ains

 

I think this comes down to a nomenclatu= re problem.  The server’s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just = has to be stable and unique.  In many cases, the underlying identity s= tore will provide identifiers with these properties already (eg – a u= uid) and it can be used by the SCIM interface.  The “externalId” is referring to the fact that the id is maint= ained external to the SCIM server.  As long as the server’s iden= tifiers are stable and unique (which is mandated by the spec), I don’= t see a problem.

 

 

> The secret is that every value = needs a key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or arra= y (of values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free i= dentifier.

 

I agree that this would be useful, espe= cially in the PATCH operation.  One reason that this wasn’t included in the spec originally is that it can put undue burden on the ser= vice provider.  Many service providers are putting SCIM interfaces in = front of their existing identity stores (eg – directory servers, SaaS= application databases, etc…).  Many of these do not have a unique identifier for multi-valued attributes.  By requ= iring this, a majority of the server providers would have to start maintain= ing a unique key for each multi-valued attribute.  I believe this woul= d be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.

 

I like the thoughts here.  Your ex= ample reminds me of unified diffs (http://en.wikipedia.org/wiki/= Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model, which is a fo= rm of tight coupling and could prove to be a source of brittleness.<= o:p>

 

I agree that we should explore optional= asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I= hope you stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

 

(I posted this on the SCIM Google Group, and I was advised to subs= cribe to the mailing list and post it here instead, so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience in Identity and Access= Management is mainly through a 3-year project at an Australian insurance c= ompany, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks= /Identity-Management-Shoestring).

 

I have been following the SCIM spec off and on, and based on my ex= perience with a loosely-coupled architecture that I found to be successful,= I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider should maintain th= eir own internal IDs for a resource, which they should not reveal to each o= ther. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should = be exposed through the API. The current specification's provision of an id = (which is the external ID and the only one to be transferred through the AP= I) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite t= o this.

 

2. When dealing with multi-valued attributes of a resource (expres= sed as arrays in JSON), they must be converted from an array into a diction= ary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys = for every attribute value of a resource, manipulating it will be clumsy and= inelegant.

 

3. The PATCH command can be improved in 3 significant ways:

3a. Leverage the fact (from 2 above) that every value has a key, t= o greatly simplify the API

3b. Use special verbs as nested operations of the PATCH command to= add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" ins= tead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tight coupling. A= major requirement with Identity Management is to split (or merge) identiti= es when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or = when multiple resources are detected to be the same. If internal identifier= s are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its internal ID to and external one crea= ted for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client POSTs a resource creat= ion request, the cloud provider must generate its own internal UUID as well= as an external UUID, map them together, and only return the external UUID in the "Location:" header. The= enterprise client should map this external UUID to a newly-generated inter= nal ID of its own. In case the resource already has an identifier within th= e enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through = the POST response.

 

2. If a resource is to be created, and one of its attributes is mu= lti-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

    ]

 

then on successful creation, the server response should include th= e representation of the resource, and this attribute should look like this:=

 

    "email-addrs" : 

    [

        { "7dfcb444-74d8-4f17-aa66-daf9ea= 3bd902" : "john_smith@yahoo.com" },

        { "3bd10085-c474-43b9-9cda-8646c3= 085bbf" : "john.smith@gmail.com" },

        { "581da5c7-c6e1-4cca-9db7-7a6d1d= e664e1" : "jsmith1970@hotmail.com" }

    ]

 

The client now knows what each value is labelled. This now provide= s an unambiguous way to reference a value to add, modify and delete it:

 

Add:

 

POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs<= /o:p>

value=3D"js70@easy.com.au"

 

Modify:

 

PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd100= 85-c474-43b9-9cda-8646c3085bbf

 

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581= da5c7-c6e1-4cca-9db7-7a6d1de664e1

 

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs

 

I believe this is more elegant than what the spec recommends.=

 

3. It's possible to think of the operations POST, PUT and DELETE a= s nested operations inside a PATCH. PATCH itself need not be nested because= its semantics apply throughout the "tree" of a resource.

 

However, the semantics of PUT are a little messy. Also, the use of= HTTP verbs at a different level could be confusing. That's why I would rec= ommend 6 separate verbs that are a little more unambiguous in their meaning:

 

1. INCLUDE (equivalent to POST): Add this resource to a collection= and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this resource at the= location specified by the accompanying URI. (If there’s already a va= lue at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Replace the value = at the location specified by the accompanying URI with this value. (If ther= e’s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This means PLACE or = REPLACE. (At the end of this operation, we want the specified URI to hold t= he accompanying value whether the URI already existed or not.)

5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise = render inaccessible the resource at the specified URI.

6. AMEND (equivalent to PATCH): (This verb is just listed for comp= leteness. We probably don’t need a nested PATCH since PATCH cascades = to every level of the tree.)

 

A PATCH request could therefore look like this:

 

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1

Host: example.com=

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

 

{

    REPLACE: {

        "key" : "first-name&quo= t;,

        "value" : "Jack"

    },

    PLACE : {

        "key" : "middle-name&qu= ot;,

        "value" : "Richard"= ;

    },

    FORCE : {

        "key" : "dob",

        "value" : "01-Jan-1971&= quot;

    },

    REPLACE : {

        "key" : "address.unit-n= umber",

        "value" : "12"

    },

    PLACE : {

        "key" : "address.state&= quot;,

        "value" : "SA"

    },

    FORCE : {

        "key" : "address.countr= y",

        "value" : "Australia&qu= ot;

    },

    INCLUDE : {

        "key" : "email-addrs&qu= ot;,

        "value" : "js70@easy.com.au"

    },

    REPLACE : {

        "key" : "email-addrs/3b= d10085-c474-43b9-9cda-8646c3085bbf",

        "value" : "john.r.smith@gmail.com&= quot;

    },

    RETIRE : {

        "key" : "email-addrs/58= 1da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

}

 

The PATCH response should utilise the status code "207 Multi-= Status" because the nested operations could have varying status codes.= A sample response is below:

 

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

 

{

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

    "external-id":"2819c223-7f76-453a-919= d-413861904646",

    REPLACE: {

        "status" : "200 OK"= ;,

        "key" : "first-name&quo= t;,

        "value" : "Jack"

    },

    PLACE : {

        "status" : "200 OK"= ;,

        "key" : "middle-name&qu= ot;,

        "value" : "Richard"= ;

    },

    FORCE : {

        "status" : "200 OK"= ;,

        "key" : "dob",

        "value" : "01-Jan-1971&= quot;

    },

    REPLACE : {

        "status" : "200 OK"= ;,

        "key" : "address.unit-n= umber",

        "value" : "12"

    },

    PLACE : {

        "status" : "200 OK"= ;,

        "key" : "address.state&= quot;,

        "value" : "SA"

    },

    FORCE : {

        "status" : "200 OK"= ;,

        "key" : "address.countr= y",

        "value" : "Australia&qu= ot;

    },

    INCLUDE : {

        "status" : "201 Created= ",

        "key" : "email-addrs/11= f664ec-898b-4f6f-8948-ecfda74deff0",

        "value" : "js70@easy.com.au"

    },

    REPLACE : {

        "status" : "200 OK"= ;,

        "key" : "email-addrs/3b= d10085-c474-43b9-9cda-8646c3085bbf",

        "value" : "john.r.smith@gmail.com&= quot;

    },

    RETIRE : {

        "status" : "200 OK"= ;,

        "key" : "email-addrs/58= 1da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

    "meta": {

        "created":"2011-08-08T0= 4:56:22Z",

        "lastModified":"2011-08= -08T08:00:12Z",

        "version":"W\/\"b4= 31af54f0671a2\""

    }

}

 

If there are errors, they will take the place of the "200 OK&= quot; or "201 Created" status codes in the above successful case.= But the outer status will remain "207 Multi-Status".<= /p>

 

The same scheme can be used to deal with operations on members of = a group, and for bulk operations.

 

I hope you find these suggestions useful.

 

I read the SCIM spec afresh last week and these ideas came floodin= g into my head because I have been working at another organisation (a telco= ) for the last 5 months, also in Identity and Access Management, and my thoughts have moved further along the direct= ion of evolving a specialised data model based on specific principles, espe= cially for IAM.

 

I am planning to write about this and also the data-related princi= ples soon and am in negotiations with InfoQ regarding publication.

 

Regards,

Ganesh Prasad

 

--_000_56C3C758F9D6534CA3778EAA1E0C343733024BFDBY2PRD0410MB354_-- From g.c.prasad@gmail.com Thu Aug 9 14:15:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACEE21F860F for ; Thu, 9 Aug 2012 14:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDoVP5mlN8MV for ; Thu, 9 Aug 2012 14:15:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 348EF21F8608 for ; Thu, 9 Aug 2012 14:15:16 -0700 (PDT) Received: by bkty7 with SMTP id y7so399918bkt.31 for ; Thu, 09 Aug 2012 14:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ylbrhp4AMiUgsbBOUr6f0dK6DECreV8w7k6onAVrVoI=; b=KvxwpCYdIS7dJXT7qXq6Emv+euMZsaV5ea0QvWeILl5LaphPFZg2UuBNWmH3eqpKXp E3nkT3B0oIy11Th3OKmIe12TN05u7vlJZaiRA3tK1n3faSBscFQ9tTdLjSfnyvx1fXfk Frfwq+5RBDZbOiqK2LeYbvDvo5eXVBQWvMgx2cqrrNs3ECDuIJUZfwiG/kOy+nqNbAra SX+y3aaDKL5BoEToMhy9eysZlt182holXIP2FBGWIUtKEpRIdt9hSPnP+DiqGT1B5Zpb +Pkanr3lt5dCLZspbAe65K7RJA+BoxhBBE3f0ZHTpXV/7IRqp6+7Gg4aXmS/i+thfzlF 7g3g== Received: by 10.204.10.70 with SMTP id o6mr360884bko.31.1344546915091; Thu, 09 Aug 2012 14:15:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Thu, 9 Aug 2012 14:14:54 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Fri, 10 Aug 2012 07:14:54 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015175cdb1a4204f204c6dbb98f Cc: "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:15:22 -0000 --0015175cdb1a4204f204c6dbb98f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution. Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I provided that example to illustrate that splitting and merging identities is a common requirement, and that decoupling local identifiers within a domain from shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight coupling. I would like to see a single identifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight coupling and ensures that both domains need simultaneously split or merge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their internal ids as part of the resource body, no one can stop them, and they can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrining the "external id" as an acceptable attribute. Am I making sense? > Regarding unique identifiers for multi-valued attributes there is a trade-off involved. On one hand this makes PATCH semantics easier. On the other hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interesting to hear from the other members of the spec mailing list. You know where I stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle wrote: > Thanks Emmanuel. I had started writing up a similar response. As you > suggest, storing this information in a mapping table outside of the SCIM > spec is a great way to enable this solution. Part of the key here is tha= t > SCIM is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains.**** > > ** ** > > You could also model these ID mappings in the SCIM user as an extension > but would probably not want to expose these externally. Here is an examp= le > of how to model the end state of the false positive scenario (splitting a > user):**** > > ** ** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true |**** > > | a99a5feba839 | D2 | 7a87f27c1dd8 | > true |**** > > ** ** > > This could be represented as two SCIM users that contain information abou= t > the entities on other domains.**** > > ** ** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "9caf78aac3d6",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "ff487230b3a0"**** > > }**** > > ]**** > > }**** > > }**** > > ** ** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "a99a5feba839",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "7a87f27c1dd8"**** > > }**** > > ]**** > > }**** > > }**** > > ** ** > > In the second user, the linkedUsers attribute would be empty until the > split user was synced to domain 2.**** > > ** ** > > ** ** > > Similarly, the false negative use case (merging two users) looked like > this at the end:**** > > ** ** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true |**** > > | 9caf78aac3d6 | D2 | 41206cc97c8b | > false |**** > > ** ** > > This could be represented with the following SCIM user:**** > > ** ** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "9caf78aac3d6",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "ff487230b3a0"**** > > },**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "41206cc97c8b",**** > > "deletionRequired": true**** > > }**** > > ]**** > > }**** > > }**** > > ** ** > > ** ** > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. Since the inceptio= n > of SCIM, a key goal has been to foster adoption by service providers by > making things fit easily onto existing systems. IMO the value gained by > unique identifiers for multi-valued attributes is not worth the demands p= ut > on a service provider. I also think that vendors that have a > non-SCIM-compliant API will choose to keep things that way if the spec is > too hard for them to implement. In a green field environment we do have > the luxury of mandating a model to make certain operations more elegant. > However, we can=92t ignore legacy systems. **** > > ** ** > > --Kelly**** > > ** ** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > ** ** > > Hi Ganesh,**** > > ** ** > > Nothing prevents you in your SCIM implementation (client or server) to > generate a unique identifier for each synchronized object and maintain an > internal mapping table ( you would have to map group membership as well).= * > *** > > ** ** > > This is what we are doing with Active Directory sources or targets:**** > > As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNam= e, > UPN) are subject to change (even objectGuid can change if an AD domain is > migrated), we decided to generate and maintain an internal table of ids. > This fits your requirements as it hides internal ids.**** > > ** ** > > This was written in dotnet and we have started a project to rewrite our > SCIM stack in PHP and will give it to the Open Source community. This > implementation will have a parameter : AllocateIds versus UseExistingIDs.= * > *** > > This will give the choice of =93hiding=94 internalIDs or use them as uniq= ue ID. > **** > > ** ** > > You can also implement such feature without violating the SCIM specs, or > without asking to include it in the specs.**** > > ** ** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > ** ** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > > *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > ** ** > > Hi Kelly,**** > > Thanks for your response. Let me first respond in brief to the two main > points you have made, and then elaborate on the first.**** > > **1. **Why should domains not expose their internal identifiers to > other domains?**** > > a.**** > > We are designing a protocol for a federated system of domains, where all > domains are co-equal peers. (In physics too, N-body problems are much > harder than 2-body problems. :-) Therefore, assuming that there are only > two players in the interaction makes this tightly coupled in a number of > ways. We should rely on messaging and notification, with encapsulation of > domain-specific data.**** > > b. **** > > In any non-trivial data store, there will always be the ongoing need to > merge and split identities as and when =93false negatives=94 and =93false > positives=94 are discovered. A domain should be able to handle this inter= nal > housekeeping freely, only notifying other domains when convenient. Mappin= g > of internal identifiers to external ones and maintaining this mapping > internally allows this loosely-coupled housekeeping to take place. Sharin= g > internal identifiers (or otherwise outsourcing the mapping of internal to > external identifiers) forces housekeeping activities to be done in > lock-step across domains.**** > > c.**** > > Asynchronous interaction is not just a matter of a suitable wire protocol > which can be designed later. The data model plays a crucial role in > enabling or constraining such interaction. A tightly-coupled data model > will force the use of synchronous interactions, and the exposure of > internal identifiers is a key part of this tight coupling.**** > > 2. The difficulty of assigning unique identifiers to the individual value= s > of multi-valued attributes:**** > > a. **** > > I'm not belittling the effort involved in migrating legacy data stores to > such a model. However, in the larger historical context of cross-domain > identity management, we are really at the very early stages. If a > relatively new discipline and a brand new spec are held captive to legacy > considerations, we are losing an opportunity to provide a clean and elega= nt > model to subsequent users of the spec, and this will have repercussions > over many years or even decades.**** > > b. **** > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can transitio= n > to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-compl= iant=94 > APIs to their customers and encouraging new customers to adopt the > =93SCIM-compliant=94 API. Legacy customers can be supported using a > =93non-SCIM-compliant=94 API for an arbitrarily long period and gradually > migrated to the SCIM-compliant API. The logistics are not insurmountable, > and shouldn't prevent the adoption of a dictionary model for multi-valued > attributes.**** > > Elaboration of Point 1:**** > > When we consider federated identity across more than one domain, we have > to assume that domains are not necessarily master-slave in their > interaction. The most generic interaction model is peer-to-peer, where > entity lifecycle events within a domain are notified to other domains (wh= en > necessary) in an asynchronous manner (i.e., through messaging) and the > other domains are free to respond to these events in an appropriate manne= r > and at a time of their convenience.**** > > A key set of lifecycle events for an entity is the merging and splitting > of identity that is often required.**** > > The question =93Is this one entity?=94 can be answered either yes (positi= ve) > or no (negative). But sometimes, we can discover false positives and fals= e > negatives in our data stores.**** > > Consider a case where customers sign up online, and two customers who are > privacy-conscious enter fake IDs such as =93John Smith=94, and also use t= he > same date of birth (say, 1 Jan 1970) or similar attributes. The front-end > application may make an intelligent (but incorrect) guess that these two > persons are the same, and re-assign the same identifier to the second > person. This is a false positive. They appear to be the same entity, but > they're actually different. When the error is discovered, the identities > will need to be split, with a new identifier generated for one of them.**= * > * > > Consider the opposite case where a customer signs up through two differen= t > portals or in two different sessions, using the names =93JSmith=94 and = =93JohnS=94. > It is very likely that they will be treated as two different customers an= d > assigned two unique identifiers. This is a false negative. They appear to > be two entities, but are actually the same. At a later stage, when the > error is discovered, the identities will have to be merged, and one of th= e > identifiers will have to be dropped.**** > > These are not theoretical use cases. They form a significant proportion o= f > the user base in most large Web-facing applications. Let's see how these > can be managed in a federated way by mapping internal identifiers to > external ones and only exposing external identifiers to other domains.***= * > > a. False positives:**** > > Domain 1 has the following information about a customer in its data store= : > **** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > When requesting the provisioning of this entity in Domain 2, the followin= g > ID is returned by Domain 2: ff487230b3a0.**** > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifier:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > When the false positive is discovered and the entity is split, Domain 1 > creates a new internal identifier and now has the following entity > information.**** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > Internal ID: a99a5feba839**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > This second entity with its own internal identifier is invisible to Domai= n > 2, and this is by design. Communication about the original entity takes > place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and v= ice-versa. > At some convenient time (importantly, this doesn't have to be at the time > the split happens), Domain 2 can be requested to provision a second entit= y, > and when it responds with an identifier of =937a87f27c1dd8=94, this can g= o into > the mapping table as a new record associated with the second entity's > internal identifier.**** > > The mapping table now contains the following entries:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** > > Domain 2 is not even aware that a split has happened, and the provisionin= g > that it does is not in lockstep with the split in identity that occurred = in > Domain 1.**** > > (What is the =93Primary flag=94 used for? We'll see when we cover the > treatment of false negatives.)**** > > b. False negatives:**** > > Domain 1 has the following information about what it thinks are two > distinct customers in its data store:**** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** > > Internal ID: 273d36e30d09**** > > Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** > > When requesting the provisioning of these entities in Domain 2, the > following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.***= * > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifiers:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | 273d36e30d09 | D2 | 41206cc97c8b | true |**** > > When the false negative is discovered and the two entities are merged, > Domain 1 drops one of the internal identifiers and rationalises the name = of > the customer (say, to =93John Smith=94). Let's say it retains the first I= D > =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** > > The mapping table now looks like this:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** > > Now two external identifiers map to the same internal one, so inbound > communication from Domain 2 can be unambiguously translated to the same > entity internally. However, when going outwards, Domain 1 will have to lo= ok > up the translation table to determine the =93primary=94 external ID for t= his > entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's wh= ere > the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never > used thereafter in outbound communication.**** > > At some stage (importantly, not in lockstep with the identity merge), > Domain 2 can be requested to delete the customer record identified by > =9341206cc97c8b=94, and the second entry in the mapping table can be remo= ved > once this is acknowledged.**** > > This scheme will scale up to multiple domains, because the =93External > Domain ID=94 column helps to keep track of which external ID is shared wi= th > which Domain. (Why don't we use just one external ID for an entity and > share it with all external domains? Tight coupling again. Just as OAuth > allows an access token given to a third party to be invalidated without > affecting the access of other third parties, the use of separate external > identifiers for different domains allows fine-grained control of identity > federation.)**** > > The scheme also allows the splitting of an entity into more than two > entities, and the merging of more than two entities into a single one. (A= ny > organisation with a web-facing application will tell you how many John > Smiths there are who were born on 1 Jan 1970!)**** > > This is a fairly long-winded explanation, but this is why we need to hide > internal identifiers from other domains, and why mappings need to be > managed internally in each domain. Such a data model also allows us to > choose asynchronous protocols for propagation of identity events, since > there is no consistency requirement to update multiple domains concurrent= ly. > **** > > Regards, **** > > Ganesh Prasad**** > > ** ** > > On 9 August 2012 04:55, Kelly Grizzle wrote= : > **** > > Thanks for the feedback, Ganesh. I read through this and your InfoQ > article (http://www.infoq.com/articles/scim-data-model-limitations) and > have some thoughts.**** > > **** > > > The rest of the protocol does not meaningfully use the enterprise > client=92s identifier, the "external ID"**** > > > at all, even though it was ostensibly introduced to make things > friendlier for the client.**** > > **** > > The usage pattern for an external ID would be to search for a user by > externalId and use the ID of the returned user in any desired operation. > For example:**** > > **** > > GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** > > **** > > {**** > > =93totalResults=94: 1,**** > > =93Resources=94: [**** > > {**** > > =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** > > }**** > > ]**** > > }**** > > **** > > Retrieve the ID from the response and use it.**** > > **** > > DELETE /Users/2819c223-7f76-453a-919d-413861904646**** > > **** > > This does introduce an additional HTTP request if the client chooses not > to store the server=92s id. An issue was created to consider allowing > operations to use the externalId ( > http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the > general consensus has been to not include this in the spec. One main poi= nt > of contention is that much of the rest of the spec (eg =96 group membersh= ip > references, manager references, etc=85) require knowledge of the server= =92s > identifier. Continuing this discussion on the IETF list would be a good > thing, though.**** > > **** > > **** > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains**** > > **** > > I think this comes down to a nomenclature problem. The server=92s ID doe= s > not necessarily have to be the unique identifier that the underlying > identity store uses, it just has to be stable and unique. In many cases, > the underlying identity store will provide identifiers with these > properties already (eg =96 a uuid) and it can be used by the SCIM interfa= ce. > The =93externalId=94 is referring to the fact that the id is maintained > external to the SCIM server. As long as the server=92s identifiers are > stable and unique (which is mandated by the spec), I don=92t see a proble= m.* > *** > > **** > > **** > > > The secret is that *every value needs a key*, and multi-valued > attributes lack that. So our solution is quite**** > > > simple - turn every list or array (of values) into a dictionary (of > key-value pairs) by providing each value**** > > > with a unique and meaning-free identifier.**** > > **** > > I agree that this would be useful, especially in the PATCH operation. On= e > reason that this wasn=92t included in the spec originally is that it can = put > undue burden on the service provider. Many service providers are putting > SCIM interfaces in front of their existing identity stores (eg =96 direct= ory > servers, SaaS application databases, etc=85). Many of these do not have = a > unique identifier for multi-valued attributes. By requiring this, a > majority of the server providers would have to start maintaining a unique > key for each multi-valued attribute. I believe this would be a roadblock > for many implementers.**** > > **** > > **** > > > When the SCIM protocol uses PATCH, there are areas where it seems a bit > clumsy.**** > > **** > > I like the thoughts here. Your example reminds me of unified diffs ( > http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly > used with a patch program (pretty much the equivalent of the PATCH verb). > However, the three proposals seem to largely hinge on being able to > uniquely address each element within an object. Without these it is not = so > easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or > provide a multi-status.**** > > > The 207 response would be interesting to consider for the bulk endpoint ( > http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however.**** > > **** > > **** > > > There are other, non-data aspects of SCIM which may require review, > such as its synchronous request-response**** > > > interaction model, which is a form of tight coupling and could prove to > be a source of brittleness.**** > > **** > > I agree that we should explore optional asynchronous requests in 2.0.**** > > **** > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward.**** > > **** > > --Kelly**** > > **** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** > > **** > > (I posted this on the SCIM Google Group, and I was advised to subscribe t= o > the mailing list and post it here instead, so here goes.)**** > > **** > > Hi,**** > > **** > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian insurance > company, an experience I have written about as a eBook on InfoQ ( > http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** > > **** > > I have been following the SCIM spec off and on, and based on my experienc= e > with a loosely-coupled architecture that I found to be successful, I have > the following 3 suggestions to make.**** > > **** > > 1. The enterprise client and the cloud provider should maintain their own > internal IDs for a resource, which they should not reveal to each other. > Both of them should map their internal IDs to a shared External ID, and > this is the only ID that should be exposed through the API. The current > specification's provision of an id (which is the external ID and the only > one to be transferred through the API) and an "external ID" (which is the > client's internal ID and should be hidden) is diametrically opposite to > this.**** > > **** > > 2. When dealing with multi-valued attributes of a resource (expressed as > arrays in JSON), they must be converted from an array into a dictionary > with unique keys (UUIDs generated by the cloud provider when the attribut= e > is created). Without unique keys for every attribute value of a resource, > manipulating it will be clumsy and inelegant.**** > > **** > > 3. The PATCH command can be improved in 3 significant ways:**** > > 3a. Leverage the fact (from 2 above) that every value has a key, to > greatly simplify the API**** > > 3b. Use special verbs as nested operations of the PATCH command to add, > modify and delete attributes at any level**** > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" > as the response to a PATCH (or BULK) command.**** > > **** > > To elaborate,**** > > **** > > 1. Revealing private IDs externally is a form of tight coupling. A major > requirement with Identity Management is to split (or merge) identities wh= en > false positives (or false negatives) are detected, i.e., when a resource = is > discovered to be more than one, or when multiple resources are detected t= o > be the same. If internal identifiers are revealed to external domains, su= ch > clean-ups become difficult, hence every domain that wants to expose > references to a resource must map its internal ID to and external one > created for this explicit purpose, and only reveal this.**** > > **** > > In the SCIM case, when an enterprise client POSTs a resource creation > request, the cloud provider must generate its own internal UUID as well a= s > an external UUID, map them together, and only return the external UUID in > the "Location:" header. The enterprise client should map this external UU= ID > to a newly-generated internal ID of its own. In case the resource already > has an identifier within the enterprise client's domain, then this is the > internal ID that must be mapped to the external UUID returned through the > POST response.**** > > **** > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g.,**** > > **** > > "email-addrs" : **** > > [**** > > "john_smith@yahoo.com",**** > > "john.smith@gmail.com",**** > > "jsmith1970@hotmail.com"**** > > ]**** > > **** > > then on successful creation, the server response should include the > representation of the resource, and this attribute should look like this:= * > *** > > **** > > "email-addrs" : **** > > [**** > > { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" > },**** > > { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" > },**** > > { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.co= m" > }**** > > ]**** > > **** > > The client now knows what each value is labelled. This now provides an > unambiguous way to reference a value to add, modify and delete it:**** > > **** > > Add:**** > > **** > > POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** > > value=3D"js70@easy.com.au"**** > > **** > > Modify:**** > > **** > > PUT > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43b= 9-9cda-8646c3085bbf > **** > > value=3D"john.r.smith@gmail.com"**** > > **** > > Delete:**** > > DELETE > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4cc= a-9db7-7a6d1de664e1 > **** > > **** > > One can even delete all email addresses like this:**** > > DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** > > **** > > I believe this is more elegant than what the spec recommends.**** > > **** > > 3. It's possible to think of the operations POST, PUT and DELETE as neste= d > operations inside a PATCH. PATCH itself need not be nested because its > semantics apply throughout the "tree" of a resource.**** > > **** > > However, the semantics of PUT are a little messy. Also, the use of HTTP > verbs at a different level could be confusing. That's why I would recomme= nd > 6 separate verbs that are a little more unambiguous in their meaning:**** > > **** > > 1. INCLUDE (equivalent to POST): Add this resource to a collection and > return a generated URI**** > > 2. PLACE (equivalent to one form of PUT): Add this resource at the > location specified by the accompanying URI. (If there=92s already a value= at > that location, return an error status.)**** > > 3. REPLACE (equivalent to another form of PUT): Replace the value at the > location specified by the accompanying URI with this value. (If there=92s= no > such URI, return an error status.)**** > > 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE= . > (At the end of this operation, we want the specified URI to hold the > accompanying value whether the URI already existed or not.)**** > > 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render > inaccessible the resource at the specified URI.**** > > 6. AMEND (equivalent to PATCH): (This verb is just listed for > completeness. We probably don=92t need a nested PATCH since PATCH cascade= s to > every level of the tree.)**** > > **** > > A PATCH request could therefore look like this:**** > > **** > > PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > Content-length: ...**** > > **** > > {**** > > REPLACE: {**** > > "key" : "first-name",**** > > "value" : "Jack"**** > > },**** > > PLACE : {**** > > "key" : "middle-name",**** > > "value" : "Richard"**** > > },**** > > FORCE : {**** > > "key" : "dob",**** > > "value" : "01-Jan-1971"**** > > },**** > > REPLACE : {**** > > "key" : "address.unit-number",**** > > "value" : "12"**** > > },**** > > PLACE : {**** > > "key" : "address.state",**** > > "value" : "SA"**** > > },**** > > FORCE : {**** > > "key" : "address.country",**** > > "value" : "Australia"**** > > },**** > > INCLUDE : {**** > > "key" : "email-addrs",**** > > "value" : "js70@easy.com.au"**** > > },**** > > REPLACE : {**** > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** > > "value" : "john.r.smith@gmail.com"**** > > },**** > > RETIRE : {**** > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** > > }**** > > }**** > > **** > > The PATCH response should utilise the status code "207 Multi-Status" > because the nested operations could have varying status codes. A sample > response is below:**** > > **** > > HTTP/1.1 207 Multi-Status**** > > Content-Type: application/json**** > > ETag: W/"b431af54f0671a2"**** > > Location:" > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646"**** > > **** > > {**** > > "schemas":["urn:scim:schemas:core:1.0"],**** > > "external-id":"2819c223-7f76-453a-919d-413861904646",**** > > REPLACE: {**** > > "status" : "200 OK",**** > > "key" : "first-name",**** > > "value" : "Jack"**** > > },**** > > PLACE : {**** > > "status" : "200 OK",**** > > "key" : "middle-name",**** > > "value" : "Richard"**** > > },**** > > FORCE : {**** > > "status" : "200 OK",**** > > "key" : "dob",**** > > "value" : "01-Jan-1971"**** > > },**** > > REPLACE : {**** > > "status" : "200 OK",**** > > "key" : "address.unit-number",**** > > "value" : "12"**** > > },**** > > PLACE : {**** > > "status" : "200 OK",**** > > "key" : "address.state",**** > > "value" : "SA"**** > > },**** > > FORCE : {**** > > "status" : "200 OK",**** > > "key" : "address.country",**** > > "value" : "Australia"**** > > },**** > > INCLUDE : {**** > > "status" : "201 Created",**** > > "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",**** > > "value" : "js70@easy.com.au"**** > > },**** > > REPLACE : {**** > > "status" : "200 OK",**** > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** > > "value" : "john.r.smith@gmail.com"**** > > },**** > > RETIRE : {**** > > "status" : "200 OK",**** > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** > > }**** > > "meta": {**** > > "created":"2011-08-08T04:56:22Z",**** > > "lastModified":"2011-08-08T08:00:12Z",**** > > "location":" > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",**** > > "version":"W\/\"b431af54f0671a2\""**** > > }**** > > }**** > > **** > > If there are errors, they will take the place of the "200 OK" or "201 > Created" status codes in the above successful case. But the outer status > will remain "207 Multi-Status".**** > > **** > > The same scheme can be used to deal with operations on members of a group= , > and for bulk operations.**** > > **** > > I hope you find these suggestions useful.**** > > **** > > I read the SCIM spec afresh last week and these ideas came flooding into > my head because I have been working at another organisation (a telco) for > the last 5 months, also in Identity and Access Management, and my thought= s > have moved further along the direction of evolving a specialised data mod= el > based on specific principles, especially for IAM.**** > > **** > > I am planning to write about this and also the data-related principles > soon and am in negotiations with InfoQ regarding publication.**** > > **** > > Regards,**** > > Ganesh Prasad**** > > ** ** > --0015175cdb1a4204f204c6dbb98f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 storing this information in a mapping table outside of the SCIM spe= c is a great way to enable this solution.=A0 Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only resp= onsible for the transport layer between domains.=A0

I wasn't suggesting that the mapping table be part of the SCIM spec= . I provided that example to illustrate that splitting and merging identiti= es is a common requirement, and that decoupling local identifiers within a = domain from shared identifiers between domains was the best way to facilita= te it.

I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do th= ere is just refrain from introducing tight coupling. I would like to see a = single identifier exposed through the API, with the implication (and perhap= s the recommendation) that it be the shared one. Allowing one domain to exp= ose its internal identifier to the other creates tight coupling and ensures= that both domains need simultaneously split or merge identities, which is = not desirable. So I recommend _taking out_ the "external id" fiel= d from the API. The spec shouldn't encourage tight coupling. If clients= want to pass in their internal ids as part of the resource body, no one ca= n stop them, and they can always do a search on that attribute to retrieve = the URI exactly as you visualise they will with the "external id"= , but let's not elevate an anti-pattern to a recommendation by enshrini= ng the "external id" as an acceptable attribute.

Am I making sense?

>=A0 Regarding unique identifiers for multi-valued attributes there is a= trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O= n the other hand it puts extra burden on service providers.=A0

Precisely. The spec has to strike the right balance. It would be i= nteresting to hear from the other members of the spec mailing list. You kno= w where I stand on this. It would be good to hear the spectrum of opinions.=

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emmanuel.=A0 I had= started writing up a similar response.=A0 As you suggest, storing this inf= ormation in a mapping table outside of the SCIM spec is a great way to enable this solution.=A0 Part of the key here is that SCIM is just = a piece of the architecture for this solution, and is only responsible for = the transport layer between domains.

=A0<= /p>

You could also model thes= e ID mappings in the SCIM user as an extension but would probably not want = to expose these externally.=A0 Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /u>

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0

This could be repre= sented as two SCIM users that contain information about the entities on oth= er domains.

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "a99a5feba839",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "7a87f27c1dd8"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

In the second user, the l= inkedUsers attribute would be empty until the split user was synced to doma= in 2.

=A0<= /p>

=A0<= /p>

Similarly, the false nega= tive use case (merging two users) looked like this at the end:

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0= | false=A0=A0=A0=A0=A0=A0=A0 |

=A0<= /p>

This could be repre= sented with the following SCIM user:

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 },

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "41206cc97c8b",

=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&= quot;: true

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

=A0<= /p>

Regarding unique identifi= ers for multi-valued attributes there is a trade-off involved.=A0 On one ha= nd this makes PATCH semantics easier.=A0 On the other hand it puts extra burden on service providers.=A0 Since the inception of SCIM, a = key goal has been to foster adoption by service providers by making things = fit easily onto existing systems.=A0 IMO the value gained by unique identif= iers for multi-valued attributes is not worth the demands put on a service provider.=A0 I also think that vend= ors that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement.=A0 In a green field environm= ent we do have the luxury of mandating a model to make certain operations more elegant.=A0 However, we can=92t ig= nore legacy systems.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

Hi Ganesh,=

=A0=

Nothing prevents you in y= our SCIM implementation (client or server) to generate a unique identifier = for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

=A0<= /p>

This is what we are doing= with Active Directory sources or targets:

As we didn=92t find an im= mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan= ge (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

=A0<= /p>

This was written in dotne= t and we have started a project to rewrite our SCIM stack in PHP and will g= ive it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice= of =93hiding=94 internalIDs or use them as unique ID.=

=A0<= /p>

You can also implement su= ch feature without violating the SCIM specs, or without asking to include i= t in the specs.

=A0<= /p>

--<= /u>

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org
Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Hi K= elly,

Than= ks for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.=A0=A0=A0=A0=A0 Why should domains not expose= their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating l= egacy data stores to such a model. However, in the larger historical contex= t of cross-domain identity management, we are really at the very early stag= es. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.=

Elab= oration of Point 1:

When= we consider federated identity across more than one domain, we have to ass= ume that domains are not necessarily master-slave in their interaction. The= most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are n= otified to other domains (when necessary) in an asynchronous manner (i.e., = through messaging) and the other domains are free to respond to these event= s in an appropriate manner and at a time of their convenience.

A ke= y set of lifecycle events for an entity is the merging and splitting of ide= ntity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores.

Cons= ider a case where customers sign up online, and two customers who are priva= cy-conscious enter fake IDs such as =93John Smith=94, and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelli= gent (but incorrect) guess that these two persons are the same, and re-assi= gn the same identifier to the second person. This is a false positive. They= appear to be the same entity, but they're actually different. When the error is discovered, the identiti= es will need to be split, with a new identifier generated for one of them.<= u>

Cons= ider the opposite case where a customer signs up through two different port= als or in two different sessions, using the names =93JSmith=94 and =93JohnS= =94. It is very likely that they will be treated as two different customers and assigned two unique id= entifiers. This is a false negative. They appear to be two entities, but ar= e actually the same. At a later stage, when the error is discovered, the id= entities will have to be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external ones and only exposing ext= ernal identifiers to other domains.

a. F= alse positives:

Doma= in 1 has the following information about a customer in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of this entity in Domain 2, the following ID i= s returned by Domain 2: ff487230b3a0.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifier:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

When= the false positive is discovered and the entity is split, Domain 1 creates= a new internal identifier and now has the following entity information.=

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: a99a5feba839

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

This= second entity with its own internal identifier is invisible to Domain 2, a= nd this is by design. Communication about the original entity takes place a= s before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien= t time (importantly, this doesn't have to be at the time the split happ= ens), Domain 2 can be requested to provision a second entity, and when it r= esponds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the sec= ond entity's internal identifier.

The = mapping table now contains the following entries:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| a99a5feba839 | = D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened= , and the provisioning that it does is not in lockstep with the split in id= entity that occurred in Domain 1.

(Wha= t is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.)

b. F= alse negatives:

Doma= in 1 has the following information about what it thinks are two distinct cu= stomers in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: 273d36e30d09

Attr= ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of these entities in Domain 2, the following I= Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifiers:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 273d36e30d09 | = D2 | 41206cc97c8b | true |

When= the false negative is discovered and the two entities are merged, Domain 1= drops one of the internal identifiers and rationalises the name of the cus= tomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr= ops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | = D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound communica= tion from Domain 2 can be unambiguously translated to the same entity inter= nally. However, when going outwards, Domain 1 will have to look up the translation table to det= ermine the =93primary=94 external ID for this entity in Domain 2, which was= decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 = comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound communication.

At s= ome stage (importantly, not in lockstep with the identity merge), Domain 2 = can be requested to delete the customer record identified by =9341206cc97c8= b=94, and the second entry in the mapping table can be removed once this is acknowledged.

This= scheme will scale up to multiple domains, because the =93External Domain I= D=94 column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it with all external domains?= Tight coupling again. Just as OAuth allows an access token given to a thir= d party to be invalidated without affecting the access of other third parti= es, the use of separate external identifiers for different domains allows fine-grained control of identity = federation.)

The = scheme also allows the splitting of an entity into more than two entities, = and the merging of more than two entities into a single one. (Any organisat= ion with a web-facing application will tell you how many John Smiths there are who were born on = 1 Jan 1970!)

This= is a fairly long-winded explanation, but this is why we need to hide inter= nal identifiers from other domains, and why mappings need to be managed int= ernally in each domain. Such a data model also allows us to choose asynchronous protocols for prop= agation of identity events, since there is no consistency requirement to up= date multiple domains concurrently.

Rega= rds,

Gane= sh Prasad

=A0

On 9 August 2012 04:55, Kelly Griz= zle <ke= lly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, = Ganesh.=A0 I read through this and your InfoQ article (= http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

=A0<= /p>

> The rest of the protocol does not meani= ngfully use the enterprise client=92s identifier, the "external ID&quo= t;

> at all, even thoug= h it was ostensibly introduced to make things friendlier for the client.

=A0<= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.=A0 For example:<= u>

=A0<= /p>

GET /Users?filter=3Dexter= nalId eq =93bjensen=94&attributes=3Did

=A0<= /p>

{

=A0 =93totalResults=94: 1,

=A0 =93Resources=94: [

=A0=A0=A0 {

=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45= 3a-919d-413861904646=94

=A0=A0=A0 }

=A0 ]

}

=A0<= /p>

Retrieve the ID from the = response and use it.

=A0<= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

=A0<= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server=92s id.= =A0 An issue was created to consider allowing operations to use the externalId= (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.=A0 One main point of contention is that much of the rest of the spec (e= g =96 group membership references, manager references, etc=85) require know= ledge of the server=92s identifier.=A0 Continuing this discussion on the IETF list would be a good thing, though.<= /u>

=A0<= /p>

=A0<= /p>

> the cloud provider's ID and the ent= erprise client's ID are both "Internal IDs" with respect to t= heir domains

=A0<= /p>

I think this comes down t= o a nomenclature problem.=A0 The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just = has to be stable and unique.=A0 In many cases, the underlying identity stor= e will provide identifiers with these properties already (eg =96 a uuid) an= d it can be used by the SCIM interface.=A0 The =93externalId=94 is referring to the fact that the id is maintained ex= ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta= ble and unique (which is mandated by the spec), I don=92t see a problem.

=A0<= /p>

=A0<= /p>

> The secret is that=A0every value nee= ds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn ever= y list or array (of values) into a dictionary (of key-value pairs) by provi= ding each value

> with a unique and = meaning-free identifier.

=A0<= /p>

I agree that this would b= e useful, especially in the PATCH operation.=A0 One reason that this wasn= =92t included in the spec originally is that it can put undue burden on the ser= vice provider.=A0 Many service providers are putting SCIM interfaces in fro= nt of their existing identity stores (eg =96 directory servers, SaaS applic= ation databases, etc=85).=A0 Many of these do not have a unique identifier for multi-valued attributes.=A0 By requiri= ng this, a majority of the server providers would have to start maintaining= a unique key for each multi-valued attribute.=A0 I believe this would be a= roadblock for many implementers.

=A0<= /p>

=A0<= /p>

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.

=A0<= /p>

I like the thoughts here.= =A0 Your example reminds me of unified diffs (http://en.wikipedi= a.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb). =A0However, the three proposals seem to largely hinge on= being able to uniquely address each element within an object.=A0 Without t= hese it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<= /span>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

=A0<= /p>

=A0<= /p>

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model,= which is a form of tight coupling and could prove to be a source of brittl= eness.

=A0<= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

=A0<= /p>

Thanks again for your tho= ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

=A0

Hi,

=A0

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks= /Identity-Management-Shoestring).

=A0

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

=A0

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should = be exposed through the API. The current specification's provision of an= id (which is the external ID and the only one to be transferred through th= e API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposi= te to this.

=A0

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys = for every attribute value of a resource, manipulating it will be clumsy and= inelegant.

=A0

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level=

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

=A0

To elaborate,

=A0

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or = when multiple resources are detected to be the same. If internal identifier= s are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its internal ID to and external one crea= ted for this explicit purpose, and only reveal this.

=A0

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The= enterprise client should map this external UUID to a newly-generated inter= nal ID of its own. In case the resource already has an identifier within th= e enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through = the POST response.

=A0

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 "john_smith@yahoo.com",

=A0 =A0 =A0 =A0 "john.smith@gmail.com",

=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"

=A0 =A0 ]

=A0

then on successful creation, the server response sho= uld include the representation of the resource, and this attribute should l= ook like this:

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 { "7dfcb444-74d8-4f17-aa66-daf9= ea3bd902" : "john_smith@yahoo.com" },

=A0 =A0 =A0 =A0 { "3bd10085-c474-43b9-9cda-8646= c3085bbf" : "john.smith@gmail.com" },

=A0 =A0 =A0 =A0 { "581da5c7-c6e1-4cca-9db7-7a6d= 1de664e1" : "jsmith1970@hotmail.com" }

=A0 =A0 ]

=A0

The client now knows what each value is labelled. Th= is now provides an unambiguous way to reference a value to add, modify and = delete it:

=A0

Add:

=A0

POST /Users/2819c223-7f76-453a-919d-413861904646/ema= il-addrs

value=3D"js70@easy.com.au"

=A0

Modify:

=A0

PUT /Users/2819c223-7f76-453a-919d-413861904646/emai= l-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

=A0

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

=A0

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs

=A0

I believe this is more elegant than what the spec re= commends.

=A0

3. It's possible to think of the operations POST= , PUT and DELETE as nested operations inside a PATCH. PATCH itself need not= be nested because its semantics apply throughout the "tree" of a resource.

=A0

However, the semantics of PUT are a little messy. Al= so, the use of HTTP verbs at a different level could be confusing. That'= ;s why I would recommend 6 separate verbs that are a little more unambiguous in their meaning:

=A0

1. INCLUDE (equivalent to POST): Add this resource t= o a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this r= esource at the location specified by the accompanying URI. (If there=92s al= ready a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Repl= ace the value at the location specified by the accompanying URI with this v= alue. (If there=92s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This m= eans PLACE or REPLACE. (At the end of this operation, we want the specified= URI to hold the accompanying value whether the URI already existed or not.)

5. RETIRE (equivalent to DELETE): Delete, deactivate= or otherwise render inaccessible the resource at the specified URI.=

6. AMEND (equivalent to PATCH): (This verb is just l= isted for completeness. We probably don=92t need a nested PATCH since PATCH= cascades to every level of the tree.)

=A0

A PATCH request could therefore look like this:

=A0

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HT= TP/1.1

Host: example.com<= /u>

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

=A0

{

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs&= quot;,

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

}

=A0

The PATCH response should utilise the status code &q= uot;207 Multi-Status" because the nested operations could have varying= status codes. A sample response is below:

=A0

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

=A0

{

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

=A0 =A0 "external-id":"2819c223-7f76-= 453a-919d-413861904646",

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "status" : "201 Creat= ed",

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 11f664ec-898b-4f6f-8948-ecfda74deff0",

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

=A0 =A0 "meta": {

=A0 =A0 =A0 =A0 "created":"2011-08-08= T04:56:22Z",

=A0 =A0 =A0 =A0 "lastModified":"2011-= 08-08T08:00:12Z",

=A0 =A0 =A0 =A0 "version":"W\/\"= b431af54f0671a2\""

=A0 =A0 }

}

=A0

If there are errors, they will take the place of the= "200 OK" or "201 Created" status codes in the above su= ccessful case. But the outer status will remain "207 Multi-Status"= ;.

=A0

The same scheme can be used to deal with operations = on members of a group, and for bulk operations.

=A0

I hope you find these suggestions useful.<= /u>

=A0

I read the SCIM spec afresh last week and these idea= s came flooding into my head because I have been working at another organis= ation (a telco) for the last 5 months, also in Identity and Access Management, and my thoughts have moved further along the direct= ion of evolving a specialised data model based on specific principles, espe= cially for IAM.

=A0

I am planning to write about this and also the data-= related principles soon and am in negotiations with InfoQ regarding publica= tion.

=A0

Regards,

Ganesh Prasad

=A0


--0015175cdb1a4204f204c6dbb98f-- From g.c.prasad@gmail.com Thu Aug 9 14:25:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34FB21F85F7 for ; Thu, 9 Aug 2012 14:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihu87Ft7coJU for ; Thu, 9 Aug 2012 14:25:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1D21F8527 for ; Thu, 9 Aug 2012 14:25:30 -0700 (PDT) Received: by bkty7 with SMTP id y7so402718bkt.31 for ; Thu, 09 Aug 2012 14:25: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:from:date:message-id:subject:to :cc:content-type; bh=M4IU1WMTg1KBRhpRJOfehJ/Qr1txNfnNSj+Tj42A3Ro=; b=ga013fRTkiTrFjcOzLcNX8OssxSINhaa3X/tvnyG0fxAJHe5fDNp1ZonLwDsyGjCxr HDgufJCSnvFNaJRQiPNkZV0x53UZ9Ne4CjX3wfKVrp+yNDYZyCP5ce0QGSk3cvtxJxmu JcEfOVXSzx0jrVpYG/oCPZ/nQ/REG1sCUBfbOyUL1/kWXzPH21mVm+7soTDhJ9zXalUZ kgGNlUsjhQBrNcOmDrRd2lp32xH0Qxc6xE6KdLqklPM6PYyi9Ej2Rk5UevSnHnKRL3pK eg0P2axNQYOPr7j8vUQQMfm0kvGqx3Co1zlL5cZx2Bm9Fu7I3EAp0o+AJ0K5T4n7T3gp 0kQA== Received: by 10.205.127.131 with SMTP id ha3mr307889bkc.123.1344547529167; Thu, 09 Aug 2012 14:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Thu, 9 Aug 2012 14:25:08 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Fri, 10 Aug 2012 07:25:08 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015173fe4acdc13cb04c6dbddc3 Cc: "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:25:35 -0000 --0015173fe4acdc13cb04c6dbddc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > It would be interesting to hear from the other members of the spec mailing list. It would be good if members also state their affiliations when they post their opinions (e.g., cloud service provider, ISV, enterprise customer, etc.) For the record, I'm an architect currently contracting with a telco that is an enterprise customer of cloud services. Regards, Ganesh On 10 August 2012 07:14, Ganesh and Sashi Prasad wrot= e: > > storing this information in a mapping table outside of the SCIM spec > is a great way to enable this solution. Part of the key here is that SCI= M > is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains. > > I wasn't suggesting that the mapping table be part of the SCIM spec. I > provided that example to illustrate that splitting and merging identities > is a common requirement, and that decoupling local identifiers within a > domain from shared identifiers between domains was the best way to > facilitate it. > > I'm suggesting that the spec do less, not more. > > What the SCIM spec needs to do there is just refrain from introducing > tight coupling. I would like to see a single identifier exposed through t= he > API, with the implication (and perhaps the recommendation) that it be the > shared one. Allowing one domain to expose its internal identifier to the > other creates tight coupling and ensures that both domains need > simultaneously split or merge identities, which is not desirable. So I > recommend _taking out_ the "external id" field from the API. The spec > shouldn't encourage tight coupling. If clients want to pass in their > internal ids as part of the resource body, no one can stop them, and they > can always do a search on that attribute to retrieve the URI exactly as y= ou > visualise they will with the "external id", but let's not elevate an > anti-pattern to a recommendation by enshrining the "external id" as an > acceptable attribute. > > Am I making sense? > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. You > know where I stand on this. It would be good to hear the spectrum of > opinions. > > Regards, > Ganesh > > > On 10 August 2012 00:28, Kelly Grizzle wrote= : > >> Thanks Emmanuel. I had started writing up a similar response. As you >> suggest, storing this information in a mapping table outside of the SCIM >> spec is a great way to enable this solution. Part of the key here is th= at >> SCIM is just a piece of the architecture for this solution, and is only >> responsible for the transport layer between domains.**** >> >> ** ** >> >> You could also model these ID mappings in the SCIM user as an extension >> but would probably not want to expose these externally. Here is an exam= ple >> of how to model the end state of the false positive scenario (splitting = a >> user):**** >> >> ** ** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true |**** >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | >> true |**** >> >> ** ** >> >> This could be represented as two SCIM users that contain information >> about the entities on other domains.**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "9caf78aac3d6",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "ff487230b3a0"**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "a99a5feba839",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "7a87f27c1dd8"**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> In the second user, the linkedUsers attribute would be empty until the >> split user was synced to domain 2.**** >> >> ** ** >> >> ** ** >> >> Similarly, the false negative use case (merging two users) looked like >> this at the end:**** >> >> ** ** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true |**** >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | >> false |**** >> >> ** ** >> >> This could be represented with the following SCIM user:**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "9caf78aac3d6",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "ff487230b3a0"**** >> >> },**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "41206cc97c8b",**** >> >> "deletionRequired": true**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> ** ** >> >> Regarding unique identifiers for multi-valued attributes there is a >> trade-off involved. On one hand this makes PATCH semantics easier. On = the >> other hand it puts extra burden on service providers. Since the incepti= on >> of SCIM, a key goal has been to foster adoption by service providers by >> making things fit easily onto existing systems. IMO the value gained by >> unique identifiers for multi-valued attributes is not worth the demands = put >> on a service provider. I also think that vendors that have a >> non-SCIM-compliant API will choose to keep things that way if the spec i= s >> too hard for them to implement. In a green field environment we do have >> the luxury of mandating a model to make certain operations more elegant. >> However, we can=92t ignore legacy systems. **** >> >> ** ** >> >> --Kelly**** >> >> ** ** >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Emmanuel Dreux >> *Sent:* Thursday, August 09, 2012 3:18 AM >> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> ** ** >> >> Hi Ganesh,**** >> >> ** ** >> >> Nothing prevents you in your SCIM implementation (client or server) to >> generate a unique identifier for each synchronized object and maintain a= n >> internal mapping table ( you would have to map group membership as well)= . >> **** >> >> ** ** >> >> This is what we are doing with Active Directory sources or targets:**** >> >> As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNa= me, >> UPN) are subject to change (even objectGuid can change if an AD domain i= s >> migrated), we decided to generate and maintain an internal table of ids. >> This fits your requirements as it hides internal ids.**** >> >> ** ** >> >> This was written in dotnet and we have started a project to rewrite our >> SCIM stack in PHP and will give it to the Open Source community. This >> implementation will have a parameter : AllocateIds versus UseExistingIDs= . >> **** >> >> This will give the choice of =93hiding=94 internalIDs or use them as uni= que >> ID.**** >> >> ** ** >> >> You can also implement such feature without violating the SCIM specs, or >> without asking to include it in the specs.**** >> >> ** ** >> >> --**** >> >> Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> ** ** >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> >> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org >> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> ** ** >> >> Hi Kelly,**** >> >> Thanks for your response. Let me first respond in brief to the two main >> points you have made, and then elaborate on the first.**** >> >> **1. **Why should domains not expose their internal identifiers to >> other domains?**** >> >> a.**** >> >> We are designing a protocol for a federated system of domains, where all >> domains are co-equal peers. (In physics too, N-body problems are much >> harder than 2-body problems. :-) Therefore, assuming that there are only >> two players in the interaction makes this tightly coupled in a number of >> ways. We should rely on messaging and notification, with encapsulation o= f >> domain-specific data.**** >> >> b. **** >> >> In any non-trivial data store, there will always be the ongoing need to >> merge and split identities as and when =93false negatives=94 and =93fals= e >> positives=94 are discovered. A domain should be able to handle this inte= rnal >> housekeeping freely, only notifying other domains when convenient. Mappi= ng >> of internal identifiers to external ones and maintaining this mapping >> internally allows this loosely-coupled housekeeping to take place. Shari= ng >> internal identifiers (or otherwise outsourcing the mapping of internal t= o >> external identifiers) forces housekeeping activities to be done in >> lock-step across domains.**** >> >> c.**** >> >> Asynchronous interaction is not just a matter of a suitable wire protoco= l >> which can be designed later. The data model plays a crucial role in >> enabling or constraining such interaction. A tightly-coupled data model >> will force the use of synchronous interactions, and the exposure of >> internal identifiers is a key part of this tight coupling.**** >> >> 2. The difficulty of assigning unique identifiers to the individual >> values of multi-valued attributes:**** >> >> a. **** >> >> I'm not belittling the effort involved in migrating legacy data stores t= o >> such a model. However, in the larger historical context of cross-domain >> identity management, we are really at the very early stages. If a >> relatively new discipline and a brand new spec are held captive to legac= y >> considerations, we are losing an opportunity to provide a clean and eleg= ant >> model to subsequent users of the spec, and this will have repercussions >> over many years or even decades.**** >> >> b. **** >> >> If incumbent cloud providers find it hard to immediately adopt the >> dictionary model for existing multi-valued attributes, they can transiti= on >> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-comp= liant=94 >> APIs to their customers and encouraging new customers to adopt the >> =93SCIM-compliant=94 API. Legacy customers can be supported using a >> =93non-SCIM-compliant=94 API for an arbitrarily long period and graduall= y >> migrated to the SCIM-compliant API. The logistics are not insurmountable= , >> and shouldn't prevent the adoption of a dictionary model for multi-value= d >> attributes.**** >> >> Elaboration of Point 1:**** >> >> When we consider federated identity across more than one domain, we have >> to assume that domains are not necessarily master-slave in their >> interaction. The most generic interaction model is peer-to-peer, where >> entity lifecycle events within a domain are notified to other domains (w= hen >> necessary) in an asynchronous manner (i.e., through messaging) and the >> other domains are free to respond to these events in an appropriate mann= er >> and at a time of their convenience.**** >> >> A key set of lifecycle events for an entity is the merging and splitting >> of identity that is often required.**** >> >> The question =93Is this one entity?=94 can be answered either yes (posit= ive) >> or no (negative). But sometimes, we can discover false positives and fal= se >> negatives in our data stores.**** >> >> Consider a case where customers sign up online, and two customers who ar= e >> privacy-conscious enter fake IDs such as =93John Smith=94, and also use = the >> same date of birth (say, 1 Jan 1970) or similar attributes. The front-en= d >> application may make an intelligent (but incorrect) guess that these two >> persons are the same, and re-assign the same identifier to the second >> person. This is a false positive. They appear to be the same entity, but >> they're actually different. When the error is discovered, the identities >> will need to be split, with a new identifier generated for one of them.*= * >> ** >> >> Consider the opposite case where a customer signs up through two >> different portals or in two different sessions, using the names =93JSmit= h=94 >> and =93JohnS=94. It is very likely that they will be treated as two diff= erent >> customers and assigned two unique identifiers. This is a false negative. >> They appear to be two entities, but are actually the same. At a later >> stage, when the error is discovered, the identities will have to be merg= ed, >> and one of the identifiers will have to be dropped.**** >> >> These are not theoretical use cases. They form a significant proportion >> of the user base in most large Web-facing applications. Let's see how th= ese >> can be managed in a federated way by mapping internal identifiers to >> external ones and only exposing external identifiers to other domains.**= * >> * >> >> a. False positives:**** >> >> Domain 1 has the following information about a customer in its data stor= e: >> **** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> When requesting the provisioning of this entity in Domain 2, the >> following ID is returned by Domain 2: ff487230b3a0.**** >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifier:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> When the false positive is discovered and the entity is split, Domain 1 >> creates a new internal identifier and now has the following entity >> information.**** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> Internal ID: a99a5feba839**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> This second entity with its own internal identifier is invisible to >> Domain 2, and this is by design. Communication about the original entity >> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >> vice-versa. At some convenient time (importantly, this doesn't have to b= e >> at the time the split happens), Domain 2 can be requested to provision a >> second entity, and when it responds with an identifier of =937a87f27c1dd= 8=94, >> this can go into the mapping table as a new record associated with the >> second entity's internal identifier.**** >> >> The mapping table now contains the following entries:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** >> >> Domain 2 is not even aware that a split has happened, and the >> provisioning that it does is not in lockstep with the split in identity >> that occurred in Domain 1.**** >> >> (What is the =93Primary flag=94 used for? We'll see when we cover the >> treatment of false negatives.)**** >> >> b. False negatives:**** >> >> Domain 1 has the following information about what it thinks are two >> distinct customers in its data store:**** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** >> >> Internal ID: 273d36e30d09**** >> >> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** >> >> When requesting the provisioning of these entities in Domain 2, the >> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.**= * >> * >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifiers:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | 273d36e30d09 | D2 | 41206cc97c8b | true |**** >> >> When the false negative is discovered and the two entities are merged, >> Domain 1 drops one of the internal identifiers and rationalises the name= of >> the customer (say, to =93John Smith=94). Let's say it retains the first = ID >> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** >> >> The mapping table now looks like this:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** >> >> Now two external identifiers map to the same internal one, so inbound >> communication from Domain 2 can be unambiguously translated to the same >> entity internally. However, when going outwards, Domain 1 will have to l= ook >> up the translation table to determine the =93primary=94 external ID for = this >> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's w= here >> the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never >> used thereafter in outbound communication.**** >> >> At some stage (importantly, not in lockstep with the identity merge), >> Domain 2 can be requested to delete the customer record identified by >> =9341206cc97c8b=94, and the second entry in the mapping table can be rem= oved >> once this is acknowledged.**** >> >> This scheme will scale up to multiple domains, because the =93External >> Domain ID=94 column helps to keep track of which external ID is shared w= ith >> which Domain. (Why don't we use just one external ID for an entity and >> share it with all external domains? Tight coupling again. Just as OAuth >> allows an access token given to a third party to be invalidated without >> affecting the access of other third parties, the use of separate externa= l >> identifiers for different domains allows fine-grained control of identit= y >> federation.)**** >> >> The scheme also allows the splitting of an entity into more than two >> entities, and the merging of more than two entities into a single one. (= Any >> organisation with a web-facing application will tell you how many John >> Smiths there are who were born on 1 Jan 1970!)**** >> >> This is a fairly long-winded explanation, but this is why we need to hid= e >> internal identifiers from other domains, and why mappings need to be >> managed internally in each domain. Such a data model also allows us to >> choose asynchronous protocols for propagation of identity events, since >> there is no consistency requirement to update multiple domains concurren= tly. >> **** >> >> Regards, **** >> >> Ganesh Prasad**** >> >> ** ** >> >> On 9 August 2012 04:55, Kelly Grizzle >> wrote:**** >> >> Thanks for the feedback, Ganesh. I read through this and your InfoQ >> article (http://www.infoq.com/articles/scim-data-model-limitations) and >> have some thoughts.**** >> >> **** >> >> > The rest of the protocol does not meaningfully use the enterprise >> client=92s identifier, the "external ID"**** >> >> > at all, even though it was ostensibly introduced to make things >> friendlier for the client.**** >> >> **** >> >> The usage pattern for an external ID would be to search for a user by >> externalId and use the ID of the returned user in any desired operation. >> For example:**** >> >> **** >> >> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** >> >> **** >> >> {**** >> >> =93totalResults=94: 1,**** >> >> =93Resources=94: [**** >> >> {**** >> >> =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** >> >> }**** >> >> ]**** >> >> }**** >> >> **** >> >> Retrieve the ID from the response and use it.**** >> >> **** >> >> DELETE /Users/2819c223-7f76-453a-919d-413861904646**** >> >> **** >> >> This does introduce an additional HTTP request if the client chooses not >> to store the server=92s id. An issue was created to consider allowing >> operations to use the externalId ( >> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the >> general consensus has been to not include this in the spec. One main po= int >> of contention is that much of the rest of the spec (eg =96 group members= hip >> references, manager references, etc=85) require knowledge of the server= =92s >> identifier. Continuing this discussion on the IETF list would be a good >> thing, though.**** >> >> **** >> >> **** >> >> > the cloud provider's ID and the enterprise client's ID are both >> "Internal IDs" with respect to their domains**** >> >> **** >> >> I think this comes down to a nomenclature problem. The server=92s ID do= es >> not necessarily have to be the unique identifier that the underlying >> identity store uses, it just has to be stable and unique. In many cases= , >> the underlying identity store will provide identifiers with these >> properties already (eg =96 a uuid) and it can be used by the SCIM interf= ace. >> The =93externalId=94 is referring to the fact that the id is maintained >> external to the SCIM server. As long as the server=92s identifiers are >> stable and unique (which is mandated by the spec), I don=92t see a probl= em. >> **** >> >> **** >> >> **** >> >> > The secret is that *every value needs a key*, and multi-valued >> attributes lack that. So our solution is quite**** >> >> > simple - turn every list or array (of values) into a dictionary (of >> key-value pairs) by providing each value**** >> >> > with a unique and meaning-free identifier.**** >> >> **** >> >> I agree that this would be useful, especially in the PATCH operation. >> One reason that this wasn=92t included in the spec originally is that it= can >> put undue burden on the service provider. Many service providers are >> putting SCIM interfaces in front of their existing identity stores (eg = =96 >> directory servers, SaaS application databases, etc=85). Many of these d= o not >> have a unique identifier for multi-valued attributes. By requiring this= , a >> majority of the server providers would have to start maintaining a uniqu= e >> key for each multi-valued attribute. I believe this would be a roadbloc= k >> for many implementers.**** >> >> **** >> >> **** >> >> > When the SCIM protocol uses PATCH, there are areas where it seems a >> bit clumsy.**** >> >> **** >> >> I like the thoughts here. Your example reminds me of unified diffs ( >> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >> used with a patch program (pretty much the equivalent of the PATCH verb)= . >> However, the three proposals seem to largely hinge on being able to >> uniquely address each element within an object. Without these it is not= so >> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or >> provide a multi-status.**** >> >> >> The 207 response would be interesting to consider for the bulk endpoint = ( >> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources)= , >> however.**** >> >> **** >> >> **** >> >> > There are other, non-data aspects of SCIM which may require review, >> such as its synchronous request-response**** >> >> > interaction model, which is a form of tight coupling and could prove t= o >> be a source of brittleness.**** >> >> **** >> >> I agree that we should explore optional asynchronous requests in 2.0.***= * >> >> **** >> >> Thanks again for your thoughts. I hope you stay involved in the >> discussion as work on SCIM 2.0 goes forward.**** >> >> **** >> >> --Kelly**** >> >> **** >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Ganesh and Sashi Prasad >> *Sent:* Wednesday, August 01, 2012 4:24 PM >> *To:* scim@ietf.org >> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> **** >> >> (I posted this on the SCIM Google Group, and I was advised to subscribe >> to the mailing list and post it here instead, so here goes.)**** >> >> **** >> >> Hi,**** >> >> **** >> >> My name is Ganesh Prasad, and my experience in Identity and Access >> Management is mainly through a 3-year project at an Australian insurance >> company, an experience I have written about as a eBook on InfoQ ( >> http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** >> >> **** >> >> I have been following the SCIM spec off and on, and based on my >> experience with a loosely-coupled architecture that I found to be >> successful, I have the following 3 suggestions to make.**** >> >> **** >> >> 1. The enterprise client and the cloud provider should maintain their ow= n >> internal IDs for a resource, which they should not reveal to each other. >> Both of them should map their internal IDs to a shared External ID, and >> this is the only ID that should be exposed through the API. The current >> specification's provision of an id (which is the external ID and the onl= y >> one to be transferred through the API) and an "external ID" (which is th= e >> client's internal ID and should be hidden) is diametrically opposite to >> this.**** >> >> **** >> >> 2. When dealing with multi-valued attributes of a resource (expressed as >> arrays in JSON), they must be converted from an array into a dictionary >> with unique keys (UUIDs generated by the cloud provider when the attribu= te >> is created). Without unique keys for every attribute value of a resource= , >> manipulating it will be clumsy and inelegant.**** >> >> **** >> >> 3. The PATCH command can be improved in 3 significant ways:**** >> >> 3a. Leverage the fact (from 2 above) that every value has a key, to >> greatly simplify the API**** >> >> 3b. Use special verbs as nested operations of the PATCH command to add, >> modify and delete attributes at any level**** >> >> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" >> as the response to a PATCH (or BULK) command.**** >> >> **** >> >> To elaborate,**** >> >> **** >> >> 1. Revealing private IDs externally is a form of tight coupling. A major >> requirement with Identity Management is to split (or merge) identities w= hen >> false positives (or false negatives) are detected, i.e., when a resource= is >> discovered to be more than one, or when multiple resources are detected = to >> be the same. If internal identifiers are revealed to external domains, s= uch >> clean-ups become difficult, hence every domain that wants to expose >> references to a resource must map its internal ID to and external one >> created for this explicit purpose, and only reveal this.**** >> >> **** >> >> In the SCIM case, when an enterprise client POSTs a resource creation >> request, the cloud provider must generate its own internal UUID as well = as >> an external UUID, map them together, and only return the external UUID i= n >> the "Location:" header. The enterprise client should map this external U= UID >> to a newly-generated internal ID of its own. In case the resource alread= y >> has an identifier within the enterprise client's domain, then this is th= e >> internal ID that must be mapped to the external UUID returned through th= e >> POST response.**** >> >> **** >> >> 2. If a resource is to be created, and one of its attributes is >> multi-valued, e.g.,**** >> >> **** >> >> "email-addrs" : **** >> >> [**** >> >> "john_smith@yahoo.com",**** >> >> "john.smith@gmail.com",**** >> >> "jsmith1970@hotmail.com"**** >> >> ]**** >> >> **** >> >> then on successful creation, the server response should include the >> representation of the resource, and this attribute should look like this= : >> **** >> >> **** >> >> "email-addrs" : **** >> >> [**** >> >> { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com= " >> },**** >> >> { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com= " >> },**** >> >> { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : " >> jsmith1970@hotmail.com" }**** >> >> ]**** >> >> **** >> >> The client now knows what each value is labelled. This now provides an >> unambiguous way to reference a value to add, modify and delete it:**** >> >> **** >> >> Add:**** >> >> **** >> >> POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** >> >> value=3D"js70@easy.com.au"**** >> >> **** >> >> Modify:**** >> >> **** >> >> PUT >> /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43= b9-9cda-8646c3085bbf >> **** >> >> value=3D"john.r.smith@gmail.com"**** >> >> **** >> >> Delete:**** >> >> DELETE >> /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4c= ca-9db7-7a6d1de664e1 >> **** >> >> **** >> >> One can even delete all email addresses like this:**** >> >> DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs**** >> >> **** >> >> I believe this is more elegant than what the spec recommends.**** >> >> **** >> >> 3. It's possible to think of the operations POST, PUT and DELETE as >> nested operations inside a PATCH. PATCH itself need not be nested becaus= e >> its semantics apply throughout the "tree" of a resource.**** >> >> **** >> >> However, the semantics of PUT are a little messy. Also, the use of HTTP >> verbs at a different level could be confusing. That's why I would recomm= end >> 6 separate verbs that are a little more unambiguous in their meaning:***= * >> >> **** >> >> 1. INCLUDE (equivalent to POST): Add this resource to a collection and >> return a generated URI**** >> >> 2. PLACE (equivalent to one form of PUT): Add this resource at the >> location specified by the accompanying URI. (If there=92s already a valu= e at >> that location, return an error status.)**** >> >> 3. REPLACE (equivalent to another form of PUT): Replace the value at the >> location specified by the accompanying URI with this value. (If there=92= s no >> such URI, return an error status.)**** >> >> 4. FORCE (equivalent to a third form of PUT): This means PLACE or >> REPLACE. (At the end of this operation, we want the specified URI to hol= d >> the accompanying value whether the URI already existed or not.)**** >> >> 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render >> inaccessible the resource at the specified URI.**** >> >> 6. AMEND (equivalent to PATCH): (This verb is just listed for >> completeness. We probably don=92t need a nested PATCH since PATCH cascad= es to >> every level of the tree.)**** >> >> **** >> >> A PATCH request could therefore look like this:**** >> >> **** >> >> PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> Content-length: ...**** >> >> **** >> >> {**** >> >> REPLACE: {**** >> >> "key" : "first-name",**** >> >> "value" : "Jack"**** >> >> },**** >> >> PLACE : {**** >> >> "key" : "middle-name",**** >> >> "value" : "Richard"**** >> >> },**** >> >> FORCE : {**** >> >> "key" : "dob",**** >> >> "value" : "01-Jan-1971"**** >> >> },**** >> >> REPLACE : {**** >> >> "key" : "address.unit-number",**** >> >> "value" : "12"**** >> >> },**** >> >> PLACE : {**** >> >> "key" : "address.state",**** >> >> "value" : "SA"**** >> >> },**** >> >> FORCE : {**** >> >> "key" : "address.country",**** >> >> "value" : "Australia"**** >> >> },**** >> >> INCLUDE : {**** >> >> "key" : "email-addrs",**** >> >> "value" : "js70@easy.com.au"**** >> >> },**** >> >> REPLACE : {**** >> >> "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** >> >> "value" : "john.r.smith@gmail.com"**** >> >> },**** >> >> RETIRE : {**** >> >> "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** >> >> }**** >> >> }**** >> >> **** >> >> The PATCH response should utilise the status code "207 Multi-Status" >> because the nested operations could have varying status codes. A sample >> response is below:**** >> >> **** >> >> HTTP/1.1 207 Multi-Status**** >> >> Content-Type: application/json**** >> >> ETag: W/"b431af54f0671a2"**** >> >> Location:" >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646"**** >> >> **** >> >> {**** >> >> "schemas":["urn:scim:schemas:core:1.0"],**** >> >> "external-id":"2819c223-7f76-453a-919d-413861904646",**** >> >> REPLACE: {**** >> >> "status" : "200 OK",**** >> >> "key" : "first-name",**** >> >> "value" : "Jack"**** >> >> },**** >> >> PLACE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "middle-name",**** >> >> "value" : "Richard"**** >> >> },**** >> >> FORCE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "dob",**** >> >> "value" : "01-Jan-1971"**** >> >> },**** >> >> REPLACE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "address.unit-number",**** >> >> "value" : "12"**** >> >> },**** >> >> PLACE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "address.state",**** >> >> "value" : "SA"**** >> >> },**** >> >> FORCE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "address.country",**** >> >> "value" : "Australia"**** >> >> },**** >> >> INCLUDE : {**** >> >> "status" : "201 Created",**** >> >> "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",**** >> >> "value" : "js70@easy.com.au"**** >> >> },**** >> >> REPLACE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",**** >> >> "value" : "john.r.smith@gmail.com"**** >> >> },**** >> >> RETIRE : {**** >> >> "status" : "200 OK",**** >> >> "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"**** >> >> }**** >> >> "meta": {**** >> >> "created":"2011-08-08T04:56:22Z",**** >> >> "lastModified":"2011-08-08T08:00:12Z",**** >> >> "location":" >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",**** >> >> "version":"W\/\"b431af54f0671a2\""**** >> >> }**** >> >> }**** >> >> **** >> >> If there are errors, they will take the place of the "200 OK" or "201 >> Created" status codes in the above successful case. But the outer status >> will remain "207 Multi-Status".**** >> >> **** >> >> The same scheme can be used to deal with operations on members of a >> group, and for bulk operations.**** >> >> **** >> >> I hope you find these suggestions useful.**** >> >> **** >> >> I read the SCIM spec afresh last week and these ideas came flooding into >> my head because I have been working at another organisation (a telco) fo= r >> the last 5 months, also in Identity and Access Management, and my though= ts >> have moved further along the direction of evolving a specialised data mo= del >> based on specific principles, especially for IAM.**** >> >> **** >> >> I am planning to write about this and also the data-related principles >> soon and am in negotiations with InfoQ regarding publication.**** >> >> **** >> >> Regards,**** >> >> Ganesh Prasad**** >> >> ** ** >> > > --0015173fe4acdc13cb04c6dbddc3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 It would be interesting to hear from the other members of the spec mailing = list.=A0

It would be good if members also state their affiliations w= hen they post their opinions (e.g., cloud service provider, ISV, enterprise= customer, etc.) For the record, I'm an architect currently contracting= with a telco that is an enterprise customer of cloud services.

Regards,
Ganesh

= On 10 August 2012 07:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com<= /a>> wrote:
>=A0 storing this information in a mapping table outside of the SCIM spe= c is a great way to enable this solution.=A0 Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only resp= onsible for the transport layer between domains.=A0

I wasn't suggesting that the mapping table be part of the SCI= M spec. I provided that example to illustrate that splitting and merging id= entities is a common requirement, and that decoupling local identifiers wit= hin a domain from shared identifiers between domains was the best way to fa= cilitate it.

I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do there is just refrain from introducing= tight coupling. I would like to see a single identifier exposed through th= e API, with the implication (and perhaps the recommendation) that it be the= shared one. Allowing one domain to expose its internal identifier to the o= ther creates tight coupling and ensures that both domains need simultaneous= ly split or merge identities, which is not desirable. So I recommend _takin= g out_ the "external id" field from the API. The spec shouldn'= ;t encourage tight coupling. If clients want to pass in their internal ids = as part of the resource body, no one can stop them, and they can always do = a search on that attribute to retrieve the URI exactly as you visualise the= y will with the "external id", but let's not elevate an anti-= pattern to a recommendation by enshrining the "external id" as an= acceptable attribute.

Am I making sense?

>=A0 Regarding unique identifiers for multi-valued attributes there is a= trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O= n the other hand it puts extra burden on service providers.=A0

Precisely. The spec has to strike the right balance. It woul= d be interesting to hear from the other members of the spec mailing list. Y= ou know where I stand on this. It would be good to hear the spectrum of opi= nions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.=A0 I had= started writing up a similar response.=A0 As you suggest, storing this inf= ormation in a mapping table outside of the SCIM spec is a great way to enable this solution.=A0 Part of the key here is that SCIM is just = a piece of the architecture for this solution, and is only responsible for = the transport layer between domains.

=A0<= /p>

You could also model thes= e ID mappings in the SCIM user as an extension but would probably not want = to expose these externally.=A0 Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /u>

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0

This could be repre= sented as two SCIM users that contain information about the entities on oth= er domains.

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "a99a5feba839",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "7a87f27c1dd8"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

In the second user, the l= inkedUsers attribute would be empty until the split user was synced to doma= in 2.

=A0<= /p>

=A0<= /p>

Similarly, the false nega= tive use case (merging two users) looked like this at the end:

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0= | false=A0=A0=A0=A0=A0=A0=A0 |

=A0<= /p>

This could be repre= sented with the following SCIM user:

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 },

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "41206cc97c8b",

=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&= quot;: true

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

=A0<= /p>

Regarding unique identifi= ers for multi-valued attributes there is a trade-off involved.=A0 On one ha= nd this makes PATCH semantics easier.=A0 On the other hand it puts extra burden on service providers.=A0 Since the inception of SCIM, a = key goal has been to foster adoption by service providers by making things = fit easily onto existing systems.=A0 IMO the value gained by unique identif= iers for multi-valued attributes is not worth the demands put on a service provider.=A0 I also think that vend= ors that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement.=A0 In a green field environm= ent we do have the luxury of mandating a model to make certain operations more elegant.=A0 However, we can=92t ig= nore legacy systems.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

Hi Ganesh,=

=A0=

Nothing prevents you in y= our SCIM implementation (client or server) to generate a unique identifier = for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

=A0<= /p>

This is what we are doing= with Active Directory sources or targets:

As we didn=92t find an im= mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan= ge (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

=A0<= /p>

This was written in dotne= t and we have started a project to rewrite our SCIM stack in PHP and will g= ive it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice= of =93hiding=94 internalIDs or use them as unique ID.=

=A0<= /p>

You can also implement su= ch feature without violating the SCIM specs, or without asking to include i= t in the specs.

=A0<= /p>

--<= /u>

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org
Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Hi K= elly,

Than= ks for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.=A0=A0=A0=A0=A0 Why should domains not expose= their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating l= egacy data stores to such a model. However, in the larger historical contex= t of cross-domain identity management, we are really at the very early stag= es. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.=

Elab= oration of Point 1:

When= we consider federated identity across more than one domain, we have to ass= ume that domains are not necessarily master-slave in their interaction. The= most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are n= otified to other domains (when necessary) in an asynchronous manner (i.e., = through messaging) and the other domains are free to respond to these event= s in an appropriate manner and at a time of their convenience.

A ke= y set of lifecycle events for an entity is the merging and splitting of ide= ntity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores.

Cons= ider a case where customers sign up online, and two customers who are priva= cy-conscious enter fake IDs such as =93John Smith=94, and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelli= gent (but incorrect) guess that these two persons are the same, and re-assi= gn the same identifier to the second person. This is a false positive. They= appear to be the same entity, but they're actually different. When the error is discovered, the identiti= es will need to be split, with a new identifier generated for one of them.<= u>

Cons= ider the opposite case where a customer signs up through two different port= als or in two different sessions, using the names =93JSmith=94 and =93JohnS= =94. It is very likely that they will be treated as two different customers and assigned two unique id= entifiers. This is a false negative. They appear to be two entities, but ar= e actually the same. At a later stage, when the error is discovered, the id= entities will have to be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external ones and only exposing ext= ernal identifiers to other domains.

a. F= alse positives:

Doma= in 1 has the following information about a customer in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of this entity in Domain 2, the following ID i= s returned by Domain 2: ff487230b3a0.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifier:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

When= the false positive is discovered and the entity is split, Domain 1 creates= a new internal identifier and now has the following entity information.=

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: a99a5feba839

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

This= second entity with its own internal identifier is invisible to Domain 2, a= nd this is by design. Communication about the original entity takes place a= s before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien= t time (importantly, this doesn't have to be at the time the split happ= ens), Domain 2 can be requested to provision a second entity, and when it r= esponds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the sec= ond entity's internal identifier.

The = mapping table now contains the following entries:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| a99a5feba839 | = D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened= , and the provisioning that it does is not in lockstep with the split in id= entity that occurred in Domain 1.

(Wha= t is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.)

b. F= alse negatives:

Doma= in 1 has the following information about what it thinks are two distinct cu= stomers in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: 273d36e30d09

Attr= ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of these entities in Domain 2, the following I= Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifiers:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 273d36e30d09 | = D2 | 41206cc97c8b | true |

When= the false negative is discovered and the two entities are merged, Domain 1= drops one of the internal identifiers and rationalises the name of the cus= tomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr= ops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | = D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound communica= tion from Domain 2 can be unambiguously translated to the same entity inter= nally. However, when going outwards, Domain 1 will have to look up the translation table to det= ermine the =93primary=94 external ID for this entity in Domain 2, which was= decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 = comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound communication.

At s= ome stage (importantly, not in lockstep with the identity merge), Domain 2 = can be requested to delete the customer record identified by =9341206cc97c8= b=94, and the second entry in the mapping table can be removed once this is acknowledged.

This= scheme will scale up to multiple domains, because the =93External Domain I= D=94 column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it with all external domains?= Tight coupling again. Just as OAuth allows an access token given to a thir= d party to be invalidated without affecting the access of other third parti= es, the use of separate external identifiers for different domains allows fine-grained control of identity = federation.)

The = scheme also allows the splitting of an entity into more than two entities, = and the merging of more than two entities into a single one. (Any organisat= ion with a web-facing application will tell you how many John Smiths there are who were born on = 1 Jan 1970!)

This= is a fairly long-winded explanation, but this is why we need to hide inter= nal identifiers from other domains, and why mappings need to be managed int= ernally in each domain. Such a data model also allows us to choose asynchronous protocols for prop= agation of identity events, since there is no consistency requirement to up= date multiple domains concurrently.

Rega= rds,

Gane= sh Prasad

=A0

On 9 August 2012 04:55, Kelly Griz= zle <ke= lly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, = Ganesh.=A0 I read through this and your InfoQ article (= http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

=A0<= /p>

> The rest of the protocol does not meani= ngfully use the enterprise client=92s identifier, the "external ID&quo= t;

> at all, even thoug= h it was ostensibly introduced to make things friendlier for the client.

=A0<= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.=A0 For example:<= u>

=A0<= /p>

GET /Users?filter=3Dexter= nalId eq =93bjensen=94&attributes=3Did

=A0<= /p>

{

=A0 =93totalResults=94: 1,

=A0 =93Resources=94: [

=A0=A0=A0 {

=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45= 3a-919d-413861904646=94

=A0=A0=A0 }

=A0 ]

}

=A0<= /p>

Retrieve the ID from the = response and use it.

=A0<= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

=A0<= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server=92s id.= =A0 An issue was created to consider allowing operations to use the externalId= (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.=A0 One main point of contention is that much of the rest of the spec (e= g =96 group membership references, manager references, etc=85) require know= ledge of the server=92s identifier.=A0 Continuing this discussion on the IETF list would be a good thing, though.<= /u>

=A0<= /p>

=A0<= /p>

> the cloud provider's ID and the ent= erprise client's ID are both "Internal IDs" with respect to t= heir domains

=A0<= /p>

I think this comes down t= o a nomenclature problem.=A0 The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just = has to be stable and unique.=A0 In many cases, the underlying identity stor= e will provide identifiers with these properties already (eg =96 a uuid) an= d it can be used by the SCIM interface.=A0 The =93externalId=94 is referring to the fact that the id is maintained ex= ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta= ble and unique (which is mandated by the spec), I don=92t see a problem.

=A0<= /p>

=A0<= /p>

> The secret is that=A0every value nee= ds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn ever= y list or array (of values) into a dictionary (of key-value pairs) by provi= ding each value

> with a unique and = meaning-free identifier.

=A0<= /p>

I agree that this would b= e useful, especially in the PATCH operation.=A0 One reason that this wasn= =92t included in the spec originally is that it can put undue burden on the ser= vice provider.=A0 Many service providers are putting SCIM interfaces in fro= nt of their existing identity stores (eg =96 directory servers, SaaS applic= ation databases, etc=85).=A0 Many of these do not have a unique identifier for multi-valued attributes.=A0 By requiri= ng this, a majority of the server providers would have to start maintaining= a unique key for each multi-valued attribute.=A0 I believe this would be a= roadblock for many implementers.

=A0<= /p>

=A0<= /p>

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.

=A0<= /p>

I like the thoughts here.= =A0 Your example reminds me of unified diffs (http://en.wikipedi= a.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb). =A0However, the three proposals seem to largely hinge on= being able to uniquely address each element within an object.=A0 Without t= hese it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<= /span>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

=A0<= /p>

=A0<= /p>

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model,= which is a form of tight coupling and could prove to be a source of brittl= eness.

=A0<= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

=A0<= /p>

Thanks again for your tho= ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

=A0

Hi,

=A0

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks= /Identity-Management-Shoestring).

=A0

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

=A0

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should = be exposed through the API. The current specification's provision of an= id (which is the external ID and the only one to be transferred through th= e API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposi= te to this.

=A0

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys = for every attribute value of a resource, manipulating it will be clumsy and= inelegant.

=A0

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level=

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

=A0

To elaborate,

=A0

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or = when multiple resources are detected to be the same. If internal identifier= s are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its internal ID to and external one crea= ted for this explicit purpose, and only reveal this.

=A0

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The= enterprise client should map this external UUID to a newly-generated inter= nal ID of its own. In case the resource already has an identifier within th= e enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through = the POST response.

=A0

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 "john_smith@yahoo.com",

=A0 =A0 =A0 =A0 "john.smith@gmail.com",

=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"

=A0 =A0 ]

=A0

then on successful creation, the server response sho= uld include the representation of the resource, and this attribute should l= ook like this:

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 { "7dfcb444-74d8-4f17-aa66-daf9= ea3bd902" : "john_smith@yahoo.com" },

=A0 =A0 =A0 =A0 { "3bd10085-c474-43b9-9cda-8646= c3085bbf" : "john.smith@gmail.com" },

=A0 =A0 =A0 =A0 { "581da5c7-c6e1-4cca-9db7-7a6d= 1de664e1" : "jsmith1970@hotmail.com" }

=A0 =A0 ]

=A0

The client now knows what each value is labelled. Th= is now provides an unambiguous way to reference a value to add, modify and = delete it:

=A0

Add:

=A0

POST /Users/2819c223-7f76-453a-919d-413861904646/ema= il-addrs

value=3D"js70@easy.com.au"

=A0

Modify:

=A0

PUT /Users/2819c223-7f76-453a-919d-413861904646/emai= l-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

=A0

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

=A0

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/e= mail-addrs

=A0

I believe this is more elegant than what the spec re= commends.

=A0

3. It's possible to think of the operations POST= , PUT and DELETE as nested operations inside a PATCH. PATCH itself need not= be nested because its semantics apply throughout the "tree" of a resource.

=A0

However, the semantics of PUT are a little messy. Al= so, the use of HTTP verbs at a different level could be confusing. That'= ;s why I would recommend 6 separate verbs that are a little more unambiguous in their meaning:

=A0

1. INCLUDE (equivalent to POST): Add this resource t= o a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this r= esource at the location specified by the accompanying URI. (If there=92s al= ready a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Repl= ace the value at the location specified by the accompanying URI with this v= alue. (If there=92s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This m= eans PLACE or REPLACE. (At the end of this operation, we want the specified= URI to hold the accompanying value whether the URI already existed or not.)

5. RETIRE (equivalent to DELETE): Delete, deactivate= or otherwise render inaccessible the resource at the specified URI.=

6. AMEND (equivalent to PATCH): (This verb is just l= isted for completeness. We probably don=92t need a nested PATCH since PATCH= cascades to every level of the tree.)

=A0

A PATCH request could therefore look like this:

=A0

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HT= TP/1.1

Host: example.com<= /u>

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

=A0

{

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs&= quot;,

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

}

=A0

The PATCH response should utilise the status code &q= uot;207 Multi-Status" because the nested operations could have varying= status codes. A sample response is below:

=A0

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

=A0

{

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

=A0 =A0 "external-id":"2819c223-7f76-= 453a-919d-413861904646",

=A0 =A0 REPLACE: {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "first-name&q= uot;,

=A0 =A0 =A0 =A0 "value" : "Jack"=

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "middle-name&= quot;,

=A0 =A0 =A0 =A0 "value" : "Richard&qu= ot;

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "dob",

=A0 =A0 =A0 =A0 "value" : "01-Jan-197= 1"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.unit= -number",

=A0 =A0 =A0 =A0 "value" : "12"

=A0 =A0 },

=A0 =A0 PLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.stat= e",

=A0 =A0 =A0 =A0 "value" : "SA"

=A0 =A0 },

=A0 =A0 FORCE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "address.coun= try",

=A0 =A0 =A0 =A0 "value" : "Australia&= quot;

=A0 =A0 },

=A0 =A0 INCLUDE : {

=A0 =A0 =A0 =A0 "status" : "201 Creat= ed",

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 11f664ec-898b-4f6f-8948-ecfda74deff0",

=A0 =A0 =A0 =A0 "value" : "js70@easy.com.au"

=A0 =A0 },

=A0 =A0 REPLACE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 3bd10085-c474-43b9-9cda-8646c3085bbf",

=A0 =A0 =A0 =A0 "value" : "john.r.smith@gmail.com"

=A0 =A0 },

=A0 =A0 RETIRE : {

=A0 =A0 =A0 =A0 "status" : "200 OK&qu= ot;,

=A0 =A0 =A0 =A0 "key" : "email-addrs/= 581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

=A0 =A0 }

=A0 =A0 "meta": {

=A0 =A0 =A0 =A0 "created":"2011-08-08= T04:56:22Z",

=A0 =A0 =A0 =A0 "lastModified":"2011-= 08-08T08:00:12Z",

=A0 =A0 =A0 =A0 "version":"W\/\"= b431af54f0671a2\""

=A0 =A0 }

}

=A0

If there are errors, they will take the place of the= "200 OK" or "201 Created" status codes in the above su= ccessful case. But the outer status will remain "207 Multi-Status"= ;.

=A0

The same scheme can be used to deal with operations = on members of a group, and for bulk operations.

=A0

I hope you find these suggestions useful.<= /u>

=A0

I read the SCIM spec afresh last week and these idea= s came flooding into my head because I have been working at another organis= ation (a telco) for the last 5 months, also in Identity and Access Management, and my thoughts have moved further along the direct= ion of evolving a specialised data model based on specific principles, espe= cially for IAM.

=A0

I am planning to write about this and also the data-= related principles soon and am in negotiations with InfoQ regarding publica= tion.

=A0

Regards,

Ganesh Prasad

=A0



--0015173fe4acdc13cb04c6dbddc3-- From prvs=56137be3e=Mark.Diodati@gartner.com Thu Aug 9 14:26:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3E921F860F for ; Thu, 9 Aug 2012 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS51Cx2D0Nh3 for ; Thu, 9 Aug 2012 14:25:49 -0700 (PDT) Received: from iron-main.gartner.com (iron-main.gartner.com [207.140.148.93]) by ietfa.amsl.com (Postfix) with ESMTP id BFA4D21F8605 for ; Thu, 9 Aug 2012 14:25:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAIzgI1AKQCMK/2dsb2JhbAA8BgOCSqVwiGEBiU2CGQcBAQEDAQ4MAToQBwIGBQUJAgIBCBEBAwEBCwIUAQYHGwYREwEDBggCBAEJBAUIDAeFLoI1AwYRpwqDB4IIhXQNiU4EiiZlEQmDKYJBYAOIGYtdAQKCAWOJdoYygTKBXw X-IronPort-AV: E=Sophos;i="4.77,742,1336363200"; d="scan'208,217";a="126554715" From: "Diodati,Mark" To: Ganesh and Sashi Prasad , Kelly Grizzle Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNdnQawdBXJSggRkKJHWTWx6NwNpdR/Afw Date: Thu, 9 Aug 2012 21:25:44 +0000 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.130] Content-Type: multipart/alternative; boundary="_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4BA20whistlerentgart_" MIME-Version: 1.0 Message-Id: <20120809212548.BFA4D21F8605@ietfa.amsl.com> Cc: "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:26:06 -0000 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4BA20whistlerentgart_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ganesh, --It would be good to hear the spectrum of opinions ... My assessment is that your proposal adds complexity, strays from the initia= l simplicity goals of SCIM, and hinders service provider adoption (which is= crucial to the success of SCIM). I speak only for myself, but in my conver= sations with others in the WG, no one supported your proposal. Mark Mark Diodati Research Vice President | Gartner phone: +1 312.238.9877 blog: http://blogs.gartner.com/mark-diodati twitter: mark_diodati From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Thursday, August 09, 2012 4:15 PM To: Kelly Grizzle Cc: scim@ietf.org; Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can't ignore le= gacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the = translation table to determine the "primary" external ID for this entity in= Domain 2, which was decided to be "ff487230b3a0". That's where the "Primar= y flag" comes in. The second external ID "41206cc97c8b" is never used there= after in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domai= n 2 can be requested to delete the customer record identified by "41206cc97= c8b", and the second entry in the mapping table can be removed once this is= acknowledged. This scheme will scale up to multiple domains, because the "External Domain= ID" column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it wi= th all external domains? Tight coupling again. Just as OAuth allows an acce= ss token given to a third party to be invalidated without affecting the acc= ess of other third parties, the use of separate external identifiers for di= fferent domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entiti= es, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed= internally in each domain. Such a data model also allows us to choose asyn= chronous protocols for propagation of identity events, since there is no co= nsistency requirement to update multiple domains concurrently. Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle > wrote: Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" ] then on successful creation, the server response should include the represe= ntation of the resource, and this attribute should look like this: "email-addrs" : [ { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" }, { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" }, { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com<= mailto:jsmith1970@hotmail.com>" } ] The client now knows what each value is labelled. This now provides an unam= biguous way to reference a value to add, modify and delete it: Add: POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs value=3D"js70@easy.com.au" Modify: PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-4= 3b9-9cda-8646c3085bbf value=3D"john.r.smith@gmail.com" Delete: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e= 1-4cca-9db7-7a6d1de664e1 One can even delete all email addresses like this: DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs I believe this is more elegant than what the spec recommends. 3. It's possible to think of the operations POST, PUT and DELETE as nested = operations inside a PATCH. PATCH itself need not be nested because its sema= ntics apply throughout the "tree" of a resource. However, the semantics of PUT are a little messy. Also, the use of HTTP ver= bs at a different level could be confusing. That's why I would recommend 6 = separate verbs that are a little more unambiguous in their meaning: 1. INCLUDE (equivalent to POST): Add this resource to a collection and retu= rn a generated URI 2. PLACE (equivalent to one form of PUT): Add this resource at the location= specified by the accompanying URI. (If there's already a value at that loc= ation, return an error status.) 3. REPLACE (equivalent to another form of PUT): Replace the value at the lo= cation specified by the accompanying URI with this value. (If there's no su= ch URI, return an error status.) 4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. = (At the end of this operation, we want the specified URI to hold the accomp= anying value whether the URI already existed or not.) 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render in= accessible the resource at the specified URI. 6. AMEND (equivalent to PATCH): (This verb is just listed for completeness.= We probably don't need a nested PATCH since PATCH cascades to every level = of the tree.) A PATCH request could therefore look like this: PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 Content-length: ... { REPLACE: { "key" : "first-name", "value" : "Jack" }, PLACE : { "key" : "middle-name", "value" : "Richard" }, FORCE : { "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "key" : "address.unit-number", "value" : "12" }, PLACE : { "key" : "address.state", "value" : "SA" }, FORCE : { "key" : "address.country", "value" : "Australia" }, INCLUDE : { "key" : "email-addrs", "value" : "js70@easy.com.au" }, REPLACE : { "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } } The PATCH response should utilise the status code "207 Multi-Status" becaus= e the nested operations could have varying status codes. A sample response = is below: HTTP/1.1 207 Multi-Status Content-Type: application/json ETag: W/"b431af54f0671a2" Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646= " { "schemas":["urn:scim:schemas:core:1.0"], "external-id":"2819c223-7f76-453a-919d-413861904646", REPLACE: { "status" : "200 OK", "key" : "first-name", "value" : "Jack" }, PLACE : { "status" : "200 OK", "key" : "middle-name", "value" : "Richard" }, FORCE : { "status" : "200 OK", "key" : "dob", "value" : "01-Jan-1971" }, REPLACE : { "status" : "200 OK", "key" : "address.unit-number", "value" : "12" }, PLACE : { "status" : "200 OK", "key" : "address.state", "value" : "SA" }, FORCE : { "status" : "200 OK", "key" : "address.country", "value" : "Australia" }, INCLUDE : { "status" : "201 Created", "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", "value" : "js70@easy.com.au" }, REPLACE : { "status" : "200 OK", "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", "value" : "john.r.smith@gmail.com" }, RETIRE : { "status" : "200 OK", "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" } "meta": { "created":"2011-08-08T04:56:22Z", "lastModified":"2011-08-08T08:00:12Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41= 3861904646", "version":"W\/\"b431af54f0671a2\"" } } If there are errors, they will take the place of the "200 OK" or "201 Creat= ed" status codes in the above successful case. But the outer status will re= main "207 Multi-Status". The same scheme can be used to deal with operations on members of a group, = and for bulk operations. I hope you find these suggestions useful. I read the SCIM spec afresh last week and these ideas came flooding into my= head because I have been working at another organisation (a telco) for the= last 5 months, also in Identity and Access Management, and my thoughts hav= e moved further along the direction of evolving a specialised data model ba= sed on specific principles, especially for IAM. I am planning to write about this and also the data-related principles soon= and am in negotiations with InfoQ regarding publication. Regards, Ganesh Prasad ________________________________ This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute,= or otherwise use this message or its attachments. Please notify the sender= immediately by return e-mail and permanently delete this message and any a= ttachments. Gartner makes no warranty that this e-mail is error or virus fr= ee. --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4BA20whistlerentgart_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ganesh,

 

--It would be good to h= ear the spectrum of opinions …

 

My assessment is that y= our proposal adds complexity, strays from the initial simplicity goals of S= CIM, and hinders service provider adoption (which is crucial to the success of SCIM). I speak only for myself, but in my conversations = with others in the WG, no one supported your proposal.

 

Mark

 

 

Mark Diodati

Research Vice President= | Gartner

phone: +1 312.238.9= 877

blog: http://blogs.gartner.com/mark-diodati

twitter: mark_diodati

 

 

 

 

From: Ganesh= and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Thursday, August 09, 2012 4:15 PM
To: Kelly Grizzle
Cc: scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

>  storing this information in a mapping table outside of the SCIM spec is a g= reat way to enable this solution.  Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain= from introducing tight coupling. I would like to see a single identifier e= xposed through the API, with the implication (and perhaps the recommendatio= n) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight co= upling and ensures that both domains need simultaneously split or merge ide= ntities, which is not desirable. So I recommend _taking out_ the "exte= rnal id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their inter= nal ids as part of the resource body, no one can stop them, and they can al= ways do a search on that attribute to retrieve the URI exactly as you visua= lise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved.  On one hand this makes PATCH semantics easier.  On = the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emman= uel.  I had started writing up a similar response.  As you sugges= t, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that= SCIM is just a piece of the architecture for this solution, and is only re= sponsible for the transport layer between domains.

 

You could al= so model these ID mappings in the SCIM user as an extension but would proba= bly not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| a99a5feba839   =     | D2        &nbs= p;        | 7a87f27c1dd8  &nbs= p;    | true        = |

 

This could b= e represented as two SCIM users that contain information about the entities= on other domains.

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }=

    ]

  }

}

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "a99= a5feba839",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "7a87f27c1dd8"

      }=

    ]

  }

}

 

In the secon= d user, the linkedUsers attribute would be empty until the split user was s= ynced to domain 2.

 

 

Similarly, t= he false negative use case (merging two users) looked like this at the end:=

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| 9caf78aac3d6   =     | D2        &nbs= p;        | 41206cc97c8b  &nbs= p;    | false        |

 

This could b= e represented with the following SCIM user:

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }= ,

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "41206cc97c8b",

     &n= bsp;  "deletionRequired": true

      }=

    ]

  }

}

 

 

Regarding un= ique identifiers for multi-valued attributes there is a trade-off involved.=   On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception = of SCIM, a key goal has been to foster adoption by service providers by mak= ing things fit easily onto existing systems.  IMO the value gained by = unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think tha= t vendors that have a non-SCIM-compliant API will choose to keep things tha= t way if the spec is too hard for them to implement.  In a green field= environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we canR= 17;t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

= Hi Ganesh,

=  

Nothing prev= ents you in your SCIM implementation (client or server) to generate a uniqu= e identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).<= /span>

 

This is what= we are doing with Active Directory sources or targets:

As we didn&#= 8217;t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) ar= e subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids= . This fits your requirements as it hides internal ids.

 

This was wri= tten in dotnet and we have started a project to rewrite our SCIM stack in P= HP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will gi= ve the choice of “hiding” internalIDs or use them as unique ID.=

 

You can also= implement such feature without violating the SCIM specs, or without asking= to include it in the specs.

 

= --

= Regards,

= Emmanuel Dreux

= http://www.cloudiway= .com

= Tel: +33 4 2= 6 78 17 58

= Mobile: +33 6 4= 7 81 26 70

= skype: Emmanuel.Dreux

=  

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi = Kelly,

Tha= nks for your response. Let me first respond in brief to the two main points= you have made, and then elaborate on the first.

1.&nbs= p;     Why should domains not = expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when “false negative= s” and “false positives” are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both “SCIM-compliant” and &= #8220;non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. L= egacy customers can be supported using a “non-SCIM-compliant” A= PI for an arbitrarily long period and gradually migrated to the SCIM-compli= ant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Ela= boration of Point 1:

Whe= n we consider federated identity across more than one domain, we have to as= sume that domains are not necessarily master-slave in their interaction. Th= e most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified t= o other domains (when necessary) in an asynchronous manner (i.e., through m= essaging) and the other domains are free to respond to these events in an a= ppropriate manner and at a time of their convenience.

A k= ey set of lifecycle events for an entity is the merging and splitting of id= entity that is often required.

The= question “Is this one entity?” can be answered either yes (pos= itive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Con= sider a case where customers sign up online, and two customers who are priv= acy-conscious enter fake IDs such as “John Smith”, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Con= sider the opposite case where a customer signs up through two different por= tals or in two different sessions, using the names “JSmith” and= “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

The= se are not theoretical use cases. They form a significant proportion of the= user base in most large Web-facing applications. Let's see how these can b= e managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. = False positives:

Dom= ain 1 has the following information about a customer in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Whe= n requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifier:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

Whe= n the false positive is discovered and the entity is split, Domain 1 create= s a new internal identifier and now has the following entity information.

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Int= ernal ID: a99a5feba839

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Thi= s second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes place = as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (imp= ortantly, this doesn't have to be at the time the split happens), Domain 2 = can be requested to provision a second entity, and when it responds with an= identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The= mapping table now contains the following entries:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| a99a5feba839 = | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happene= d, and the provisioning that it does is not in lockstep with the split in i= dentity that occurred in Domain 1.

(Wh= at is the “Primary flag” used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Dom= ain 1 has the following information about what it thinks are two distinct c= ustomers in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “JSmith”, dob: “01-Jan-1970”}

Int= ernal ID: 273d36e30d09

Att= ributes: {name: “JohnS”, dob: “01-Jan-1970”}=

Whe= n requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifiers:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 273d36e30d09 = | D2 | 41206cc97c8b | true |

Whe= n the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the cu= stomer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the secon= d “273d36e30d09”.

The= mapping table now looks like this:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 = | D2 | 41206cc97c8b | false |

Now= two external identifiers map to the same internal one, so inbound communic= ation from Domain 2 can be unambiguously translated to the same entity inte= rnally. However, when going outwards, Domain 1 will have to look up the translation table to determine the ̶= 0;primary” external ID for this entity in Domain 2, which was decided= to be “ff487230b3a0”. That's where the “Primary flagR= 21; comes in. The second external ID “41206cc97c8b” is never us= ed thereafter in outbound communication.

At = some stage (importantly, not in lockstep with the identity merge), Domain 2= can be requested to delete the customer record identified by “41206c= c97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

Thi= s scheme will scale up to multiple domains, because the “External Dom= ain ID” column helps to keep track of which external ID is shared wit= h which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling ag= ain. Just as OAuth allows an access token given to a third party to be inva= lidated without affecting the access of other third parties, the use of sep= arate external identifiers for different domains allows fine-grained control of identity federation.)

The= scheme also allows the splitting of an entity into more than two entities,= and the merging of more than two entities into a single one. (Any organisa= tion with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

Thi= s is a fairly long-winded explanation, but this is why we need to hide inte= rnal identifiers from other domains, and why mappings need to be managed in= ternally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of i= dentity events, since there is no consistency requirement to update multipl= e domains concurrently.

Reg= ards,

Gan= esh Prasad

 

On 9 August 2012 04:55,= Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for t= he feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not mea= ningfully use the enterprise client’s identifier, the "external = ID"

> at al= l, even though it was ostensibly introduced to make things friendlier for t= he client.

 

The usage pa= ttern for an external ID would be to search for a user by externalId and us= e the ID of the returned user in any desired operation.  For example:

 

GET /Users?f= ilter=3DexternalId eq “bjensen”&attributes=3Did

 

{

  “totalResults”= ;: 1,

  “Resources”: = [

    {

      &= #8220;id”: “2819c223-7f76-453a-919d-413861904646”<= /p>

    }

  ]

}

 

Retrieve the= ID from the response and use it.

 

DELETE /User= s/2819c223-7f76-453a-919d-413861904646

 

This does in= troduce an additional HTTP request if the client chooses not to store the s= erver’s id.  An issue was created to consider allowing operation= s to use the externalId (http://code.google.com/p/scim/issues/= detail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One = main point of contention is that much of the rest of the spec (eg – g= roup membership references, manager references, etc…) require knowled= ge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enter= prise client's ID are both "Internal IDs" with respect to their d= omains

 

I think this= comes down to a nomenclature problem.  The server’s ID does not= necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the = underlying identity store will provide identifiers with these properties al= ready (eg – a uuid) and it can be used by the SCIM interface.  T= he “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server&= #8217;s identifiers are stable and unique (which is mandated by the spec), = I don’t see a problem.

 

 

> The secret is that every valu= e needs a key, and multi-valued attributes lack that. So our solution i= s quite

> simpl= e - turn every list or array (of values) into a dictionary (of key-value pa= irs) by providing each value

> with = a unique and meaning-free identifier.

 

I agree that= this would be useful, especially in the PATCH operation.  One reason = that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are= putting SCIM interfaces in front of their existing identity stores (eg = 211; directory servers, SaaS application databases, etc…).  Many= of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers wo= uld have to start maintaining a unique key for each multi-valued attribute.=   I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, th= ere are areas where it seems a bit clumsy.

 

I like the t= houghts here.  Your example reminds me of unified diffs (ht= tp://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of = SCIM which may require review, such as its synchronous request-response

> inter= action model, which is a form of tight coupling and could prove to be a sou= rce of brittleness.

 

I agree that= we should explore optional asynchronous requests in 2.0.

 

Thanks again= for your thoughts.  I hope you stay involved in the discussion as wor= k on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

 

(I posted this on the SCIM Google Group, = and I was advised to subscribe to the mailing list and post it here instead= , so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experien= ce in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eB= ook on InfoQ (http://www.infoq.com/minibooks/Identity-Mana= gement-Shoestring).

 

I have been following the SCIM spec off a= nd on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud pr= ovider should maintain their own internal IDs for a resource, which they sh= ould not reveal to each other. Both of them should map their internal IDs t= o a shared External ID, and this is the only ID that should be exposed through the API. The current specificat= ion's provision of an id (which is the external ID and the only one to be t= ransferred through the API) and an "external ID" (which is the cl= ient's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attribu= tes of a resource (expressed as arrays in JSON), they must be converted fro= m an array into a dictionary with unique keys (UUIDs generated by the cloud= provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating = it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3= significant ways:

3a. Leverage the fact (from 2 above) that= every value has a key, to greatly simplify the API

3b. Use special verbs as nested operation= s of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "2= 07 Multi-Status" instead of "200 OK" as the response to a PA= TCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is to = split (or merge) identities when false positives (or false negatives) are d= etected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the sam= e. If internal identifiers are revealed to external domains, such clean-ups= become difficult, hence every domain that wants to expose references to a = resource must map its internal ID to and external one created for this explicit purpose, and only reveal thi= s.

 

In the SCIM case, when an enterprise clie= nt POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only = return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-gen= erated internal ID of its own. In case the resource already has an identifi= er within the enterprise client's domain, then this is the internal ID that= must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and on= e of its attributes is multi-valued, e.g.,

 

    "email-addrs" :&n= bsp;

    [

        "john_smith@yahoo.com= ",

        "john.smith@gmail.com= ",

        "jsmith1970@hotmail.com= "

    ]

 

then on successful creation, the server r= esponse should include the representation of the resource, and this attribu= te should look like this:

 

    "email-addrs" :&n= bsp;

    [

        { "7dfcb= 444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" },

        { "3bd10= 085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" },

        { "581da= 5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com" }

    ]

 

The client now knows what each value is l= abelled. This now provides an unambiguous way to reference a value to add, = modify and delete it:

 

Add:

 

POST /Users/2819c223-7f76-453a-919d-41386= 1904646/email-addrs

value=3D"js70@easy.com.au"

 

Modify:

 

PUT /Users/2819c223-7f76-453a-919d-413861= 904646/email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

 

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413= 861904646/email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

 

One can even delete all email addresses l= ike this:

DELETE /Users/2819c223-7f76-453a-919d-413= 861904646/email-addrs

 

I believe this is more elegant than what = the spec recommends.

 

3. It's possible to think of the operatio= ns POST, PUT and DELETE as nested operations inside a PATCH. PATCH itself n= eed not be nested because its semantics apply throughout the "tree&quo= t; of a resource.

 

However, the semantics of PUT are a littl= e messy. Also, the use of HTTP verbs at a different level could be confusin= g. That's why I would recommend 6 separate verbs that are a little more una= mbiguous in their meaning:

 

1. INCLUDE (equivalent to POST): Add this= resource to a collection and return a generated URI

2. PLACE (equivalent to one form of PUT):= Add this resource at the location specified by the accompanying URI. (If t= here’s already a value at that location, return an error status.)

3. REPLACE (equivalent to another form of= PUT): Replace the value at the location specified by the accompanying URI = with this value. (If there’s no such URI, return an error status.)

4. FORCE (equivalent to a third form of P= UT): This means PLACE or REPLACE. (At the end of this operation, we want th= e specified URI to hold the accompanying value whether the URI already exis= ted or not.)

5. RETIRE (equivalent to DELETE): Delete,= deactivate or otherwise render inaccessible the resource at the specified = URI.

6. AMEND (equivalent to PATCH): (This ver= b is just listed for completeness. We probably don’t need a nested PA= TCH since PATCH cascades to every level of the tree.)

 

A PATCH request could therefore look like= this:

 

PATCH /Users/2819c223-7f76-453a-919d-4138= 61904646 HTTP/1.1

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

 

{

    REPLACE: {

        "key&quo= t; : "first-name",

        "value&q= uot; : "Jack"

    },

    PLACE : {

        "key&quo= t; : "middle-name",

        "value&q= uot; : "Richard"

    },

    FORCE : {

        "key&quo= t; : "dob",

        "value&q= uot; : "01-Jan-1971"

    },

    REPLACE : {

        "key&quo= t; : "address.unit-number",

        "value&q= uot; : "12"

    },

    PLACE : {

        "key&quo= t; : "address.state",

        "value&q= uot; : "SA"

    },

    FORCE : {

        "key&quo= t; : "address.country",

        "value&q= uot; : "Australia"

    },

    INCLUDE : {

        "key&quo= t; : "email-addrs",

        "value&q= uot; : "js70@eas= y.com.au"

    },

    REPLACE : {

        "key&quo= t; : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value&q= uot; : "jo= hn.r.smith@gmail.com"

    },

    RETIRE : {

        "key&quo= t; : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

}

 

The PATCH response should utilise the sta= tus code "207 Multi-Status" because the nested operations could h= ave varying status codes. A sample response is below:

 

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

 

{

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

    "external-id":&qu= ot;2819c223-7f76-453a-919d-413861904646",

    REPLACE: {

        "status&= quot; : "200 OK",

        "key&quo= t; : "first-name",

        "value&q= uot; : "Jack"

    },

    PLACE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "middle-name",

        "value&q= uot; : "Richard"

    },

    FORCE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "dob",

        "value&q= uot; : "01-Jan-1971"

    },

    REPLACE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "address.unit-number",

        "value&q= uot; : "12"

    },

    PLACE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "address.state",

        "value&q= uot; : "SA"

    },

    FORCE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "address.country",

        "value&q= uot; : "Australia"

    },

    INCLUDE : {

        "status&= quot; : "201 Created",

        "key&quo= t; : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",

        "value&q= uot; : "js70@eas= y.com.au"

    },

    REPLACE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value&q= uot; : "jo= hn.r.smith@gmail.com"

    },

    RETIRE : {

        "status&= quot; : "200 OK",

        "key&quo= t; : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

    "meta": {

        "created= ":"2011-08-08T04:56:22Z",

        "lastMod= ified":"2011-08-08T08:00:12Z",

        "version= ":"W\/\"b431af54f0671a2\""

    }

}

 

If there are errors, they will take the p= lace of the "200 OK" or "201 Created" status codes in t= he above successful case. But the outer status will remain "207 Multi-= Status".

 

The same scheme can be used to deal with = operations on members of a group, and for bulk operations.

 

I hope you find these suggestions useful.=

 

I read the SCIM spec afresh last week and= these ideas came flooding into my head because I have been working at anot= her organisation (a telco) for the last 5 months, also in Identity and Acce= ss Management, and my thoughts have moved further along the direction of evolving a specialised data model bas= ed on specific principles, especially for IAM.

 

I am planning to write about this and als= o the data-related principles soon and am in negotiations with InfoQ regard= ing publication.

 

Regards,

Ganesh Prasad

 

 



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.
 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4BA20whistlerentgart_-- From prateek.mishra@oracle.com Thu Aug 9 14:41:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE2E21F8690 for ; Thu, 9 Aug 2012 14:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO0ECUJsZN6I for ; Thu, 9 Aug 2012 14:41:06 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id D300121F8604 for ; Thu, 9 Aug 2012 14:40:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79LenxK004130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 21:40:49 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79LemTu021180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 21:40:48 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79LemKJ024257; Thu, 9 Aug 2012 16:40:48 -0500 Received: from [10.159.182.73] (/10.159.182.73) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 14:40:47 -0700 Message-ID: <50242E5B.40500@oracle.com> Date: Thu, 09 Aug 2012 17:40:43 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <20120809212548.BFA4D21F8605@ietfa.amsl.com> In-Reply-To: <20120809212548.BFA4D21F8605@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050002080609040807060102" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "Diodati,Mark" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:41:19 -0000 This is a multi-part message in MIME format. --------------050002080609040807060102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Mark - what is the basis of these strong opinions? I dont see any evidence or support for your statements in your message below. I am a member of this working group, and I dont agree with you. This is an IETF mailing list meant for discussion of an emerging technology, its possible you are not familiar with this type of discussion. In that case, I encourage you to educate yourself in this area. Thanks, prateek > > Hi Ganesh, > > --It would be good to hear the spectrum of opinions ... > > My assessment is that your proposal adds complexity, strays from the > initial simplicity goals of SCIM, and hinders service provider > adoption (which is crucial to the success of SCIM). I speak only for > myself, but in my conversations with others in the WG, no one > supported your proposal. > > Mark > > Mark Diodati > > Research Vice President | Gartner > > phone: +1 312.238.9877 > > blog: http://blogs.gartner.com/mark-diodati > > twitter: mark_diodati > > *From:*Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Thursday, August 09, 2012 4:15 PM > *To:* Kelly Grizzle > *Cc:* scim@ietf.org; Emmanuel Dreux > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > > storing this information in a mapping table outside of the SCIM spec > is a great way to enable this solution. Part of the key here is that > SCIM is just a piece of the architecture for this solution, and is > only responsible for the transport layer between domains. > > I wasn't suggesting that the mapping table be part of the SCIM spec. I > provided that example to illustrate that splitting and merging > identities is a common requirement, and that decoupling local > identifiers within a domain from shared identifiers between domains > was the best way to facilitate it. > > I'm suggesting that the spec do less, not more. > > What the SCIM spec needs to do there is just refrain from introducing > tight coupling. I would like to see a single identifier exposed > through the API, with the implication (and perhaps the recommendation) > that it be the shared one. Allowing one domain to expose its internal > identifier to the other creates tight coupling and ensures that both > domains need simultaneously split or merge identities, which is not > desirable. So I recommend _taking out_ the "external id" field from > the API. The spec shouldn't encourage tight coupling. If clients want > to pass in their internal ids as part of the resource body, no one can > stop them, and they can always do a search on that attribute to > retrieve the URI exactly as you visualise they will with the "external > id", but let's not elevate an anti-pattern to a recommendation by > enshrining the "external id" as an acceptable attribute. > > Am I making sense? > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. > On the other hand it puts extra burden on service providers. > > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. > You know where I stand on this. It would be good to hear the spectrum > of opinions. > > Regards, > > Ganesh > > On 10 August 2012 00:28, Kelly Grizzle > wrote: > > Thanks Emmanuel. I had started writing up a similar response. As you > suggest, storing this information in a mapping table outside of the > SCIM spec is a great way to enable this solution. Part of the key > here is that SCIM is just a piece of the architecture for this > solution, and is only responsible for the transport layer between domains. > > You could also model these ID mappings in the SCIM user as an > extension but would probably not want to expose these externally. > Here is an example of how to model the end state of the false positive > scenario (splitting a user): > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | > true | > > This could be represented as two SCIM users that contain information > about the entities on other domains. > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > } > > ] > > } > > } > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "a99a5feba839", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "7a87f27c1dd8" > > } > > ] > > } > > } > > In the second user, the linkedUsers attribute would be empty until the > split user was synced to domain 2. > > Similarly, the false negative use case (merging two users) looked like > this at the end: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | > false | > > This could be represented with the following SCIM user: > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > }, > > { > > "domain": "D2", > > "externalEntityId": "41206cc97c8b", > > "deletionRequired": true > > } > > ] > > } > > } > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. > On the other hand it puts extra burden on service providers. Since > the inception of SCIM, a key goal has been to foster adoption by > service providers by making things fit easily onto existing systems. > IMO the value gained by unique identifiers for multi-valued attributes > is not worth the demands put on a service provider. I also think that > vendors that have a non-SCIM-compliant API will choose to keep things > that way if the spec is too hard for them to implement. In a green > field environment we do have the luxury of mandating a model to make > certain operations more elegant. However, we can't ignore legacy systems. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Ganesh, > > Nothing prevents you in your SCIM implementation (client or server) to > generate a unique identifier for each synchronized object and maintain > an internal mapping table ( you would have to map group membership as > well). > > This is what we are doing with Active Directory sources or targets: > > As we didn't find an immutable uniqueID in AD systems > (DN,samAccountName, UPN) are subject to change (even objectGuid can > change if an AD domain is migrated), we decided to generate and > maintain an internal table of ids. This fits your requirements as it > hides internal ids. > > This was written in dotnet and we have started a project to rewrite > our SCIM stack in PHP and will give it to the Open Source community. > This implementation will have a parameter : AllocateIds versus > UseExistingIDs. > > This will give the choice of "hiding" internalIDs or use them as > unique ID. > > You can also implement such feature without violating the SCIM specs, > or without asking to include it in the specs. > > -- > > Regards, > > Emmanuel Dreux > > http://www.cloudiway.com > > Tel: +33 4 26 78 17 58 > > Mobile: +33 6 47 81 26 70 > > skype: Emmanuel.Dreux > > *De :*Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoyé :* jeudi 9 août 2012 03:35 > *À :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Kelly, > > Thanks for your response. Let me first respond in brief to the two > main points you have made, and then elaborate on the first. > > 1.Why should domains not expose their internal identifiers to other > domains? > > a. > > We are designing a protocol for a federated system of domains, where > all domains are co-equal peers. (In physics too, N-body problems are > much harder than 2-body problems. :-) Therefore, assuming that there > are only two players in the interaction makes this tightly coupled in > a number of ways. We should rely on messaging and notification, with > encapsulation of domain-specific data. > > b. > > In any non-trivial data store, there will always be the ongoing need > to merge and split identities as and when "false negatives" and "false > positives" are discovered. A domain should be able to handle this > internal housekeeping freely, only notifying other domains when > convenient. Mapping of internal identifiers to external ones and > maintaining this mapping internally allows this loosely-coupled > housekeeping to take place. Sharing internal identifiers (or otherwise > outsourcing the mapping of internal to external identifiers) forces > housekeeping activities to be done in lock-step across domains. > > c. > > Asynchronous interaction is not just a matter of a suitable wire > protocol which can be designed later. The data model plays a crucial > role in enabling or constraining such interaction. A tightly-coupled > data model will force the use of synchronous interactions, and the > exposure of internal identifiers is a key part of this tight coupling. > > 2. The difficulty of assigning unique identifiers to the individual > values of multi-valued attributes: > > a. > > I'm not belittling the effort involved in migrating legacy data stores > to such a model. However, in the larger historical context of > cross-domain identity management, we are really at the very early > stages. If a relatively new discipline and a brand new spec are held > captive to legacy considerations, we are losing an opportunity to > provide a clean and elegant model to subsequent users of the spec, and > this will have repercussions over many years or even decades. > > b. > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can > transition to this model by offering both "SCIM-compliant" and > "non-SCIM-compliant" APIs to their customers and encouraging new > customers to adopt the "SCIM-compliant" API. Legacy customers can be > supported using a "non-SCIM-compliant" API for an arbitrarily long > period and gradually migrated to the SCIM-compliant API. The logistics > are not insurmountable, and shouldn't prevent the adoption of a > dictionary model for multi-valued attributes. > > Elaboration of Point 1: > > When we consider federated identity across more than one domain, we > have to assume that domains are not necessarily master-slave in their > interaction. The most generic interaction model is peer-to-peer, where > entity lifecycle events within a domain are notified to other domains > (when necessary) in an asynchronous manner (i.e., through messaging) > and the other domains are free to respond to these events in an > appropriate manner and at a time of their convenience. > > A key set of lifecycle events for an entity is the merging and > splitting of identity that is often required. > > The question "Is this one entity?" can be answered either yes > (positive) or no (negative). But sometimes, we can discover false > positives and false negatives in our data stores. > > Consider a case where customers sign up online, and two customers who > are privacy-conscious enter fake IDs such as "John Smith", and also > use the same date of birth (say, 1 Jan 1970) or similar attributes. > The front-end application may make an intelligent (but incorrect) > guess that these two persons are the same, and re-assign the same > identifier to the second person. This is a false positive. They appear > to be the same entity, but they're actually different. When the error > is discovered, the identities will need to be split, with a new > identifier generated for one of them. > > Consider the opposite case where a customer signs up through two > different portals or in two different sessions, using the names > "JSmith" and "JohnS". It is very likely that they will be treated as > two different customers and assigned two unique identifiers. This is a > false negative. They appear to be two entities, but are actually the > same. At a later stage, when the error is discovered, the identities > will have to be merged, and one of the identifiers will have to be > dropped. > > These are not theoretical use cases. They form a significant > proportion of the user base in most large Web-facing applications. > Let's see how these can be managed in a federated way by mapping > internal identifiers to external ones and only exposing external > identifiers to other domains. > > a. False positives: > > Domain 1 has the following information about a customer in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > When requesting the provisioning of this entity in Domain 2, the > following ID is returned by Domain 2: ff487230b3a0. > > Domain 1 then maintains the following in a mapping table and uses it > for translation when talking to Domain 2, taking care never to expose > its internal identifier: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > When the false positive is discovered and the entity is split, Domain > 1 creates a new internal identifier and now has the following entity > information. > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > Internal ID: a99a5feba839 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > This second entity with its own internal identifier is invisible to > Domain 2, and this is by design. Communication about the original > entity takes place as before by mapping "9caf78aac3d6" to > "ff487230b3a0" and vice-versa. At some convenient time (importantly, > this doesn't have to be at the time the split happens), Domain 2 can > be requested to provision a second entity, and when it responds with > an identifier of "7a87f27c1dd8", this can go into the mapping table as > a new record associated with the second entity's internal identifier. > > The mapping table now contains the following entries: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > > Domain 2 is not even aware that a split has happened, and the > provisioning that it does is not in lockstep with the split in > identity that occurred in Domain 1. > > (What is the "Primary flag" used for? We'll see when we cover the > treatment of false negatives.) > > b. False negatives: > > Domain 1 has the following information about what it thinks are two > distinct customers in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "JSmith", dob: "01-Jan-1970"} > > Internal ID: 273d36e30d09 > > Attributes: {name: "JohnS", dob: "01-Jan-1970"} > > When requesting the provisioning of these entities in Domain 2, the > following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > > Domain 1 then maintains the following in a mapping table and uses it > for translation when talking to Domain 2, taking care never to expose > its internal identifiers: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 273d36e30d09 | D2 | 41206cc97c8b | true | > > When the false negative is discovered and the two entities are merged, > Domain 1 drops one of the internal identifiers and rationalises the > name of the customer (say, to "John Smith"). Let's say it retains the > first ID "9caf78aac3d6" and drops the second "273d36e30d09". > > The mapping table now looks like this: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > > Now two external identifiers map to the same internal one, so inbound > communication from Domain 2 can be unambiguously translated to the > same entity internally. However, when going outwards, Domain 1 will > have to look up the translation table to determine the "primary" > external ID for this entity in Domain 2, which was decided to be > "ff487230b3a0". That's where the "Primary flag" comes in. The second > external ID "41206cc97c8b" is never used thereafter in outbound > communication. > > At some stage (importantly, not in lockstep with the identity merge), > Domain 2 can be requested to delete the customer record identified by > "41206cc97c8b", and the second entry in the mapping table can be > removed once this is acknowledged. > > This scheme will scale up to multiple domains, because the "External > Domain ID" column helps to keep track of which external ID is shared > with which Domain. (Why don't we use just one external ID for an > entity and share it with all external domains? Tight coupling again. > Just as OAuth allows an access token given to a third party to be > invalidated without affecting the access of other third parties, the > use of separate external identifiers for different domains allows > fine-grained control of identity federation.) > > The scheme also allows the splitting of an entity into more than two > entities, and the merging of more than two entities into a single one. > (Any organisation with a web-facing application will tell you how many > John Smiths there are who were born on 1 Jan 1970!) > > This is a fairly long-winded explanation, but this is why we need to > hide internal identifiers from other domains, and why mappings need to > be managed internally in each domain. Such a data model also allows us > to choose asynchronous protocols for propagation of identity events, > since there is no consistency requirement to update multiple domains > concurrently. > > Regards, > > Ganesh Prasad > > On 9 August 2012 04:55, Kelly Grizzle > wrote: > > Thanks for the feedback, Ganesh. I read through this and your InfoQ > article (http://www.infoq.com/articles/scim-data-model-limitations) > and have some thoughts. > > > The rest of the protocol does not meaningfully use the enterprise > client's identifier, the "external ID" > > > at all, even though it was ostensibly introduced to make things friendlier for the client. > > The usage pattern for an external ID would be to search for a user by > externalId and use the ID of the returned user in any desired > operation. For example: > > GET /Users?filter=externalId eq "bjensen"&attributes=id > > { > > "totalResults": 1, > > "Resources": [ > > { > > "id": "2819c223-7f76-453a-919d-413861904646" > > } > > ] > > } > > Retrieve the ID from the response and use it. > > DELETE /Users/2819c223-7f76-453a-919d-413861904646 > > This does introduce an additional HTTP request if the client chooses > not to store the server's id. An issue was created to consider > allowing operations to use the externalId > (http://code.google.com/p/scim/issues/detail?id=35), but I believe the > general consensus has been to not include this in the spec. One main > point of contention is that much of the rest of the spec (eg -- group > membership references, manager references, etc...) require knowledge > of the server's identifier. Continuing this discussion on the IETF > list would be a good thing, though. > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains > > I think this comes down to a nomenclature problem. The server's ID > does not necessarily have to be the unique identifier that the > underlying identity store uses, it just has to be stable and unique. > In many cases, the underlying identity store will provide identifiers > with these properties already (eg -- a uuid) and it can be used by the > SCIM interface. The "externalId" is referring to the fact that the id > is maintained external to the SCIM server. As long as the server's > identifiers are stable and unique (which is mandated by the spec), I > don't see a problem. > > > The secret is that /every value needs a key/, and multi-valued > attributes lack that. So our solution is quite > > > simple - turn every list or array (of values) into a dictionary (of key-value pairs) by > providing each value > > > with a unique and meaning-free identifier. > > I agree that this would be useful, especially in the PATCH operation. > One reason that this wasn't included in the spec originally is that it > can put undue burden on the service provider. Many service providers > are putting SCIM interfaces in front of their existing identity stores > (eg -- directory servers, SaaS application databases, etc...). Many > of these do not have a unique identifier for multi-valued attributes. > By requiring this, a majority of the server providers would have to > start maintaining a unique key for each multi-valued attribute. I > believe this would be a roadblock for many implementers. > > > When the SCIM protocol uses PATCH, there are areas where it seems a > bit clumsy. > > I like the thoughts here. Your example reminds me of unified diffs > (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly > used with a patch program (pretty much the equivalent of the PATCH > verb). However, the three proposals seem to largely hinge on being > able to uniquely address each element within an object. Without these > it is not so easy to address each patch sub-operation (REPLACE, > INCLUDE, etc...) or provide a multi-status. > > > The 207 response would be interesting to consider for the bulk > endpoint > (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however. > > > There are other, non-data aspects of SCIM which may require review, > such as its synchronous request-response > > > interaction model, which is a form of tight coupling and could prove to be a source of > brittleness. > > I agree that we should explore optional asynchronous requests in 2.0. > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement > > (I posted this on the SCIM Google Group, and I was advised to > subscribe to the mailing list and post it here instead, so here goes.) > > Hi, > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian > insurance company, an experience I have written about as a eBook on > InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoestring). > > I have been following the SCIM spec off and on, and based on my > experience with a loosely-coupled architecture that I found to be > successful, I have the following 3 suggestions to make. > > 1. The enterprise client and the cloud provider should maintain their > own internal IDs for a resource, which they should not reveal to each > other. Both of them should map their internal IDs to a shared External > ID, and this is the only ID that should be exposed through the API. > The current specification's provision of an id (which is the external > ID and the only one to be transferred through the API) and an > "external ID" (which is the client's internal ID and should be hidden) > is diametrically opposite to this. > > 2. When dealing with multi-valued attributes of a resource (expressed > as arrays in JSON), they must be converted from an array into a > dictionary with unique keys (UUIDs generated by the cloud provider > when the attribute is created). Without unique keys for every > attribute value of a resource, manipulating it will be clumsy and > inelegant. > > 3. The PATCH command can be improved in 3 significant ways: > > 3a. Leverage the fact (from 2 above) that every value has a key, to > greatly simplify the API > > 3b. Use special verbs as nested operations of the PATCH command to > add, modify and delete attributes at any level > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 > OK" as the response to a PATCH (or BULK) command. > > To elaborate, > > 1. Revealing private IDs externally is a form of tight coupling. A > major requirement with Identity Management is to split (or merge) > identities when false positives (or false negatives) are detected, > i.e., when a resource is discovered to be more than one, or when > multiple resources are detected to be the same. If internal > identifiers are revealed to external domains, such clean-ups become > difficult, hence every domain that wants to expose references to a > resource must map its internal ID to and external one created for this > explicit purpose, and only reveal this. > > In the SCIM case, when an enterprise client POSTs a resource creation > request, the cloud provider must generate its own internal UUID as > well as an external UUID, map them together, and only return the > external UUID in the "Location:" header. The enterprise client should > map this external UUID to a newly-generated internal ID of its own. In > case the resource already has an identifier within the enterprise > client's domain, then this is the internal ID that must be mapped to > the external UUID returned through the POST response. > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g., > > "email-addrs" : > > [ > > "john_smith@yahoo.com ", > > "john.smith@gmail.com ", > > "jsmith1970@hotmail.com " > > ] > > then on successful creation, the server response should include the > representation of the resource, and this attribute should look like this: > > "email-addrs" : > > [ > > { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : > "john_smith@yahoo.com " }, > > { "3bd10085-c474-43b9-9cda-8646c3085bbf" : > "john.smith@gmail.com " }, > > { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : > "jsmith1970@hotmail.com " } > > ] > > The client now knows what each value is labelled. This now provides an > unambiguous way to reference a value to add, modify and delete it: > > Add: > > POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs > > value="js70@easy.com.au " > > Modify: > > PUT > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf > > value="john.r.smith@gmail.com " > > Delete: > > DELETE > /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1 > > One can even delete all email addresses like this: > > DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs > > I believe this is more elegant than what the spec recommends. > > 3. It's possible to think of the operations POST, PUT and DELETE as > nested operations inside a PATCH. PATCH itself need not be nested > because its semantics apply throughout the "tree" of a resource. > > However, the semantics of PUT are a little messy. Also, the use of > HTTP verbs at a different level could be confusing. That's why I would > recommend 6 separate verbs that are a little more unambiguous in their > meaning: > > 1. INCLUDE (equivalent to POST): Add this resource to a collection and > return a generated URI > > 2. PLACE (equivalent to one form of PUT): Add this resource at the > location specified by the accompanying URI. (If there's already a > value at that location, return an error status.) > > 3. REPLACE (equivalent to another form of PUT): Replace the value at > the location specified by the accompanying URI with this value. (If > there's no such URI, return an error status.) > > 4. FORCE (equivalent to a third form of PUT): This means PLACE or > REPLACE. (At the end of this operation, we want the specified URI to > hold the accompanying value whether the URI already existed or not.) > > 5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise > render inaccessible the resource at the specified URI. > > 6. AMEND (equivalent to PATCH): (This verb is just listed for > completeness. We probably don't need a nested PATCH since PATCH > cascades to every level of the tree.) > > A PATCH request could therefore look like this: > > PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1 > > Host: example.com > > Accept: application/json > > Authorization: Bearer h480djs93hd8 > > Content-length: ... > > { > > REPLACE: { > > "key" : "first-name", > > "value" : "Jack" > > }, > > PLACE : { > > "key" : "middle-name", > > "value" : "Richard" > > }, > > FORCE : { > > "key" : "dob", > > "value" : "01-Jan-1971" > > }, > > REPLACE : { > > "key" : "address.unit-number", > > "value" : "12" > > }, > > PLACE : { > > "key" : "address.state", > > "value" : "SA" > > }, > > FORCE : { > > "key" : "address.country", > > "value" : "Australia" > > }, > > INCLUDE : { > > "key" : "email-addrs", > > "value" : "js70@easy.com.au " > > }, > > REPLACE : { > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", > > "value" : "john.r.smith@gmail.com " > > }, > > RETIRE : { > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" > > } > > } > > The PATCH response should utilise the status code "207 Multi-Status" > because the nested operations could have varying status codes. A > sample response is below: > > HTTP/1.1 207 Multi-Status > > Content-Type: application/json > > ETag: W/"b431af54f0671a2" > > Location:"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646" > > { > > "schemas":["urn:scim:schemas:core:1.0"], > > "external-id":"2819c223-7f76-453a-919d-413861904646", > > REPLACE: { > > "status" : "200 OK", > > "key" : "first-name", > > "value" : "Jack" > > }, > > PLACE : { > > "status" : "200 OK", > > "key" : "middle-name", > > "value" : "Richard" > > }, > > FORCE : { > > "status" : "200 OK", > > "key" : "dob", > > "value" : "01-Jan-1971" > > }, > > REPLACE : { > > "status" : "200 OK", > > "key" : "address.unit-number", > > "value" : "12" > > }, > > PLACE : { > > "status" : "200 OK", > > "key" : "address.state", > > "value" : "SA" > > }, > > FORCE : { > > "status" : "200 OK", > > "key" : "address.country", > > "value" : "Australia" > > }, > > INCLUDE : { > > "status" : "201 Created", > > "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0", > > "value" : "js70@easy.com.au " > > }, > > REPLACE : { > > "status" : "200 OK", > > "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf", > > "value" : "john.r.smith@gmail.com " > > }, > > RETIRE : { > > "status" : "200 OK", > > "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1" > > } > > "meta": { > > "created":"2011-08-08T04:56:22Z", > > "lastModified":"2011-08-08T08:00:12Z", > > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", > > "version":"W\/\"b431af54f0671a2\"" > > } > > } > > If there are errors, they will take the place of the "200 OK" or "201 > Created" status codes in the above successful case. But the outer > status will remain "207 Multi-Status". > > The same scheme can be used to deal with operations on members of a > group, and for bulk operations. > > I hope you find these suggestions useful. > > I read the SCIM spec afresh last week and these ideas came flooding > into my head because I have been working at another organisation (a > telco) for the last 5 months, also in Identity and Access Management, > and my thoughts have moved further along the direction of evolving a > specialised data model based on specific principles, especially for IAM. > > I am planning to write about this and also the data-related principles > soon and am in negotiations with InfoQ regarding publication. > > Regards, > > Ganesh Prasad > > > ------------------------------------------------------------------------ > > This e-mail message, including any attachments, is for the sole use of > the person to whom it has been sent, and may contain information that > is confidential or legally protected. If you are not the intended > recipient or have received this message in error, you are not > authorized to copy, distribute, or otherwise use this message or its > attachments. Please notify the sender immediately by return e-mail and > permanently delete this message and any attachments. Gartner makes no > warranty that this e-mail is error or virus free. > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------050002080609040807060102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mark -

what is the basis of these strong opinions? I dont see any evidence or support for your statements in your message below.

I am a member of this working group, and I dont agree with you.

This is an IETF mailing list meant for discussion of an emerging technology, its possible you are not familiar with this type of discussion.
In that case, I encourage you to educate yourself in this area.

Thanks,
prateek

Hi Ganesh,

 

--It would be good to hear the spectrum of opinions …

 

My assessment is that your proposal adds complexity, strays from the initial simplicity goals of SCIM, and hinders service provider adoption (which is crucial to the success of SCIM). I speak only for myself, but in my conversations with others in the WG, no one supported your proposal.

 

Mark

 

 

Mark Diodati

Research Vice President | Gartner

phone: +1 312.238.9877

blog: http://blogs.gartner.com/mark-diodati

twitter: mark_diodati

 

 

 

 

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Thursday, August 09, 2012 4:15 PM
To: Kelly Grizzle
Cc: scim@ietf.org; Emmanuel Dreux
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

>  storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provided that example to illustrate that splitting and merging identities is a common requirement, and that decoupling local identifiers within a domain from shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain from introducing tight coupling. I would like to see a single identifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight coupling and ensures that both domains need simultaneously split or merge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their internal ids as part of the resource body, no one can stop them, and they can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting to hear from the other members of the spec mailing list. You know where I stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains.

 

You could also model these ID mappings in the SCIM user as an extension but would probably not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| a99a5feba839       | D2                 | 7a87f27c1dd8       | true         |

 

This could be represented as two SCIM users that contain information about the entities on other domains.

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

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

  "id": "a99a5feba839",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the linkedUsers attribute would be empty until the split user was synced to domain 2.

 

 

Similarly, the false negative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| 9caf78aac3d6       | D2                 | 41206cc97c8b       | false        |

 

This could be represented with the following SCIM user:

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      },

      {

        "domain": "D2",

        "externalEntityId": "41206cc97c8b",

        "deletionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a key goal has been to foster adoption by service providers by making things fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that vendors that have a non-SCIM-compliant API will choose to keep things that way if the spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can’t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation (client or server) to generate a unique identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing with Active Directory sources or targets:

As we didn’t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits your requirements as it hides internal ids.

 

This was written in dotnet and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice of “hiding” internalIDs or use them as unique ID.

 

You can also implement such feature without violating the SCIM specs, or without asking to include it in the specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoyé : jeudi 9 août 2012 03:35
À : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Kelly,

Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first.

1.      Why should domains not expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when “false negatives” and “false positives” are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling.

2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both “SCIM-compliant” and “non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers can be supported using a “non-SCIM-compliant” API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is the merging and splitting of identity that is often required.

The question “Is this one entity?” can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as “John Smith”, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names “JSmith” and “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.

a. False positives:

Domain 1 has the following information about a customer in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information.

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

Internal ID: a99a5feba839

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's internal identifier.

The mapping table now contains the following entries:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1.

(What is the “Primary flag” used for? We'll see when we cover the treatment of false negatives.)

b. False negatives:

Domain 1 has the following information about what it thinks are two distinct customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “JSmith”, dob: “01-Jan-1970”}

Internal ID: 273d36e30d09

Attributes: {name: “JohnS”, dob: “01-Jan-1970”}

When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 273d36e30d09 | D2 | 41206cc97c8b | true |

When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the second “273d36e30d09”.

The mapping table now looks like this:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambiguously translated to the same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to determine the “primary” external ID for this entity in Domain 2, which was decided to be “ff487230b3a0”. That's where the “Primary flag” comes in. The second external ID “41206cc97c8b” is never used thereafter in outbound communication.

At some stage (importantly, not in lockstep with the identity merge), Domain 2 can be requested to delete the customer record identified by “41206cc97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

This scheme will scale up to multiple domains, because the “External Domain ID” column helps to keep track of which external ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling again. Just as OAuth allows an access token given to a third party to be invalidated without affecting the access of other third parties, the use of separate external identifiers for different domains allows fine-grained control of identity federation.)

The scheme also allows the splitting of an entity into more than two entities, and the merging of more than two entities into a single one. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This is a fairly long-winded explanation, but this is why we need to hide internal identifiers from other domains, and why mappings need to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of identity events, since there is no consistency requirement to update multiple domains concurrently.

Regards,

Ganesh Prasad

 

On 9 August 2012 04:55, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not meaningfully use the enterprise client’s identifier, the "external ID"

> at all, even though it was ostensibly introduced to make things friendlier for the client.

 

The usage pattern for an external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.  For example:

 

GET /Users?filter=externalId eq “bjensen”&attributes=id

 

{

  “totalResults”: 1,

  “Resources”: [

    {

      “id”: “2819c223-7f76-453a-919d-413861904646”

    }

  ]

}

 

Retrieve the ID from the response and use it.

 

DELETE /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if the client chooses not to store the server’s id.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/detail?id=35), but I believe the general consensus has been to not include this in the spec.  One main point of contention is that much of the rest of the spec (eg – group membership references, manager references, etc…) require knowledge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterprise client's ID are both "Internal IDs" with respect to their domains

 

I think this comes down to a nomenclature problem.  The server’s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the underlying identity store will provide identifiers with these properties already (eg – a uuid) and it can be used by the SCIM interface.  The “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server’s identifiers are stable and unique (which is mandated by the spec), I don’t see a problem.

 

 

> The secret is that every value needs a key, and multi-valued attributes lack that. So our solution is quite

> simple - turn every list or array (of values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free identifier.

 

I agree that this would be useful, especially in the PATCH operation.  One reason that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are putting SCIM interfaces in front of their existing identity stores (eg – directory servers, SaaS application databases, etc…).  Many of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers would have to start maintaining a unique key for each multi-valued attribute.  I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, there are areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of the PATCH verb).  However, the three proposals seem to largely hinge on being able to uniquely address each element within an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-status.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which may require review, such as its synchronous request-response

> interaction model, which is a form of tight coupling and could prove to be a source of brittleness.

 

I agree that we should explore optional asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for improvement

 

(I posted this on the SCIM Google Group, and I was advised to subscribe to the mailing list and post it here instead, so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience in Identity and Access Management is mainly through a 3-year project at an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoestring).

 

I have been following the SCIM spec off and on, and based on my experience with a loosely-coupled architecture that I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider should maintain their own internal IDs for a resource, which they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should be exposed through the API. The current specification's provision of an id (which is the external ID and the only one to be transferred through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significant ways:

3a. Leverage the fact (from 2 above) that every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tight coupling. A major requirement with Identity Management is to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the same. If internal identifiers are revealed to external domains, such clean-ups become difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one created for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client POSTs a resource creation request, the cloud provider must generate its own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated internal ID of its own. In case the resource already has an identifier within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its attributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

    ]

 

then on successful creation, the server response should include the representation of the resource, and this attribute should look like this:

 

    "email-addrs" : 

    [

        { "7dfcb444-74d8-4f17-aa66-daf9ea3bd902" : "john_smith@yahoo.com" },

        { "3bd10085-c474-43b9-9cda-8646c3085bbf" : "john.smith@gmail.com" },

        { "581da5c7-c6e1-4cca-9db7-7a6d1de664e1" : "jsmith1970@hotmail.com" }

    ]

 

The client now knows what each value is labelled. This now provides an unambiguous way to reference a value to add, modify and delete it:

 

Add:

 

POST /Users/2819c223-7f76-453a-919d-413861904646/email-addrs

 

Modify:

 

PUT /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf

 

Delete:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1

 

One can even delete all email addresses like this:

DELETE /Users/2819c223-7f76-453a-919d-413861904646/email-addrs

 

I believe this is more elegant than what the spec recommends.

 

3. It's possible to think of the operations POST, PUT and DELETE as nested operations inside a PATCH. PATCH itself need not be nested because its semantics apply throughout the "tree" of a resource.

 

However, the semantics of PUT are a little messy. Also, the use of HTTP verbs at a different level could be confusing. That's why I would recommend 6 separate verbs that are a little more unambiguous in their meaning:

 

1. INCLUDE (equivalent to POST): Add this resource to a collection and return a generated URI

2. PLACE (equivalent to one form of PUT): Add this resource at the location specified by the accompanying URI. (If there’s already a value at that location, return an error status.)

3. REPLACE (equivalent to another form of PUT): Replace the value at the location specified by the accompanying URI with this value. (If there’s no such URI, return an error status.)

4. FORCE (equivalent to a third form of PUT): This means PLACE or REPLACE. (At the end of this operation, we want the specified URI to hold the accompanying value whether the URI already existed or not.)

5. RETIRE (equivalent to DELETE): Delete, deactivate or otherwise render inaccessible the resource at the specified URI.

6. AMEND (equivalent to PATCH): (This verb is just listed for completeness. We probably don’t need a nested PATCH since PATCH cascades to every level of the tree.)

 

A PATCH request could therefore look like this:

 

PATCH /Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1

Accept: application/json

Authorization: Bearer h480djs93hd8

Content-length: ...

 

{

    REPLACE: {

        "key" : "first-name",

        "value" : "Jack"

    },

    PLACE : {

        "key" : "middle-name",

        "value" : "Richard"

    },

    FORCE : {

        "key" : "dob",

        "value" : "01-Jan-1971"

    },

    REPLACE : {

        "key" : "address.unit-number",

        "value" : "12"

    },

    PLACE : {

        "key" : "address.state",

        "value" : "SA"

    },

    FORCE : {

        "key" : "address.country",

        "value" : "Australia"

    },

    INCLUDE : {

        "key" : "email-addrs",

        "value" : "js70@easy.com.au"

    },

    REPLACE : {

        "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value" : "john.r.smith@gmail.com"

    },

    RETIRE : {

        "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

}

 

The PATCH response should utilise the status code "207 Multi-Status" because the nested operations could have varying status codes. A sample response is below:

 

HTTP/1.1 207 Multi-Status

Content-Type: application/json

ETag: W/"b431af54f0671a2"

 

{

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

    "external-id":"2819c223-7f76-453a-919d-413861904646",

    REPLACE: {

        "status" : "200 OK",

        "key" : "first-name",

        "value" : "Jack"

    },

    PLACE : {

        "status" : "200 OK",

        "key" : "middle-name",

        "value" : "Richard"

    },

    FORCE : {

        "status" : "200 OK",

        "key" : "dob",

        "value" : "01-Jan-1971"

    },

    REPLACE : {

        "status" : "200 OK",

        "key" : "address.unit-number",

        "value" : "12"

    },

    PLACE : {

        "status" : "200 OK",

        "key" : "address.state",

        "value" : "SA"

    },

    FORCE : {

        "status" : "200 OK",

        "key" : "address.country",

        "value" : "Australia"

    },

    INCLUDE : {

        "status" : "201 Created",

        "key" : "email-addrs/11f664ec-898b-4f6f-8948-ecfda74deff0",

        "value" : "js70@easy.com.au"

    },

    REPLACE : {

        "status" : "200 OK",

        "key" : "email-addrs/3bd10085-c474-43b9-9cda-8646c3085bbf",

        "value" : "john.r.smith@gmail.com"

    },

    RETIRE : {

        "status" : "200 OK",

        "key" : "email-addrs/581da5c7-c6e1-4cca-9db7-7a6d1de664e1"

    }

    "meta": {

        "created":"2011-08-08T04:56:22Z",

        "lastModified":"2011-08-08T08:00:12Z",

        "version":"W\/\"b431af54f0671a2\""

    }

}

 

If there are errors, they will take the place of the "200 OK" or "201 Created" status codes in the above successful case. But the outer status will remain "207 Multi-Status".

 

The same scheme can be used to deal with operations on members of a group, and for bulk operations.

 

I hope you find these suggestions useful.

 

I read the SCIM spec afresh last week and these ideas came flooding into my head because I have been working at another organisation (a telco) for the last 5 months, also in Identity and Access Management, and my thoughts have moved further along the direction of evolving a specialised data model based on specific principles, especially for IAM.

 

I am planning to write about this and also the data-related principles soon and am in negotiations with InfoQ regarding publication.

 

Regards,

Ganesh Prasad

 

 



This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.
 

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

--------------050002080609040807060102-- From phil.hunt@oracle.com Thu Aug 9 14:53:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D321F86D8 for ; Thu, 9 Aug 2012 14:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSrAQs4wp5xa for ; Thu, 9 Aug 2012 14:53:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id F299921F861D for ; Thu, 9 Aug 2012 14:53:27 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79LrMg2014620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Aug 2012 21:53:23 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q79LrLLq027965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Aug 2012 21:53:21 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q79LrKGl028608; Thu, 9 Aug 2012 16:53:20 -0500 Received: from [25.65.10.249] (/74.198.150.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Aug 2012 14:53:19 -0700 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-D8574484-A114-41C5-9C6F-E8498386BC59 Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Thu, 9 Aug 2012 14:53:12 -0700 To: Ganesh and Sashi Prasad X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 21:53:31 -0000 --Apple-Mail-D8574484-A114-41C5-9C6F-E8498386BC59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad wrot= e: > > storing this information in a mapping table outside of the SCIM spec is= a great way to enable this solution. Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains.=20 >=20 > I wasn't suggesting that the mapping table be part of the SCIM spec. I pro= vided that example to illustrate that splitting and merging identities is a c= ommon requirement, and that decoupling local identifiers within a domain fro= m shared identifiers between domains was the best way to facilitate it. >=20 > I'm suggesting that the spec do less, not more. >=20 > What the SCIM spec needs to do there is just refrain from introducing tigh= t coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the shared= one. Allowing one domain to expose its internal identifier to the other cre= ates tight coupling and ensures that both domains need simultaneously split o= r merge identities, which is not desirable. So I recommend _taking out_ the "= external id" field from the API. The spec shouldn't encourage tight coupling= . If clients want to pass in their internal ids as part of the resource body= , no one can stop them, and they can always do a search on that attribute to= retrieve the URI exactly as you visualise they will with the "external id",= but let's not elevate an anti-pattern to a recommendation by enshrining the= "external id" as an acceptable attribute. >=20 > Am I making sense? I see what you are saying. I think scim gets its current simplicity from its= single owner hub spoke model implementing tight coupling.=20 IMHO loose coupling is a much more complex solution. The reality is that eac= h end-point has value to contribute and thus the single-owner model will eve= ntually need to become multi-owner or multi-hub.=20 That said i think the current model provides a practical starting point.=20 >=20 > > Regarding unique identifiers for multi-valued attributes there is a tra= de-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers.=20 >=20 > Precisely. The spec has to strike the right balance. It would be interesti= ng to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. >=20 > Regards, > Ganesh >=20 > On 10 August 2012 00:28, Kelly Grizzle wrote= : > Thanks Emmanuel. I had started writing up a similar response. As you sug= gest, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsibl= e for the transport layer between domains. >=20 > =20 >=20 > You could also model these ID mappings in the SCIM user as an extension bu= t would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >=20 > =20 >=20 > This could be represented as two SCIM users that contain information about= the entities on other domains. >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "a99a5feba839", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "7a87f27c1dd8" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > In the second user, the linkedUsers attribute would be empty until the spl= it user was synced to domain 2. >=20 > =20 >=20 > =20 >=20 > Similarly, the false negative use case (merging two users) looked like thi= s at the end: >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >=20 > =20 >=20 > This could be represented with the following SCIM user: >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > }, >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "41206cc97c8b", >=20 > "deletionRequired": true >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > =20 >=20 > Regarding unique identifiers for multi-valued attributes there is a trade-= off involved. On one hand this makes PATCH semantics easier. On the other h= and it puts extra burden on service providers. Since the inception of SCIM,= a key goal has been to foster adoption by service providers by making thing= s fit easily onto existing systems. IMO the value gained by unique identifi= ers for multi-valued attributes is not worth the demands put on a service pr= ovider. I also think that vendors that have a non-SCIM-compliant API will c= hoose to keep things that way if the spec is too hard for them to implement.= In a green field environment we do have the luxury of mandating a model to= make certain operations more elegant. However, we can=E2=80=99t ignore leg= acy systems. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Em= manuel Dreux > Sent: Thursday, August 09, 2012 3:18 AM > To: Ganesh and Sashi Prasad; Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Ganesh, >=20 > =20 >=20 > Nothing prevents you in your SCIM implementation (client or server) to gen= erate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). >=20 > =20 >=20 > This is what we are doing with Active Directory sources or targets: >=20 > As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAccou= ntName, UPN) are subject to change (even objectGuid can change if an AD doma= in is migrated), we decided to generate and maintain an internal table of id= s. This fits your requirements as it hides internal ids. >=20 > =20 >=20 > This was written in dotnet and we have started a project to rewrite our SC= IM stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. >=20 > This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or use t= hem as unique ID. >=20 > =20 >=20 > You can also implement such feature without violating the SCIM specs, or w= ithout asking to include it in the specs. >=20 > =20 >=20 > -- >=20 > Regards, >=20 > Emmanuel Dreux >=20 > http://www.cloudiway.com >=20 > Tel: +33 4 26 78 17 58 >=20 > Mobile: +33 6 47 81 26 70 >=20 > skype: Emmanuel.Dreux >=20 > =20 >=20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 > =C3=80 : Kelly Grizzle > Cc : scim@ietf.org > Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Kelly, > Thanks for your response. Let me first respond in brief to the two main po= ints you have made, and then elaborate on the first. > 1. Why should domains not expose their internal identifiers to other d= omains? > a. > We are designing a protocol for a federated system of domains, where all d= omains are co-equal peers. (In physics too, N-body problems are much harder t= han 2-body problems. :-) Therefore, assuming that there are only two players= in the interaction makes this tightly coupled in a number of ways. We shoul= d rely on messaging and notification, with encapsulation of domain-specific d= ata. > b. > In any non-trivial data store, there will always be the ongoing need to me= rge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D and =E2= =80=9Cfalse positives=E2=80=9D are discovered. A domain should be able to ha= ndle this internal housekeeping freely, only notifying other domains when co= nvenient. Mapping of internal identifiers to external ones and maintaining t= his mapping internally allows this loosely-coupled housekeeping to take plac= e. Sharing internal identifiers (or otherwise outsourcing the mapping of int= ernal to external identifiers) forces housekeeping activities to be done in l= ock-step across domains. > c. > Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling o= r constraining such interaction. A tightly-coupled data model will force the= use of synchronous interactions, and the exposure of internal identifiers i= s a key part of this tight coupling. > 2. The difficulty of assigning unique identifiers to the individual values= of multi-valued attributes: > a. > I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain ident= ity management, we are really at the very early stages. If a relatively new d= iscipline and a brand new spec are held captive to legacy considerations, we= are losing an opportunity to provide a clean and elegant model to subsequen= t users of the spec, and this will have repercussions over many years or eve= n decades. > b. > If incumbent cloud providers find it hard to immediately adopt the diction= ary model for existing multi-valued attributes, they can transition to this m= odel by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-SCIM= -compliant=E2=80=9D APIs to their customers and encouraging new customers to= adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be sup= ported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrarily l= ong period and gradually migrated to the SCIM-compliant API. The logistics a= re not insurmountable, and shouldn't prevent the adoption of a dictionary mo= del for multi-valued attributes. > Elaboration of Point 1: > When we consider federated identity across more than one domain, we have t= o assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle e= vents within a domain are notified to other domains (when necessary) in an a= synchronous manner (i.e., through messaging) and the other domains are free t= o respond to these events in an appropriate manner and at a time of their co= nvenience. > A key set of lifecycle events for an entity is the merging and splitting o= f identity that is often required. > The question =E2=80=9CIs this one entity?=E2=80=9D can be answered either y= es (positive) or no (negative). But sometimes, we can discover false positiv= es and false negatives in our data stores. > Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and al= so use the same date of birth (say, 1 Jan 1970) or similar attributes. The f= ront-end application may make an intelligent (but incorrect) guess that thes= e two persons are the same, and re-assign the same identifier to the second p= erson. This is a false positive. They appear to be the same entity, but they= 're actually different. When the error is discovered, the identities will ne= ed to be split, with a new identifier generated for one of them. > Consider the opposite case where a customer signs up through two different= portals or in two different sessions, using the names =E2=80=9CJSmith=E2=80= =9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated= as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped. > These are not theoretical use cases. They form a significant proportion of= the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external o= nes and only exposing external identifiers to other domains. > a. False positives: > Domain 1 has the following information about a customer in its data store:= > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > When requesting the provisioning of this entity in Domain 2, the following= ID is returned by Domain 2: ff487230b3a0. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifier: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > When the false positive is discovered and the entity is split, Domain 1 cr= eates a new internal identifier and now has the following entity information= . > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > Internal ID: a99a5feba839 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > This second entity with its own internal identifier is invisible to Domain= 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b= 3a0=E2=80=9D and vice-versa. At some convenient time (importantly, this does= n't have to be at the time the split happens), Domain 2 can be requested to p= rovision a second entity, and when it responds with an identifier of =E2=80=9C= 7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record as= sociated with the second entity's internal identifier. > The mapping table now contains the following entries: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > Domain 2 is not even aware that a split has happened, and the provisioning= that it does is not in lockstep with the split in identity that occurred in= Domain 1. > (What is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we co= ver the treatment of false negatives.) > b. False negatives: > Domain 1 has the following information about what it thinks are two distin= ct customers in its data store: > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > Internal ID: 273d36e30d09 > Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > When requesting the provisioning of these entities in Domain 2, the follow= ing IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifiers: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 273d36e30d09 | D2 | 41206cc97c8b | true | > When the false negative is discovered and the two entities are merged, Dom= ain 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the f= irst ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the second =E2=80=9C273d36e= 30d09=E2=80=9D. > The mapping table now looks like this: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > Now two external identifiers map to the same internal one, so inbound comm= unication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the t= ranslation table to determine the =E2=80=9Cprimary=E2=80=9D external ID for t= his entity in Domain 2, which was decided to be =E2=80=9Cff487230b3a0=E2=80=9D= . That's where the =E2=80=9CPrimary flag=E2=80=9D comes in. The second exter= nal ID =E2=80=9C41206cc97c8b=E2=80=9D is never used thereafter in outbound c= ommunication. > At some stage (importantly, not in lockstep with the identity merge), Doma= in 2 can be requested to delete the customer record identified by =E2=80=9C4= 1206cc97c8b=E2=80=9D, and the second entry in the mapping table can be remov= ed once this is acknowledged. > This scheme will scale up to multiple domains, because the =E2=80=9CExtern= al Domain ID=E2=80=9D column helps to keep track of which external ID is sha= red with which Domain. (Why don't we use just one external ID for an entity a= nd share it with all external domains? Tight coupling again. Just as OAuth a= llows an access token given to a third party to be invalidated without affec= ting the access of other third parties, the use of separate external identif= iers for different domains allows fine-grained control of identity federatio= n.) > The scheme also allows the splitting of an entity into more than two entit= ies, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) > This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed i= nternally in each domain. Such a data model also allows us to choose asynchr= onous protocols for propagation of identity events, since there is no consis= tency requirement to update multiple domains concurrently. > Regards, > Ganesh Prasad > =20 >=20 > On 9 August 2012 04:55, Kelly Grizzle wrote:= >=20 > Thanks for the feedback, Ganesh. I read through this and your InfoQ artic= le (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. >=20 > =20 >=20 > > The rest of the protocol does not meaningfully use the enterprise client= =E2=80=99s identifier, the "external ID" >=20 > > at all, even though it was ostensibly introduced to make things friendli= er for the client. >=20 > =20 >=20 > The usage pattern for an external ID would be to search for a user by exte= rnalId and use the ID of the returned user in any desired operation. For ex= ample: >=20 > =20 >=20 > GET /Users?filter=3DexternalId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Di= d >=20 > =20 >=20 > { >=20 > =E2=80=9CtotalResults=E2=80=9D: 1, >=20 > =E2=80=9CResources=E2=80=9D: [ >=20 > { >=20 > =E2=80=9Cid=E2=80=9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2= =80=9D >=20 > } >=20 > ] >=20 > } >=20 > =20 >=20 > Retrieve the ID from the response and use it. >=20 > =20 >=20 > DELETE /Users/2819c223-7f76-453a-919d-413861904646 >=20 > =20 >=20 > This does introduce an additional HTTP request if the client chooses not t= o store the server=E2=80=99s id. An issue was created to consider allowing o= perations to use the externalId (http://code.google.com/p/scim/issues/detail= ?id=3D35), but I believe the general consensus has been to not include this i= n the spec. One main point of contention is that much of the rest of the sp= ec (eg =E2=80=93 group membership references, manager references, etc=E2=80=A6= ) require knowledge of the server=E2=80=99s identifier. Continuing this dis= cussion on the IETF list would be a good thing, though. >=20 > =20 >=20 > =20 >=20 > > the cloud provider's ID and the enterprise client's ID are both "Interna= l IDs" with respect to their domains >=20 > =20 >=20 > I think this comes down to a nomenclature problem. The server=E2=80=99s I= D does not necessarily have to be the unique identifier that the underlying i= dentity store uses, it just has to be stable and unique. In many cases, the= underlying identity store will provide identifiers with these properties al= ready (eg =E2=80=93 a uuid) and it can be used by the SCIM interface. The =E2= =80=9CexternalId=E2=80=9D is referring to the fact that the id is maintained= external to the SCIM server. As long as the server=E2=80=99s identifiers a= re stable and unique (which is mandated by the spec), I don=E2=80=99t see a p= roblem. >=20 > =20 >=20 > =20 >=20 > > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite >=20 > > simple - turn every list or array (of values) into a dictionary (of key-= value pairs) by providing each value >=20 > > with a unique and meaning-free identifier. >=20 > =20 >=20 > I agree that this would be useful, especially in the PATCH operation. One= reason that this wasn=E2=80=99t included in the spec originally is that it c= an put undue burden on the service provider. Many service providers are put= ting SCIM interfaces in front of their existing identity stores (eg =E2=80=93= directory servers, SaaS application databases, etc=E2=80=A6). Many of thes= e do not have a unique identifier for multi-valued attributes. By requiring= this, a majority of the server providers would have to start maintaining a u= nique key for each multi-valued attribute. I believe this would be a roadbl= ock for many implementers. >=20 > =20 >=20 > =20 >=20 > > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. >=20 > =20 >=20 > I like the thoughts here. Your example reminds me of unified diffs (http:= //en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, the= three proposals seem to largely hinge on being able to uniquely address eac= h element within an object. Without these it is not so easy to address each= patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus. >=20 >=20 > The 207 response would be interesting to consider for the bulk endpoint (h= ttp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. >=20 > =20 >=20 > =20 >=20 > > There are other, non-data aspects of SCIM which may require review, such= as its synchronous request-response >=20 > > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. >=20 > =20 >=20 > I agree that we should explore optional asynchronous requests in 2.0. >=20 > =20 >=20 > Thanks again for your thoughts. I hope you stay involved in the discussio= n as work on SCIM 2.0 goes forward. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ga= nesh and Sashi Prasad > Sent: Wednesday, August 01, 2012 4:24 PM > To: scim@ietf.org > Subject: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > (I posted this on the SCIM Google Group, and I was advised to subscribe to= the mailing list and post it here instead, so here goes.) >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > My name is Ganesh Prasad, and my experience in Identity and Access Managem= ent is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com/= minibooks/Identity-Management-Shoestring). >=20 > =20 >=20 > I have been following the SCIM spec off and on, and based on my experience= with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. >=20 > =20 >=20 > 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Both= of them should map their internal IDs to a shared External ID, and this is t= he only ID that should be exposed through the API. The current specification= 's provision of an id (which is the external ID and the only one to be trans= ferred through the API) and an "external ID" (which is the client's internal= ID and should be hidden) is diametrically opposite to this. >=20 > =20 >=20 > 2. When dealing with multi-valued attributes of a resource (expressed as a= rrays in JSON), they must be converted from an array into a dictionary with u= nique keys (UUIDs generated by the cloud provider when the attribute is crea= ted). Without unique keys for every attribute value of a resource, manipulat= ing it will be clumsy and inelegant. >=20 > =20 >=20 > 3. The PATCH command can be improved in 3 significant ways: >=20 > 3a. Leverage the fact (from 2 above) that every value has a key, to greatl= y simplify the API >=20 > 3b. Use special verbs as nested operations of the PATCH command to add, mo= dify and delete attributes at any level >=20 > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" a= s the response to a PATCH (or BULK) command. >=20 > =20 >=20 > To elaborate, >=20 > =20 >=20 > 1. Revealing private IDs externally is a form of tight coupling. A major r= equirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is d= iscovered to be more than one, or when multiple resources are detected to be= the same. If internal identifiers are revealed to external domains, such cl= ean-ups become difficult, hence every domain that wants to expose references= to a resource must map its internal ID to and external one created for this= explicit purpose, and only reveal this. >=20 > =20 >=20 > In the SCIM case, when an enterprise client POSTs a resource creation requ= est, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "Lo= cation:" header. The enterprise client should map this external UUID to a ne= wly-generated internal ID of its own. In case the resource already has an id= entifier within the enterprise client's domain, then this is the internal ID= that must be mapped to the external UUID returned through the POST response= . >=20 > =20 >=20 > 2. If a resource is to be created, and one of its attributes is multi-valu= ed, e.g., >=20 > =20 >=20 > "email-addrs" :=20 >=20 > [ >=20 > "john_smith@yahoo.com", >=20 > "john.smith@gmail.com", >=20 > "jsmith1970@hotmail.com" >=20 > < > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-D8574484-A114-41C5-9C6F-E8498386BC59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


Phil
On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution.  Part of the key here is that SC= IM is just a piece of the architecture for this solution, and is only respon= sible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I p= rovided that example to illustrate that splitting and merging identities is a= common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.
I'm suggesting that the spec do less, not more.

What the SCIM spec needs to do there is= just refrain from introducing tight coupling. I would like to see a single i= dentifier exposed through the API, with the implication (and perhaps the rec= ommendation) that it be the shared one. Allowing one domain to expose its in= ternal identifier to the other creates tight coupling and ensures that both d= omains need simultaneously split or merge identities, which is not desirable= . So I recommend _taking out_ the "external id" field from the API. The spec= shouldn't encourage tight coupling. If clients want to pass in their intern= al ids as part of the resource body, no one can stop them, and they can alwa= ys do a search on that attribute to retrieve the URI exactly as you visualis= e they will with the "external id", but let's not elevate an anti-pattern to= a recommendation by enshrining the "external id" as an acceptable attribute= .

Am I making sense?

I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling. 

<= /div>
IMHO loose coupling is a much more complex solution. The reality i= s that each end-point has value to contribute and thus the single-owner mode= l will eventually need to become multi-owner or multi-hub. 
<= br>
That said i think the current model provides a practical start= ing point. 

>&= nbsp; Regarding unique identifiers for multi-valued attributes there is a t= rade-off involved.  On one hand this makes PATCH semantics easier. = ; On the other hand it puts extra burden on service providers. <= /div>

Precisely. The spec has to strike the right balance. It would be in= teresting to hear from the other members of the spec mailing list. You know w= here I stand on this. It would be good to hear the spectrum of opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoin= t.com> wrote:

Thanks Emmanuel.  I ha= d started writing up a similar response.  As you suggest, storing this i= nformation in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is jus= t a piece of the architecture for this solution, and is only responsible for= the transport layer between domains.

 =

You could also model these I= D mappings in the SCIM user as an extension but would probably not want to e= xpose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 =

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| a99a5feba839     &nb= sp; | D2           &n= bsp;     | 7a87f27c1dd8     &nb= sp; | true         |

 

This could be represe= nted as two SCIM users that contain information about the entities on other d= omains.

 =

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",<= /span>

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {<= /span>

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      }<= /span>

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",<= /span>

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {<= /span>

        "dom= ain": "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

      }<= /span>

    ]

  }

}

 =

In the second user, the lin= kedUsers attribute would be empty until the split user was synced to domain 2= .

 =

 =

Similarly, the false negati= ve use case (merging two users) looked like this at the end:

 =

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | 41206cc97c8b     &nb= sp; | false        |=

 =

This could be represe= nted with the following SCIM user:

 =

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",<= /span>

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {<= /span>

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      },=

      {<= /span>

        "dom= ain": "D2",

        "ext= ernalEntityId": "41206cc97c8b",

        "del= etionRequired": true

      }<= /span>

    ]

  }

}

 =

 =

Regarding unique identifier= s for multi-valued attributes there is a trade-off involved.  On one ha= nd this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a= key goal has been to foster adoption by service providers by making things f= it easily onto existing systems.  IMO the value gained by unique identi= fiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that ve= ndors that have a non-SCIM-compliant API will choose to keep things that way= if the spec is too hard for them to implement.  In a green field envir= onment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 =

--Kelly

 =

From: scim-bounces@ietf.org [m= ailto:scim-bounce= s@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement<= /u>

 

Hi Ganesh,

 

Nothing prevents you in you= r SCIM implementation (client or server) to generate a unique identifier for= each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 =

This is what we are doing w= ith Active Directory sources or targets:

As we didn=E2=80=99t find a= n immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to c= hange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits you= r requirements as it hides internal ids.

 =

This was written in dotnet a= nd we have started a project to rewrite our SCIM stack in PHP and will give i= t to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice o= f =E2=80=9Chiding=E2=80=9D internalIDs or use them as unique ID.

 =

You can also implement such= feature without violating the SCIM specs, or without asking to include it i= n the specs.

 =

--

Regards,=

Emmanuel Dreux<= u>

http://www.cloudiway.com<= u>

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel= .Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi Ke= lly,

Thank= s for your response. Let me first respond in brief to the two main points yo= u have made, and then elaborate on the first.

1.      Why should domains not expose t= heir internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.=

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.<= /u>

Elabo= ration of Point 1:

When w= e consider federated identity across more than one domain, we have to assume= that domains are not necessarily master-slave in their interaction. The mos= t generic interaction model is peer-to-peer, where entity lifecycle events within a domain are no= tified to other domains (when necessary) in an asynchronous manner (i.e., th= rough messaging) and the other domains are free to respond to these events i= n an appropriate manner and at a time of their convenience.

A key= set of lifecycle events for an entity is the merging and splitting of ident= ity that is often required.

The q= uestion =E2=80=9CIs this one entity?=E2=80=9D can be answered either yes (po= sitive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Consi= der a case where customers sign up online, and two customers who are privacy= -conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intellig= ent (but incorrect) guess that these two persons are the same, and re-assign= the same identifier to the second person. This is a false positive. They ap= pear to be the same entity, but they're actually different. When the error is discovered, the identities wi= ll need to be split, with a new identifier generated for one of them.=

Consi= der the opposite case where a customer signs up through two different portal= s or in two different sessions, using the names =E2=80=9CJSmith=E2=80=9D and= =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique ide= ntifiers. This is a false negative. They appear to be two entities, but are a= ctually the same. At a later stage, when the error is discovered, the identi= ties will have to be merged, and one of the identifiers will have to be dropped.

These= are not theoretical use cases. They form a significant proportion of the us= er base in most large Web-facing applications. Let's see how these can be ma= naged in a federated way by mapping internal identifiers to external ones and only exposing exte= rnal identifiers to other domains.

a. Fa= lse positives:

Domai= n 1 has the following information about a customer in its data store:=

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

When r= equesting the provisioning of this entity in Domain 2, the following ID is r= eturned by Domain 2: ff487230b3a0.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

When t= he false positive is discovered and the entity is split, Domain 1 creates a n= ew internal identifier and now has the following entity information.<= u>

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

Inter= nal ID: a99a5feba839

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

This s= econd entity with its own internal identifier is invisible to Domain 2, and t= his is by design. Communication about the original entity takes place as bef= ore by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b3a0=E2=80=9D and vice-v= ersa. At some convenient time (importantly, this doesn't have to be at the t= ime the split happens), Domain 2 can be requested to provision a second enti= ty, and when it responds with an identifier of =E2=80=9C7a87f27c1dd8=E2=80=9D= , this can go into the mapping table as a new record associated with the seco= nd entity's internal identifier.

The m= apping table now contains the following entries:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| a99a5feba839 | D2= | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, a= nd the provisioning that it does is not in lockstep with the split in identi= ty that occurred in Domain 1.

(What= is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we cover the= treatment of false negatives.)

b. Fa= lse negatives:

Domai= n 1 has the following information about what it thinks are two distinct cust= omers in its data store:

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}<= u>

Inter= nal ID: 273d36e30d09

Attri= butes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}

When r= equesting the provisioning of these entities in Domain 2, the following IDs a= re returned by Domain 2: ff487230b3a0 and 41206cc97c8b.=

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifiers:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 273d36e30d09 | D2= | 41206cc97c8b | true |

When t= he false negative is discovered and the two entities are merged, Domain 1 dr= ops one of the internal identifiers and rationalises the name of the custome= r (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the first ID =E2=80=9C9caf78aac3d6=E2= =80=9D and drops the second =E2=80=9C273d36e30d09=E2=80=9D.

The m= apping table now looks like this:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 9caf78aac3d6 | D2= | 41206cc97c8b | false |

Now t= wo external identifiers map to the same internal one, so inbound communicati= on from Domain 2 can be unambiguously translated to the same entity internal= ly. However, when going outwards, Domain 1 will have to look up the translation table to dete= rmine the =E2=80=9Cprimary=E2=80=9D external ID for this entity in Domain 2,= which was decided to be =E2=80=9Cff487230b3a0=E2=80=9D. That's where the =E2= =80=9CPrimary flag=E2=80=9D comes in. The second external ID =E2=80=9C41206c= c97c8b=E2=80=9D is never used thereafter in outbound communication.

At so= me stage (importantly, not in lockstep with the identity merge), Domain 2 ca= n be requested to delete the customer record identified by =E2=80=9C41206cc9= 7c8b=E2=80=9D, and the second entry in the mapping table can be removed once this is acknowledged.

This s= cheme will scale up to multiple domains, because the =E2=80=9CExternal Domai= n ID=E2=80=9D column helps to keep track of which external ID is shared with= which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? T= ight coupling again. Just as OAuth allows an access token given to a third p= arty to be invalidated without affecting the access of other third parties, t= he use of separate external identifiers for different domains allows fine-grained control of identity f= ederation.)

The s= cheme also allows the splitting of an entity into more than two entities, an= d the merging of more than two entities into a single one. (Any organisation= with a web-facing application will tell you how many John Smiths there are who were born on 1= Jan 1970!)

This i= s a fairly long-winded explanation, but this is why we need to hide internal= identifiers from other domains, and why mappings need to be managed interna= lly in each domain. Such a data model also allows us to choose asynchronous protocols for propa= gation of identity events, since there is no consistency requirement to upda= te multiple domains concurrently.

Regar= ds,

Ganes= h Prasad

 

On 9 August 2012 04:55, Kelly Grizz= le <kell= y.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ga= nesh.  I read through this and your InfoQ article (h= ttp://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 =

> The rest of the protocol does not meaning= fully use the enterprise client=E2=80=99s identifier, the "external ID"

> at all, even though i= t was ostensibly introduced to make things friendlier for the client.=

 =

The usage pattern for an ex= ternal ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.  For example:

 =

GET /Users?filter=3Dexterna= lId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Did

 =

{

  =E2=80=9CtotalResults=E2=80=9D: 1,

  =E2=80=9CResources=E2=80=9D: [=

    {

      =E2=80=9Cid=E2=80= =9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2=80=9D=

    }

  ]

}

 =

Retrieve the ID from the re= sponse and use it.

 =

DELETE /Users/2819c223-7f76= -453a-919d-413861904646

 =

This does introduce an addi= tional HTTP request if the client chooses not to store the server=E2=80=99s i= d.  An issue was created to consider allowing operations to use the externalId (= http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the spe= c.  One main point of contention is that much of the rest of the spec (= eg =E2=80=93 group membership references, manager references, etc=E2=80=A6) r= equire knowledge of the server=E2=80=99s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 =

 =

> the cloud provider's ID and the enterpris= e client's ID are both "Internal IDs" with respect to their domains

 =

I think this comes down to a= nomenclature problem.  The server=E2=80=99s ID does not necessarily ha= ve to be the unique identifier that the underlying identity store uses, it just h= as to be stable and unique.  In many cases, the underlying identity sto= re will provide identifiers with these properties already (eg =E2=80=93 a uu= id) and it can be used by the SCIM interface.  The =E2=80=9CexternalId=E2=80=9D is referring to the fact that the id is ma= intained external to the SCIM server.  As long as the server=E2=80=99s i= dentifiers are stable and unique (which is mandated by the spec), I don=E2=80= =99t see a problem.

 =

 =

> The secret is that every value ne= eds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn every l= ist or array (of values) into a dictionary (of key-value pairs) by providing= each value

> with a unique and me= aning-free identifier.

 =

I agree that this would be u= seful, especially in the PATCH operation.  One reason that this wasn=E2= =80=99t included in the spec originally is that it can put undue burden on the serv= ice provider.  Many service providers are putting SCIM interfaces in fr= ont of their existing identity stores (eg =E2=80=93 directory servers, SaaS a= pplication databases, etc=E2=80=A6).  Many of these do not have a unique identifier for multi-valued attributes.  By requi= ring this, a majority of the server providers would have to start maintainin= g a unique key for each multi-valued attribute.  I believe this would b= e a roadblock for many implementers.

 =

 =

> When the SCIM protocol uses PATCH, there a= re areas where it seems a bit clumsy.

 =

I like the thoughts here.&n= bsp; Your example reminds me of unified diffs (http://en.wikipedia= .org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of= the PATCH verb).  However, the three proposals seem to largely hinge o= n being able to uniquely address each element within an object.  Withou= t these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-a= pi-00.html#bulk-resources), however.

 =

 =

> There are other, non-data aspects of SCIM= which may require review, such as its synchronous request-response

> interaction model, w= hich is a form of tight coupling and could prove to be a source of brittlene= ss.

 =

I agree that we should expl= ore optional asynchronous requests in 2.0.

 =

Thanks again for your thoug= hts.  I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

 =

--Kelly

 =

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org<= /a>
Subject: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

 

(I posted this on the SCIM Google Group, and I was ad= vised to subscribe to the mailing list and post it here instead, so here goe= s.)

 

Hi,

 

 

I have been following the SCIM spec off and on, and b= ased on my experience with a loosely-coupled architecture that I found to be= successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider shoul= d maintain their own internal IDs for a resource, which they should not reve= al to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should b= e exposed through the API. The current specification's provision of an id (w= hich is the external ID and the only one to be transferred through the API) a= nd an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite to= this.

 

2. When dealing with multi-valued attributes of a res= ource (expressed as arrays in JSON), they must be converted from an array in= to a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys f= or every attribute value of a resource, manipulating it will be clumsy and i= nelegant.

 

3. The PATCH command can be improved in 3 significant= ways:

3a. Leverage the fact (from 2 above) that every value= has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PAT= CH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" i= nstead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tigh= t coupling. A major requirement with Identity Management is to split (or mer= ge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or w= hen multiple resources are detected to be the same. If internal identifiers a= re revealed to external domains, such clean-ups become difficult, hence ever= y domain that wants to expose references to a resource must map its internal ID to and external one creat= ed for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client POSTs a r= esource creation request, the cloud provider must generate its own internal U= UID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The enterprise= client should map this external UUID to a newly-generated internal ID of it= s own. In case the resource already has an identifier within the enterprise c= lient's domain, then this is the internal ID that must be mapped to the external UUID returned through t= he POST response.

 

2. If a resource is to be created, and one of its att= ributes is multi-valued, e.g.,

 

    "email-addrs" : 

=

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

<
______________________________________________= _
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim<= br>
= --Apple-Mail-D8574484-A114-41C5-9C6F-E8498386BC59-- From g.c.prasad@gmail.com Fri Aug 10 03:49:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573DC21F8610 for ; Fri, 10 Aug 2012 03:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q88wdhdfuCED for ; Fri, 10 Aug 2012 03:49:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F99A21F854A for ; Fri, 10 Aug 2012 03:49:48 -0700 (PDT) Received: by bkty7 with SMTP id y7so610802bkt.31 for ; Fri, 10 Aug 2012 03:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=gBjRPZUuh+0vM8dHx4af7RiLcZKfo9wpte1Ffpo+SoM=; b=G9lRlWqMZ06uVY29WW1mSgSnbeNDiSvVFd7KYjK7q24nyOY84iVR4qV9shdxork1Oj re614uLMT7g4EEEKiKxUWgXcAUxT1HRxuaoxhoBXB1d2ybFSRka9VxJ3pjzO/NIT4khW FB5Gl2IqWOHIwqJ2lLdvvmWrk9p0uEDIWHIVxDYlJnRl1Ps609rs/uvAjXnLXMq2GEJY NbmhEzrvmehJJYGIb7Sq0dB0cqmjr7oMnr8/EzP+bt+ULLrvAiqGvb6xY5ljQ6/+6GhA Nz3OCl4sHZcRTfxmYvy9G1l2fpnI7f5mjsPZBiouTZCjhYlWr+yEfrVRnaHKj8FcigNH USCw== Received: by 10.204.152.211 with SMTP id h19mr987098bkw.45.1344595787424; Fri, 10 Aug 2012 03:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Fri, 10 Aug 2012 03:49:27 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Fri, 10 Aug 2012 20:49:27 +1000 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175cd13a46a3ea04c6e71af5 Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 10:49:53 -0000 --0015175cd13a46a3ea04c6e71af5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. [...] IMHO loose coupling is a much more complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariably, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-and-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the resource body, inside some attribute defined by them (but not defined by the protocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, which is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt wrote: > > > Phil > > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > > > storing this information in a mapping table outside of the SCIM spec > is a great way to enable this solution. Part of the key here is that SCI= M > is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains. > > I wasn't suggesting that the mapping table be part of the SCIM spec. I > provided that example to illustrate that splitting and merging identities > is a common requirement, and that decoupling local identifiers within a > domain from shared identifiers between domains was the best way to > facilitate it. > > I'm suggesting that the spec do less, not more. > > What the SCIM spec needs to do there is just refrain from introducing > tight coupling. I would like to see a single identifier exposed through t= he > API, with the implication (and perhaps the recommendation) that it be the > shared one. Allowing one domain to expose its internal identifier to the > other creates tight coupling and ensures that both domains need > simultaneously split or merge identities, which is not desirable. So I > recommend _taking out_ the "external id" field from the API. The spec > shouldn't encourage tight coupling. If clients want to pass in their > internal ids as part of the resource body, no one can stop them, and they > can always do a search on that attribute to retrieve the URI exactly as y= ou > visualise they will with the "external id", but let's not elevate an > anti-pattern to a recommendation by enshrining the "external id" as an > acceptable attribute. > > Am I making sense? > > > I see what you are saying. I think scim gets its current simplicity from > its single owner hub spoke model implementing tight coupling. > > IMHO loose coupling is a much more complex solution. The reality is that > each end-point has value to contribute and thus the single-owner model wi= ll > eventually need to become multi-owner or multi-hub. > > That said i think the current model provides a practical starting point. > > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. You > know where I stand on this. It would be good to hear the spectrum of > opinions. > > Regards, > Ganesh > > On 10 August 2012 00:28, Kelly Grizzle wrote= : > >> Thanks Emmanuel. I had started writing up a similar response. As you >> suggest, storing this information in a mapping table outside of the SCIM >> spec is a great way to enable this solution. Part of the key here is th= at >> SCIM is just a piece of the architecture for this solution, and is only >> responsible for the transport layer between domains.**** >> >> ** ** >> >> You could also model these ID mappings in the SCIM user as an extension >> but would probably not want to expose these externally. Here is an exam= ple >> of how to model the end state of the false positive scenario (splitting = a >> user):**** >> >> ** ** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true |**** >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | >> true |**** >> >> ** ** >> >> This could be represented as two SCIM users that contain information >> about the entities on other domains.**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "9caf78aac3d6",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "ff487230b3a0"**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "a99a5feba839",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "7a87f27c1dd8"**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> In the second user, the linkedUsers attribute would be empty until the >> split user was synced to domain 2.**** >> >> ** ** >> >> ** ** >> >> Similarly, the false negative use case (merging two users) looked like >> this at the end:**** >> >> ** ** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true |**** >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | >> false |**** >> >> ** ** >> >> This could be represented with the following SCIM user:**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"],**** >> >> "id": "9caf78aac3d6",**** >> >> "userName": "John Smith",**** >> >> "urn:scim:schemas:extension:federation:1.0": {**** >> >> "linkedUsers": [**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "ff487230b3a0"**** >> >> },**** >> >> {**** >> >> "domain": "D2",**** >> >> "externalEntityId": "41206cc97c8b",**** >> >> "deletionRequired": true**** >> >> }**** >> >> ]**** >> >> }**** >> >> }**** >> >> ** ** >> >> ** ** >> >> Regarding unique identifiers for multi-valued attributes there is a >> trade-off involved. On one hand this makes PATCH semantics easier. On = the >> other hand it puts extra burden on service providers. Since the incepti= on >> of SCIM, a key goal has been to foster adoption by service providers by >> making things fit easily onto existing systems. IMO the value gained by >> unique identifiers for multi-valued attributes is not worth the demands = put >> on a service provider. I also think that vendors that have a >> non-SCIM-compliant API will choose to keep things that way if the spec i= s >> too hard for them to implement. In a green field environment we do have >> the luxury of mandating a model to make certain operations more elegant. >> However, we can=92t ignore legacy systems. **** >> >> ** ** >> >> --Kelly**** >> >> ** ** >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Emmanuel Dreux >> *Sent:* Thursday, August 09, 2012 3:18 AM >> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> ** ** >> >> Hi Ganesh,**** >> >> ** ** >> >> Nothing prevents you in your SCIM implementation (client or server) to >> generate a unique identifier for each synchronized object and maintain a= n >> internal mapping table ( you would have to map group membership as well)= . >> **** >> >> ** ** >> >> This is what we are doing with Active Directory sources or targets:**** >> >> As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNa= me, >> UPN) are subject to change (even objectGuid can change if an AD domain i= s >> migrated), we decided to generate and maintain an internal table of ids. >> This fits your requirements as it hides internal ids.**** >> >> ** ** >> >> This was written in dotnet and we have started a project to rewrite our >> SCIM stack in PHP and will give it to the Open Source community. This >> implementation will have a parameter : AllocateIds versus UseExistingIDs= . >> **** >> >> This will give the choice of =93hiding=94 internalIDs or use them as uni= que >> ID.**** >> >> ** ** >> >> You can also implement such feature without violating the SCIM specs, or >> without asking to include it in the specs.**** >> >> ** ** >> >> --**** >> >> Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> ** ** >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> >> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org >> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> ** ** >> >> Hi Kelly,**** >> >> Thanks for your response. Let me first respond in brief to the two main >> points you have made, and then elaborate on the first.**** >> >> **1. **Why should domains not expose their internal identifiers to >> other domains?**** >> >> a.**** >> >> We are designing a protocol for a federated system of domains, where all >> domains are co-equal peers. (In physics too, N-body problems are much >> harder than 2-body problems. :-) Therefore, assuming that there are only >> two players in the interaction makes this tightly coupled in a number of >> ways. We should rely on messaging and notification, with encapsulation o= f >> domain-specific data.**** >> >> b. **** >> >> In any non-trivial data store, there will always be the ongoing need to >> merge and split identities as and when =93false negatives=94 and =93fals= e >> positives=94 are discovered. A domain should be able to handle this inte= rnal >> housekeeping freely, only notifying other domains when convenient. Mappi= ng >> of internal identifiers to external ones and maintaining this mapping >> internally allows this loosely-coupled housekeeping to take place. Shari= ng >> internal identifiers (or otherwise outsourcing the mapping of internal t= o >> external identifiers) forces housekeeping activities to be done in >> lock-step across domains.**** >> >> c.**** >> >> Asynchronous interaction is not just a matter of a suitable wire protoco= l >> which can be designed later. The data model plays a crucial role in >> enabling or constraining such interaction. A tightly-coupled data model >> will force the use of synchronous interactions, and the exposure of >> internal identifiers is a key part of this tight coupling.**** >> >> 2. The difficulty of assigning unique identifiers to the individual >> values of multi-valued attributes:**** >> >> a. **** >> >> I'm not belittling the effort involved in migrating legacy data stores t= o >> such a model. However, in the larger historical context of cross-domain >> identity management, we are really at the very early stages. If a >> relatively new discipline and a brand new spec are held captive to legac= y >> considerations, we are losing an opportunity to provide a clean and eleg= ant >> model to subsequent users of the spec, and this will have repercussions >> over many years or even decades.**** >> >> b. **** >> >> If incumbent cloud providers find it hard to immediately adopt the >> dictionary model for existing multi-valued attributes, they can transiti= on >> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-comp= liant=94 >> APIs to their customers and encouraging new customers to adopt the >> =93SCIM-compliant=94 API. Legacy customers can be supported using a >> =93non-SCIM-compliant=94 API for an arbitrarily long period and graduall= y >> migrated to the SCIM-compliant API. The logistics are not insurmountable= , >> and shouldn't prevent the adoption of a dictionary model for multi-value= d >> attributes.**** >> >> Elaboration of Point 1:**** >> >> When we consider federated identity across more than one domain, we have >> to assume that domains are not necessarily master-slave in their >> interaction. The most generic interaction model is peer-to-peer, where >> entity lifecycle events within a domain are notified to other domains (w= hen >> necessary) in an asynchronous manner (i.e., through messaging) and the >> other domains are free to respond to these events in an appropriate mann= er >> and at a time of their convenience.**** >> >> A key set of lifecycle events for an entity is the merging and splitting >> of identity that is often required.**** >> >> The question =93Is this one entity?=94 can be answered either yes (posit= ive) >> or no (negative). But sometimes, we can discover false positives and fal= se >> negatives in our data stores.**** >> >> Consider a case where customers sign up online, and two customers who ar= e >> privacy-conscious enter fake IDs such as =93John Smith=94, and also use = the >> same date of birth (say, 1 Jan 1970) or similar attributes. The front-en= d >> application may make an intelligent (but incorrect) guess that these two >> persons are the same, and re-assign the same identifier to the second >> person. This is a false positive. They appear to be the same entity, but >> they're actually different. When the error is discovered, the identities >> will need to be split, with a new identifier generated for one of them.*= * >> ** >> >> Consider the opposite case where a customer signs up through two >> different portals or in two different sessions, using the names =93JSmit= h=94 >> and =93JohnS=94. It is very likely that they will be treated as two diff= erent >> customers and assigned two unique identifiers. This is a false negative. >> They appear to be two entities, but are actually the same. At a later >> stage, when the error is discovered, the identities will have to be merg= ed, >> and one of the identifiers will have to be dropped.**** >> >> These are not theoretical use cases. They form a significant proportion >> of the user base in most large Web-facing applications. Let's see how th= ese >> can be managed in a federated way by mapping internal identifiers to >> external ones and only exposing external identifiers to other domains.**= * >> * >> >> a. False positives:**** >> >> Domain 1 has the following information about a customer in its data stor= e: >> **** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> When requesting the provisioning of this entity in Domain 2, the >> following ID is returned by Domain 2: ff487230b3a0.**** >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifier:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> When the false positive is discovered and the entity is split, Domain 1 >> creates a new internal identifier and now has the following entity >> information.**** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> Internal ID: a99a5feba839**** >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >> >> This second entity with its own internal identifier is invisible to >> Domain 2, and this is by design. Communication about the original entity >> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >> vice-versa. At some convenient time (importantly, this doesn't have to b= e >> at the time the split happens), Domain 2 can be requested to provision a >> second entity, and when it responds with an identifier of =937a87f27c1dd= 8=94, >> this can go into the mapping table as a new record associated with the >> second entity's internal identifier.**** >> >> The mapping table now contains the following entries:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** >> >> Domain 2 is not even aware that a split has happened, and the >> provisioning that it does is not in lockstep with the split in identity >> that occurred in Domain 1.**** >> >> (What is the =93Primary flag=94 used for? We'll see when we cover the >> treatment of false negatives.)**** >> >> b. False negatives:**** >> >> Domain 1 has the following information about what it thinks are two >> distinct customers in its data store:**** >> >> Internal ID: 9caf78aac3d6**** >> >> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** >> >> Internal ID: 273d36e30d09**** >> >> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** >> >> When requesting the provisioning of these entities in Domain 2, the >> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.**= * >> * >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifiers:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | 273d36e30d09 | D2 | 41206cc97c8b | true |**** >> >> When the false negative is discovered and the two entities are merged, >> Domain 1 drops one of the internal identifiers and rationalises the name= of >> the customer (say, to =93John Smith=94). Let's say it retains the first = ID >> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** >> >> The mapping table now looks like this:**** >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag |**** >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** >> >> Now two external identifiers map to the same internal one, so inbound >> communication from Domain 2 can be unambiguously translated to the same >> entity internally. However, when going outwards, Domain 1 will have to l= ook >> up the translation table to determine the =93primary=94 external ID for = this >> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's w= here >> the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never >> used thereafter in outbound communication.**** >> >> At some stage (importantly, not in lockstep with the identity merge), >> Domain 2 can be requested to delete the customer record identified by >> =9341206cc97c8b=94, and the second entry in the mapping table can be rem= oved >> once this is acknowledged.**** >> >> This scheme will scale up to multiple domains, because the =93External >> Domain ID=94 column helps to keep track of which external ID is shared w= ith >> which Domain. (Why don't we use just one external ID for an entity and >> share it with all external domains? Tight coupling again. Just as OAuth >> allows an access token given to a third party to be invalidated without >> affecting the access of other third parties, the use of separate externa= l >> identifiers for different domains allows fine-grained control of identit= y >> federation.)**** >> >> The scheme also allows the splitting of an entity into more than two >> entities, and the merging of more than two entities into a single one. (= Any >> organisation with a web-facing application will tell you how many John >> Smiths there are who were born on 1 Jan 1970!)**** >> >> This is a fairly long-winded explanation, but this is why we need to hid= e >> internal identifiers from other domains, and why mappings need to be >> managed internally in each domain. Such a data model also allows us to >> choose asynchronous protocols for propagation of identity events, since >> there is no consistency requirement to update multiple domains concurren= tly. >> **** >> >> Regards, **** >> >> Ganesh Prasad**** >> >> ** ** >> >> On 9 August 2012 04:55, Kelly Grizzle >> wrote:**** >> >> Thanks for the feedback, Ganesh. I read through this and your InfoQ >> article (http://www.infoq.com/articles/scim-data-model-limitations) and >> have some thoughts.**** >> >> **** >> >> > The rest of the protocol does not meaningfully use the enterprise >> client=92s identifier, the "external ID"**** >> >> > at all, even though it was ostensibly introduced to make things >> friendlier for the client.**** >> >> **** >> >> The usage pattern for an external ID would be to search for a user by >> externalId and use the ID of the returned user in any desired operation. >> For example:**** >> >> **** >> >> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** >> >> **** >> >> {**** >> >> =93totalResults=94: 1,**** >> >> =93Resources=94: [**** >> >> {**** >> >> =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** >> >> }**** >> >> ]**** >> >> }**** >> >> **** >> >> Retrieve the ID from the response and use it.**** >> >> **** >> >> DELETE /Users/2819c223-7f76-453a-919d-413861904646**** >> >> **** >> >> This does introduce an additional HTTP request if the client chooses not >> to store the server=92s id. An issue was created to consider allowing >> operations to use the externalId ( >> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the >> general consensus has been to not include this in the spec. One main po= int >> of contention is that much of the rest of the spec (eg =96 group members= hip >> references, manager references, etc=85) require knowledge of the server= =92s >> identifier. Continuing this discussion on the IETF list would be a good >> thing, though.**** >> >> **** >> >> **** >> >> > the cloud provider's ID and the enterprise client's ID are both >> "Internal IDs" with respect to their domains**** >> >> **** >> >> I think this comes down to a nomenclature problem. The server=92s ID do= es >> not necessarily have to be the unique identifier that the underlying >> identity store uses, it just has to be stable and unique. In many cases= , >> the underlying identity store will provide identifiers with these >> properties already (eg =96 a uuid) and it can be used by the SCIM interf= ace. >> The =93externalId=94 is referring to the fact that the id is maintained >> external to the SCIM server. As long as the server=92s identifiers are >> stable and unique (which is mandated by the spec), I don=92t see a probl= em. >> **** >> >> **** >> >> **** >> >> > The secret is that *every value needs a key*, and multi-valued >> attributes lack that. So our solution is quite**** >> >> > simple - turn every list or array (of values) into a dictionary (of >> key-value pairs) by providing each value**** >> >> > with a unique and meaning-free identifier.**** >> >> **** >> >> I agree that this would be useful, especially in the PATCH operation. >> One reason that this wasn=92t included in the spec originally is that it= can >> put undue burden on the service provider. Many service providers are >> putting SCIM interfaces in front of their existing identity stores (eg = =96 >> directory servers, SaaS application databases, etc=85). Many of these d= o not >> have a unique identifier for multi-valued attributes. By requiring this= , a >> majority of the server providers would have to start maintaining a uniqu= e >> key for each multi-valued attribute. I believe this would be a roadbloc= k >> for many implementers.**** >> >> **** >> >> **** >> >> > When the SCIM protocol uses PATCH, there are areas where it seems a >> bit clumsy.**** >> >> **** >> >> I like the thoughts here. Your example reminds me of unified diffs ( >> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >> used with a patch program (pretty much the equivalent of the PATCH verb)= . >> However, the three proposals seem to largely hinge on being able to >> uniquely address each element within an object. Without these it is not= so >> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or >> provide a multi-status.**** >> >> >> The 207 response would be interesting to consider for the bulk endpoint = ( >> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources)= , >> however.**** >> >> **** >> >> **** >> >> > There are other, non-data aspects of SCIM which may require review, >> such as its synchronous request-response**** >> >> > interaction model, which is a form of tight coupling and could prove t= o >> be a source of brittleness.**** >> >> **** >> >> I agree that we should explore optional asynchronous requests in 2.0.***= * >> >> **** >> >> Thanks again for your thoughts. I hope you stay involved in the >> discussion as work on SCIM 2.0 goes forward.**** >> >> **** >> >> --Kelly**** >> >> **** >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Ganesh and Sashi Prasad >> *Sent:* Wednesday, August 01, 2012 4:24 PM >> *To:* scim@ietf.org >> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> **** >> >> (I posted this on the SCIM Google Group, and I was advised to subscribe >> to the mailing list and post it here instead, so here goes.)**** >> >> **** >> >> Hi,**** >> >> **** >> >> My name is Ganesh Prasad, and my experience in Identity and Access >> Management is mainly through a 3-year project at an Australian insurance >> company, an experience I have written about as a eBook on InfoQ ( >> http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** >> >> **** >> >> I have been following the SCIM spec off and on, and based on my >> experience with a loosely-coupled architecture that I found to be >> successful, I have the following 3 suggestions to make.**** >> >> **** >> >> 1. The enterprise client and the cloud provider should maintain their ow= n >> internal IDs for a resource, which they should not reveal to each other. >> Both of them should map their internal IDs to a shared External ID, and >> this is the only ID that should be exposed through the API. The current >> specification's provision of an id (which is the external ID and the onl= y >> one to be transferred through the API) and an "external ID" (which is th= e >> client's internal ID and should be hidden) is diametrically opposite to >> this.**** >> >> **** >> >> 2. When dealing with multi-valued attributes of a resource (expressed as >> arrays in JSON), they must be converted from an array into a dictionary >> with unique keys (UUIDs generated by the cloud provider when the attribu= te >> is created). Without unique keys for every attribute value of a resource= , >> manipulating it will be clumsy and inelegant.**** >> >> **** >> >> 3. The PATCH command can be improved in 3 significant ways:**** >> >> 3a. Leverage the fact (from 2 above) that every value has a key, to >> greatly simplify the API**** >> >> 3b. Use special verbs as nested operations of the PATCH command to add, >> modify and delete attributes at any level**** >> >> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" >> as the response to a PATCH (or BULK) command.**** >> >> **** >> >> To elaborate,**** >> >> **** >> >> 1. Revealing private IDs externally is a form of tight coupling. A major >> requirement with Identity Management is to split (or merge) identities w= hen >> false positives (or false negatives) are detected, i.e., when a resource= is >> discovered to be more than one, or when multiple resources are detected = to >> be the same. If internal identifiers are revealed to external domains, s= uch >> clean-ups become difficult, hence every domain that wants to expose >> references to a resource must map its internal ID to and external one >> created for this explicit purpose, and only reveal this.**** >> >> **** >> >> In the SCIM case, when an enterprise client POSTs a resource creation >> request, the cloud provider must generate its own internal UUID as well = as >> an external UUID, map them together, and only return the external UUID i= n >> the "Location:" header. The enterprise client should map this external U= UID >> to a newly-generated internal ID of its own. In case the resource alread= y >> has an identifier within the enterprise client's domain, then this is th= e >> internal ID that must be mapped to the external UUID returned through th= e >> POST response.**** >> >> **** >> >> 2. If a resource is to be created, and one of its attributes is >> multi-valued, e.g.,**** >> >> **** >> >> "email-addrs" : **** >> >> [**** >> >> "john_smith@yahoo.com",**** >> >> "john.smith@gmail.com",**** >> >> "jsmith1970@hotmail.com"**** >> < >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015175cd13a46a3ea04c6e71af5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 I think scim gets its current simplicity from its single owner hub spoke mo= del implementing tight coupling. [...]=A0IMHO loose coupling is a much more= complex solution.

Phil,

I'= m a bit surprised that you're implying "tight coupling =3D=3D simp= le" and "loose coupling =3D=3D complex". That's contrary= to my experience.

When I say "loose coupling", I mean "no = unnecessary dependencies". Invariably, a reduction in dependencies lea= ds to greater simplicity.

Let's not confuse re= duction of dependencies in the data model with a hub-and-spokes architectur= e. They're entirely orthogonal aspects of the solution.

All that my suggestion involves is,
= --Apple-Mail=_9D6382E4-3AA5-42CF-8F70-A0796D9D0C9F-- From trey.drake@unboundid.com Fri Aug 10 11:32:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D8A21F86B6 for ; Fri, 10 Aug 2012 11:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFUQ6V2DEZo9 for ; Fri, 10 Aug 2012 11:31:57 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C6B4E21F8699 for ; Fri, 10 Aug 2012 11:31:56 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3017163obb.31 for ; Fri, 10 Aug 2012 11:31:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7nXTYFt+W4rerH+GEtgsCvnuJLWQ+hTCLepRdhxRN2A=; b=WHyKSelFj9Z60f/37hgnDJAmEcfmEX8OZQLxKDLurAy98ZxCJ9IGXHrmvz7rFjZ82l Dk7xpdoL6bTPBvPJw+Ye4oySIrlsjZP6u4NGv41NJhQO6UDSylxDuMqpWo5fRKB3wQVm luM8lQae/APVYMONuKrKww3iiK++4zGo0xOxRL/mZskaPiBHVvAtizheKQSBkosNHdoE RHMd2Vy/GK7L7C0jznUkHLZQUX+N9sWmTcJMT4TCtCPB1nZzh+PdBN7qE82M894S2gcb W5RqjnvUrscutSEg9gICFHIU7cNCx2sbCxPA3w+9Ptx9v/JZY9arnoExfWAZN1eDO1q0 2cWA== Received: by 10.182.164.103 with SMTP id yp7mr5462929obb.26.1344623515969; Fri, 10 Aug 2012 11:31:55 -0700 (PDT) Received: from [192.168.241.66] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id th3sm3977287obb.6.2012.08.10.11.31.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 11:31:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_3BE6DB64-55D6-4A63-B3E4-CF908A891B3F" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> Date: Fri, 10 Aug 2012 13:31:51 -0500 Message-Id: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQlvB09NngIfpHoYTTvCE2pB7vGAJI9yXdkfpbtlvpB/TU2BpbsV+WafHUMeat71dq/2gllZ Cc: "scim@ietf.org" , Ganesh and Sashi Prasad , Emmanuel Dreux , Kelly Grizzle Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:32:01 -0000 --Apple-Mail=_3BE6DB64-55D6-4A63-B3E4-CF908A891B3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Maybe. I suppose that depends on the meaning of "owns". =20 - A SP may augment the resource and not expose the augmented info with = the consumer. =20 - Schema is defined by the SP not the consumer - A consumer may delete a resource though the SP may simply "hide" it = from future requests Thanks, Trey On Aug 10, 2012, at 11:48 AM, Phil Hunt wrote: > Ganesh, >=20 > See below... >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad wrote: >=20 >> > I think scim gets its current simplicity from its single owner hub = spoke model implementing tight coupling. [...] IMHO loose coupling is a = much more complex solution. >>=20 >> Phil, >>=20 >> I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. >=20 > I think we actually agree. What I was saying is that for a = sufficiently narrow scope model, tight coupling is "simple". But in the = long term it *may* turn out to be "simplistic". SCIM current seems to = assume that an enterprise can claim ownership of the entirety of the = object being provisioned in the cloud. The enterprise has full = knowledge of the resource in the cloud. Under that highly restricted = definition, it is simple. >=20 > The model is fine on a point-to-point basis, but the higher-level = provisioning "system" is more complex. >=20 > I agree with Trey, externalID is optional. I also do not equate = "externalID" with tight or loose coupling. Yes, you can cause tight = coupling, but that doesn't necessarily follow.=20 >=20 > I look at it this way: ObjectID is simply the ID asserted by the = holder of the resource. ExternalID is an optional ID that is meaningful = to a particular client. SAML has a similar concept. >=20 >>=20 >> When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >>=20 >> Let's not confuse reduction of dependencies in the data model with a = hub-and-spokes architecture. They're entirely orthogonal aspects of the = solution. >>=20 >> All that my suggestion involves is, >>=20 >> 1. Take 'external ID' out of the protocol. >> 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >>=20 >> No planned functionality is lost by this. >>=20 >> 1. The client enterprise can still send its internal ID as part of = the resource body, inside some attribute defined by them (but not = defined by the protocol). Let's say they call it 'myID'. >> 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID >> 'GET /Users?myID=3Dbjensen' >> Since myID is a candidate key, the server will return exactly one = URI, which is the canonical URI for the resource >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> 3. The client can use this URI to perform all other operations as = usual. >>=20 >> So taking 'externalID' out of the protocol spec only does this: >> 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) >> 2. It encourages loose coupling by nudging clients towards = maintaining their own internal-to-external identifier mappings. >>=20 >> That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >>=20 >> I'll address the multi-valued attribute suggestion separately. >>=20 >> Regards, >> Ganesh >>=20 >>=20 >>=20 >> On 10 August 2012 07:53, Phil Hunt wrote: >>=20 >>=20 >> Phil >>=20 >> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >>=20 >>> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>>=20 >>> I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>>=20 >>> I'm suggesting that the spec do less, not more. >>>=20 >>> What the SCIM spec needs to do there is just refrain from = introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute. >>>=20 >>> Am I making sense? >>=20 >> I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >>=20 >> IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >>=20 >> That said i think the current model provides a practical starting = point.=20 >>>=20 >>> > Regarding unique identifiers for multi-valued attributes there is = a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>>=20 >>> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>>=20 >>> Regards, >>> Ganesh >>>=20 >>> On 10 August 2012 00:28, Kelly Grizzle = wrote: >>> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>>=20 >>> =20 >>>=20 >>> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>>=20 >>> =20 >>>=20 >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>=20 >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | = true | >>>=20 >>> =20 >>>=20 >>> This could be represented as two SCIM users that contain information = about the entities on other domains. >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "a99a5feba839", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "7a87f27c1dd8" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Similarly, the false negative use case (merging two users) looked = like this at the end: >>>=20 >>> =20 >>>=20 >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>=20 >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>>=20 >>> =20 >>>=20 >>> This could be represented with the following SCIM user: >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> }, >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "41206cc97c8b", >>>=20 >>> "deletionRequired": true >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Regarding unique identifiers for multi-valued attributes there is a = trade-off involved. On one hand this makes PATCH semantics easier. On = the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Emmanuel Dreux >>> Sent: Thursday, August 09, 2012 3:18 AM >>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>> Cc: scim@ietf.org >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>>=20 >>> Hi Ganesh, >>>=20 >>> =20 >>>=20 >>> Nothing prevents you in your SCIM implementation (client or server) = to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>>=20 >>> =20 >>>=20 >>> This is what we are doing with Active Directory sources or targets: >>>=20 >>> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>>=20 >>> =20 >>>=20 >>> This was written in dotnet and we have started a project to rewrite = our SCIM stack in PHP and will give it to the Open Source community. = This implementation will have a parameter : AllocateIds versus = UseExistingIDs. >>>=20 >>> This will give the choice of =93hiding=94 internalIDs or use them as = unique ID. >>>=20 >>> =20 >>>=20 >>> You can also implement such feature without violating the SCIM = specs, or without asking to include it in the specs. >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Regards, >>>=20 >>> Emmanuel Dreux >>>=20 >>> http://www.cloudiway.com >>>=20 >>> Tel: +33 4 26 78 17 58 >>>=20 >>> Mobile: +33 6 47 81 26 70 >>>=20 >>> skype: Emmanuel.Dreux >>>=20 >>> =20 >>>=20 >>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >>> =C0 : Kelly Grizzle >>> Cc : scim@ietf.org >>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>>=20 >>> Hi Kelly, >>> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >>> 1. Why should domains not expose their internal identifiers to = other domains? >>> a. >>> We are designing a protocol for a federated system of domains, where = all domains are co-equal peers. (In physics too, N-body problems are = much harder than 2-body problems. :-) Therefore, assuming that there are = only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >>> b. >>> In any non-trivial data store, there will always be the ongoing need = to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >>> c. >>> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >>> 2. The difficulty of assigning unique identifiers to the individual = values of multi-valued attributes: >>> a. >>> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >>> b. >>> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >>> Elaboration of Point 1: >>> When we consider federated identity across more than one domain, we = have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >>> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >>> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >>> Consider a case where customers sign up online, and two customers = who are privacy-conscious enter fake IDs such as =93John Smith=94, and = also use the same date of birth (say, 1 Jan 1970) or similar attributes. = The front-end application may make an intelligent (but incorrect) guess = that these two persons are the same, and re-assign the same identifier = to the second person. This is a false positive. They appear to be the = same entity, but they're actually different. When the error is = discovered, the identities will need to be split, with a new identifier = generated for one of them. >>> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >>> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >>> a. False positives: >>> Domain 1 has the following information about a customer in its data = store: >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >>> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifier: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> When the false positive is discovered and the entity is split, = Domain 1 creates a new internal identifier and now has the following = entity information. >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> Internal ID: a99a5feba839 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> This second entity with its own internal identifier is invisible to = Domain 2, and this is by design. Communication about the original entity = takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 = and vice-versa. At some convenient time (importantly, this doesn't have = to be at the time the split happens), Domain 2 can be requested to = provision a second entity, and when it responds with an identifier of = =937a87f27c1dd8=94, this can go into the mapping table as a new record = associated with the second entity's internal identifier. >>> The mapping table now contains the following entries: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >>> (What is the =93Primary flag=94 used for? We'll see when we cover = the treatment of false negatives.) >>> b. False negatives: >>> Domain 1 has the following information about what it thinks are two = distinct customers in its data store: >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>> Internal ID: 273d36e30d09 >>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>> When requesting the provisioning of these entities in Domain 2, the = following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >>> The mapping table now looks like this: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>> Now two external identifiers map to the same internal one, so = inbound communication from Domain 2 can be unambiguously translated to = the same entity internally. However, when going outwards, Domain 1 will = have to look up the translation table to determine the =93primary=94 = external ID for this entity in Domain 2, which was decided to be = =93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The = second external ID =9341206cc97c8b=94 is never used thereafter in = outbound communication. >>> At some stage (importantly, not in lockstep with the identity = merge), Domain 2 can be requested to delete the customer record = identified by =9341206cc97c8b=94, and the second entry in the mapping = table can be removed once this is acknowledged. >>> This scheme will scale up to multiple domains, because the =93External= Domain ID=94 column helps to keep track of which external ID is shared = with which Domain. (Why don't we use just one external ID for an entity = and share it with all external domains? Tight coupling again. Just as = OAuth allows an access token given to a third party to be invalidated = without affecting the access of other third parties, the use of separate = external identifiers for different domains allows fine-grained control = of identity federation.) >>> The scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many = John Smiths there are who were born on 1 Jan 1970!) >>> This is a fairly long-winded explanation, but this is why we need to = hide internal identifiers from other domains, and why mappings need to = be managed internally in each domain. Such a data model also allows us = to choose asynchronous protocols for propagation of identity events, = since there is no consistency requirement to update multiple domains = concurrently. >>> Regards, >>> Ganesh Prasad >>> =20 >>>=20 >>> On 9 August 2012 04:55, Kelly Grizzle = wrote: >>>=20 >>> Thanks for the feedback, Ganesh. I read through this and your InfoQ = article (http://www.infoq.com/articles/scim-data-model-limitations) and = have some thoughts. >>>=20 >>> =20 >>>=20 >>> > The rest of the protocol does not meaningfully use the enterprise = client=92s identifier, the "external ID" >>>=20 >>> > at all, even though it was ostensibly introduced to make things = friendlier for the client. >>>=20 >>> =20 >>>=20 >>> The usage pattern for an external ID would be to search for a user = by externalId and use the ID of the returned user in any desired = operation. For example: >>>=20 >>> =20 >>>=20 >>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> =93totalResults=94: 1, >>>=20 >>> =93Resources=94: [ >>>=20 >>> { >>>=20 >>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> Retrieve the ID from the response and use it. >>>=20 >>> =20 >>>=20 >>> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >>>=20 >>> =20 >>>=20 >>> This does introduce an additional HTTP request if the client chooses = not to store the server=92s id. An issue was created to consider = allowing operations to use the externalId = (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the = general consensus has been to not include this in the spec. One main = point of contention is that much of the rest of the spec (eg =96 group = membership references, manager references, etc=85) require knowledge of = the server=92s identifier. Continuing this discussion on the IETF list = would be a good thing, though. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> > the cloud provider's ID and the enterprise client's ID are both = "Internal IDs" with respect to their domains >>>=20 >>> =20 >>>=20 >>> I think this comes down to a nomenclature problem. The server=92s = ID does not necessarily have to be the unique identifier that the = underlying identity store uses, it just has to be stable and unique. In = many cases, the underlying identity store will provide identifiers with = these properties already (eg =96 a uuid) and it can be used by the SCIM = interface. The =93externalId=94 is referring to the fact that the id is = maintained external to the SCIM server. As long as the server=92s = identifiers are stable and unique (which is mandated by the spec), I = don=92t see a problem. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> > The secret is that every value needs a key, and multi-valued = attributes lack that. So our solution is quite >>>=20 >>> > simple - turn every list or array (of values) into a dictionary = (of key-value pairs) by providing each value >>>=20 >>> > with a unique and meaning-free identifier. >>>=20 >>> =20 >>>=20 >>> I agree that this would be useful, especially in the PATCH = operation. One reason that this wasn=92t included in the spec = originally is that it can put undue burden on the service provider. = Many service providers are putting SCIM interfaces in front of their = existing identity stores (eg =96 directory servers, SaaS application = databases, etc=85). Many of these do not have a unique identifier for = multi-valued attributes. By requiring this, a majority of the server = providers would have to start maintaining a unique key for each = multi-valued attribute. I believe this would be a roadblock for many = implementers. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> > When the SCIM protocol uses PATCH, there are areas where it seems = a bit clumsy. >>>=20 >>> =20 >>>=20 >>> I like the thoughts here. Your example reminds me of unified diffs = (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly = used with a patch program (pretty much the equivalent of the PATCH = verb). However, the three proposals seem to largely hinge on being able = to uniquely address each element within an object. Without these it is = not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85)= or provide a multi-status. >>>=20 >>>=20 >>> The 207 response would be interesting to consider for the bulk = endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),= however. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> > There are other, non-data aspects of SCIM which may require = review, such as its synchronous request-response >>>=20 >>> > interaction model, which is a form of tight coupling and could = prove to be a source of brittleness. >>>=20 >>> =20 >>>=20 >>> I agree that we should explore optional asynchronous requests in = 2.0. >>>=20 >>> =20 >>>=20 >>> Thanks again for your thoughts. I hope you stay involved in the = discussion as work on SCIM 2.0 goes forward. >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Ganesh and Sashi Prasad >>> Sent: Wednesday, August 01, 2012 4:24 PM >>> To: scim@ietf.org >>> Subject: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>>=20 >>> (I posted this on the SCIM Google Group, and I was advised to = subscribe to the mailing list and post it here instead, so here goes.) >>>=20 >>> =20 >>>=20 >>> Hi, >>>=20 >>> =20 >>>=20 >>> My name is Ganesh Prasad, and my experience in Identity and Access = Management is mainly through a 3-year project at an Australian insurance = company, an experience I have written about as a eBook on InfoQ = (http://www.infoq.com/minibooks/Identity-Management-Shoestring). >>>=20 >>> =20 >>>=20 >>> I have been following the SCIM spec off and on, and based on my = experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make. >>>=20 >>> =20 >>>=20 >>> 1. The enterprise client and the cloud provider should maintain = their own internal IDs for a resource, which they should not reveal to = each other. Both of them should map their internal IDs to a shared = External ID, and this is the only ID that should be exposed through the = API. The current specification's provision of an id (which is the = external ID and the only one to be transferred through the API) and an = "external ID" (which is the client's internal ID and should be hidden) = is diametrically opposite to this. >>>=20 >>> =20 >>>=20 >>> 2. When dealing with multi-valued attributes of a resource = (expressed as arrays in JSON), they must be converted from an array into = a dictionary with unique keys (UUIDs generated by the cloud provider = when the attribute is created). Without unique keys for every attribute = value of a resource, manipulating it will be clumsy and inelegant. >>>=20 >>> =20 >>>=20 >>> 3. The PATCH command can be improved in 3 significant ways: >>>=20 >>> 3a. Leverage the fact (from 2 above) that every value has a key, to = greatly simplify the API >>>=20 >>> 3b. Use special verbs as nested operations of the PATCH command to = add, modify and delete attributes at any level >>>=20 >>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 = OK" as the response to a PATCH (or BULK) command. >>>=20 >>> =20 >>>=20 >>> To elaborate, >>>=20 >>> =20 >>>=20 >>> 1. Revealing private IDs externally is a form of tight coupling. A = major requirement with Identity Management is to split (or merge) = identities when false positives (or false negatives) are detected, i.e., = when a resource is discovered to be more than one, or when multiple = resources are detected to be the same. If internal identifiers are = revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its = internal ID to and external one created for this explicit purpose, and = only reveal this. >>>=20 >>> =20 >>>=20 >>> In the SCIM case, when an enterprise client POSTs a resource = creation request, the cloud provider must generate its own internal UUID = as well as an external UUID, map them together, and only return the = external UUID in the "Location:" header. The enterprise client should = map this external UUID to a newly-generated internal ID of its own. In = case the resource already has an identifier within the enterprise = client's domain, then this is the internal ID that must be mapped to the = external UUID returned through the POST response. >>>=20 >>> =20 >>>=20 >>> 2. If a resource is to be created, and one of its attributes is = multi-valued, e.g., >>>=20 >>> =20 >>>=20 >>> "email-addrs" :=20 >>>=20 >>> [ >>>=20 >>> "john_smith@yahoo.com", >>>=20 >>> "john.smith@gmail.com", >>>=20 >>> "jsmith1970@hotmail.com" >>>=20 >>> < >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_3BE6DB64-55D6-4A63-B3E4-CF908A891B3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

1. Take 'external ID' out of the protocol.
2. Allow= generic search using 'GET /Users' and arbitrary URI parameters

No planned functionality is lost by this.
1. The client enterprise can still send its internal ID as part= of the resource body, inside some attribute defined by them (but not defin= ed by the protocol). Let's say they call it 'myID'.
2. The client enterprise can search for resource URIs using any attrib= ute, including this internal ID
'GET /Users?myID=3Dbjensen= 9;
Since myID is a candidate key, the server will return exactly = one URI, which is the canonical URI for the resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-4138619046=
46
3. The client can use this URI to perform all other operations as usual=
.


So taking 'externalID' out of the protocol spec only d=
oes this:

1. It avoids enshrining tight coupling in the protocol (If cli=
ents want to tightly couple themselves to the cloud provider by sending the=
ir internal IDs, they can do so. Suicide is OK, but the protocol should not=
 be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards maintaining =
their own internal-to-external identifier mappings.


That's what I'd like to see. I don't believe this =
complicates the protocol. It simplifies it and it also lends itself to a lo=
osely-coupled approach.


I'll address the multi-valued attribute suggestion separat=
ely.


Regards,
Ganesh


On 10 August 2012 0= 7:53, Phil Hunt <phil.hunt@oracle.com> wrote:


Phil

On 2012-08-09, at 14:14, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 storing this information in a mapping table outside of the SCIM spe= c is a great way to enable this solution.=A0 Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only resp= onsible for the transport layer between domains.=A0

I wasn't suggesting that the mapping table be part of the SCIM spec= . I provided that example to illustrate that splitting and merging identiti= es is a common requirement, and that decoupling local identifiers within a = domain from shared identifiers between domains was the best way to facilita= te it.

I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do there is just refrain from introducing= tight coupling. I would like to see a single identifier exposed through th= e API, with the implication (and perhaps the recommendation) that it be the= shared one. Allowing one domain to expose its internal identifier to the o= ther creates tight coupling and ensures that both domains need simultaneous= ly split or merge identities, which is not desirable. So I recommend _takin= g out_ the "external id" field from the API. The spec shouldn'= ;t encourage tight coupling. If clients want to pass in their internal ids = as part of the resource body, no one can stop them, and they can always do = a search on that attribute to retrieve the URI exactly as you visualise the= y will with the "external id", but let's not elevate an anti-= pattern to a recommendation by enshrining the "external id" as an= acceptable attribute.

Am I making sense?

I see what you are saying. I think scim gets its current simplicit= y from its single owner hub spoke model implementing tight coupling.=A0
IMHO loose coupling is a much more complex solution. The rea= lity is that each end-point has value to contribute and thus the single-own= er model will eventually need to become multi-owner or multi-hub.=A0

That said i think the current model provides a practica= l starting point.=A0

>=A0 Regarding unique identifiers for multi-valued attributes there is a= trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O= n the other hand it puts extra burden on service providers.=A0

Precisely. The spec has to strike the right balance. It would be i= nteresting to hear from the other members of the spec mailing list. You kno= w where I stand on this. It would be good to hear the spectrum of opinions.=

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emmanuel.=A0 I had= started writing up a similar response.=A0 As you suggest, storing this inf= ormation in a mapping table outside of the SCIM spec is a great way to enable this solution.=A0 Part of the key here is that SCIM is just = a piece of the architecture for this solution, and is only responsible for = the transport layer between domains.

=A0<= /p>

You could also model thes= e ID mappings in the SCIM user as an extension but would probably not want = to expose these externally.=A0 Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /u>

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0

This could be repre= sented as two SCIM users that contain information about the entities on oth= er domains.

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "a99a5feba839",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "7a87f27c1dd8"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

In the second user, the l= inkedUsers attribute would be empty until the split user was synced to doma= in 2.

=A0<= /p>

=A0<= /p>

Similarly, the false nega= tive use case (merging two users) looked like this at the end:

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0= | false=A0=A0=A0=A0=A0=A0=A0 |

=A0<= /p>

This could be repre= sented with the following SCIM user:

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 },

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "41206cc97c8b",

=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&= quot;: true

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

=A0<= /p>

Regarding unique identifi= ers for multi-valued attributes there is a trade-off involved.=A0 On one ha= nd this makes PATCH semantics easier.=A0 On the other hand it puts extra burden on service providers.=A0 Since the inception of SCIM, a = key goal has been to foster adoption by service providers by making things = fit easily onto existing systems.=A0 IMO the value gained by unique identif= iers for multi-valued attributes is not worth the demands put on a service provider.=A0 I also think that vend= ors that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement.=A0 In a green field environm= ent we do have the luxury of mandating a model to make certain operations more elegant.=A0 However, we can=92t ig= nore legacy systems.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

Hi Ganesh,=

=A0=

Nothing prevents you in y= our SCIM implementation (client or server) to generate a unique identifier = for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

=A0<= /p>

This is what we are doing= with Active Directory sources or targets:

As we didn=92t find an im= mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan= ge (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

=A0<= /p>

This was written in dotne= t and we have started a project to rewrite our SCIM stack in PHP and will g= ive it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice= of =93hiding=94 internalIDs or use them as unique ID.=

=A0<= /p>

You can also implement su= ch feature without violating the SCIM specs, or without asking to include i= t in the specs.

=A0<= /p>

--<= /u>

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org
Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Hi K= elly,

Than= ks for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.=A0=A0=A0=A0=A0 Why should domains not expose= their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating l= egacy data stores to such a model. However, in the larger historical contex= t of cross-domain identity management, we are really at the very early stag= es. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.=

Elab= oration of Point 1:

When= we consider federated identity across more than one domain, we have to ass= ume that domains are not necessarily master-slave in their interaction. The= most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are n= otified to other domains (when necessary) in an asynchronous manner (i.e., = through messaging) and the other domains are free to respond to these event= s in an appropriate manner and at a time of their convenience.

A ke= y set of lifecycle events for an entity is the merging and splitting of ide= ntity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores.

Cons= ider a case where customers sign up online, and two customers who are priva= cy-conscious enter fake IDs such as =93John Smith=94, and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelli= gent (but incorrect) guess that these two persons are the same, and re-assi= gn the same identifier to the second person. This is a false positive. They= appear to be the same entity, but they're actually different. When the error is discovered, the identiti= es will need to be split, with a new identifier generated for one of them.<= u>

Cons= ider the opposite case where a customer signs up through two different port= als or in two different sessions, using the names =93JSmith=94 and =93JohnS= =94. It is very likely that they will be treated as two different customers and assigned two unique id= entifiers. This is a false negative. They appear to be two entities, but ar= e actually the same. At a later stage, when the error is discovered, the id= entities will have to be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external ones and only exposing ext= ernal identifiers to other domains.

a. F= alse positives:

Doma= in 1 has the following information about a customer in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of this entity in Domain 2, the following ID i= s returned by Domain 2: ff487230b3a0.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifier:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

When= the false positive is discovered and the entity is split, Domain 1 creates= a new internal identifier and now has the following entity information.=

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: a99a5feba839

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

This= second entity with its own internal identifier is invisible to Domain 2, a= nd this is by design. Communication about the original entity takes place a= s before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien= t time (importantly, this doesn't have to be at the time the split happ= ens), Domain 2 can be requested to provision a second entity, and when it r= esponds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the sec= ond entity's internal identifier.

The = mapping table now contains the following entries:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| a99a5feba839 | = D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened= , and the provisioning that it does is not in lockstep with the split in id= entity that occurred in Domain 1.

(Wha= t is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.)

b. F= alse negatives:

Doma= in 1 has the following information about what it thinks are two distinct cu= stomers in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: 273d36e30d09

Attr= ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of these entities in Domain 2, the following I= Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifiers:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 273d36e30d09 | = D2 | 41206cc97c8b | true |

When= the false negative is discovered and the two entities are merged, Domain 1= drops one of the internal identifiers and rationalises the name of the cus= tomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr= ops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | = D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound communica= tion from Domain 2 can be unambiguously translated to the same entity inter= nally. However, when going outwards, Domain 1 will have to look up the translation table to det= ermine the =93primary=94 external ID for this entity in Domain 2, which was= decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 = comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound communication.

At s= ome stage (importantly, not in lockstep with the identity merge), Domain 2 = can be requested to delete the customer record identified by =9341206cc97c8= b=94, and the second entry in the mapping table can be removed once this is acknowledged.

This= scheme will scale up to multiple domains, because the =93External Domain I= D=94 column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it with all external domains?= Tight coupling again. Just as OAuth allows an access token given to a thir= d party to be invalidated without affecting the access of other third parti= es, the use of separate external identifiers for different domains allows fine-grained control of identity = federation.)

The = scheme also allows the splitting of an entity into more than two entities, = and the merging of more than two entities into a single one. (Any organisat= ion with a web-facing application will tell you how many John Smiths there are who were born on = 1 Jan 1970!)

This= is a fairly long-winded explanation, but this is why we need to hide inter= nal identifiers from other domains, and why mappings need to be managed int= ernally in each domain. Such a data model also allows us to choose asynchronous protocols for prop= agation of identity events, since there is no consistency requirement to up= date multiple domains concurrently.

Rega= rds,

Gane= sh Prasad

=A0

On 9 August 2012 04:55, Kelly Griz= zle <ke= lly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, = Ganesh.=A0 I read through this and your InfoQ article (= http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

=A0<= /p>

> The rest of the protocol does not meani= ngfully use the enterprise client=92s identifier, the "external ID&quo= t;

> at all, even thoug= h it was ostensibly introduced to make things friendlier for the client.

=A0<= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.=A0 For example:<= u>

=A0<= /p>

GET /Users?filter=3Dexter= nalId eq =93bjensen=94&attributes=3Did

=A0<= /p>

{

=A0 =93totalResults=94: 1,

=A0 =93Resources=94: [

=A0=A0=A0 {

=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45= 3a-919d-413861904646=94

=A0=A0=A0 }

=A0 ]

}

=A0<= /p>

Retrieve the ID from the = response and use it.

=A0<= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

=A0<= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server=92s id.= =A0 An issue was created to consider allowing operations to use the externalId= (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.=A0 One main point of contention is that much of the rest of the spec (e= g =96 group membership references, manager references, etc=85) require know= ledge of the server=92s identifier.=A0 Continuing this discussion on the IETF list would be a good thing, though.<= /u>

=A0<= /p>

=A0<= /p>

> the cloud provider's ID and the ent= erprise client's ID are both "Internal IDs" with respect to t= heir domains

=A0<= /p>

I think this comes down t= o a nomenclature problem.=A0 The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just = has to be stable and unique.=A0 In many cases, the underlying identity stor= e will provide identifiers with these properties already (eg =96 a uuid) an= d it can be used by the SCIM interface.=A0 The =93externalId=94 is referring to the fact that the id is maintained ex= ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta= ble and unique (which is mandated by the spec), I don=92t see a problem.

=A0<= /p>

=A0<= /p>

> The secret is that=A0every value nee= ds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn ever= y list or array (of values) into a dictionary (of key-value pairs) by provi= ding each value

> with a unique and = meaning-free identifier.

=A0<= /p>

I agree that this would b= e useful, especially in the PATCH operation.=A0 One reason that this wasn= =92t included in the spec originally is that it can put undue burden on the ser= vice provider.=A0 Many service providers are putting SCIM interfaces in fro= nt of their existing identity stores (eg =96 directory servers, SaaS applic= ation databases, etc=85).=A0 Many of these do not have a unique identifier for multi-valued attributes.=A0 By requiri= ng this, a majority of the server providers would have to start maintaining= a unique key for each multi-valued attribute.=A0 I believe this would be a= roadblock for many implementers.

=A0<= /p>

=A0<= /p>

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.

=A0<= /p>

I like the thoughts here.= =A0 Your example reminds me of unified diffs (http://en.wikipedi= a.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb). =A0However, the three proposals seem to largely hinge on= being able to uniquely address each element within an object.=A0 Without t= hese it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<= /span>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

=A0<= /p>

=A0<= /p>

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model,= which is a form of tight coupling and could prove to be a source of brittl= eness.

=A0<= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

=A0<= /p>

Thanks again for your tho= ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

=A0

Hi,

=A0

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks= /Identity-Management-Shoestring).

=A0

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

=A0

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should = be exposed through the API. The current specification's provision of an= id (which is the external ID and the only one to be transferred through th= e API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposi= te to this.

=A0

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys = for every attribute value of a resource, manipulating it will be clumsy and= inelegant.

=A0

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level=

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

=A0

To elaborate,

=A0

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or = when multiple resources are detected to be the same. If internal identifier= s are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its internal ID to and external one crea= ted for this explicit purpose, and only reveal this.

=A0

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The= enterprise client should map this external UUID to a newly-generated inter= nal ID of its own. In case the resource already has an identifier within th= e enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through = the POST response.

=A0

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 "john_smith@yahoo.com",

=A0 =A0 =A0 =A0 "john.smith@gmail.com",

=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"

<
________________________________= _______________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

--0015175cd13a46a3ea04c6e71af5-- From trey.drake@unboundid.com Fri Aug 10 07:51:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6940721F84F7 for ; Fri, 10 Aug 2012 07:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfX+cZ-O1p8O for ; Fri, 10 Aug 2012 07:51:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54F8A21F84EF for ; Fri, 10 Aug 2012 07:51:00 -0700 (PDT) Received: by yhq56 with SMTP id 56so1798748yhq.31 for ; Fri, 10 Aug 2012 07:50:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=GMRXCgmFDq+gPTaJ6VbkR7r4p3EcO7CfR0E36Z+lEmE=; b=msihEJSlaD7SHVWe7wuU/JVH1i6zuLGSolVCCheRomIL5GYloC+dP6xvInNGBqlj9B OEOVfjefXg2jAWUyL5YzkkE5h/6dOoryNpfFpZGcsqhoNrSmv2d3GfNbDLT3fot+XTVR EN4HtYB3Erk5vt9xY9ZUATaTJojJWCryHnQRsehuPTzVG7u7RUlLbsaaGWcN5pJv5Zup SQaGXfYB3FNfs6hts2FTwZfsMAMeKfM8cG5HH0APbZi4ik9fwWQqL0DFTr0v7clhtT10 64I6osZ52/jo8DB0al7q7oojtFzVBRb2203/klBdFf3hgbrqiOwykuQaRoxvvIs03mbt ke3w== MIME-Version: 1.0 Received: by 10.236.136.39 with SMTP id v27mr3042411yhi.96.1344610259586; Fri, 10 Aug 2012 07:50:59 -0700 (PDT) Received: by 10.236.173.73 with HTTP; Fri, 10 Aug 2012 07:50:59 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Fri, 10 Aug 2012 09:50:59 -0500 Message-ID: From: Trey Drake To: Ganesh and Sashi Prasad Content-Type: multipart/alternative; boundary=20cf303bfcc6e2511504c6ea781d X-Gm-Message-State: ALoCoQmW+CTcxfoii/CqtdAlndciY1BunbVK5M9BP8Z1o9XU5lQUFqNKRlDt/WRTO2UdfT+Ol2en Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle , Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:51:08 -0000 --20cf303bfcc6e2511504c6ea781d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute within the *schema* specification. As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). Please clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence retrieve resources on any attribute it chooses, externalId or otherwise. Nothing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < g.c.prasad@gmail.com> wrote: > > I think scim gets its current simplicity from its single owner hub > spoke model implementing tight coupling. [...] IMHO loose coupling is a > much more complex solution. > > Phil, > > I'm a bit surprised that you're implying "tight coupling =3D=3D simple" a= nd > "loose coupling =3D=3D complex". That's contrary to my experience. > > When I say "loose coupling", I mean "no unnecessary dependencies". > Invariably, a reduction in dependencies leads to greater simplicity. > > Let's not confuse reduction of dependencies in the data model with a > hub-and-spokes architecture. They're entirely orthogonal aspects of the > solution. > > All that my suggestion involves is, > > 1. Take 'external ID' out of the protocol. > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters > > No planned functionality is lost by this. > > 1. The client enterprise can still send its internal ID as part of the > resource body, inside some attribute defined by them (but not defined by > the protocol). Let's say they call it 'myID'. > 2. The client enterprise can search for resource URIs using any attribute= , > including this internal ID > 'GET /Users?myID=3Dbjensen' > Since myID is a candidate key, the server will return exactly one URI, > which is the canonical URI for the resource > > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > > 3. The client can use this URI to perform all other operations as usual. > > > So taking 'externalID' out of the protocol spec only does this: > > 1. It avoids enshrining tight coupling in the protocol (If clients want t= o tightly couple themselves to the cloud provider by sending their internal= IDs, they can do so. Suicide is OK, but the protocol should not be guilty = of assisted suicide. ;-) > > 2. It encourages loose coupling by nudging clients towards maintaining th= eir own internal-to-external identifier mappings. > > > That's what I'd like to see. I don't believe this complicates the protoco= l. It simplifies it and it also lends itself to a loosely-coupled approach. > > > I'll address the multi-valued attribute suggestion separately. > > > Regards, > > Ganesh > > > > > On 10 August 2012 07:53, Phil Hunt wrote: > >> >> >> Phil >> >> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >> wrote: >> >> > storing this information in a mapping table outside of the SCIM spec >> is a great way to enable this solution. Part of the key here is that SC= IM >> is just a piece of the architecture for this solution, and is only >> responsible for the transport layer between domains. >> >> I wasn't suggesting that the mapping table be part of the SCIM spec. I >> provided that example to illustrate that splitting and merging identitie= s >> is a common requirement, and that decoupling local identifiers within a >> domain from shared identifiers between domains was the best way to >> facilitate it. >> >> I'm suggesting that the spec do less, not more. >> >> What the SCIM spec needs to do there is just refrain from introducing >> tight coupling. I would like to see a single identifier exposed through = the >> API, with the implication (and perhaps the recommendation) that it be th= e >> shared one. Allowing one domain to expose its internal identifier to the >> other creates tight coupling and ensures that both domains need >> simultaneously split or merge identities, which is not desirable. So I >> recommend _taking out_ the "external id" field from the API. The spec >> shouldn't encourage tight coupling. If clients want to pass in their >> internal ids as part of the resource body, no one can stop them, and the= y >> can always do a search on that attribute to retrieve the URI exactly as = you >> visualise they will with the "external id", but let's not elevate an >> anti-pattern to a recommendation by enshrining the "external id" as an >> acceptable attribute. >> >> Am I making sense? >> >> >> I see what you are saying. I think scim gets its current simplicity from >> its single owner hub spoke model implementing tight coupling. >> >> IMHO loose coupling is a much more complex solution. The reality is that >> each end-point has value to contribute and thus the single-owner model w= ill >> eventually need to become multi-owner or multi-hub. >> >> That said i think the current model provides a practical starting point. >> >> >> > Regarding unique identifiers for multi-valued attributes there is a >> trade-off involved. On one hand this makes PATCH semantics easier. On = the >> other hand it puts extra burden on service providers. >> >> Precisely. The spec has to strike the right balance. It would be >> interesting to hear from the other members of the spec mailing list. You >> know where I stand on this. It would be good to hear the spectrum of >> opinions. >> >> Regards, >> Ganesh >> >> On 10 August 2012 00:28, Kelly Grizzle wrot= e: >> >>> Thanks Emmanuel. I had started writing up a similar response. As you >>> suggest, storing this information in a mapping table outside of the SCI= M >>> spec is a great way to enable this solution. Part of the key here is t= hat >>> SCIM is just a piece of the architecture for this solution, and is only >>> responsible for the transport layer between domains.**** >>> >>> ** ** >>> >>> You could also model these ID mappings in the SCIM user as an extension >>> but would probably not want to expose these externally. Here is an exa= mple >>> of how to model the end state of the false positive scenario (splitting= a >>> user):**** >>> >>> ** ** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>> true |**** >>> >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>> true |**** >>> >>> ** ** >>> >>> This could be represented as two SCIM users that contain information >>> about the entities on other domains.**** >>> >>> ** ** >>> >>> {**** >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"],**** >>> >>> "id": "9caf78aac3d6",**** >>> >>> "userName": "John Smith",**** >>> >>> "urn:scim:schemas:extension:federation:1.0": {**** >>> >>> "linkedUsers": [**** >>> >>> {**** >>> >>> "domain": "D2",**** >>> >>> "externalEntityId": "ff487230b3a0"**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> {**** >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"],**** >>> >>> "id": "a99a5feba839",**** >>> >>> "userName": "John Smith",**** >>> >>> "urn:scim:schemas:extension:federation:1.0": {**** >>> >>> "linkedUsers": [**** >>> >>> {**** >>> >>> "domain": "D2",**** >>> >>> "externalEntityId": "7a87f27c1dd8"**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> In the second user, the linkedUsers attribute would be empty until the >>> split user was synced to domain 2.**** >>> >>> ** ** >>> >>> ** ** >>> >>> Similarly, the false negative use case (merging two users) looked like >>> this at the end:**** >>> >>> ** ** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>> true |**** >>> >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>> false |**** >>> >>> ** ** >>> >>> This could be represented with the following SCIM user:**** >>> >>> ** ** >>> >>> {**** >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"],**** >>> >>> "id": "9caf78aac3d6",**** >>> >>> "userName": "John Smith",**** >>> >>> "urn:scim:schemas:extension:federation:1.0": {**** >>> >>> "linkedUsers": [**** >>> >>> {**** >>> >>> "domain": "D2",**** >>> >>> "externalEntityId": "ff487230b3a0"**** >>> >>> },**** >>> >>> {**** >>> >>> "domain": "D2",**** >>> >>> "externalEntityId": "41206cc97c8b",**** >>> >>> "deletionRequired": true**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> ** ** >>> >>> Regarding unique identifiers for multi-valued attributes there is a >>> trade-off involved. On one hand this makes PATCH semantics easier. On= the >>> other hand it puts extra burden on service providers. Since the incept= ion >>> of SCIM, a key goal has been to foster adoption by service providers by >>> making things fit easily onto existing systems. IMO the value gained b= y >>> unique identifiers for multi-valued attributes is not worth the demands= put >>> on a service provider. I also think that vendors that have a >>> non-SCIM-compliant API will choose to keep things that way if the spec = is >>> too hard for them to implement. In a green field environment we do hav= e >>> the luxury of mandating a model to make certain operations more elegant= . >>> However, we can=92t ignore legacy systems. **** >>> >>> ** ** >>> >>> --Kelly**** >>> >>> ** ** >>> >>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >>> Of *Emmanuel Dreux >>> *Sent:* Thursday, August 09, 2012 3:18 AM >>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>> *Cc:* scim@ietf.org >>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >>> >>> ** ** >>> >>> Hi Ganesh,**** >>> >>> ** ** >>> >>> Nothing prevents you in your SCIM implementation (client or server) to >>> generate a unique identifier for each synchronized object and maintain = an >>> internal mapping table ( you would have to map group membership as well= ). >>> **** >>> >>> ** ** >>> >>> This is what we are doing with Active Directory sources or targets:**** >>> >>> As we didn=92t find an immutable uniqueID in AD systems >>> (DN,samAccountName, UPN) are subject to change (even objectGuid can cha= nge >>> if an AD domain is migrated), we decided to generate and maintain an >>> internal table of ids. This fits your requirements as it hides internal= ids. >>> **** >>> >>> ** ** >>> >>> This was written in dotnet and we have started a project to rewrite our >>> SCIM stack in PHP and will give it to the Open Source community. This >>> implementation will have a parameter : AllocateIds versus UseExistingID= s. >>> **** >>> >>> This will give the choice of =93hiding=94 internalIDs or use them as un= ique >>> ID.**** >>> >>> ** ** >>> >>> You can also implement such feature without violating the SCIM specs, o= r >>> without asking to include it in the specs.**** >>> >>> ** ** >>> >>> --**** >>> >>> Regards,**** >>> >>> Emmanuel Dreux**** >>> >>> http://www.cloudiway.com**** >>> >>> Tel: +33 4 26 78 17 58**** >>> >>> Mobile: +33 6 47 81 26 70**** >>> >>> skype: Emmanuel.Dreux**** >>> >>> ** ** >>> >>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>> >>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>> *=C0 :* Kelly Grizzle >>> *Cc :* scim@ietf.org >>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >>> >>> ** ** >>> >>> Hi Kelly,**** >>> >>> Thanks for your response. Let me first respond in brief to the two main >>> points you have made, and then elaborate on the first.**** >>> >>> **1. **Why should domains not expose their internal identifiers to >>> other domains?**** >>> >>> a.**** >>> >>> We are designing a protocol for a federated system of domains, where al= l >>> domains are co-equal peers. (In physics too, N-body problems are much >>> harder than 2-body problems. :-) Therefore, assuming that there are onl= y >>> two players in the interaction makes this tightly coupled in a number o= f >>> ways. We should rely on messaging and notification, with encapsulation = of >>> domain-specific data.**** >>> >>> b. **** >>> >>> In any non-trivial data store, there will always be the ongoing need to >>> merge and split identities as and when =93false negatives=94 and =93fal= se >>> positives=94 are discovered. A domain should be able to handle this int= ernal >>> housekeeping freely, only notifying other domains when convenient. Mapp= ing >>> of internal identifiers to external ones and maintaining this mapping >>> internally allows this loosely-coupled housekeeping to take place. Shar= ing >>> internal identifiers (or otherwise outsourcing the mapping of internal = to >>> external identifiers) forces housekeeping activities to be done in >>> lock-step across domains.**** >>> >>> c.**** >>> >>> Asynchronous interaction is not just a matter of a suitable wire >>> protocol which can be designed later. The data model plays a crucial ro= le >>> in enabling or constraining such interaction. A tightly-coupled data mo= del >>> will force the use of synchronous interactions, and the exposure of >>> internal identifiers is a key part of this tight coupling.**** >>> >>> 2. The difficulty of assigning unique identifiers to the individual >>> values of multi-valued attributes:**** >>> >>> a. **** >>> >>> I'm not belittling the effort involved in migrating legacy data stores >>> to such a model. However, in the larger historical context of cross-dom= ain >>> identity management, we are really at the very early stages. If a >>> relatively new discipline and a brand new spec are held captive to lega= cy >>> considerations, we are losing an opportunity to provide a clean and ele= gant >>> model to subsequent users of the spec, and this will have repercussions >>> over many years or even decades.**** >>> >>> b. **** >>> >>> If incumbent cloud providers find it hard to immediately adopt the >>> dictionary model for existing multi-valued attributes, they can transit= ion >>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-com= pliant=94 >>> APIs to their customers and encouraging new customers to adopt the >>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradual= ly >>> migrated to the SCIM-compliant API. The logistics are not insurmountabl= e, >>> and shouldn't prevent the adoption of a dictionary model for multi-valu= ed >>> attributes.**** >>> >>> Elaboration of Point 1:**** >>> >>> When we consider federated identity across more than one domain, we hav= e >>> to assume that domains are not necessarily master-slave in their >>> interaction. The most generic interaction model is peer-to-peer, where >>> entity lifecycle events within a domain are notified to other domains (= when >>> necessary) in an asynchronous manner (i.e., through messaging) and the >>> other domains are free to respond to these events in an appropriate man= ner >>> and at a time of their convenience.**** >>> >>> A key set of lifecycle events for an entity is the merging and splittin= g >>> of identity that is often required.**** >>> >>> The question =93Is this one entity?=94 can be answered either yes (posi= tive) >>> or no (negative). But sometimes, we can discover false positives and fa= lse >>> negatives in our data stores.**** >>> >>> Consider a case where customers sign up online, and two customers who >>> are privacy-conscious enter fake IDs such as =93John Smith=94, and also= use the >>> same date of birth (say, 1 Jan 1970) or similar attributes. The front-e= nd >>> application may make an intelligent (but incorrect) guess that these tw= o >>> persons are the same, and re-assign the same identifier to the second >>> person. This is a false positive. They appear to be the same entity, bu= t >>> they're actually different. When the error is discovered, the identitie= s >>> will need to be split, with a new identifier generated for one of them.= * >>> *** >>> >>> Consider the opposite case where a customer signs up through two >>> different portals or in two different sessions, using the names =93JSmi= th=94 >>> and =93JohnS=94. It is very likely that they will be treated as two dif= ferent >>> customers and assigned two unique identifiers. This is a false negative= . >>> They appear to be two entities, but are actually the same. At a later >>> stage, when the error is discovered, the identities will have to be mer= ged, >>> and one of the identifiers will have to be dropped.**** >>> >>> These are not theoretical use cases. They form a significant proportion >>> of the user base in most large Web-facing applications. Let's see how t= hese >>> can be managed in a federated way by mapping internal identifiers to >>> external ones and only exposing external identifiers to other domains.*= * >>> ** >>> >>> a. False positives:**** >>> >>> Domain 1 has the following information about a customer in its data >>> store:**** >>> >>> Internal ID: 9caf78aac3d6**** >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>> >>> When requesting the provisioning of this entity in Domain 2, the >>> following ID is returned by Domain 2: ff487230b3a0.**** >>> >>> Domain 1 then maintains the following in a mapping table and uses it fo= r >>> translation when talking to Domain 2, taking care never to expose its >>> internal identifier:**** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>> >>> When the false positive is discovered and the entity is split, Domain 1 >>> creates a new internal identifier and now has the following entity >>> information.**** >>> >>> Internal ID: 9caf78aac3d6**** >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>> >>> Internal ID: a99a5feba839**** >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>> >>> This second entity with its own internal identifier is invisible to >>> Domain 2, and this is by design. Communication about the original entit= y >>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >>> vice-versa. At some convenient time (importantly, this doesn't have to = be >>> at the time the split happens), Domain 2 can be requested to provision = a >>> second entity, and when it responds with an identifier of =937a87f27c1d= d8=94, >>> this can go into the mapping table as a new record associated with the >>> second entity's internal identifier.**** >>> >>> The mapping table now contains the following entries:**** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>> >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** >>> >>> Domain 2 is not even aware that a split has happened, and the >>> provisioning that it does is not in lockstep with the split in identity >>> that occurred in Domain 1.**** >>> >>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>> treatment of false negatives.)**** >>> >>> b. False negatives:**** >>> >>> Domain 1 has the following information about what it thinks are two >>> distinct customers in its data store:**** >>> >>> Internal ID: 9caf78aac3d6**** >>> >>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** >>> >>> Internal ID: 273d36e30d09**** >>> >>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** >>> >>> When requesting the provisioning of these entities in Domain 2, the >>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.*= * >>> ** >>> >>> Domain 1 then maintains the following in a mapping table and uses it fo= r >>> translation when talking to Domain 2, taking care never to expose its >>> internal identifiers:**** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>> >>> | 273d36e30d09 | D2 | 41206cc97c8b | true |**** >>> >>> When the false negative is discovered and the two entities are merged, >>> Domain 1 drops one of the internal identifiers and rationalises the nam= e of >>> the customer (say, to =93John Smith=94). Let's say it retains the first= ID >>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** >>> >>> The mapping table now looks like this:**** >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag |**** >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>> >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** >>> >>> Now two external identifiers map to the same internal one, so inbound >>> communication from Domain 2 can be unambiguously translated to the same >>> entity internally. However, when going outwards, Domain 1 will have to = look >>> up the translation table to determine the =93primary=94 external ID for= this >>> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's = where >>> the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never >>> used thereafter in outbound communication.**** >>> >>> At some stage (importantly, not in lockstep with the identity merge), >>> Domain 2 can be requested to delete the customer record identified by >>> =9341206cc97c8b=94, and the second entry in the mapping table can be re= moved >>> once this is acknowledged.**** >>> >>> This scheme will scale up to multiple domains, because the =93External >>> Domain ID=94 column helps to keep track of which external ID is shared = with >>> which Domain. (Why don't we use just one external ID for an entity and >>> share it with all external domains? Tight coupling again. Just as OAuth >>> allows an access token given to a third party to be invalidated without >>> affecting the access of other third parties, the use of separate extern= al >>> identifiers for different domains allows fine-grained control of identi= ty >>> federation.)**** >>> >>> The scheme also allows the splitting of an entity into more than two >>> entities, and the merging of more than two entities into a single one. = (Any >>> organisation with a web-facing application will tell you how many John >>> Smiths there are who were born on 1 Jan 1970!)**** >>> >>> This is a fairly long-winded explanation, but this is why we need to >>> hide internal identifiers from other domains, and why mappings need to = be >>> managed internally in each domain. Such a data model also allows us to >>> choose asynchronous protocols for propagation of identity events, since >>> there is no consistency requirement to update multiple domains concurre= ntly. >>> **** >>> >>> Regards, **** >>> >>> Ganesh Prasad**** >>> >>> ** ** >>> >>> On 9 August 2012 04:55, Kelly Grizzle >>> wrote:**** >>> >>> Thanks for the feedback, Ganesh. I read through this and your InfoQ >>> article (http://www.infoq.com/articles/scim-data-model-limitations) and >>> have some thoughts.**** >>> >>> **** >>> >>> > The rest of the protocol does not meaningfully use the enterprise >>> client=92s identifier, the "external ID"**** >>> >>> > at all, even though it was ostensibly introduced to make things >>> friendlier for the client.**** >>> >>> **** >>> >>> The usage pattern for an external ID would be to search for a user by >>> externalId and use the ID of the returned user in any desired operation= . >>> For example:**** >>> >>> **** >>> >>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** >>> >>> **** >>> >>> {**** >>> >>> =93totalResults=94: 1,**** >>> >>> =93Resources=94: [**** >>> >>> {**** >>> >>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> **** >>> >>> Retrieve the ID from the response and use it.**** >>> >>> **** >>> >>> DELETE /Users/2819c223-7f76-453a-919d-413861904646**** >>> >>> **** >>> >>> This does introduce an additional HTTP request if the client chooses no= t >>> to store the server=92s id. An issue was created to consider allowing >>> operations to use the externalId ( >>> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the >>> general consensus has been to not include this in the spec. One main p= oint >>> of contention is that much of the rest of the spec (eg =96 group member= ship >>> references, manager references, etc=85) require knowledge of the server= =92s >>> identifier. Continuing this discussion on the IETF list would be a goo= d >>> thing, though.**** >>> >>> **** >>> >>> **** >>> >>> > the cloud provider's ID and the enterprise client's ID are both >>> "Internal IDs" with respect to their domains**** >>> >>> **** >>> >>> I think this comes down to a nomenclature problem. The server=92s ID d= oes >>> not necessarily have to be the unique identifier that the underlying >>> identity store uses, it just has to be stable and unique. In many case= s, >>> the underlying identity store will provide identifiers with these >>> properties already (eg =96 a uuid) and it can be used by the SCIM inter= face. >>> The =93externalId=94 is referring to the fact that the id is maintained >>> external to the SCIM server. As long as the server=92s identifiers are >>> stable and unique (which is mandated by the spec), I don=92t see a prob= lem. >>> **** >>> >>> **** >>> >>> **** >>> >>> > The secret is that *every value needs a key*, and multi-valued >>> attributes lack that. So our solution is quite**** >>> >>> > simple - turn every list or array (of values) into a dictionary (of >>> key-value pairs) by providing each value**** >>> >>> > with a unique and meaning-free identifier.**** >>> >>> **** >>> >>> I agree that this would be useful, especially in the PATCH operation. >>> One reason that this wasn=92t included in the spec originally is that i= t can >>> put undue burden on the service provider. Many service providers are >>> putting SCIM interfaces in front of their existing identity stores (eg = =96 >>> directory servers, SaaS application databases, etc=85). Many of these = do not >>> have a unique identifier for multi-valued attributes. By requiring thi= s, a >>> majority of the server providers would have to start maintaining a uniq= ue >>> key for each multi-valued attribute. I believe this would be a roadblo= ck >>> for many implementers.**** >>> >>> **** >>> >>> **** >>> >>> > When the SCIM protocol uses PATCH, there are areas where it seems a >>> bit clumsy.**** >>> >>> **** >>> >>> I like the thoughts here. Your example reminds me of unified diffs ( >>> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >>> used with a patch program (pretty much the equivalent of the PATCH verb= ). >>> However, the three proposals seem to largely hinge on being able to >>> uniquely address each element within an object. Without these it is no= t so >>> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or >>> provide a multi-status.**** >>> >>> >>> The 207 response would be interesting to consider for the bulk endpoint= ( >>> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources= ), >>> however.**** >>> >>> **** >>> >>> **** >>> >>> > There are other, non-data aspects of SCIM which may require review, >>> such as its synchronous request-response**** >>> >>> > interaction model, which is a form of tight coupling and could prove >>> to be a source of brittleness.**** >>> >>> **** >>> >>> I agree that we should explore optional asynchronous requests in 2.0.**= * >>> * >>> >>> **** >>> >>> Thanks again for your thoughts. I hope you stay involved in the >>> discussion as work on SCIM 2.0 goes forward.**** >>> >>> **** >>> >>> --Kelly**** >>> >>> **** >>> >>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >>> Of *Ganesh and Sashi Prasad >>> *Sent:* Wednesday, August 01, 2012 4:24 PM >>> *To:* scim@ietf.org >>> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** >>> >>> **** >>> >>> (I posted this on the SCIM Google Group, and I was advised to subscribe >>> to the mailing list and post it here instead, so here goes.)**** >>> >>> **** >>> >>> Hi,**** >>> >>> **** >>> >>> My name is Ganesh Prasad, and my experience in Identity and Access >>> Management is mainly through a 3-year project at an Australian insuranc= e >>> company, an experience I have written about as a eBook on InfoQ ( >>> http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** >>> >>> **** >>> >>> I have been following the SCIM spec off and on, and based on my >>> experience with a loosely-coupled architecture that I found to be >>> successful, I have the following 3 suggestions to make.**** >>> >>> **** >>> >>> 1. The enterprise client and the cloud provider should maintain their >>> own internal IDs for a resource, which they should not reveal to each >>> other. Both of them should map their internal IDs to a shared External = ID, >>> and this is the only ID that should be exposed through the API. The cur= rent >>> specification's provision of an id (which is the external ID and the on= ly >>> one to be transferred through the API) and an "external ID" (which is t= he >>> client's internal ID and should be hidden) is diametrically opposite to >>> this.**** >>> >>> **** >>> >>> 2. When dealing with multi-valued attributes of a resource (expressed a= s >>> arrays in JSON), they must be converted from an array into a dictionary >>> with unique keys (UUIDs generated by the cloud provider when the attrib= ute >>> is created). Without unique keys for every attribute value of a resourc= e, >>> manipulating it will be clumsy and inelegant.**** >>> >>> **** >>> >>> 3. The PATCH command can be improved in 3 significant ways:**** >>> >>> 3a. Leverage the fact (from 2 above) that every value has a key, to >>> greatly simplify the API**** >>> >>> 3b. Use special verbs as nested operations of the PATCH command to add, >>> modify and delete attributes at any level**** >>> >>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK= " >>> as the response to a PATCH (or BULK) command.**** >>> >>> **** >>> >>> To elaborate,**** >>> >>> **** >>> >>> 1. Revealing private IDs externally is a form of tight coupling. A majo= r >>> requirement with Identity Management is to split (or merge) identities = when >>> false positives (or false negatives) are detected, i.e., when a resourc= e is >>> discovered to be more than one, or when multiple resources are detected= to >>> be the same. If internal identifiers are revealed to external domains, = such >>> clean-ups become difficult, hence every domain that wants to expose >>> references to a resource must map its internal ID to and external one >>> created for this explicit purpose, and only reveal this.**** >>> >>> **** >>> >>> In the SCIM case, when an enterprise client POSTs a resource creation >>> request, the cloud provider must generate its own internal UUID as well= as >>> an external UUID, map them together, and only return the external UUID = in >>> the "Location:" header. The enterprise client should map this external = UUID >>> to a newly-generated internal ID of its own. In case the resource alrea= dy >>> has an identifier within the enterprise client's domain, then this is t= he >>> internal ID that must be mapped to the external UUID returned through t= he >>> POST response.**** >>> >>> **** >>> >>> 2. If a resource is to be created, and one of its attributes is >>> multi-valued, e.g.,**** >>> >>> **** >>> >>> "email-addrs" : **** >>> >>> [**** >>> >>> "john_smith@yahoo.com",**** >>> >>> "john.smith@gmail.com",**** >>> >>> "jsmith1970@hotmail.com"**** >>> < >>> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --20cf303bfcc6e2511504c6ea781d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ganesh,

I'll base my comments on your latest reply (= below). =A0

The externalID is not part of the prot= ocol. =A0It is an *optional* attribute within the *schema* specification. = =A0As for #2, the protocol spec works as you describe if "arbitrary UR= I parameters" equate to resource attributes (Allow generic search usin= g 'GET /Users' and arbitrary URI parameters). =A0Please clarify you= r suggestion.

I'm not tracking your coupling concern. =A0The clie= nt can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0


What do you mean by "candidate key"= ? =A0Given=A0

On Fri, Aug 10, 2012= at 5:49 AM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
>=A0 I think scim gets its current simplicity from its single owner hub spoke mo= del implementing tight coupling. [...]=A0IMHO loose coupling is a much more= complex solution.

Phil,

I'= m a bit surprised that you're implying "tight coupling =3D=3D simp= le" and "loose coupling =3D=3D complex". That's contrary= to my experience.

When I say "loose coupling", I mean "no = unnecessary dependencies". Invariably, a reduction in dependencies lea= ds to greater simplicity.

Let's not confuse re= duction of dependencies in the data model with a hub-and-spokes architectur= e. They're entirely orthogonal aspects of the solution.

All that my suggestion involves is,

1. Take 'external ID' out of the protocol.
2. Allow= generic search using 'GET /Users' and arbitrary URI parameters

No planned functionality is lost by this.
1. The client enterprise can still send its internal ID as part= of the resource body, inside some attribute defined by them (but not defin= ed by the protocol). Let's say they call it 'myID'.
2. The client enterprise can search for resource URIs using any attrib= ute, including this internal ID
'GET /Users?myID=3Dbjensen= 9;
Since myID is a candidate key, the server will return exactly = one URI, which is the canonical URI for the resource
https://example.com/v1/Use=
rs/2819c223-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other =
operations as usual.

So taking &#=
39;externalID' out of the protocol spec only does this:
1. It avoids enshrining tight coupling in the protoc=
ol (If clients want to tightly couple themselves to the cloud provider by s=
ending their internal IDs, they can do so. Suicide is OK, but the protocol =
should not be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients t=
owards maintaining their own internal-to-external identifier mappings.

That's w=
hat I'd like to see. I don't believe this complicates the protocol.=
 It simplifies it and it also lends itself to a loosely-coupled approach.

I'll add=
ress the multi-valued attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt= <phil.hunt@oracle.com> wrote:


Phil

On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com<= /a>> wrote:

>=A0 storing this information in a mapping table outside of the SCIM spe= c is a great way to enable this solution.=A0 Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only resp= onsible for the transport layer between domains.=A0

I wasn't suggesting that the mapping table be part of the SCIM spec= . I provided that example to illustrate that splitting and merging identiti= es is a common requirement, and that decoupling local identifiers within a = domain from shared identifiers between domains was the best way to facilita= te it.

I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do there is just refrain from introducing= tight coupling. I would like to see a single identifier exposed through th= e API, with the implication (and perhaps the recommendation) that it be the= shared one. Allowing one domain to expose its internal identifier to the o= ther creates tight coupling and ensures that both domains need simultaneous= ly split or merge identities, which is not desirable. So I recommend _takin= g out_ the "external id" field from the API. The spec shouldn'= ;t encourage tight coupling. If clients want to pass in their internal ids = as part of the resource body, no one can stop them, and they can always do = a search on that attribute to retrieve the URI exactly as you visualise the= y will with the "external id", but let's not elevate an anti-= pattern to a recommendation by enshrining the "external id" as an= acceptable attribute.

Am I making sense?

I see what you are saying. I think scim gets its current simplicit= y from its single owner hub spoke model implementing tight coupling.=A0

That said i think the current model provides a practica= l starting point.=A0

<= /div>
>=A0 Regarding unique identifiers for multi-valued attributes there is a= trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O= n the other hand it puts extra burden on service providers.=A0

Precisely. The spec has to strike the right balance. It would be i= nteresting to hear from the other members of the spec mailing list. You kno= w where I stand on this. It would be good to hear the spectrum of opinions.=

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emmanuel.=A0 I had= started writing up a similar response.=A0 As you suggest, storing this inf= ormation in a mapping table outside of the SCIM spec is a great way to enable this solution.=A0 Part of the key here is that SCIM is just = a piece of the architecture for this solution, and is only responsible for = the transport layer between domains.

=A0<= /p>

You could also model thes= e ID mappings in the SCIM user as an extension but would probably not want = to expose these externally.=A0 Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /u>

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0

This could be repre= sented as two SCIM users that contain information about the entities on oth= er domains.

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "a99a5feba839",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "7a87f27c1dd8"

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

In the second user, the l= inkedUsers attribute would be empty until the split user was synced to doma= in 2.

=A0<= /p>

=A0<= /p>

Similarly, the false nega= tive use case (merging two users) looked like this at the end:

=A0<= /p>

| Internal Entity ID | External Domain ID | E= xternal Entity ID | Primary flag |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0= | true=A0=A0=A0=A0=A0=A0=A0=A0 |

| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0= | false=A0=A0=A0=A0=A0=A0=A0 |

=A0<= /p>

This could be repre= sented with the following SCIM user:

=A0<= /p>

{

=A0 "schemas": ["urn:scim:sche= mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=

=A0 "id": "9caf78aac3d6",=

=A0 "userName": "John Smith&qu= ot;,

=A0 "urn:scim:schemas:extension:federati= on:1.0": {

=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "ff487230b3a0"

=A0=A0=A0=A0=A0 },

=A0=A0=A0=A0=A0 {

=A0=A0=A0=A0=A0=A0=A0 "domain": &qu= ot;D2",

=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&= quot;: "41206cc97c8b",

=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&= quot;: true

=A0=A0=A0=A0=A0 }

=A0=A0=A0 ]

=A0 }

}

=A0<= /p>

=A0<= /p>

Regarding unique identifi= ers for multi-valued attributes there is a trade-off involved.=A0 On one ha= nd this makes PATCH semantics easier.=A0 On the other hand it puts extra burden on service providers.=A0 Since the inception of SCIM, a = key goal has been to foster adoption by service providers by making things = fit easily onto existing systems.=A0 IMO the value gained by unique identif= iers for multi-valued attributes is not worth the demands put on a service provider.=A0 I also think that vend= ors that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement.=A0 In a green field environm= ent we do have the luxury of mandating a model to make certain operations more elegant.=A0 However, we can=92t ig= nore legacy systems.

=A0<= /p>

--Kelly

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

Hi Ganesh,=

=A0=

Nothing prevents you in y= our SCIM implementation (client or server) to generate a unique identifier = for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

=A0<= /p>

This is what we are doing= with Active Directory sources or targets:

As we didn=92t find an im= mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan= ge (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

=A0<= /p>

This was written in dotne= t and we have started a project to rewrite our SCIM stack in PHP and will g= ive it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice= of =93hiding=94 internalIDs or use them as unique ID.=

=A0<= /p>

You can also implement su= ch feature without violating the SCIM specs, or without asking to include i= t in the specs.

=A0<= /p>

--<= /u>

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org
Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Hi K= elly,

Than= ks for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.=A0=A0=A0=A0=A0 Why should domains not expose= their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating l= egacy data stores to such a model. However, in the larger historical contex= t of cross-domain identity management, we are really at the very early stag= es. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.=

Elab= oration of Point 1:

When= we consider federated identity across more than one domain, we have to ass= ume that domains are not necessarily master-slave in their interaction. The= most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are n= otified to other domains (when necessary) in an asynchronous manner (i.e., = through messaging) and the other domains are free to respond to these event= s in an appropriate manner and at a time of their convenience.

A ke= y set of lifecycle events for an entity is the merging and splitting of ide= ntity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores.

Cons= ider a case where customers sign up online, and two customers who are priva= cy-conscious enter fake IDs such as =93John Smith=94, and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelli= gent (but incorrect) guess that these two persons are the same, and re-assi= gn the same identifier to the second person. This is a false positive. They= appear to be the same entity, but they're actually different. When the error is discovered, the identiti= es will need to be split, with a new identifier generated for one of them.<= u>

Cons= ider the opposite case where a customer signs up through two different port= als or in two different sessions, using the names =93JSmith=94 and =93JohnS= =94. It is very likely that they will be treated as two different customers and assigned two unique id= entifiers. This is a false negative. They appear to be two entities, but ar= e actually the same. At a later stage, when the error is discovered, the id= entities will have to be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external ones and only exposing ext= ernal identifiers to other domains.

a. F= alse positives:

Doma= in 1 has the following information about a customer in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of this entity in Domain 2, the following ID i= s returned by Domain 2: ff487230b3a0.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifier:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

When= the false positive is discovered and the entity is split, Domain 1 creates= a new internal identifier and now has the following entity information.=

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: a99a5feba839

Attr= ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

This= second entity with its own internal identifier is invisible to Domain 2, a= nd this is by design. Communication about the original entity takes place a= s before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien= t time (importantly, this doesn't have to be at the time the split happ= ens), Domain 2 can be requested to provision a second entity, and when it r= esponds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the sec= ond entity's internal identifier.

The = mapping table now contains the following entries:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| a99a5feba839 | = D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened= , and the provisioning that it does is not in lockstep with the split in id= entity that occurred in Domain 1.

(Wha= t is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.)

b. F= alse negatives:

Doma= in 1 has the following information about what it thinks are two distinct cu= stomers in its data store:

Inte= rnal ID: 9caf78aac3d6

Attr= ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Inte= rnal ID: 273d36e30d09

Attr= ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When= requesting the provisioning of these entities in Domain 2, the following I= Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Doma= in 1 then maintains the following in a mapping table and uses it for transl= ation when talking to Domain 2, taking care never to expose its internal id= entifiers:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 273d36e30d09 | = D2 | 41206cc97c8b | true |

When= the false negative is discovered and the two entities are merged, Domain 1= drops one of the internal identifiers and rationalises the name of the cus= tomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr= ops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal Entity= ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | = D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | = D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound communica= tion from Domain 2 can be unambiguously translated to the same entity inter= nally. However, when going outwards, Domain 1 will have to look up the translation table to det= ermine the =93primary=94 external ID for this entity in Domain 2, which was= decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 = comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound communication.

At s= ome stage (importantly, not in lockstep with the identity merge), Domain 2 = can be requested to delete the customer record identified by =9341206cc97c8= b=94, and the second entry in the mapping table can be removed once this is acknowledged.

This= scheme will scale up to multiple domains, because the =93External Domain I= D=94 column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it with all external domains?= Tight coupling again. Just as OAuth allows an access token given to a thir= d party to be invalidated without affecting the access of other third parti= es, the use of separate external identifiers for different domains allows fine-grained control of identity = federation.)

The = scheme also allows the splitting of an entity into more than two entities, = and the merging of more than two entities into a single one. (Any organisat= ion with a web-facing application will tell you how many John Smiths there are who were born on = 1 Jan 1970!)

This= is a fairly long-winded explanation, but this is why we need to hide inter= nal identifiers from other domains, and why mappings need to be managed int= ernally in each domain. Such a data model also allows us to choose asynchronous protocols for prop= agation of identity events, since there is no consistency requirement to up= date multiple domains concurrently.

Rega= rds,

Gane= sh Prasad

=A0

On 9 August 2012 04:55, Kelly Griz= zle <ke= lly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, = Ganesh.=A0 I read through this and your InfoQ article (= http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

=A0<= /p>

> The rest of the protocol does not meani= ngfully use the enterprise client=92s identifier, the "external ID&quo= t;

> at all, even thoug= h it was ostensibly introduced to make things friendlier for the client.

=A0<= /p>

The usage pattern for an = external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.=A0 For example:<= u>

=A0<= /p>

GET /Users?filter=3Dexter= nalId eq =93bjensen=94&attributes=3Did

=A0<= /p>

{

=A0 =93totalResults=94: 1,

=A0 =93Resources=94: [

=A0=A0=A0 {

=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45= 3a-919d-413861904646=94

=A0=A0=A0 }

=A0 ]

}

=A0<= /p>

Retrieve the ID from the = response and use it.

=A0<= /p>

DELETE /Users/2819c223-7f= 76-453a-919d-413861904646

=A0<= /p>

This does introduce an ad= ditional HTTP request if the client chooses not to store the server=92s id.= =A0 An issue was created to consider allowing operations to use the externalId= (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the general consensus has been to not include this in the sp= ec.=A0 One main point of contention is that much of the rest of the spec (e= g =96 group membership references, manager references, etc=85) require know= ledge of the server=92s identifier.=A0 Continuing this discussion on the IETF list would be a good thing, though.<= /u>

=A0<= /p>

=A0<= /p>

> the cloud provider's ID and the ent= erprise client's ID are both "Internal IDs" with respect to t= heir domains

=A0<= /p>

I think this comes down t= o a nomenclature problem.=A0 The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just = has to be stable and unique.=A0 In many cases, the underlying identity stor= e will provide identifiers with these properties already (eg =96 a uuid) an= d it can be used by the SCIM interface.=A0 The =93externalId=94 is referring to the fact that the id is maintained ex= ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta= ble and unique (which is mandated by the spec), I don=92t see a problem.

=A0<= /p>

=A0<= /p>

> The secret is that=A0every value nee= ds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn ever= y list or array (of values) into a dictionary (of key-value pairs) by provi= ding each value

> with a unique and = meaning-free identifier.

=A0<= /p>

I agree that this would b= e useful, especially in the PATCH operation.=A0 One reason that this wasn= =92t included in the spec originally is that it can put undue burden on the ser= vice provider.=A0 Many service providers are putting SCIM interfaces in fro= nt of their existing identity stores (eg =96 directory servers, SaaS applic= ation databases, etc=85).=A0 Many of these do not have a unique identifier for multi-valued attributes.=A0 By requiri= ng this, a majority of the server providers would have to start maintaining= a unique key for each multi-valued attribute.=A0 I believe this would be a= roadblock for many implementers.

=A0<= /p>

=A0<= /p>

> When the SCIM protocol uses PATCH, ther= e are areas where it seems a bit clumsy.

=A0<= /p>

I like the thoughts here.= =A0 Your example reminds me of unified diffs (http://en.wikipedi= a.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb). =A0However, the three proposals seem to largely hinge on= being able to uniquely address each element within an object.=A0 Without t= hese it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<= /span>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

=A0<= /p>

=A0<= /p>

> There are other, non-data aspects of SC= IM which may require review, such as its synchronous request-response

> interaction model,= which is a form of tight coupling and could prove to be a source of brittl= eness.

=A0<= /p>

I agree that we should ex= plore optional asynchronous requests in 2.0.

=A0<= /p>

Thanks again for your tho= ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

(I posted this on the SCIM Google Group, and I was a= dvised to subscribe to the mailing list and post it here instead, so here g= oes.)

=A0

Hi,

=A0

My name is Ganesh Prasad, and my experience in Ident= ity and Access Management is mainly through a 3-year project at an Australi= an insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks= /Identity-Management-Shoestring).

=A0

I have been following the SCIM spec off and on, and = based on my experience with a loosely-coupled architecture that I found to = be successful, I have the following 3 suggestions to make.

=A0

1. The enterprise client and the cloud provider shou= ld maintain their own internal IDs for a resource, which they should not re= veal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should = be exposed through the API. The current specification's provision of an= id (which is the external ID and the only one to be transferred through th= e API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposi= te to this.

=A0

2. When dealing with multi-valued attributes of a re= source (expressed as arrays in JSON), they must be converted from an array = into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys = for every attribute value of a resource, manipulating it will be clumsy and= inelegant.

=A0

3. The PATCH command can be improved in 3 significan= t ways:

3a. Leverage the fact (from 2 above) that every valu= e has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PA= TCH command to add, modify and delete attributes at any level=

3c. Use the WebDAV status code of "207 Multi-St= atus" instead of "200 OK" as the response to a PATCH (or BUL= K) command.

=A0

To elaborate,

=A0

1. Revealing private IDs externally is a form of tig= ht coupling. A major requirement with Identity Management is to split (or m= erge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or = when multiple resources are detected to be the same. If internal identifier= s are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its internal ID to and external one crea= ted for this explicit purpose, and only reveal this.

=A0

In the SCIM case, when an enterprise client POSTs a = resource creation request, the cloud provider must generate its own interna= l UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The= enterprise client should map this external UUID to a newly-generated inter= nal ID of its own. In case the resource already has an identifier within th= e enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through = the POST response.

=A0

2. If a resource is to be created, and one of its at= tributes is multi-valued, e.g.,

=A0

=A0 =A0 "email-addrs" :=A0

=A0 =A0 [

=A0 =A0 =A0 =A0 "john_smith@yahoo.com",

=A0 =A0 =A0 =A0 "john.smith@gmail.com",

=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"

<
________________________________= _______________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


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


--20cf303bfcc6e2511504c6ea781d-- From prvs=56278ac87=Mark.Diodati@gartner.com Fri Aug 10 08:35:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9FC21F85E4 for ; Fri, 10 Aug 2012 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvaaPRV5d2w7 for ; Fri, 10 Aug 2012 08:35:22 -0700 (PDT) Received: from iron-main.gartner.com (iron-main.gartner.com [207.140.148.93]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6A21F8783 for ; Fri, 10 Aug 2012 08:35:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAIzgI1AKQCMD/2dsb2JhbAA8CYJKpXCIYQGJTYIZBwEBAQMBAQEBCwwBOhAHAgYFBQsCAQgRAQMBAQEKAhQBBgchBgsTAQMGCAIECgQFCAwHhS6CNQMGEacKhQ+FdA2JTooqZREJBoVkYAOIGYtdAQKCAWOJdoYygTKBVwg X-IronPort-AV: E=Sophos;i="4.77,745,1336363200"; d="scan'208,217";a="126660917" From: "Diodati,Mark" To: Ganesh and Sashi Prasad Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNdweX2F+eN/GgNE2pHte0IDs8vZdTKOrg Date: Fri, 10 Aug 2012 15:35:18 +0000 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.130] Content-Type: multipart/alternative; boundary="_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4DA4Fwhistlerentgart_" MIME-Version: 1.0 Message-Id: <20120810153522.17C6A21F8783@ietfa.amsl.com> Cc: "scim@ietf.org" , Phil Hunt , Kelly Grizzle , Trey Drake , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:35:39 -0000 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4DA4Fwhistlerentgart_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ganesh, I am concerned about your second suggestion: "2. When dealing with multi-valued attributes of a resource (expressed as a= rrays in JSON), they must be converted from an array into a dictionary with= unique keys (UUIDs generated by the cloud provider when the attribute is c= reated). Without unique keys for every attribute value of a resource, manip= ulating it will be clumsy and inelegant." One of the primary reasons that SPML failed was lack of adoption by service= providers due to its complexity. Very few target applications implemented = SPML. Most of the commercial provisioning systems had an SPML interface (ei= ther v1 or v2), but not one of them was conformant to the SPML standard bec= ause of complexity. If you are interested, I will forward you the research = documents that discuss these problems in detail. For SCIM to be successful,= it must be adopted by commercial target applications (i.e., service provid= ers). I am confident that a requirement for unique identifiers with multi-v= alued attributes will preclude its adoption, because it requires major chan= ges to the service provider's existing identity storage mechanisms. Mark From: Trey Drake [mailto:trey.drake@unboundid.com] Sent: Friday, August 10, 2012 9:51 AM To: Ganesh and Sashi Prasad Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute = within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (Al= low generic search using 'GET /Users' and arbitrary URI parameters). Pleas= e clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence re= trieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > wrote: > I think scim gets its current simplicity from its single owner hub spoke= model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and= "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariab= ly, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-an= d-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the reso= urce body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, = including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, whic= h is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to = tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of= assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining thei= r own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol.= It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt > wrote: Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? I see what you are saying. I think scim gets its current simplicity from it= s single owner hub spoke model implementing tight coupling. IMHO loose coupling is a much more complex solution. The reality is that ea= ch end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub. That said i think the current model provides a practical starting point. > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can't ignore le= gacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the = translation table to determine the "primary" external ID for this entity in= Domain 2, which was decided to be "ff487230b3a0". That's where the "Primar= y flag" comes in. The second external ID "41206cc97c8b" is never used there= after in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domai= n 2 can be requested to delete the customer record identified by "41206cc97= c8b", and the second entry in the mapping table can be removed once this is= acknowledged. This scheme will scale up to multiple domains, because the "External Domain= ID" column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it wi= th all external domains? Tight coupling again. Just as OAuth allows an acce= ss token given to a third party to be invalidated without affecting the acc= ess of other third parties, the use of separate external identifiers for di= fferent domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entiti= es, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed= internally in each domain. Such a data model also allows us to choose asyn= chronous protocols for propagation of identity events, since there is no co= nsistency requirement to update multiple domains concurrently. Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle > wrote: Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" < _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ________________________________ This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute,= or otherwise use this message or its attachments. Please notify the sender= immediately by return e-mail and permanently delete this message and any a= ttachments. Gartner makes no warranty that this e-mail is error or virus fr= ee. --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4DA4Fwhistlerentgart_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ganesh,

 

I am concerned about yo= ur second suggestion:

“2. When dealing = with multi-valued attributes of a resource (expressed as arrays in JSON), t= hey must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.”

 

One of the primary reas= ons that SPML failed was lack of adoption by service providers due to its c= omplexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider’s existing identity storage mechanis= ms.

Mark<= /p>

 

 

 

From: Trey D= rake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM
To: Ganesh and Sashi Prasad
Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). =  

 

The externalID is not part of the protocol.  It= is an *optional* attribute within the *schema* specification.  As for= #2, the protocol spec works as you describe if "arbitrary URI paramet= ers" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clar= ify your suggestion.

 

I'm not tracking your coupling concern.  The cl= ient can search and hence retrieve resources on any attribute it chooses, e= xternalId or otherwise.  Nothing mandates use of externalId.  &nb= sp;

 

 

What do you mean by "candidate key"?  = ;Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>  I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling. [...]&nb= sp;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight= coupling =3D=3D simple" and "loose coupling =3D=3D complex"= . That's contrary to my experience.

 

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the d= ata model with a hub-and-spokes architecture. They're entirely orthogonal a= spects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbit= rary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
 
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
 
T=
hat's what I'd like to see. I don't believe this complicates the protocol. =
It simplifies it and it also lends itself to a loosely-coupled approach.
 
I=
'll address the multi-valued attribute suggestion separately.
 
R=
egards,
G=
anesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w= rote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a g= reat way to enable this solution.  Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain= from introducing tight coupling. I would like to see a single identifier e= xposed through the API, with the implication (and perhaps the recommendatio= n) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight co= upling and ensures that both domains need simultaneously split or merge ide= ntities, which is not desirable. So I recommend _taking out_ the "exte= rnal id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their inter= nal ids as part of the resource body, no one can stop them, and they can al= ways do a search on that attribute to retrieve the URI exactly as you visua= lise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its cur= rent simplicity from its single owner hub spoke model implementing tight co= upling. 

 

IMHO loose coupling is a much more complex solution.= The reality is that each end-point has value to contribute and thus the si= ngle-owner model will eventually need to become multi-owner or multi-hub.&n= bsp;

 

That said i think the current model provides a pract= ical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved.  On one hand this makes PATCH semantics easier.  On = the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emman= uel.  I had started writing up a similar response.  As you sugges= t, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that= SCIM is just a piece of the architecture for this solution, and is only re= sponsible for the transport layer between domains.

 

You could al= so model these ID mappings in the SCIM user as an extension but would proba= bly not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| a99a5feba839   =     | D2        &nbs= p;        | 7a87f27c1dd8  &nbs= p;    | true        = |

 

This could b= e represented as two SCIM users that contain information about the entities= on other domains.

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }=

    ]

  }

}

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "a99= a5feba839",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "7a87f27c1dd8"

      }=

    ]

  }

}

 

In the secon= d user, the linkedUsers attribute would be empty until the split user was s= ynced to domain 2.

 

 

Similarly, t= he false negative use case (merging two users) looked like this at the end:=

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| 9caf78aac3d6   =     | D2        &nbs= p;        | 41206cc97c8b  &nbs= p;    | false        |

 

This could b= e represented with the following SCIM user:

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }= ,

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "41206cc97c8b",

     &n= bsp;  "deletionRequired": true

      }=

    ]

  }

}

 

 

Regarding un= ique identifiers for multi-valued attributes there is a trade-off involved.=   On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception = of SCIM, a key goal has been to foster adoption by service providers by mak= ing things fit easily onto existing systems.  IMO the value gained by = unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think tha= t vendors that have a non-SCIM-compliant API will choose to keep things tha= t way if the spec is too hard for them to implement.  In a green field= environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we canR= 17;t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

= Hi Ganesh,

=  

Nothing prev= ents you in your SCIM implementation (client or server) to generate a uniqu= e identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).<= /span>

 

This is what= we are doing with Active Directory sources or targets:

As we didn&#= 8217;t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) ar= e subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids= . This fits your requirements as it hides internal ids.

 

This was wri= tten in dotnet and we have started a project to rewrite our SCIM stack in P= HP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will gi= ve the choice of “hiding” internalIDs or use them as unique ID.=

 

You can also= implement such feature without violating the SCIM specs, or without asking= to include it in the specs.

 

= --

= Regards,

= Emmanuel Dreux

= http://www.cloudiway= .com

= Tel: +33 4 2= 6 78 17 58

= Mobile: +33 6 4= 7 81 26 70

= skype: Emmanuel.Dreux

=  

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi = Kelly,

Tha= nks for your response. Let me first respond in brief to the two main points= you have made, and then elaborate on the first.

1.&nbs= p;     Why should domains not = expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when “false negative= s” and “false positives” are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both “SCIM-compliant” and &= #8220;non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. L= egacy customers can be supported using a “non-SCIM-compliant” A= PI for an arbitrarily long period and gradually migrated to the SCIM-compli= ant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Ela= boration of Point 1:

Whe= n we consider federated identity across more than one domain, we have to as= sume that domains are not necessarily master-slave in their interaction. Th= e most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified t= o other domains (when necessary) in an asynchronous manner (i.e., through m= essaging) and the other domains are free to respond to these events in an a= ppropriate manner and at a time of their convenience.

A k= ey set of lifecycle events for an entity is the merging and splitting of id= entity that is often required.

The= question “Is this one entity?” can be answered either yes (pos= itive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Con= sider a case where customers sign up online, and two customers who are priv= acy-conscious enter fake IDs such as “John Smith”, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Con= sider the opposite case where a customer signs up through two different por= tals or in two different sessions, using the names “JSmith” and= “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

The= se are not theoretical use cases. They form a significant proportion of the= user base in most large Web-facing applications. Let's see how these can b= e managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. = False positives:

Dom= ain 1 has the following information about a customer in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Whe= n requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifier:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

Whe= n the false positive is discovered and the entity is split, Domain 1 create= s a new internal identifier and now has the following entity information.

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Int= ernal ID: a99a5feba839

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Thi= s second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes place = as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (imp= ortantly, this doesn't have to be at the time the split happens), Domain 2 = can be requested to provision a second entity, and when it responds with an= identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The= mapping table now contains the following entries:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| a99a5feba839 = | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happene= d, and the provisioning that it does is not in lockstep with the split in i= dentity that occurred in Domain 1.

(Wh= at is the “Primary flag” used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Dom= ain 1 has the following information about what it thinks are two distinct c= ustomers in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “JSmith”, dob: “01-Jan-1970”}

Int= ernal ID: 273d36e30d09

Att= ributes: {name: “JohnS”, dob: “01-Jan-1970”}=

Whe= n requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifiers:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 273d36e30d09 = | D2 | 41206cc97c8b | true |

Whe= n the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the cu= stomer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the secon= d “273d36e30d09”.

The= mapping table now looks like this:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 = | D2 | 41206cc97c8b | false |

Now= two external identifiers map to the same internal one, so inbound communic= ation from Domain 2 can be unambiguously translated to the same entity inte= rnally. However, when going outwards, Domain 1 will have to look up the translation table to determine the ̶= 0;primary” external ID for this entity in Domain 2, which was decided= to be “ff487230b3a0”. That's where the “Primary flagR= 21; comes in. The second external ID “41206cc97c8b” is never us= ed thereafter in outbound communication.

At = some stage (importantly, not in lockstep with the identity merge), Domain 2= can be requested to delete the customer record identified by “41206c= c97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

Thi= s scheme will scale up to multiple domains, because the “External Dom= ain ID” column helps to keep track of which external ID is shared wit= h which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling ag= ain. Just as OAuth allows an access token given to a third party to be inva= lidated without affecting the access of other third parties, the use of sep= arate external identifiers for different domains allows fine-grained control of identity federation.)

The= scheme also allows the splitting of an entity into more than two entities,= and the merging of more than two entities into a single one. (Any organisa= tion with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

Thi= s is a fairly long-winded explanation, but this is why we need to hide inte= rnal identifiers from other domains, and why mappings need to be managed in= ternally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of i= dentity events, since there is no consistency requirement to update multipl= e domains concurrently.

Reg= ards,

Gan= esh Prasad

 

On 9 August 2012 04:55,= Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for t= he feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not mea= ningfully use the enterprise client’s identifier, the "external = ID"

> at al= l, even though it was ostensibly introduced to make things friendlier for t= he client.

 

The usage pa= ttern for an external ID would be to search for a user by externalId and us= e the ID of the returned user in any desired operation.  For example:

 

GET /Users?f= ilter=3DexternalId eq “bjensen”&attributes=3Did

 

{

  “totalResults”= ;: 1,

  “Resources”: = [

    {

      &= #8220;id”: “2819c223-7f76-453a-919d-413861904646”<= /p>

    }

  ]

}

 

Retrieve the= ID from the response and use it.

 

DELETE /User= s/2819c223-7f76-453a-919d-413861904646

 

This does in= troduce an additional HTTP request if the client chooses not to store the s= erver’s id.  An issue was created to consider allowing operation= s to use the externalId (http://code.google.com/p/scim/issues/= detail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One = main point of contention is that much of the rest of the spec (eg – g= roup membership references, manager references, etc…) require knowled= ge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enter= prise client's ID are both "Internal IDs" with respect to their d= omains

 

I think this= comes down to a nomenclature problem.  The server’s ID does not= necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the = underlying identity store will provide identifiers with these properties al= ready (eg – a uuid) and it can be used by the SCIM interface.  T= he “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server&= #8217;s identifiers are stable and unique (which is mandated by the spec), = I don’t see a problem.

 

 

> The secret is that every valu= e needs a key, and multi-valued attributes lack that. So our solution i= s quite

> simpl= e - turn every list or array (of values) into a dictionary (of key-value pa= irs) by providing each value

> with = a unique and meaning-free identifier.

 

I agree that= this would be useful, especially in the PATCH operation.  One reason = that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are= putting SCIM interfaces in front of their existing identity stores (eg = 211; directory servers, SaaS application databases, etc…).  Many= of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers wo= uld have to start maintaining a unique key for each multi-valued attribute.=   I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, th= ere are areas where it seems a bit clumsy.

 

I like the t= houghts here.  Your example reminds me of unified diffs (ht= tp://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of = SCIM which may require review, such as its synchronous request-response

> inter= action model, which is a form of tight coupling and could prove to be a sou= rce of brittleness.

 

I agree that= we should explore optional asynchronous requests in 2.0.

 

Thanks again= for your thoughts.  I hope you stay involved in the discussion as wor= k on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

 

(I posted this on the SCIM Google Group, = and I was advised to subscribe to the mailing list and post it here instead= , so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experien= ce in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eB= ook on InfoQ (http://www.infoq.com/minibooks/Identity-Mana= gement-Shoestring).

 

I have been following the SCIM spec off a= nd on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud pr= ovider should maintain their own internal IDs for a resource, which they sh= ould not reveal to each other. Both of them should map their internal IDs t= o a shared External ID, and this is the only ID that should be exposed through the API. The current specificat= ion's provision of an id (which is the external ID and the only one to be t= ransferred through the API) and an "external ID" (which is the cl= ient's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attribu= tes of a resource (expressed as arrays in JSON), they must be converted fro= m an array into a dictionary with unique keys (UUIDs generated by the cloud= provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating = it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3= significant ways:

3a. Leverage the fact (from 2 above) that= every value has a key, to greatly simplify the API

3b. Use special verbs as nested operation= s of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "2= 07 Multi-Status" instead of "200 OK" as the response to a PA= TCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is to = split (or merge) identities when false positives (or false negatives) are d= etected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the sam= e. If internal identifiers are revealed to external domains, such clean-ups= become difficult, hence every domain that wants to expose references to a = resource must map its internal ID to and external one created for this explicit purpose, and only reveal thi= s.

 

In the SCIM case, when an enterprise clie= nt POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only = return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-gen= erated internal ID of its own. In case the resource already has an identifi= er within the enterprise client's domain, then this is the internal ID that= must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and on= e of its attributes is multi-valued, e.g.,

 

    "email-addrs" :&n= bsp;

    [

        "john_smith@yahoo.com= ",

        "john.smith@gmail.com= ",

        "jsmith1970@hotmail.com= "

< 

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

 


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

 



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.
 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4DA4Fwhistlerentgart_-- From phil.hunt@oracle.com Fri Aug 10 09:48:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3B921F86F8 for ; Fri, 10 Aug 2012 09:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hez7dK5WqKLp for ; Fri, 10 Aug 2012 09:48:41 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 549F021F8703 for ; Fri, 10 Aug 2012 09:48:37 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AGmWRq027483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 16:48:33 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AGmUKo004283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2012 16:48:31 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AGmUMT018140; Fri, 10 Aug 2012 11:48:30 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 09:48:28 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D6382E4-3AA5-42CF-8F70-A0796D9D0C9F" From: Phil Hunt In-Reply-To: Date: Fri, 10 Aug 2012 09:48:26 -0700 Message-Id: <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:48:46 -0000 --Apple-Mail=_9D6382E4-3AA5-42CF-8F70-A0796D9D0C9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ganesh, See below... Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad wrote: > > I think scim gets its current simplicity from its single owner hub = spoke model implementing tight coupling. [...] IMHO loose coupling is a = much more complex solution. >=20 > Phil, >=20 > I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. I think we actually agree. What I was saying is that for a sufficiently = narrow scope model, tight coupling is "simple". But in the long term it = *may* turn out to be "simplistic". SCIM current seems to assume that an = enterprise can claim ownership of the entirety of the object being = provisioned in the cloud. The enterprise has full knowledge of the = resource in the cloud. Under that highly restricted definition, it is = simple. The model is fine on a point-to-point basis, but the higher-level = provisioning "system" is more complex. I agree with Trey, externalID is optional. I also do not equate = "externalID" with tight or loose coupling. Yes, you can cause tight = coupling, but that doesn't necessarily follow.=20 I look at it this way: ObjectID is simply the ID asserted by the holder = of the resource. ExternalID is an optional ID that is meaningful to a = particular client. SAML has a similar concept. >=20 > When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >=20 > Let's not confuse reduction of dependencies in the data model with a = hub-and-spokes architecture. They're entirely orthogonal aspects of the = solution. >=20 > All that my suggestion involves is, >=20 > 1. Take 'external ID' out of the protocol. > 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >=20 > No planned functionality is lost by this. >=20 > 1. The client enterprise can still send its internal ID as part of the = resource body, inside some attribute defined by them (but not defined by = the protocol). Let's say they call it 'myID'. > 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID > 'GET /Users?myID=3Dbjensen' > Since myID is a candidate key, the server will return exactly one URI, = which is the canonical URI for the resource > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > 3. The client can use this URI to perform all other operations as = usual. >=20 >=20 > So taking 'externalID' out of the protocol spec only does this: >=20 > 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) > 2. It encourages loose coupling by nudging clients towards maintaining = their own internal-to-external identifier mappings. >=20 >=20 > That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >=20 >=20 > I'll address the multi-valued attribute suggestion separately. >=20 >=20 > Regards, > Ganesh >=20 >=20 >=20 >=20 > On 10 August 2012 07:53, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >=20 >> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>=20 >> I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>=20 >> I'm suggesting that the spec do less, not more. >>=20 >> What the SCIM spec needs to do there is just refrain from introducing = tight coupling. I would like to see a single identifier exposed through = the API, with the implication (and perhaps the recommendation) that it = be the shared one. Allowing one domain to expose its internal identifier = to the other creates tight coupling and ensures that both domains need = simultaneously split or merge identities, which is not desirable. So I = recommend _taking out_ the "external id" field from the API. The spec = shouldn't encourage tight coupling. If clients want to pass in their = internal ids as part of the resource body, no one can stop them, and = they can always do a search on that attribute to retrieve the URI = exactly as you visualise they will with the "external id", but let's not = elevate an anti-pattern to a recommendation by enshrining the "external = id" as an acceptable attribute. >>=20 >> Am I making sense? >=20 > I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >=20 > IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >=20 > That said i think the current model provides a practical starting = point.=20 >>=20 >> > Regarding unique identifiers for multi-valued attributes there is = a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>=20 >> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>=20 >> Regards, >> Ganesh >>=20 >> On 10 August 2012 00:28, Kelly Grizzle = wrote: >> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>=20 >> =20 >>=20 >> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >>=20 >> =20 >>=20 >> This could be represented as two SCIM users that contain information = about the entities on other domains. >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "a99a5feba839", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "7a87f27c1dd8" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>=20 >> =20 >>=20 >> =20 >>=20 >> Similarly, the false negative use case (merging two users) looked = like this at the end: >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>=20 >> =20 >>=20 >> This could be represented with the following SCIM user: >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> }, >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "41206cc97c8b", >>=20 >> "deletionRequired": true >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> =20 >>=20 >> Regarding unique identifiers for multi-valued attributes there is a = trade-off involved. On one hand this makes PATCH semantics easier. On = the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Emmanuel Dreux >> Sent: Thursday, August 09, 2012 3:18 AM >> To: Ganesh and Sashi Prasad; Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Ganesh, >>=20 >> =20 >>=20 >> Nothing prevents you in your SCIM implementation (client or server) = to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>=20 >> =20 >>=20 >> This is what we are doing with Active Directory sources or targets: >>=20 >> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>=20 >> =20 >>=20 >> This was written in dotnet and we have started a project to rewrite = our SCIM stack in PHP and will give it to the Open Source community. = This implementation will have a parameter : AllocateIds versus = UseExistingIDs. >>=20 >> This will give the choice of =93hiding=94 internalIDs or use them as = unique ID. >>=20 >> =20 >>=20 >> You can also implement such feature without violating the SCIM specs, = or without asking to include it in the specs. >>=20 >> =20 >>=20 >> -- >>=20 >> Regards, >>=20 >> Emmanuel Dreux >>=20 >> http://www.cloudiway.com >>=20 >> Tel: +33 4 26 78 17 58 >>=20 >> Mobile: +33 6 47 81 26 70 >>=20 >> skype: Emmanuel.Dreux >>=20 >> =20 >>=20 >> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >> =C0 : Kelly Grizzle >> Cc : scim@ietf.org >> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Kelly, >> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >> 1. Why should domains not expose their internal identifiers to = other domains? >> a. >> We are designing a protocol for a federated system of domains, where = all domains are co-equal peers. (In physics too, N-body problems are = much harder than 2-body problems. :-) Therefore, assuming that there are = only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >> b. >> In any non-trivial data store, there will always be the ongoing need = to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >> c. >> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >> 2. The difficulty of assigning unique identifiers to the individual = values of multi-valued attributes: >> a. >> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >> b. >> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >> Elaboration of Point 1: >> When we consider federated identity across more than one domain, we = have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >> Consider a case where customers sign up online, and two customers who = are privacy-conscious enter fake IDs such as =93John Smith=94, and also = use the same date of birth (say, 1 Jan 1970) or similar attributes. The = front-end application may make an intelligent (but incorrect) guess that = these two persons are the same, and re-assign the same identifier to the = second person. This is a false positive. They appear to be the same = entity, but they're actually different. When the error is discovered, = the identities will need to be split, with a new identifier generated = for one of them. >> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >> a. False positives: >> Domain 1 has the following information about a customer in its data = store: >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifier: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> When the false positive is discovered and the entity is split, Domain = 1 creates a new internal identifier and now has the following entity = information. >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> Internal ID: a99a5feba839 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> This second entity with its own internal identifier is invisible to = Domain 2, and this is by design. Communication about the original entity = takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 = and vice-versa. At some convenient time (importantly, this doesn't have = to be at the time the split happens), Domain 2 can be requested to = provision a second entity, and when it responds with an identifier of = =937a87f27c1dd8=94, this can go into the mapping table as a new record = associated with the second entity's internal identifier. >> The mapping table now contains the following entries: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >> (What is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.) >> b. False negatives: >> Domain 1 has the following information about what it thinks are two = distinct customers in its data store: >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >> Internal ID: 273d36e30d09 >> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >> When requesting the provisioning of these entities in Domain 2, the = following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 273d36e30d09 | D2 | 41206cc97c8b | true | >> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >> The mapping table now looks like this: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >> Now two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to = look up the translation table to determine the =93primary=94 external ID = for this entity in Domain 2, which was decided to be =93ff487230b3a0=94. = That's where the =93Primary flag=94 comes in. The second external ID = =9341206cc97c8b=94 is never used thereafter in outbound communication. >> At some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be = removed once this is acknowledged. >> This scheme will scale up to multiple domains, because the =93External = Domain ID=94 column helps to keep track of which external ID is shared = with which Domain. (Why don't we use just one external ID for an entity = and share it with all external domains? Tight coupling again. Just as = OAuth allows an access token given to a third party to be invalidated = without affecting the access of other third parties, the use of separate = external identifiers for different domains allows fine-grained control = of identity federation.) >> The scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many = John Smiths there are who were born on 1 Jan 1970!) >> This is a fairly long-winded explanation, but this is why we need to = hide internal identifiers from other domains, and why mappings need to = be managed internally in each domain. Such a data model also allows us = to choose asynchronous protocols for propagation of identity events, = since there is no consistency requirement to update multiple domains = concurrently. >> Regards, >> Ganesh Prasad >> =20 >>=20 >> On 9 August 2012 04:55, Kelly Grizzle = wrote: >>=20 >> Thanks for the feedback, Ganesh. I read through this and your InfoQ = article (http://www.infoq.com/articles/scim-data-model-limitations) and = have some thoughts. >>=20 >> =20 >>=20 >> > The rest of the protocol does not meaningfully use the enterprise = client=92s identifier, the "external ID" >>=20 >> > at all, even though it was ostensibly introduced to make things = friendlier for the client. >>=20 >> =20 >>=20 >> The usage pattern for an external ID would be to search for a user by = externalId and use the ID of the returned user in any desired operation. = For example: >>=20 >> =20 >>=20 >> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >>=20 >> =20 >>=20 >> { >>=20 >> =93totalResults=94: 1, >>=20 >> =93Resources=94: [ >>=20 >> { >>=20 >> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> =20 >>=20 >> Retrieve the ID from the response and use it. >>=20 >> =20 >>=20 >> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >>=20 >> =20 >>=20 >> This does introduce an additional HTTP request if the client chooses = not to store the server=92s id. An issue was created to consider = allowing operations to use the externalId = (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the = general consensus has been to not include this in the spec. One main = point of contention is that much of the rest of the spec (eg =96 group = membership references, manager references, etc=85) require knowledge of = the server=92s identifier. Continuing this discussion on the IETF list = would be a good thing, though. >>=20 >> =20 >>=20 >> =20 >>=20 >> > the cloud provider's ID and the enterprise client's ID are both = "Internal IDs" with respect to their domains >>=20 >> =20 >>=20 >> I think this comes down to a nomenclature problem. The server=92s ID = does not necessarily have to be the unique identifier that the = underlying identity store uses, it just has to be stable and unique. In = many cases, the underlying identity store will provide identifiers with = these properties already (eg =96 a uuid) and it can be used by the SCIM = interface. The =93externalId=94 is referring to the fact that the id is = maintained external to the SCIM server. As long as the server=92s = identifiers are stable and unique (which is mandated by the spec), I = don=92t see a problem. >>=20 >> =20 >>=20 >> =20 >>=20 >> > The secret is that every value needs a key, and multi-valued = attributes lack that. So our solution is quite >>=20 >> > simple - turn every list or array (of values) into a dictionary (of = key-value pairs) by providing each value >>=20 >> > with a unique and meaning-free identifier. >>=20 >> =20 >>=20 >> I agree that this would be useful, especially in the PATCH operation. = One reason that this wasn=92t included in the spec originally is that = it can put undue burden on the service provider. Many service providers = are putting SCIM interfaces in front of their existing identity stores = (eg =96 directory servers, SaaS application databases, etc=85). Many of = these do not have a unique identifier for multi-valued attributes. By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute. I believe = this would be a roadblock for many implementers. >>=20 >> =20 >>=20 >> =20 >>=20 >> > When the SCIM protocol uses PATCH, there are areas where it seems a = bit clumsy. >>=20 >> =20 >>=20 >> I like the thoughts here. Your example reminds me of unified diffs = (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly = used with a patch program (pretty much the equivalent of the PATCH = verb). However, the three proposals seem to largely hinge on being able = to uniquely address each element within an object. Without these it is = not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85)= or provide a multi-status. >>=20 >>=20 >> The 207 response would be interesting to consider for the bulk = endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),= however. >>=20 >> =20 >>=20 >> =20 >>=20 >> > There are other, non-data aspects of SCIM which may require review, = such as its synchronous request-response >>=20 >> > interaction model, which is a form of tight coupling and could = prove to be a source of brittleness. >>=20 >> =20 >>=20 >> I agree that we should explore optional asynchronous requests in 2.0. >>=20 >> =20 >>=20 >> Thanks again for your thoughts. I hope you stay involved in the = discussion as work on SCIM 2.0 goes forward. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Ganesh and Sashi Prasad >> Sent: Wednesday, August 01, 2012 4:24 PM >> To: scim@ietf.org >> Subject: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> (I posted this on the SCIM Google Group, and I was advised to = subscribe to the mailing list and post it here instead, so here goes.) >>=20 >> =20 >>=20 >> Hi, >>=20 >> =20 >>=20 >> My name is Ganesh Prasad, and my experience in Identity and Access = Management is mainly through a 3-year project at an Australian insurance = company, an experience I have written about as a eBook on InfoQ = (http://www.infoq.com/minibooks/Identity-Management-Shoestring). >>=20 >> =20 >>=20 >> I have been following the SCIM spec off and on, and based on my = experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make. >>=20 >> =20 >>=20 >> 1. The enterprise client and the cloud provider should maintain their = own internal IDs for a resource, which they should not reveal to each = other. Both of them should map their internal IDs to a shared External = ID, and this is the only ID that should be exposed through the API. The = current specification's provision of an id (which is the external ID and = the only one to be transferred through the API) and an "external ID" = (which is the client's internal ID and should be hidden) is = diametrically opposite to this. >>=20 >> =20 >>=20 >> 2. When dealing with multi-valued attributes of a resource (expressed = as arrays in JSON), they must be converted from an array into a = dictionary with unique keys (UUIDs generated by the cloud provider when = the attribute is created). Without unique keys for every attribute value = of a resource, manipulating it will be clumsy and inelegant. >>=20 >> =20 >>=20 >> 3. The PATCH command can be improved in 3 significant ways: >>=20 >> 3a. Leverage the fact (from 2 above) that every value has a key, to = greatly simplify the API >>=20 >> 3b. Use special verbs as nested operations of the PATCH command to = add, modify and delete attributes at any level >>=20 >> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 = OK" as the response to a PATCH (or BULK) command. >>=20 >> =20 >>=20 >> To elaborate, >>=20 >> =20 >>=20 >> 1. Revealing private IDs externally is a form of tight coupling. A = major requirement with Identity Management is to split (or merge) = identities when false positives (or false negatives) are detected, i.e., = when a resource is discovered to be more than one, or when multiple = resources are detected to be the same. If internal identifiers are = revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its = internal ID to and external one created for this explicit purpose, and = only reveal this. >>=20 >> =20 >>=20 >> In the SCIM case, when an enterprise client POSTs a resource creation = request, the cloud provider must generate its own internal UUID as well = as an external UUID, map them together, and only return the external = UUID in the "Location:" header. The enterprise client should map this = external UUID to a newly-generated internal ID of its own. In case the = resource already has an identifier within the enterprise client's = domain, then this is the internal ID that must be mapped to the external = UUID returned through the POST response. >>=20 >> =20 >>=20 >> 2. If a resource is to be created, and one of its attributes is = multi-valued, e.g., >>=20 >> =20 >>=20 >> "email-addrs" :=20 >>=20 >> [ >>=20 >> "john_smith@yahoo.com", >>=20 >> "john.smith@gmail.com", >>=20 >> "jsmith1970@hotmail.com" >>=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 --Apple-Mail=_9D6382E4-3AA5-42CF-8F70-A0796D9D0C9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Phil

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





On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad = wrote:

>  I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. [...] IMHO loose coupling is a = much more complex = solution.

Phil,

I'm a bit = surprised that you're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my = experience.

I think we actually agree. = What I was saying is that for a sufficiently narrow scope model, tight = coupling is "simple". But in the long term it *may* turn out to be = "simplistic".  SCIM current seems to assume that an enterprise = can claim ownership of the entirety of the object being provisioned in = the cloud.  The enterprise has full knowledge of the resource in = the cloud.  Under that highly restricted definition, it is = simple.

The model is fine on a point-to-point = basis, but the higher-level provisioning "system" is more = complex.

I agree with Trey, externalID is = optional.  I also do not equate "externalID" with tight or loose = coupling. Yes, you can cause tight coupling, but that doesn't = necessarily follow. 

I look at it this = way: ObjectID is simply the ID asserted by the holder of the resource. =  ExternalID is an optional ID that is meaningful to a particular = client.   SAML has a similar = concept.


When I say "loose coupling", I mean = "no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

Let's not confuse = reduction of dependencies in the data model with a hub-and-spokes = architecture. They're entirely orthogonal aspects of the solution.

All that my suggestion involves = is,

1. Take 'external ID' out of the = protocol.
2. Allow generic search using 'GET /Users' and = arbitrary URI parameters

No planned functionality is lost by = this.

1. The client enterprise can still send = its internal ID as part of the resource body, inside some attribute = defined by them (but not defined by the protocol). Let's say they call = it 'myID'.
2. The client enterprise can search for resource URIs using any = attribute, including this internal ID
'GET = /Users?myID=3Dbjensen'
Since myID is a candidate key, the = server will return exactly one URI, which is the canonical URI for the = resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this =
URI to perform all other operations as usual.

So taking 'externalID' out =
of the protocol spec only does this:
1. It avoids enshrining =
tight coupling in the protocol (If clients want to tightly couple =
themselves to the cloud provider by sending their internal IDs, they can =
do so. Suicide is OK, but the protocol should not be guilty of assisted =
suicide. ;-)
2. It encourages loose =
coupling by nudging clients towards maintaining their own =
internal-to-external identifier mappings.

That's what I'd like to see. =
I don't believe this complicates the protocol. It simplifies it and it =
also lends itself to a loosely-coupled approach.

I'll address the =
multi-valued attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:


Phil

On = 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec = is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it.

I'm suggesting that the spec do less, not = more.

What the SCIM spec needs to do there is just refrain = from introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

Am I making = sense?

I see what you are = saying. I think scim gets its current simplicity from its single owner = hub spoke model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The = reality is that each end-point has value to contribute and thus the = single-owner model will eventually need to become multi-owner or = multi-hub. 

That said i think the current model provides a = practical starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 

Precisely. The spec has to strike the right balance. It would = be interesting to hear from the other members of the spec mailing list. = You know where I stand on this. It would be good to hear the spectrum of = opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only = responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "a99a5feba839",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      = }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 

 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        = |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = },

      = {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      = }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of = SCIM, a key goal has been to foster adoption by service providers by = making things fit easily onto existing systems.  IMO the value = gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits = your requirements as it hides internal ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus = UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 = 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the = first.

1.      Why should domains not = expose their internal identifiers to other = domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued = attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain = are notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an = intelligent (but incorrect) guess that these two persons are the same, = and re-assign the same identifier to the second person. This is a false = positive. They appear to be the same entity, but they're actually different. When the error is discovered, the = identities will need to be split, with a new identifier generated for = one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique = identifiers. This is a false negative. They appear to be two entities, = but are actually the same. At a later stage, when the error is = discovered, the identities will have to be merged, and one of the identifiers will have to be = dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing = external identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some = convenient time (importantly, this doesn't have to be at the time the = split happens), Domain 2 can be requested to provision a second entity, = and when it responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the = second entity's internal identifier.

The = mapping table now contains the following = entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and = drops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to look up the translation table to = determine the =93primary=94 external ID for this entity in Domain 2, = which was decided to be =93ff487230b3a0=94. That's where the =93Primary = flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound = communication.

At = some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is = acknowledged.

This = scheme will scale up to multiple domains, because the =93External Domain = ID=94 column helps to keep track of which external ID is shared with = which Domain. (Why don't we use just one external ID for an entity and share it with all external = domains? Tight coupling again. Just as OAuth allows an access token = given to a third party to be invalidated without affecting the access of = other third parties, the use of separate external identifiers for different domains allows fine-grained control of = identity federation.)

The = scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many John Smiths there are who were born = on 1 Jan 1970!)

This = is a fairly long-winded explanation, but this is why we need to hide = internal identifiers from other domains, and why mappings need to be = managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for = propagation of identity events, since there is no consistency = requirement to update multiple domains = concurrently.

Regards,

Ganesh= Prasad

 

On 9 August 2012 04:55, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Thanks for the feedback, Ganesh.  I read = through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitation= s) and have some thoughts.

 

> The rest of the protocol does not meaningfully = use the enterprise client=92s identifier, the "external = ID"

> at all, even though it was ostensibly = introduced to make things friendlier for the = client.

 

The usage pattern for an external ID would be to = search for a user by externalId and use the ID of the returned user in any desired operation.  For = example:

 

GET /Users?filter=3DexternalId eq = =93bjensen=94&attributes=3Did

 

{

  =93totalResults=94: = 1,

  =93Resources=94: = [

    {

      =93id=94: = =932819c223-7f76-453a-919d-413861904646=94

    }

  ]

}

 

Retrieve the ID from the response and use = it.

 

DELETE = /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if = the client chooses not to store the server=92s id.  An issue was created to consider allowing operations to use the = externalId (http://code.google.com/p/scim/issues/detail?id=3D35<= span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1f497d">), but I believe the general consensus has been to not include this in the = spec.  One main point of contention is that much of the rest of the = spec (eg =96 group membership references, manager references, etc=85) = require knowledge of the server=92s identifier.  Continuing this discussion on the IETF list would be a good thing, = though.

 

 

> the cloud provider's ID and the enterprise = client's ID are both "Internal IDs" with respect to their = domains

 

I think this comes down to a nomenclature = problem.  The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it = just has to be stable and unique.  In many cases, the underlying = identity store will provide identifiers with these properties already = (eg =96 a uuid) and it can be used by the SCIM interface.  The =93externalId=94 is referring to the fact that the id is maintained = external to the SCIM server.  As long as the server=92s identifiers = are stable and unique (which is mandated by the spec), I don=92t see a = problem.

 

 

> The secret is that every value needs a = key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or array (of = values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free = identifier.

 

I agree that this would be useful, especially in = the PATCH operation.  One reason that this wasn=92t included in the spec originally is that it can put undue burden on the = service provider.  Many service providers are putting SCIM = interfaces in front of their existing identity stores (eg =96 directory = servers, SaaS application databases, etc=85).  Many of these do not have a unique identifier for multi-valued attributes.  By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I = believe this would be a roadblock for many = implementers.

 

 

> When the SCIM protocol uses PATCH, there are = areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example = reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the = equivalent of the PATCH verb).  However, the three proposals seem = to largely hinge on being able to uniquely address each element within = an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a = multi-status.


The 207 response would be interesting to consider for the bulk endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html= #bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which = may require review, such as its synchronous = request-response

> interaction model, which is a form of tight = coupling and could prove to be a source of = brittleness.

 

I agree that we should explore optional = asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you = stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for = improvement

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, = so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience = in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoes= tring).

 

I have been following the SCIM spec off and = on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud = provider should maintain their own internal IDs for a resource, which = they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that = should be exposed through the API. The current specification's provision = of an id (which is the external ID and the only one to be transferred = through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically = opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from = an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique = keys for every attribute value of a resource, manipulating it will be = clumsy and inelegant.

 

3. The PATCH command can be improved in 3 = significant ways:

3a. Leverage the fact (from 2 above) that = every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations = of the PATCH command to add, modify and delete attributes at any = level

3c. Use the WebDAV status code of "207 = Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) = command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is = to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, = or when multiple resources are detected to be the same. If internal = identifiers are revealed to external domains, such clean-ups become = difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one = created for this explicit purpose, and only reveal = this.

 

In the SCIM case, when an enterprise client = POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The = enterprise client should map this external UUID to a newly-generated = internal ID of its own. In case the resource already has an identifier = within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned = through the POST response.

 

2. If a resource is to be created, and one = of its attributes is multi-valued, e.g.,

 

    "email-addrs" = : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

= <
______________________________= _________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim

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

- A SP may augment the resource and not = expose the augmented info with the consumer.  
- Schema = is defined by the SP not the consumer
- A consumer may delete = a resource though the SP may simply "hide" it from future = requests

Thanks,
Trey

On Aug 10, 2012, at 11:48 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

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





On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad = wrote:

>  I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. [...] IMHO loose coupling is a = much more complex = solution.

Phil,

I'm a bit = surprised that you're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my = experience.

I think we actually agree. = What I was saying is that for a sufficiently narrow scope model, tight = coupling is "simple". But in the long term it *may* turn out to be = "simplistic".  SCIM current seems to assume that an enterprise = can claim ownership of the entirety of the object being provisioned in = the cloud.  The enterprise has full knowledge of the resource in = the cloud.  Under that highly restricted definition, it is = simple.

The model is fine on a point-to-point = basis, but the higher-level provisioning "system" is more = complex.

I agree with Trey, externalID is = optional.  I also do not equate "externalID" with tight or loose = coupling. Yes, you can cause tight coupling, but that doesn't = necessarily follow. 

I look at it this = way: ObjectID is simply the ID asserted by the holder of the resource. =  ExternalID is an optional ID that is meaningful to a particular = client.   SAML has a similar = concept.


When I say "loose coupling", I mean = "no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

Let's not confuse = reduction of dependencies in the data model with a hub-and-spokes = architecture. They're entirely orthogonal aspects of the solution.

All that my suggestion involves = is,

1. Take 'external ID' out of the = protocol.
2. Allow generic search using 'GET /Users' and = arbitrary URI parameters

No planned functionality is lost by = this.

1. The client enterprise can still send = its internal ID as part of the resource body, inside some attribute = defined by them (but not defined by the protocol). Let's say they call = it 'myID'.
2. The client enterprise can search for resource URIs using any = attribute, including this internal ID
'GET = /Users?myID=3Dbjensen'
Since myID is a candidate key, the = server will return exactly one URI, which is the canonical URI for the = resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this =
URI to perform all other operations as usual.

So taking 'externalID' out =
of the protocol spec only does this:
1. It =
avoids enshrining tight coupling in the protocol (If clients want to =
tightly couple themselves to the cloud provider by sending their =
internal IDs, they can do so. Suicide is OK, but the protocol should not =
be guilty of assisted suicide. ;-)
2. It encourages loose =
coupling by nudging clients towards maintaining their own =
internal-to-external identifier mappings.

That's what I'd like to see. =
I don't believe this complicates the protocol. It simplifies it and it =
also lends itself to a loosely-coupled approach.

I'll address the =
multi-valued attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:


Phil

On = 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec = is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it.

I'm suggesting that the spec do less, not = more.

What the SCIM spec needs to do there is just refrain = from introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

Am I making = sense?

I see what you are saying. = I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The = reality is that each end-point has value to contribute and thus the = single-owner model will eventually need to become multi-owner or = multi-hub. 

That said i think the current model provides a = practical starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 

Precisely. The spec has to strike the right balance. It would = be interesting to hear from the other members of the spec mailing list. = You know where I stand on this. It would be good to hear the spectrum of = opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only = responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "a99a5feba839",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      = }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 

 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        = |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = },

      = {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      = }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of = SCIM, a key goal has been to foster adoption by service providers by = making things fit easily onto existing systems.  IMO the value = gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits = your requirements as it hides internal ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus = UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 = 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the = first.

1.      Why should domains not = expose their internal identifiers to other = domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued = attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain = are notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an = intelligent (but incorrect) guess that these two persons are the same, = and re-assign the same identifier to the second person. This is a false = positive. They appear to be the same entity, but they're actually different. When the error is discovered, the = identities will need to be split, with a new identifier generated for = one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique = identifiers. This is a false negative. They appear to be two entities, = but are actually the same. At a later stage, when the error is = discovered, the identities will have to be merged, and one of the identifiers will have to be = dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing = external identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some = convenient time (importantly, this doesn't have to be at the time the = split happens), Domain 2 can be requested to provision a second entity, = and when it responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the = second entity's internal identifier.

The = mapping table now contains the following = entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and = drops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to look up the translation table to = determine the =93primary=94 external ID for this entity in Domain 2, = which was decided to be =93ff487230b3a0=94. That's where the =93Primary = flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound = communication.

At = some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is = acknowledged.

This = scheme will scale up to multiple domains, because the =93External Domain = ID=94 column helps to keep track of which external ID is shared with = which Domain. (Why don't we use just one external ID for an entity and share it with all external = domains? Tight coupling again. Just as OAuth allows an access token = given to a third party to be invalidated without affecting the access of = other third parties, the use of separate external identifiers for different domains allows fine-grained control of = identity federation.)

The = scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many John Smiths there are who were born = on 1 Jan 1970!)

This = is a fairly long-winded explanation, but this is why we need to hide = internal identifiers from other domains, and why mappings need to be = managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for = propagation of identity events, since there is no consistency = requirement to update multiple domains = concurrently.

Regards,

Ganesh= Prasad

 

On 9 August 2012 04:55, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Thanks for the feedback, Ganesh.  I read = through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitation= s) and have some thoughts.

 

> The rest of the protocol does not meaningfully = use the enterprise client=92s identifier, the "external = ID"

> at all, even though it was ostensibly = introduced to make things friendlier for the = client.

 

The usage pattern for an external ID would be to = search for a user by externalId and use the ID of the returned user in any desired operation.  For = example:

 

GET /Users?filter=3DexternalId eq = =93bjensen=94&attributes=3Did

 

{

  =93totalResults=94: = 1,

  =93Resources=94: = [

    {

      =93id=94: = =932819c223-7f76-453a-919d-413861904646=94

    }

  ]

}

 

Retrieve the ID from the response and use = it.

 

DELETE = /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if = the client chooses not to store the server=92s id.  An issue was created to consider allowing operations to use the = externalId (http://code.google.com/p/scim/issues/detail?id=3D35<= span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1f497d">), but I believe the general consensus has been to not include this in the = spec.  One main point of contention is that much of the rest of the = spec (eg =96 group membership references, manager references, etc=85) = require knowledge of the server=92s identifier.  Continuing this discussion on the IETF list would be a good thing, = though.

 

 

> the cloud provider's ID and the enterprise = client's ID are both "Internal IDs" with respect to their = domains

 

I think this comes down to a nomenclature = problem.  The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it = just has to be stable and unique.  In many cases, the underlying = identity store will provide identifiers with these properties already = (eg =96 a uuid) and it can be used by the SCIM interface.  The =93externalId=94 is referring to the fact that the id is maintained = external to the SCIM server.  As long as the server=92s identifiers = are stable and unique (which is mandated by the spec), I don=92t see a = problem.

 

 

> The secret is that every value needs a = key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or array (of = values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free = identifier.

 

I agree that this would be useful, especially in = the PATCH operation.  One reason that this wasn=92t included in the spec originally is that it can put undue burden on the = service provider.  Many service providers are putting SCIM = interfaces in front of their existing identity stores (eg =96 directory = servers, SaaS application databases, etc=85).  Many of these do not have a unique identifier for multi-valued attributes.  By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I = believe this would be a roadblock for many = implementers.

 

 

> When the SCIM protocol uses PATCH, there are = areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example = reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the = equivalent of the PATCH verb).  However, the three proposals seem = to largely hinge on being able to uniquely address each element within = an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a = multi-status.


The 207 response would be interesting to consider for the bulk endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html= #bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which = may require review, such as its synchronous = request-response

> interaction model, which is a form of tight = coupling and could prove to be a source of = brittleness.

 

I agree that we should explore optional = asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you = stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for = improvement

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, = so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience = in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoes= tring).

 

I have been following the SCIM spec off and = on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud = provider should maintain their own internal IDs for a resource, which = they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that = should be exposed through the API. The current specification's provision = of an id (which is the external ID and the only one to be transferred = through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically = opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from = an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique = keys for every attribute value of a resource, manipulating it will be = clumsy and inelegant.

 

3. The PATCH command can be improved in 3 = significant ways:

3a. Leverage the fact (from 2 above) that = every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations = of the PATCH command to add, modify and delete attributes at any = level

3c. Use the WebDAV status code of "207 = Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) = command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is = to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, = or when multiple resources are detected to be the same. If internal = identifiers are revealed to external domains, such clean-ups become = difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one = created for this explicit purpose, and only reveal = this.

 

In the SCIM case, when an enterprise client = POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The = enterprise client should map this external UUID to a newly-generated = internal ID of its own. In case the resource already has an identifier = within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned = through the POST response.

 

2. If a resource is to be created, and one = of its attributes is multi-valued, e.g.,

 

    "email-addrs" = : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

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

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

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

= --Apple-Mail=_3BE6DB64-55D6-4A63-B3E4-CF908A891B3F-- From phil.hunt@oracle.com Fri Aug 10 12:12:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7CE21F86F7 for ; Fri, 10 Aug 2012 12:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD5ckpdq6AXa for ; Fri, 10 Aug 2012 12:12:01 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 83F5221F86F6 for ; Fri, 10 Aug 2012 12:11:59 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AJBsNh008505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Aug 2012 19:11:55 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AJBqPp022612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2012 19:11:53 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AJBn6Y015724; Fri, 10 Aug 2012 14:11:49 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 12:11:47 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_358CB413-D7BC-4EE4-91DB-37BFAB37A12A" From: Phil Hunt In-Reply-To: Date: Fri, 10 Aug 2012 12:11:46 -0700 Message-Id: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> To: Trey Drake X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "scim@ietf.org" , Ganesh and Sashi Prasad , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:12:05 -0000 --Apple-Mail=_358CB413-D7BC-4EE4-91DB-37BFAB37A12A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 By "own", I was implying a possible scenario where a client assumes it = knows everything it needs to know about the state of the resource within = a SP (because for example only that client can change the resource). = Thus an owning client could execute a PATCH operation on an attribute = without a lot of errors (missing values, non-existent attributes and = other errors) because it knows of the full state of the resource in the = SP. I think your example nicely points out the complexity that is likely to = occur for service providers. At some point, full knowledge of "state" = for the provisioning clients isn't realistic.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-10, at 11:31 AM, Trey Drake wrote: > Maybe. I suppose that depends on the meaning of "owns". =20 >=20 > - A SP may augment the resource and not expose the augmented info with = the consumer. =20 > - Schema is defined by the SP not the consumer > - A consumer may delete a resource though the SP may simply "hide" it = from future requests >=20 > Thanks, > Trey >=20 > On Aug 10, 2012, at 11:48 AM, Phil Hunt wrote: >=20 >> Ganesh, >>=20 >> See below... >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad wrote: >>=20 >>> > I think scim gets its current simplicity from its single owner = hub spoke model implementing tight coupling. [...] IMHO loose coupling = is a much more complex solution. >>>=20 >>> Phil, >>>=20 >>> I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. >>=20 >> I think we actually agree. What I was saying is that for a = sufficiently narrow scope model, tight coupling is "simple". But in the = long term it *may* turn out to be "simplistic". SCIM current seems to = assume that an enterprise can claim ownership of the entirety of the = object being provisioned in the cloud. The enterprise has full = knowledge of the resource in the cloud. Under that highly restricted = definition, it is simple. >>=20 >> The model is fine on a point-to-point basis, but the higher-level = provisioning "system" is more complex. >>=20 >> I agree with Trey, externalID is optional. I also do not equate = "externalID" with tight or loose coupling. Yes, you can cause tight = coupling, but that doesn't necessarily follow.=20 >>=20 >> I look at it this way: ObjectID is simply the ID asserted by the = holder of the resource. ExternalID is an optional ID that is meaningful = to a particular client. SAML has a similar concept. >>=20 >>>=20 >>> When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >>>=20 >>> Let's not confuse reduction of dependencies in the data model with a = hub-and-spokes architecture. They're entirely orthogonal aspects of the = solution. >>>=20 >>> All that my suggestion involves is, >>>=20 >>> 1. Take 'external ID' out of the protocol. >>> 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >>>=20 >>> No planned functionality is lost by this. >>>=20 >>> 1. The client enterprise can still send its internal ID as part of = the resource body, inside some attribute defined by them (but not = defined by the protocol). Let's say they call it 'myID'. >>> 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID >>> 'GET /Users?myID=3Dbjensen' >>> Since myID is a candidate key, the server will return exactly one = URI, which is the canonical URI for the resource >>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>> 3. The client can use this URI to perform all other operations as = usual. >>>=20 >>> So taking 'externalID' out of the protocol spec only does this: >>> 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) >>> 2. It encourages loose coupling by nudging clients towards = maintaining their own internal-to-external identifier mappings. >>>=20 >>> That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >>>=20 >>> I'll address the multi-valued attribute suggestion separately. >>>=20 >>> Regards, >>> Ganesh >>>=20 >>>=20 >>>=20 >>> On 10 August 2012 07:53, Phil Hunt wrote: >>>=20 >>>=20 >>> Phil >>>=20 >>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >>>=20 >>>> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>>>=20 >>>> I wasn't suggesting that the mapping table be part of the SCIM = spec. I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>>>=20 >>>> I'm suggesting that the spec do less, not more. >>>>=20 >>>> What the SCIM spec needs to do there is just refrain from = introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute. >>>>=20 >>>> Am I making sense? >>>=20 >>> I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >>>=20 >>> IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >>>=20 >>> That said i think the current model provides a practical starting = point.=20 >>>>=20 >>>> > Regarding unique identifiers for multi-valued attributes there = is a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>>>=20 >>>> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>>>=20 >>>> Regards, >>>> Ganesh >>>>=20 >>>> On 10 August 2012 00:28, Kelly Grizzle = wrote: >>>> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>>>=20 >>>> =20 >>>>=20 >>>> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>>>=20 >>>> =20 >>>>=20 >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>=20 >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>>=20 >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | = true | >>>>=20 >>>> =20 >>>>=20 >>>> This could be represented as two SCIM users that contain = information about the entities on other domains. >>>>=20 >>>> =20 >>>>=20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>=20 >>>> "id": "9caf78aac3d6", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "ff487230b3a0" >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>>=20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>=20 >>>> "id": "a99a5feba839", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "7a87f27c1dd8" >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>>=20 >>>> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> Similarly, the false negative use case (merging two users) looked = like this at the end: >>>>=20 >>>> =20 >>>>=20 >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>=20 >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>>=20 >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>>>=20 >>>> =20 >>>>=20 >>>> This could be represented with the following SCIM user: >>>>=20 >>>> =20 >>>>=20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>=20 >>>> "id": "9caf78aac3d6", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "ff487230b3a0" >>>>=20 >>>> }, >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "41206cc97c8b", >>>>=20 >>>> "deletionRequired": true >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> Regarding unique identifiers for multi-valued attributes there is a = trade-off involved. On one hand this makes PATCH semantics easier. On = the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>>>=20 >>>> =20 >>>>=20 >>>> --Kelly >>>>=20 >>>> =20 >>>>=20 >>>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On = Behalf Of Emmanuel Dreux >>>> Sent: Thursday, August 09, 2012 3:18 AM >>>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>>> Cc: scim@ietf.org >>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>>=20 >>>> Hi Ganesh, >>>>=20 >>>> =20 >>>>=20 >>>> Nothing prevents you in your SCIM implementation (client or server) = to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>>>=20 >>>> =20 >>>>=20 >>>> This is what we are doing with Active Directory sources or targets: >>>>=20 >>>> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>>>=20 >>>> =20 >>>>=20 >>>> This was written in dotnet and we have started a project to rewrite = our SCIM stack in PHP and will give it to the Open Source community. = This implementation will have a parameter : AllocateIds versus = UseExistingIDs. >>>>=20 >>>> This will give the choice of =93hiding=94 internalIDs or use them = as unique ID. >>>>=20 >>>> =20 >>>>=20 >>>> You can also implement such feature without violating the SCIM = specs, or without asking to include it in the specs. >>>>=20 >>>> =20 >>>>=20 >>>> -- >>>>=20 >>>> Regards, >>>>=20 >>>> Emmanuel Dreux >>>>=20 >>>> http://www.cloudiway.com >>>>=20 >>>> Tel: +33 4 26 78 17 58 >>>>=20 >>>> Mobile: +33 6 47 81 26 70 >>>>=20 >>>> skype: Emmanuel.Dreux >>>>=20 >>>> =20 >>>>=20 >>>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>>> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >>>> =C0 : Kelly Grizzle >>>> Cc : scim@ietf.org >>>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>>=20 >>>> Hi Kelly, >>>> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >>>> 1. Why should domains not expose their internal identifiers to = other domains? >>>> a. >>>> We are designing a protocol for a federated system of domains, = where all domains are co-equal peers. (In physics too, N-body problems = are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >>>> b. >>>> In any non-trivial data store, there will always be the ongoing = need to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >>>> c. >>>> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >>>> 2. The difficulty of assigning unique identifiers to the individual = values of multi-valued attributes: >>>> a. >>>> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >>>> b. >>>> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >>>> Elaboration of Point 1: >>>> When we consider federated identity across more than one domain, we = have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >>>> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >>>> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >>>> Consider a case where customers sign up online, and two customers = who are privacy-conscious enter fake IDs such as =93John Smith=94, and = also use the same date of birth (say, 1 Jan 1970) or similar attributes. = The front-end application may make an intelligent (but incorrect) guess = that these two persons are the same, and re-assign the same identifier = to the second person. This is a false positive. They appear to be the = same entity, but they're actually different. When the error is = discovered, the identities will need to be split, with a new identifier = generated for one of them. >>>> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >>>> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >>>> a. False positives: >>>> Domain 1 has the following information about a customer in its data = store: >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >>>> Domain 1 then maintains the following in a mapping table and uses = it for translation when talking to Domain 2, taking care never to expose = its internal identifier: >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> When the false positive is discovered and the entity is split, = Domain 1 creates a new internal identifier and now has the following = entity information. >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> Internal ID: a99a5feba839 >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> This second entity with its own internal identifier is invisible to = Domain 2, and this is by design. Communication about the original entity = takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 = and vice-versa. At some convenient time (importantly, this doesn't have = to be at the time the split happens), Domain 2 can be requested to = provision a second entity, and when it responds with an identifier of = =937a87f27c1dd8=94, this can go into the mapping table as a new record = associated with the second entity's internal identifier. >>>> The mapping table now contains the following entries: >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >>>> (What is the =93Primary flag=94 used for? We'll see when we cover = the treatment of false negatives.) >>>> b. False negatives: >>>> Domain 1 has the following information about what it thinks are two = distinct customers in its data store: >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>> Internal ID: 273d36e30d09 >>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>> When requesting the provisioning of these entities in Domain 2, the = following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>>> Domain 1 then maintains the following in a mapping table and uses = it for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >>>> The mapping table now looks like this: >>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>> Now two external identifiers map to the same internal one, so = inbound communication from Domain 2 can be unambiguously translated to = the same entity internally. However, when going outwards, Domain 1 will = have to look up the translation table to determine the =93primary=94 = external ID for this entity in Domain 2, which was decided to be = =93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The = second external ID =9341206cc97c8b=94 is never used thereafter in = outbound communication. >>>> At some stage (importantly, not in lockstep with the identity = merge), Domain 2 can be requested to delete the customer record = identified by =9341206cc97c8b=94, and the second entry in the mapping = table can be removed once this is acknowledged. >>>> This scheme will scale up to multiple domains, because the = =93External Domain ID=94 column helps to keep track of which external ID = is shared with which Domain. (Why don't we use just one external ID for = an entity and share it with all external domains? Tight coupling again. = Just as OAuth allows an access token given to a third party to be = invalidated without affecting the access of other third parties, the use = of separate external identifiers for different domains allows = fine-grained control of identity federation.) >>>> The scheme also allows the splitting of an entity into more than = two entities, and the merging of more than two entities into a single = one. (Any organisation with a web-facing application will tell you how = many John Smiths there are who were born on 1 Jan 1970!) >>>> This is a fairly long-winded explanation, but this is why we need = to hide internal identifiers from other domains, and why mappings need = to be managed internally in each domain. Such a data model also allows = us to choose asynchronous protocols for propagation of identity events, = since there is no consistency requirement to update multiple domains = concurrently. >>>> Regards, >>>> Ganesh Prasad >>>> =20 >>>>=20 >>>> On 9 August 2012 04:55, Kelly Grizzle = wrote: >>>>=20 >>>> Thanks for the feedback, Ganesh. I read through this and your = InfoQ article = (http://www.infoq.com/articles/scim-data-model-limitations) and have = some thoughts. >>>>=20 >>>> =20 >>>>=20 >>>> > The rest of the protocol does not meaningfully use the enterprise = client=92s identifier, the "external ID" >>>>=20 >>>> > at all, even though it was ostensibly introduced to make things = friendlier for the client. >>>>=20 >>>> =20 >>>>=20 >>>> The usage pattern for an external ID would be to search for a user = by externalId and use the ID of the returned user in any desired = operation. For example: >>>>=20 >>>> =20 >>>>=20 >>>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >>>>=20 >>>> =20 >>>>=20 >>>> { >>>>=20 >>>> =93totalResults=94: 1, >>>>=20 >>>> =93Resources=94: [ >>>>=20 >>>> { >>>>=20 >>>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> =20 >>>>=20 >>>> Retrieve the ID from the response and use it. >>>>=20 >>>> =20 >>>>=20 >>>> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >>>>=20 >>>> =20 >>>>=20 >>>> This does introduce an additional HTTP request if the client = chooses not to store the server=92s id. An issue was created to = consider allowing operations to use the externalId = (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the = general consensus has been to not include this in the spec. One main = point of contention is that much of the rest of the spec (eg =96 group = membership references, manager references, etc=85) require knowledge of = the server=92s identifier. Continuing this discussion on the IETF list = would be a good thing, though. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > the cloud provider's ID and the enterprise client's ID are both = "Internal IDs" with respect to their domains >>>>=20 >>>> =20 >>>>=20 >>>> I think this comes down to a nomenclature problem. The server=92s = ID does not necessarily have to be the unique identifier that the = underlying identity store uses, it just has to be stable and unique. In = many cases, the underlying identity store will provide identifiers with = these properties already (eg =96 a uuid) and it can be used by the SCIM = interface. The =93externalId=94 is referring to the fact that the id is = maintained external to the SCIM server. As long as the server=92s = identifiers are stable and unique (which is mandated by the spec), I = don=92t see a problem. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > The secret is that every value needs a key, and multi-valued = attributes lack that. So our solution is quite >>>>=20 >>>> > simple - turn every list or array (of values) into a dictionary = (of key-value pairs) by providing each value >>>>=20 >>>> > with a unique and meaning-free identifier. >>>>=20 >>>> =20 >>>>=20 >>>> I agree that this would be useful, especially in the PATCH = operation. One reason that this wasn=92t included in the spec = originally is that it can put undue burden on the service provider. = Many service providers are putting SCIM interfaces in front of their = existing identity stores (eg =96 directory servers, SaaS application = databases, etc=85). Many of these do not have a unique identifier for = multi-valued attributes. By requiring this, a majority of the server = providers would have to start maintaining a unique key for each = multi-valued attribute. I believe this would be a roadblock for many = implementers. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > When the SCIM protocol uses PATCH, there are areas where it seems = a bit clumsy. >>>>=20 >>>> =20 >>>>=20 >>>> I like the thoughts here. Your example reminds me of unified diffs = (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly = used with a patch program (pretty much the equivalent of the PATCH = verb). However, the three proposals seem to largely hinge on being able = to uniquely address each element within an object. Without these it is = not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85)= or provide a multi-status. >>>>=20 >>>>=20 >>>> The 207 response would be interesting to consider for the bulk = endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),= however. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> > There are other, non-data aspects of SCIM which may require = review, such as its synchronous request-response >>>>=20 >>>> > interaction model, which is a form of tight coupling and could = prove to be a source of brittleness. >>>>=20 >>>> =20 >>>>=20 >>>> I agree that we should explore optional asynchronous requests in = 2.0. >>>>=20 >>>> =20 >>>>=20 >>>> Thanks again for your thoughts. I hope you stay involved in the = discussion as work on SCIM 2.0 goes forward. >>>>=20 >>>> =20 >>>>=20 >>>> --Kelly >>>>=20 >>>> =20 >>>>=20 >>>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On = Behalf Of Ganesh and Sashi Prasad >>>> Sent: Wednesday, August 01, 2012 4:24 PM >>>> To: scim@ietf.org >>>> Subject: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>>=20 >>>> (I posted this on the SCIM Google Group, and I was advised to = subscribe to the mailing list and post it here instead, so here goes.) >>>>=20 >>>> =20 >>>>=20 >>>> Hi, >>>>=20 >>>> =20 >>>>=20 >>>> My name is Ganesh Prasad, and my experience in Identity and Access = Management is mainly through a 3-year project at an Australian insurance = company, an experience I have written about as a eBook on InfoQ = (http://www.infoq.com/minibooks/Identity-Management-Shoestring). >>>>=20 >>>> =20 >>>>=20 >>>> I have been following the SCIM spec off and on, and based on my = experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make. >>>>=20 >>>> =20 >>>>=20 >>>> 1. The enterprise client and the cloud provider should maintain = their own internal IDs for a resource, which they should not reveal to = each other. Both of them should map their internal IDs to a shared = External ID, and this is the only ID that should be exposed through the = API. The current specification's provision of an id (which is the = external ID and the only one to be transferred through the API) and an = "external ID" (which is the client's internal ID and should be hidden) = is diametrically opposite to this. >>>>=20 >>>> =20 >>>>=20 >>>> 2. When dealing with multi-valued attributes of a resource = (expressed as arrays in JSON), they must be converted from an array into = a dictionary with unique keys (UUIDs generated by the cloud provider = when the attribute is created). Without unique keys for every attribute = value of a resource, manipulating it will be clumsy and inelegant. >>>>=20 >>>> =20 >>>>=20 >>>> 3. The PATCH command can be improved in 3 significant ways: >>>>=20 >>>> 3a. Leverage the fact (from 2 above) that every value has a key, to = greatly simplify the API >>>>=20 >>>> 3b. Use special verbs as nested operations of the PATCH command to = add, modify and delete attributes at any level >>>>=20 >>>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of = "200 OK" as the response to a PATCH (or BULK) command. >>>>=20 >>>> =20 >>>>=20 >>>> To elaborate, >>>>=20 >>>> =20 >>>>=20 >>>> 1. Revealing private IDs externally is a form of tight coupling. A = major requirement with Identity Management is to split (or merge) = identities when false positives (or false negatives) are detected, i.e., = when a resource is discovered to be more than one, or when multiple = resources are detected to be the same. If internal identifiers are = revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its = internal ID to and external one created for this explicit purpose, and = only reveal this. >>>>=20 >>>> =20 >>>>=20 >>>> In the SCIM case, when an enterprise client POSTs a resource = creation request, the cloud provider must generate its own internal UUID = as well as an external UUID, map them together, and only return the = external UUID in the "Location:" header. The enterprise client should = map this external UUID to a newly-generated internal ID of its own. In = case the resource already has an identifier within the enterprise = client's domain, then this is the internal ID that must be mapped to the = external UUID returned through the POST response. >>>>=20 >>>> =20 >>>>=20 >>>> 2. If a resource is to be created, and one of its attributes is = multi-valued, e.g., >>>>=20 >>>> =20 >>>>=20 >>>> "email-addrs" :=20 >>>>=20 >>>> [ >>>>=20 >>>> "john_smith@yahoo.com", >>>>=20 >>>> "john.smith@gmail.com", >>>>=20 >>>> "jsmith1970@hotmail.com" >>>>=20 >>>> < >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_358CB413-D7BC-4EE4-91DB-37BFAB37A12A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 By = "own", I was implying a possible scenario where a client assumes it = knows everything it needs to know about the state of the resource within = a SP (because for example only that client can change the resource). =  Thus an owning client could execute a PATCH operation on an = attribute without a lot of errors (missing values, non-existent = attributes and other errors) because it knows of the full state of the = resource in the SP.

I think your example nicely = points out the complexity that is likely to occur for service providers. = At some point, full knowledge of "state" for the provisioning clients = isn't realistic. 


On 2012-08-10, at 11:31 AM, Trey Drake wrote:


- A SP may augment the resource and not = expose the augmented info with the consumer.  
- Schema = is defined by the SP not the consumer
- A consumer may delete = a resource though the SP may simply "hide" it from future = requests

Thanks,
Trey

On Aug 10, 2012, at 11:48 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

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





On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad = wrote:

>  I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. [...] IMHO loose coupling is a = much more complex = solution.

Phil,

I'm a bit = surprised that you're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my = experience.

I think we actually agree. = What I was saying is that for a sufficiently narrow scope model, tight = coupling is "simple". But in the long term it *may* turn out to be = "simplistic".  SCIM current seems to assume that an enterprise = can claim ownership of the entirety of the object being provisioned in = the cloud.  The enterprise has full knowledge of the resource in = the cloud.  Under that highly restricted definition, it is = simple.

The model is fine on a point-to-point = basis, but the higher-level provisioning "system" is more = complex.

I agree with Trey, externalID is = optional.  I also do not equate "externalID" with tight or loose = coupling. Yes, you can cause tight coupling, but that doesn't = necessarily follow. 

I look at it this = way: ObjectID is simply the ID asserted by the holder of the resource. =  ExternalID is an optional ID that is meaningful to a particular = client.   SAML has a similar = concept.


When I say "loose coupling", I mean = "no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

Let's not confuse = reduction of dependencies in the data model with a hub-and-spokes = architecture. They're entirely orthogonal aspects of the solution.

All that my suggestion involves = is,

1. Take 'external ID' out of the = protocol.
2. Allow generic search using 'GET /Users' and = arbitrary URI parameters

No planned functionality is lost by = this.

1. The client enterprise can still send = its internal ID as part of the resource body, inside some attribute = defined by them (but not defined by the protocol). Let's say they call = it 'myID'.
2. The client enterprise can search for resource URIs using any = attribute, including this internal ID
'GET = /Users?myID=3Dbjensen'
Since myID is a candidate key, the = server will return exactly one URI, which is the canonical URI for the = resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this =
URI to perform all other operations as usual.

So taking 'externalID' out =
of the protocol spec only does this:
1. It =
avoids enshrining tight coupling in the protocol (If clients want to =
tightly couple themselves to the cloud provider by sending their =
internal IDs, they can do so. Suicide is OK, but the protocol should not =
be guilty of assisted suicide. ;-)
2. It encourages loose =
coupling by nudging clients towards maintaining their own =
internal-to-external identifier mappings.

That's what I'd like to see. =
I don't believe this complicates the protocol. It simplifies it and it =
also lends itself to a loosely-coupled approach.

I'll address the =
multi-valued attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:


Phil

On = 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec = is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it.

I'm suggesting that the spec do less, not = more.

What the SCIM spec needs to do there is just refrain = from introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

Am I making = sense?

I see what you are saying. = I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The = reality is that each end-point has value to contribute and thus the = single-owner model will eventually need to become multi-owner or = multi-hub. 

That said i think the current model provides a = practical starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 

Precisely. The spec has to strike the right balance. It would = be interesting to hear from the other members of the spec mailing list. = You know where I stand on this. It would be good to hear the spectrum of = opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only = responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "a99a5feba839",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      = }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 

 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        = |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = },

      = {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      = }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of = SCIM, a key goal has been to foster adoption by service providers by = making things fit easily onto existing systems.  IMO the value = gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits = your requirements as it hides internal ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus = UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 = 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the = first.

1.      Why should domains not = expose their internal identifiers to other = domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued = attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain = are notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an = intelligent (but incorrect) guess that these two persons are the same, = and re-assign the same identifier to the second person. This is a false = positive. They appear to be the same entity, but they're actually different. When the error is discovered, the = identities will need to be split, with a new identifier generated for = one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique = identifiers. This is a false negative. They appear to be two entities, = but are actually the same. At a later stage, when the error is = discovered, the identities will have to be merged, and one of the identifiers will have to be = dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing = external identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some = convenient time (importantly, this doesn't have to be at the time the = split happens), Domain 2 can be requested to provision a second entity, = and when it responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the = second entity's internal identifier.

The = mapping table now contains the following = entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and = drops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to look up the translation table to = determine the =93primary=94 external ID for this entity in Domain 2, = which was decided to be =93ff487230b3a0=94. That's where the =93Primary = flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound = communication.

At = some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is = acknowledged.

This = scheme will scale up to multiple domains, because the =93External Domain = ID=94 column helps to keep track of which external ID is shared with = which Domain. (Why don't we use just one external ID for an entity and share it with all external = domains? Tight coupling again. Just as OAuth allows an access token = given to a third party to be invalidated without affecting the access of = other third parties, the use of separate external identifiers for different domains allows fine-grained control of = identity federation.)

The = scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many John Smiths there are who were born = on 1 Jan 1970!)

This = is a fairly long-winded explanation, but this is why we need to hide = internal identifiers from other domains, and why mappings need to be = managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for = propagation of identity events, since there is no consistency = requirement to update multiple domains = concurrently.

Regards,

Ganesh= Prasad

 

On 9 August 2012 04:55, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Thanks for the feedback, Ganesh.  I read = through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitation= s) and have some thoughts.

 

> The rest of the protocol does not meaningfully = use the enterprise client=92s identifier, the "external = ID"

> at all, even though it was ostensibly = introduced to make things friendlier for the = client.

 

The usage pattern for an external ID would be to = search for a user by externalId and use the ID of the returned user in any desired operation.  For = example:

 

GET /Users?filter=3DexternalId eq = =93bjensen=94&attributes=3Did

 

{

  =93totalResults=94: = 1,

  =93Resources=94: = [

    {

      =93id=94: = =932819c223-7f76-453a-919d-413861904646=94

    }

  ]

}

 

Retrieve the ID from the response and use = it.

 

DELETE = /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if = the client chooses not to store the server=92s id.  An issue was created to consider allowing operations to use the = externalId (http://code.google.com/p/scim/issues/detail?id=3D35<= span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1f497d">), but I believe the general consensus has been to not include this in the = spec.  One main point of contention is that much of the rest of the = spec (eg =96 group membership references, manager references, etc=85) = require knowledge of the server=92s identifier.  Continuing this discussion on the IETF list would be a good thing, = though.

 

 

> the cloud provider's ID and the enterprise = client's ID are both "Internal IDs" with respect to their = domains

 

I think this comes down to a nomenclature = problem.  The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it = just has to be stable and unique.  In many cases, the underlying = identity store will provide identifiers with these properties already = (eg =96 a uuid) and it can be used by the SCIM interface.  The =93externalId=94 is referring to the fact that the id is maintained = external to the SCIM server.  As long as the server=92s identifiers = are stable and unique (which is mandated by the spec), I don=92t see a = problem.

 

 

> The secret is that every value needs a = key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or array (of = values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free = identifier.

 

I agree that this would be useful, especially in = the PATCH operation.  One reason that this wasn=92t included in the spec originally is that it can put undue burden on the = service provider.  Many service providers are putting SCIM = interfaces in front of their existing identity stores (eg =96 directory = servers, SaaS application databases, etc=85).  Many of these do not have a unique identifier for multi-valued attributes.  By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I = believe this would be a roadblock for many = implementers.

 

 

> When the SCIM protocol uses PATCH, there are = areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example = reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the = equivalent of the PATCH verb).  However, the three proposals seem = to largely hinge on being able to uniquely address each element within = an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a = multi-status.


The 207 response would be interesting to consider for the bulk endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html= #bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which = may require review, such as its synchronous = request-response

> interaction model, which is a form of tight = coupling and could prove to be a source of = brittleness.

 

I agree that we should explore optional = asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you = stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for = improvement

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, = so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience = in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoes= tring).

 

I have been following the SCIM spec off and = on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud = provider should maintain their own internal IDs for a resource, which = they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that = should be exposed through the API. The current specification's provision = of an id (which is the external ID and the only one to be transferred = through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically = opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from = an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique = keys for every attribute value of a resource, manipulating it will be = clumsy and inelegant.

 

3. The PATCH command can be improved in 3 = significant ways:

3a. Leverage the fact (from 2 above) that = every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations = of the PATCH command to add, modify and delete attributes at any = level

3c. Use the WebDAV status code of "207 = Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) = command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is = to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, = or when multiple resources are detected to be the same. If internal = identifiers are revealed to external domains, such clean-ups become = difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one = created for this explicit purpose, and only reveal = this.

 

In the SCIM case, when an enterprise client = POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The = enterprise client should map this external UUID to a newly-generated = internal ID of its own. In case the resource already has an identifier = within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned = through the POST response.

 

2. If a resource is to be created, and one = of its attributes is multi-valued, e.g.,

 

    "email-addrs" = : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

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

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

___________= ____________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim

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

= --Apple-Mail=_358CB413-D7BC-4EE4-91DB-37BFAB37A12A-- From trey.drake@unboundid.com Fri Aug 10 12:15:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8306311E809A for ; Fri, 10 Aug 2012 12:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyFDKSOdDgx3 for ; Fri, 10 Aug 2012 12:15:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07711E8099 for ; Fri, 10 Aug 2012 12:15:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3070078obb.31 for ; Fri, 10 Aug 2012 12:15:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=l6Aby9w6owntuMRXQtucxjiaGD77B8I3fpDfbfxS9e0=; b=k4FR81j6lcVR56hXFixqx7n9+eo2AnkGRJtzv0pvgx865nj3vlySP+kxqRpq/SL5kx 7OB93XCqQH3ujTb3IQx5FvD/Hvr9t+n+Ic7w+g/tv/f7B9jnVwWDkgwexekRI/rNAq48 iWJkHYdZyVHgHX2HkcHxm5ZnCf1hSfQfSg+5YqXCQtKjCexh8aaJUUlMFDsoZhUU5Gyi kMCu8uP2cF3GZyeD0BQQyCksVWBYrGccsfcxo0GRwy+3dMxGCE3vz4MhKYiwrnN0jnu2 88vRV4u9tC/Ot/4G/jtlqgIAFwbCxROGGzYiqA8Yw66VHCWL5UulbEIj6H1TA+EZcFlo LfNg== Received: by 10.60.2.42 with SMTP id 10mr170590oer.9.1344626142506; Fri, 10 Aug 2012 12:15:42 -0700 (PDT) Received: from [192.168.241.66] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id qd7sm4065851obc.5.2012.08.10.12.15.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 12:15:41 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E5774BB9-EB8B-4C7F-9CE7-F863B681FFBA" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: Date: Fri, 10 Aug 2012 14:15:40 -0500 Message-Id: <411B68AE-A698-4DFE-9D35-1D4D5857528C@unboundid.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQk/Vs+z7Ui5SKWYbsQ/hvIC5is04gz2O2faL6Y5I4JgT1O9rgJMyXBsOm5MC2c6VoUYEx98 Cc: "scim@ietf.org" , Ganesh and Sashi Prasad , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:15:47 -0000 --Apple-Mail=_E5774BB9-EB8B-4C7F-9CE7-F863B681FFBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the clarification Phil - makes sense to me. On Aug 10, 2012, at 2:11 PM, Phil Hunt wrote: > By "own", I was implying a possible scenario where a client assumes it = knows everything it needs to know about the state of the resource within = a SP (because for example only that client can change the resource). = Thus an owning client could execute a PATCH operation on an attribute = without a lot of errors (missing values, non-existent attributes and = other errors) because it knows of the full state of the resource in the = SP. >=20 > I think your example nicely points out the complexity that is likely = to occur for service providers. At some point, full knowledge of "state" = for the provisioning clients isn't realistic.=20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-08-10, at 11:31 AM, Trey Drake wrote: >=20 >> Maybe. I suppose that depends on the meaning of "owns". =20 >>=20 >> - A SP may augment the resource and not expose the augmented info = with the consumer. =20 >> - Schema is defined by the SP not the consumer >> - A consumer may delete a resource though the SP may simply "hide" it = from future requests >>=20 >> Thanks, >> Trey >>=20 >> On Aug 10, 2012, at 11:48 AM, Phil Hunt wrote: >>=20 >>> Ganesh, >>>=20 >>> See below... >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad wrote: >>>=20 >>>> > I think scim gets its current simplicity from its single owner = hub spoke model implementing tight coupling. [...] IMHO loose coupling = is a much more complex solution. >>>>=20 >>>> Phil, >>>>=20 >>>> I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. >>>=20 >>> I think we actually agree. What I was saying is that for a = sufficiently narrow scope model, tight coupling is "simple". But in the = long term it *may* turn out to be "simplistic". SCIM current seems to = assume that an enterprise can claim ownership of the entirety of the = object being provisioned in the cloud. The enterprise has full = knowledge of the resource in the cloud. Under that highly restricted = definition, it is simple. >>>=20 >>> The model is fine on a point-to-point basis, but the higher-level = provisioning "system" is more complex. >>>=20 >>> I agree with Trey, externalID is optional. I also do not equate = "externalID" with tight or loose coupling. Yes, you can cause tight = coupling, but that doesn't necessarily follow.=20 >>>=20 >>> I look at it this way: ObjectID is simply the ID asserted by the = holder of the resource. ExternalID is an optional ID that is meaningful = to a particular client. SAML has a similar concept. >>>=20 >>>>=20 >>>> When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >>>>=20 >>>> Let's not confuse reduction of dependencies in the data model with = a hub-and-spokes architecture. They're entirely orthogonal aspects of = the solution. >>>>=20 >>>> All that my suggestion involves is, >>>>=20 >>>> 1. Take 'external ID' out of the protocol. >>>> 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >>>>=20 >>>> No planned functionality is lost by this. >>>>=20 >>>> 1. The client enterprise can still send its internal ID as part of = the resource body, inside some attribute defined by them (but not = defined by the protocol). Let's say they call it 'myID'. >>>> 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID >>>> 'GET /Users?myID=3Dbjensen' >>>> Since myID is a candidate key, the server will return exactly one = URI, which is the canonical URI for the resource >>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>> 3. The client can use this URI to perform all other operations as = usual. >>>>=20 >>>> So taking 'externalID' out of the protocol spec only does this: >>>> 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) >>>> 2. It encourages loose coupling by nudging clients towards = maintaining their own internal-to-external identifier mappings. >>>>=20 >>>> That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >>>>=20 >>>> I'll address the multi-valued attribute suggestion separately. >>>>=20 >>>> Regards, >>>> Ganesh >>>>=20 >>>>=20 >>>>=20 >>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >>>>=20 >>>>> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>>>>=20 >>>>> I wasn't suggesting that the mapping table be part of the SCIM = spec. I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>>>>=20 >>>>> I'm suggesting that the spec do less, not more. >>>>>=20 >>>>> What the SCIM spec needs to do there is just refrain from = introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute. >>>>>=20 >>>>> Am I making sense? >>>>=20 >>>> I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >>>>=20 >>>> IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >>>>=20 >>>> That said i think the current model provides a practical starting = point.=20 >>>>>=20 >>>>> > Regarding unique identifiers for multi-valued attributes there = is a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>>>>=20 >>>>> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>>>>=20 >>>>> Regards, >>>>> Ganesh >>>>>=20 >>>>> On 10 August 2012 00:28, Kelly Grizzle = wrote: >>>>> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>>>>=20 >>>>> =20 >>>>>=20 >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>>=20 >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>>>=20 >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | = true | >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This could be represented as two SCIM users that contain = information about the entities on other domains. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> { >>>>>=20 >>>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>>=20 >>>>> "id": "9caf78aac3d6", >>>>>=20 >>>>> "userName": "John Smith", >>>>>=20 >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>=20 >>>>> "linkedUsers": [ >>>>>=20 >>>>> { >>>>>=20 >>>>> "domain": "D2", >>>>>=20 >>>>> "externalEntityId": "ff487230b3a0" >>>>>=20 >>>>> } >>>>>=20 >>>>> ] >>>>>=20 >>>>> } >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> { >>>>>=20 >>>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>>=20 >>>>> "id": "a99a5feba839", >>>>>=20 >>>>> "userName": "John Smith", >>>>>=20 >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>=20 >>>>> "linkedUsers": [ >>>>>=20 >>>>> { >>>>>=20 >>>>> "domain": "D2", >>>>>=20 >>>>> "externalEntityId": "7a87f27c1dd8" >>>>>=20 >>>>> } >>>>>=20 >>>>> ] >>>>>=20 >>>>> } >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Similarly, the false negative use case (merging two users) looked = like this at the end: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>>=20 >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>>>=20 >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This could be represented with the following SCIM user: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> { >>>>>=20 >>>>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>>>=20 >>>>> "id": "9caf78aac3d6", >>>>>=20 >>>>> "userName": "John Smith", >>>>>=20 >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>=20 >>>>> "linkedUsers": [ >>>>>=20 >>>>> { >>>>>=20 >>>>> "domain": "D2", >>>>>=20 >>>>> "externalEntityId": "ff487230b3a0" >>>>>=20 >>>>> }, >>>>>=20 >>>>> { >>>>>=20 >>>>> "domain": "D2", >>>>>=20 >>>>> "externalEntityId": "41206cc97c8b", >>>>>=20 >>>>> "deletionRequired": true >>>>>=20 >>>>> } >>>>>=20 >>>>> ] >>>>>=20 >>>>> } >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Regarding unique identifiers for multi-valued attributes there is = a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --Kelly >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On = Behalf Of Emmanuel Dreux >>>>> Sent: Thursday, August 09, 2012 3:18 AM >>>>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>>>> Cc: scim@ietf.org >>>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi Ganesh, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Nothing prevents you in your SCIM implementation (client or = server) to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This is what we are doing with Active Directory sources or = targets: >>>>>=20 >>>>> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This was written in dotnet and we have started a project to = rewrite our SCIM stack in PHP and will give it to the Open Source = community. This implementation will have a parameter : AllocateIds = versus UseExistingIDs. >>>>>=20 >>>>> This will give the choice of =93hiding=94 internalIDs or use them = as unique ID. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> You can also implement such feature without violating the SCIM = specs, or without asking to include it in the specs. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Emmanuel Dreux >>>>>=20 >>>>> http://www.cloudiway.com >>>>>=20 >>>>> Tel: +33 4 26 78 17 58 >>>>>=20 >>>>> Mobile: +33 6 47 81 26 70 >>>>>=20 >>>>> skype: Emmanuel.Dreux >>>>>=20 >>>>> =20 >>>>>=20 >>>>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>>>> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >>>>> =C0 : Kelly Grizzle >>>>> Cc : scim@ietf.org >>>>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi Kelly, >>>>> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >>>>> 1. Why should domains not expose their internal identifiers = to other domains? >>>>> a. >>>>> We are designing a protocol for a federated system of domains, = where all domains are co-equal peers. (In physics too, N-body problems = are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >>>>> b. >>>>> In any non-trivial data store, there will always be the ongoing = need to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >>>>> c. >>>>> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >>>>> 2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes: >>>>> a. >>>>> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >>>>> b. >>>>> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >>>>> Elaboration of Point 1: >>>>> When we consider federated identity across more than one domain, = we have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >>>>> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >>>>> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >>>>> Consider a case where customers sign up online, and two customers = who are privacy-conscious enter fake IDs such as =93John Smith=94, and = also use the same date of birth (say, 1 Jan 1970) or similar attributes. = The front-end application may make an intelligent (but incorrect) guess = that these two persons are the same, and re-assign the same identifier = to the second person. This is a false positive. They appear to be the = same entity, but they're actually different. When the error is = discovered, the identities will need to be split, with a new identifier = generated for one of them. >>>>> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >>>>> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >>>>> a. False positives: >>>>> Domain 1 has the following information about a customer in its = data store: >>>>> Internal ID: 9caf78aac3d6 >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >>>>> Domain 1 then maintains the following in a mapping table and uses = it for translation when talking to Domain 2, taking care never to expose = its internal identifier: >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> When the false positive is discovered and the entity is split, = Domain 1 creates a new internal identifier and now has the following = entity information. >>>>> Internal ID: 9caf78aac3d6 >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> Internal ID: a99a5feba839 >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> This second entity with its own internal identifier is invisible = to Domain 2, and this is by design. Communication about the original = entity takes place as before by mapping =939caf78aac3d6=94 to = =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly, = this doesn't have to be at the time the split happens), Domain 2 can be = requested to provision a second entity, and when it responds with an = identifier of =937a87f27c1dd8=94, this can go into the mapping table as = a new record associated with the second entity's internal identifier. >>>>> The mapping table now contains the following entries: >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >>>>> (What is the =93Primary flag=94 used for? We'll see when we cover = the treatment of false negatives.) >>>>> b. False negatives: >>>>> Domain 1 has the following information about what it thinks are = two distinct customers in its data store: >>>>> Internal ID: 9caf78aac3d6 >>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>> Internal ID: 273d36e30d09 >>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>> When requesting the provisioning of these entities in Domain 2, = the following IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b. >>>>> Domain 1 then maintains the following in a mapping table and uses = it for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >>>>> The mapping table now looks like this: >>>>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>> Now two external identifiers map to the same internal one, so = inbound communication from Domain 2 can be unambiguously translated to = the same entity internally. However, when going outwards, Domain 1 will = have to look up the translation table to determine the =93primary=94 = external ID for this entity in Domain 2, which was decided to be = =93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The = second external ID =9341206cc97c8b=94 is never used thereafter in = outbound communication. >>>>> At some stage (importantly, not in lockstep with the identity = merge), Domain 2 can be requested to delete the customer record = identified by =9341206cc97c8b=94, and the second entry in the mapping = table can be removed once this is acknowledged. >>>>> This scheme will scale up to multiple domains, because the = =93External Domain ID=94 column helps to keep track of which external ID = is shared with which Domain. (Why don't we use just one external ID for = an entity and share it with all external domains? Tight coupling again. = Just as OAuth allows an access token given to a third party to be = invalidated without affecting the access of other third parties, the use = of separate external identifiers for different domains allows = fine-grained control of identity federation.) >>>>> The scheme also allows the splitting of an entity into more than = two entities, and the merging of more than two entities into a single = one. (Any organisation with a web-facing application will tell you how = many John Smiths there are who were born on 1 Jan 1970!) >>>>> This is a fairly long-winded explanation, but this is why we need = to hide internal identifiers from other domains, and why mappings need = to be managed internally in each domain. Such a data model also allows = us to choose asynchronous protocols for propagation of identity events, = since there is no consistency requirement to update multiple domains = concurrently. >>>>> Regards, >>>>> Ganesh Prasad >>>>> =20 >>>>>=20 >>>>> On 9 August 2012 04:55, Kelly Grizzle = wrote: >>>>>=20 >>>>> Thanks for the feedback, Ganesh. I read through this and your = InfoQ article = (http://www.infoq.com/articles/scim-data-model-limitations) and have = some thoughts. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> > The rest of the protocol does not meaningfully use the = enterprise client=92s identifier, the "external ID" >>>>>=20 >>>>> > at all, even though it was ostensibly introduced to make things = friendlier for the client. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> The usage pattern for an external ID would be to search for a user = by externalId and use the ID of the returned user in any desired = operation. For example: >>>>>=20 >>>>> =20 >>>>>=20 >>>>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >>>>>=20 >>>>> =20 >>>>>=20 >>>>> { >>>>>=20 >>>>> =93totalResults=94: 1, >>>>>=20 >>>>> =93Resources=94: [ >>>>>=20 >>>>> { >>>>>=20 >>>>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >>>>>=20 >>>>> } >>>>>=20 >>>>> ] >>>>>=20 >>>>> } >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Retrieve the ID from the response and use it. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> This does introduce an additional HTTP request if the client = chooses not to store the server=92s id. An issue was created to = consider allowing operations to use the externalId = (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the = general consensus has been to not include this in the spec. One main = point of contention is that much of the rest of the spec (eg =96 group = membership references, manager references, etc=85) require knowledge of = the server=92s identifier. Continuing this discussion on the IETF list = would be a good thing, though. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> > the cloud provider's ID and the enterprise client's ID are both = "Internal IDs" with respect to their domains >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I think this comes down to a nomenclature problem. The server=92s = ID does not necessarily have to be the unique identifier that the = underlying identity store uses, it just has to be stable and unique. In = many cases, the underlying identity store will provide identifiers with = these properties already (eg =96 a uuid) and it can be used by the SCIM = interface. The =93externalId=94 is referring to the fact that the id is = maintained external to the SCIM server. As long as the server=92s = identifiers are stable and unique (which is mandated by the spec), I = don=92t see a problem. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> > The secret is that every value needs a key, and multi-valued = attributes lack that. So our solution is quite >>>>>=20 >>>>> > simple - turn every list or array (of values) into a dictionary = (of key-value pairs) by providing each value >>>>>=20 >>>>> > with a unique and meaning-free identifier. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I agree that this would be useful, especially in the PATCH = operation. One reason that this wasn=92t included in the spec = originally is that it can put undue burden on the service provider. = Many service providers are putting SCIM interfaces in front of their = existing identity stores (eg =96 directory servers, SaaS application = databases, etc=85). Many of these do not have a unique identifier for = multi-valued attributes. By requiring this, a majority of the server = providers would have to start maintaining a unique key for each = multi-valued attribute. I believe this would be a roadblock for many = implementers. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> > When the SCIM protocol uses PATCH, there are areas where it = seems a bit clumsy. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I like the thoughts here. Your example reminds me of unified = diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are = commonly used with a patch program (pretty much the equivalent of the = PATCH verb). However, the three proposals seem to largely hinge on = being able to uniquely address each element within an object. Without = these it is not so easy to address each patch sub-operation (REPLACE, = INCLUDE, etc=85) or provide a multi-status. >>>>>=20 >>>>>=20 >>>>> The 207 response would be interesting to consider for the bulk = endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),= however. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> =20 >>>>>=20 >>>>> > There are other, non-data aspects of SCIM which may require = review, such as its synchronous request-response >>>>>=20 >>>>> > interaction model, which is a form of tight coupling and could = prove to be a source of brittleness. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I agree that we should explore optional asynchronous requests in = 2.0. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Thanks again for your thoughts. I hope you stay involved in the = discussion as work on SCIM 2.0 goes forward. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> --Kelly >>>>>=20 >>>>> =20 >>>>>=20 >>>>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On = Behalf Of Ganesh and Sashi Prasad >>>>> Sent: Wednesday, August 01, 2012 4:24 PM >>>>> To: scim@ietf.org >>>>> Subject: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>=20 >>>>> =20 >>>>>=20 >>>>> (I posted this on the SCIM Google Group, and I was advised to = subscribe to the mailing list and post it here instead, so here goes.) >>>>>=20 >>>>> =20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> My name is Ganesh Prasad, and my experience in Identity and Access = Management is mainly through a 3-year project at an Australian insurance = company, an experience I have written about as a eBook on InfoQ = (http://www.infoq.com/minibooks/Identity-Management-Shoestring). >>>>>=20 >>>>> =20 >>>>>=20 >>>>> I have been following the SCIM spec off and on, and based on my = experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 1. The enterprise client and the cloud provider should maintain = their own internal IDs for a resource, which they should not reveal to = each other. Both of them should map their internal IDs to a shared = External ID, and this is the only ID that should be exposed through the = API. The current specification's provision of an id (which is the = external ID and the only one to be transferred through the API) and an = "external ID" (which is the client's internal ID and should be hidden) = is diametrically opposite to this. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 2. When dealing with multi-valued attributes of a resource = (expressed as arrays in JSON), they must be converted from an array into = a dictionary with unique keys (UUIDs generated by the cloud provider = when the attribute is created). Without unique keys for every attribute = value of a resource, manipulating it will be clumsy and inelegant. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 3. The PATCH command can be improved in 3 significant ways: >>>>>=20 >>>>> 3a. Leverage the fact (from 2 above) that every value has a key, = to greatly simplify the API >>>>>=20 >>>>> 3b. Use special verbs as nested operations of the PATCH command to = add, modify and delete attributes at any level >>>>>=20 >>>>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of = "200 OK" as the response to a PATCH (or BULK) command. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> To elaborate, >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 1. Revealing private IDs externally is a form of tight coupling. A = major requirement with Identity Management is to split (or merge) = identities when false positives (or false negatives) are detected, i.e., = when a resource is discovered to be more than one, or when multiple = resources are detected to be the same. If internal identifiers are = revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its = internal ID to and external one created for this explicit purpose, and = only reveal this. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> In the SCIM case, when an enterprise client POSTs a resource = creation request, the cloud provider must generate its own internal UUID = as well as an external UUID, map them together, and only return the = external UUID in the "Location:" header. The enterprise client should = map this external UUID to a newly-generated internal ID of its own. In = case the resource already has an identifier within the enterprise = client's domain, then this is the internal ID that must be mapped to the = external UUID returned through the POST response. >>>>>=20 >>>>> =20 >>>>>=20 >>>>> 2. If a resource is to be created, and one of its attributes is = multi-valued, e.g., >>>>>=20 >>>>> =20 >>>>>=20 >>>>> "email-addrs" :=20 >>>>>=20 >>>>> [ >>>>>=20 >>>>> "john_smith@yahoo.com", >>>>>=20 >>>>> "john.smith@gmail.com", >>>>>=20 >>>>> "jsmith1970@hotmail.com" >>>>>=20 >>>>> < >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 --Apple-Mail=_E5774BB9-EB8B-4C7F-9CE7-F863B681FFBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 phil.hunt@oracle.com> = wrote:
By "own", I was implying = a possible scenario where a client assumes it knows everything it needs = to know about the state of the resource within a SP (because for example = only that client can change the resource).  Thus an owning client = could execute a PATCH operation on an attribute without a lot of errors = (missing values, non-existent attributes and other errors) because it = knows of the full state of the resource in the SP.

I = think your example nicely points out the complexity that is likely to = occur for service providers. At some point, full knowledge of "state" = for the provisioning clients isn't = realistic. 

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





On 2012-08-10, at 11:31 AM, Trey Drake wrote:


- A SP may augment the resource and not = expose the augmented info with the consumer.  
- Schema = is defined by the SP not the consumer
- A consumer may delete = a resource though the SP may simply "hide" it from future = requests

Thanks,
Trey

On Aug 10, 2012, at 11:48 AM, Phil Hunt <phil.hunt@oracle.com> = wrote:

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





On 2012-08-10, at 3:49 AM, Ganesh and Sashi Prasad = wrote:

>  I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. [...] IMHO loose coupling is a = much more complex = solution.

Phil,

I'm a bit = surprised that you're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my = experience.

I think we actually agree. = What I was saying is that for a sufficiently narrow scope model, tight = coupling is "simple". But in the long term it *may* turn out to be = "simplistic".  SCIM current seems to assume that an enterprise = can claim ownership of the entirety of the object being provisioned in = the cloud.  The enterprise has full knowledge of the resource in = the cloud.  Under that highly restricted definition, it is = simple.

The model is fine on a point-to-point = basis, but the higher-level provisioning "system" is more = complex.

I agree with Trey, externalID is = optional.  I also do not equate "externalID" with tight or loose = coupling. Yes, you can cause tight coupling, but that doesn't = necessarily follow. 

I look at it this = way: ObjectID is simply the ID asserted by the holder of the resource. =  ExternalID is an optional ID that is meaningful to a particular = client.   SAML has a similar = concept.


When I say "loose coupling", I mean = "no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

Let's not confuse = reduction of dependencies in the data model with a hub-and-spokes = architecture. They're entirely orthogonal aspects of the solution.

All that my suggestion involves = is,

1. Take 'external ID' out of the = protocol.
2. Allow generic search using 'GET /Users' and = arbitrary URI parameters

No planned functionality is lost by = this.

1. The client enterprise can still send = its internal ID as part of the resource body, inside some attribute = defined by them (but not defined by the protocol). Let's say they call = it 'myID'.
2. The client enterprise can search for resource URIs using any = attribute, including this internal ID
'GET = /Users?myID=3Dbjensen'
Since myID is a candidate key, the = server will return exactly one URI, which is the canonical URI for the = resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this =
URI to perform all other operations as usual.

So taking 'externalID' out =
of the protocol spec only does this:
1. It =
avoids enshrining tight coupling in the protocol (If clients want to =
tightly couple themselves to the cloud provider by sending their =
internal IDs, they can do so. Suicide is OK, but the protocol should not =
be guilty of assisted suicide. ;-)
2. It encourages loose =
coupling by nudging clients towards maintaining their own =
internal-to-external identifier mappings.

That's what I'd like to see. =
I don't believe this complicates the protocol. It simplifies it and it =
also lends itself to a loosely-coupled approach.

I'll address the =
multi-valued attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:


Phil

On = 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec = is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it.

I'm suggesting that the spec do less, not = more.

What the SCIM spec needs to do there is just refrain = from introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

Am I making = sense?

I see what you are saying. = I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The = reality is that each end-point has value to contribute and thus the = single-owner model will eventually need to become multi-owner or = multi-hub. 

That said i think the current model provides a = practical starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 

Precisely. The spec has to strike the right balance. It would = be interesting to hear from the other members of the spec mailing list. = You know where I stand on this. It would be good to hear the spectrum of = opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only = responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "a99a5feba839",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      = }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 

 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        = |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = },

      = {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      = }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of = SCIM, a key goal has been to foster adoption by service providers by = making things fit easily onto existing systems.  IMO the value = gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits = your requirements as it hides internal ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus = UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 = 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the = first.

1.      Why should domains not = expose their internal identifiers to other = domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued = attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain = are notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an = intelligent (but incorrect) guess that these two persons are the same, = and re-assign the same identifier to the second person. This is a false = positive. They appear to be the same entity, but they're actually different. When the error is discovered, the = identities will need to be split, with a new identifier generated for = one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique = identifiers. This is a false negative. They appear to be two entities, = but are actually the same. At a later stage, when the error is = discovered, the identities will have to be merged, and one of the identifiers will have to be = dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing = external identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some = convenient time (importantly, this doesn't have to be at the time the = split happens), Domain 2 can be requested to provision a second entity, = and when it responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the = second entity's internal identifier.

The = mapping table now contains the following = entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and = drops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to look up the translation table to = determine the =93primary=94 external ID for this entity in Domain 2, = which was decided to be =93ff487230b3a0=94. That's where the =93Primary = flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound = communication.

At = some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is = acknowledged.

This = scheme will scale up to multiple domains, because the =93External Domain = ID=94 column helps to keep track of which external ID is shared with = which Domain. (Why don't we use just one external ID for an entity and share it with all external = domains? Tight coupling again. Just as OAuth allows an access token = given to a third party to be invalidated without affecting the access of = other third parties, the use of separate external identifiers for different domains allows fine-grained control of = identity federation.)

The = scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many John Smiths there are who were born = on 1 Jan 1970!)

This = is a fairly long-winded explanation, but this is why we need to hide = internal identifiers from other domains, and why mappings need to be = managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for = propagation of identity events, since there is no consistency = requirement to update multiple domains = concurrently.

Regards,

Ganesh= Prasad

 

On 9 August 2012 04:55, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Thanks for the feedback, Ganesh.  I read = through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitation= s) and have some thoughts.

 

> The rest of the protocol does not meaningfully = use the enterprise client=92s identifier, the "external = ID"

> at all, even though it was ostensibly = introduced to make things friendlier for the = client.

 

The usage pattern for an external ID would be to = search for a user by externalId and use the ID of the returned user in any desired operation.  For = example:

 

GET /Users?filter=3DexternalId eq = =93bjensen=94&attributes=3Did

 

{

  =93totalResults=94: = 1,

  =93Resources=94: = [

    {

      =93id=94: = =932819c223-7f76-453a-919d-413861904646=94

    }

  ]

}

 

Retrieve the ID from the response and use = it.

 

DELETE = /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if = the client chooses not to store the server=92s id.  An issue was created to consider allowing operations to use the = externalId (http://code.google.com/p/scim/issues/detail?id=3D35<= span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1f497d">), but I believe the general consensus has been to not include this in the = spec.  One main point of contention is that much of the rest of the = spec (eg =96 group membership references, manager references, etc=85) = require knowledge of the server=92s identifier.  Continuing this discussion on the IETF list would be a good thing, = though.

 

 

> the cloud provider's ID and the enterprise = client's ID are both "Internal IDs" with respect to their = domains

 

I think this comes down to a nomenclature = problem.  The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it = just has to be stable and unique.  In many cases, the underlying = identity store will provide identifiers with these properties already = (eg =96 a uuid) and it can be used by the SCIM interface.  The =93externalId=94 is referring to the fact that the id is maintained = external to the SCIM server.  As long as the server=92s identifiers = are stable and unique (which is mandated by the spec), I don=92t see a = problem.

 

 

> The secret is that every value needs a = key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or array (of = values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free = identifier.

 

I agree that this would be useful, especially in = the PATCH operation.  One reason that this wasn=92t included in the spec originally is that it can put undue burden on the = service provider.  Many service providers are putting SCIM = interfaces in front of their existing identity stores (eg =96 directory = servers, SaaS application databases, etc=85).  Many of these do not have a unique identifier for multi-valued attributes.  By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I = believe this would be a roadblock for many = implementers.

 

 

> When the SCIM protocol uses PATCH, there are = areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example = reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the = equivalent of the PATCH verb).  However, the three proposals seem = to largely hinge on being able to uniquely address each element within = an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a = multi-status.


The 207 response would be interesting to consider for the bulk endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html= #bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which = may require review, such as its synchronous = request-response

> interaction model, which is a form of tight = coupling and could prove to be a source of = brittleness.

 

I agree that we should explore optional = asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you = stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for = improvement

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, = so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience = in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoes= tring).

 

I have been following the SCIM spec off and = on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud = provider should maintain their own internal IDs for a resource, which = they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that = should be exposed through the API. The current specification's provision = of an id (which is the external ID and the only one to be transferred = through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically = opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from = an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique = keys for every attribute value of a resource, manipulating it will be = clumsy and inelegant.

 

3. The PATCH command can be improved in 3 = significant ways:

3a. Leverage the fact (from 2 above) that = every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations = of the PATCH command to add, modify and delete attributes at any = level

3c. Use the WebDAV status code of "207 = Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) = command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is = to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, = or when multiple resources are detected to be the same. If internal = identifiers are revealed to external domains, such clean-ups become = difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one = created for this explicit purpose, and only reveal = this.

 

In the SCIM case, when an enterprise client = POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The = enterprise client should map this external UUID to a newly-generated = internal ID of its own. In case the resource already has an identifier = within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned = through the POST response.

 

2. If a resource is to be created, and one = of its attributes is multi-valued, e.g.,

 

    "email-addrs" = : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

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

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

___________= ____________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim

_____= __________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/m= ailman/listinfo/scim


= --Apple-Mail=_E5774BB9-EB8B-4C7F-9CE7-F863B681FFBA-- From prateek.mishra@oracle.com Fri Aug 10 12:46:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3E21F86C8 for ; Fri, 10 Aug 2012 12:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGLTa1DQSQb2 for ; Fri, 10 Aug 2012 12:46:10 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 921BE21F86C7 for ; Fri, 10 Aug 2012 12:46:10 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7AJk8JW010451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Aug 2012 19:46:08 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7AJk75q018379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Aug 2012 19:46:07 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7AJk6VL023603 for ; Fri, 10 Aug 2012 14:46:06 -0500 Received: from [192.168.2.2] (/66.31.108.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 12:46:06 -0700 Message-ID: <502564FD.7050102@oracle.com> Date: Fri, 10 Aug 2012 15:46:05 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> <411B68AE-A698-4DFE-9D35-1D4D5857528C@unboundid.com> In-Reply-To: <411B68AE-A698-4DFE-9D35-1D4D5857528C@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [scim] Where are the remaining SCIM 1.1 IETF drafts? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:46:11 -0000 I could only find Phil Hunt's draft document at - http://datatracker.ietf.org/wg/scim/ From trey.drake@unboundid.com Fri Aug 10 12:51:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09EE11E809A for ; Fri, 10 Aug 2012 12:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBbXTd9BWbHl for ; Fri, 10 Aug 2012 12:51:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA0BA11E8099 for ; Fri, 10 Aug 2012 12:51:37 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3112069obb.31 for ; Fri, 10 Aug 2012 12:51:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=2UDq3XYNXo7bnceK8nUX4nlqprtDSP/EGKE9VVR8e/k=; b=oN+Pi1iq9frQrixS7OTcOnrW/5RZFkbKgUGjHfxG5eQrSnqD2mdFoWWY5bDvg2hRGj 0SS3Bw9V59N5csZcdb+y2CuKenuGF9uNqTWYhjGAZSw7PRX33yTZ7T0dnHEdvkHDer9q KP9JQEXOtu/qENtLdzMCCQAjWkvTrli9Aagz1/PEsiW1GDwZAmQ99Jvp4jJqSfH0SOsG j33D2vZXYhUiefeqvMUlYnYKgaOmN/qqBW0l9djesX2MLjE45NlQEFURVQoEnnfJATTU zHgMege9nCwFYoYd0Wg7z2RermKQxQofJsxK3uwvXOJwMJ8/k7fVKusmXmpIuE8TTsqH Uuew== Received: by 10.60.12.234 with SMTP id b10mr5586214oec.72.1344628296900; Fri, 10 Aug 2012 12:51:36 -0700 (PDT) Received: from [192.168.241.66] (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id m7sm3106869oef.1.2012.08.10.12.51.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 12:51:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: <502564FD.7050102@oracle.com> Date: Fri, 10 Aug 2012 14:51:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> <411B68AE-A698-4DFE-9D35-1D4D5857528C@unboundid.com> <502564FD.7050102@oracle.com> To: prateek mishra X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQnkESZujwK5FPo0xfT3kkyxf+n7PUYoCNf7ZGAGzE/5JtomfKrljVsJ4lwmFVP6jX87p2Kk Cc: scim@ietf.org Subject: Re: [scim] Where are the remaining SCIM 1.1 IETF drafts? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 19:51:40 -0000 Core schema is here: = https://datatracker.ietf.org/doc/draft-scim-core-schema/ I suppose the API is still making its way through the manual submission = process. It was submitted. On Aug 10, 2012, at 2:46 PM, prateek mishra = wrote: > I could only find Phil Hunt's draft document at - >=20 > http://datatracker.ietf.org/wg/scim/ >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Fri Aug 10 15:17:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B1A11E8091 for ; Fri, 10 Aug 2012 15:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJjb3HIfEYt4 for ; Fri, 10 Aug 2012 15:17:46 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 70ABF11E808D for ; Fri, 10 Aug 2012 15:17:46 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7AMHjVx005901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 10 Aug 2012 17:17:45 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7AMHiQZ029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 10 Aug 2012 17:17:44 -0500 Received: from [135.244.0.7] (faynberg.lra.lucent.com [135.244.0.7]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7AMHfgL003582; Fri, 10 Aug 2012 17:17:42 -0500 (CDT) Message-ID: <50258885.7000503@alcatel-lucent.com> Date: Fri, 10 Aug 2012 18:17:41 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <20120810153522.17C6A21F8783@ietfa.amsl.com> In-Reply-To: <20120810153522.17C6A21F8783@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060607020304010005070107" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:17:47 -0000 This is a multi-part message in MIME format. --------------060607020304010005070107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit +1 Igor On 8/10/2012 11:35 AM, Diodati,Mark wrote: > > Hi Ganesh, > > I am concerned about your second suggestion: > > "2. When dealing with multi-valued attributes of a resource (expressed > as arrays in JSON), they must be converted from an array into a > dictionary with unique keys (UUIDs generated by the cloud provider > when the attribute is created). Without unique keys for every > attribute value of a resource, manipulating it will be clumsy and > inelegant." > > One of the primary reasons that SPML failed was lack of adoption by > service providers due to its complexity. Very few target applications > implemented SPML. Most of the commercial provisioning systems had an > SPML interface (either v1 or v2), but not one of them was conformant > to the SPML standard because of complexity. If you are interested, I > will forward you the research documents that discuss these problems in > detail. For SCIM to be successful, it must be adopted by commercial > target applications (i.e., service providers). I am confident that a > requirement for unique identifiers with multi-valued attributes will > preclude its adoption, because it requires major changes to the > service provider's existing identity storage mechanisms. > > Mark > > *From:*Trey Drake [mailto:trey.drake@unboundid.com] > *Sent:* Friday, August 10, 2012 9:51 AM > *To:* Ganesh and Sashi Prasad > *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Ganesh, > > I'll base my comments on your latest reply (below). > > The externalID is not part of the protocol. It is an *optional* > attribute within the *schema* specification. As for #2, the protocol > spec works as you describe if "arbitrary URI parameters" equate to > resource attributes (Allow generic search using 'GET /Users' and > arbitrary URI parameters). Please clarify your suggestion. > > I'm not tracking your coupling concern. The client can search and > hence retrieve resources on any attribute it chooses, externalId or > otherwise. Nothing mandates use of externalId. > > What do you mean by "candidate key"? Given > > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > > wrote: > > > I think scim gets its current simplicity from its single owner hub > spoke model implementing tight coupling. [...] IMHO loose coupling is > a much more complex solution. > > Phil, > > I'm a bit surprised that you're implying "tight coupling == simple" > and "loose coupling == complex". That's contrary to my experience. > > When I say "loose coupling", I mean "no unnecessary dependencies". > Invariably, a reduction in dependencies leads to greater simplicity. > > Let's not confuse reduction of dependencies in the data model with a > hub-and-spokes architecture. They're entirely orthogonal aspects of > the solution. > > All that my suggestion involves is, > > 1. Take 'external ID' out of the protocol. > > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters > > No planned functionality is lost by this. > > 1. The client enterprise can still send its internal ID as part of the > resource body, inside some attribute defined by them (but not defined > by the protocol). Let's say they call it 'myID'. > > 2. The client enterprise can search for resource URIs using any > attribute, including this internal ID > > 'GET /Users?myID=bjensen' > > Since myID is a candidate key, the server will return exactly one URI, > which is the canonical URI for the resource > > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > 3. The client can use this URI to perform all other operations as usual. > > So taking 'externalID' out of the protocol spec only does this: > 1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-) > 2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings. > > That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach. > > I'll address the multi-valued attribute suggestion separately. > > Regards, > Ganesh > > > > > On 10 August 2012 07:53, Phil Hunt > wrote: > > > > Phil > > > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > > > storing this information in a mapping table outside of the SCIM > spec is a great way to enable this solution. Part of the key here > is that SCIM is just a piece of the architecture for this > solution, and is only responsible for the transport layer between > domains. > > I wasn't suggesting that the mapping table be part of the SCIM > spec. I provided that example to illustrate that splitting and > merging identities is a common requirement, and that decoupling > local identifiers within a domain from shared identifiers between > domains was the best way to facilitate it. > > I'm suggesting that the spec do less, not more. > > What the SCIM spec needs to do there is just refrain from > introducing tight coupling. I would like to see a single > identifier exposed through the API, with the implication (and > perhaps the recommendation) that it be the shared one. Allowing > one domain to expose its internal identifier to the other creates > tight coupling and ensures that both domains need simultaneously > split or merge identities, which is not desirable. So I recommend > _taking out_ the "external id" field from the API. The spec > shouldn't encourage tight coupling. If clients want to pass in > their internal ids as part of the resource body, no one can stop > them, and they can always do a search on that attribute to > retrieve the URI exactly as you visualise they will with the > "external id", but let's not elevate an anti-pattern to a > recommendation by enshrining the "external id" as an acceptable > attribute. > > Am I making sense? > > I see what you are saying. I think scim gets its current simplicity > from its single owner hub spoke model implementing tight coupling. > > IMHO loose coupling is a much more complex solution. The reality is > that each end-point has value to contribute and thus the single-owner > model will eventually need to become multi-owner or multi-hub. > > That said i think the current model provides a practical starting point. > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. > On the other hand it puts extra burden on service providers. > > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. > You know where I stand on this. It would be good to hear the spectrum > of opinions. > > Regards, > > Ganesh > > On 10 August 2012 00:28, Kelly Grizzle > wrote: > > Thanks Emmanuel. I had started writing up a similar response. As you > suggest, storing this information in a mapping table outside of the > SCIM spec is a great way to enable this solution. Part of the key > here is that SCIM is just a piece of the architecture for this > solution, and is only responsible for the transport layer between domains. > > You could also model these ID mappings in the SCIM user as an > extension but would probably not want to expose these externally. > Here is an example of how to model the end state of the false positive > scenario (splitting a user): > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | > true | > > This could be represented as two SCIM users that contain information > about the entities on other domains. > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > } > > ] > > } > > } > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "a99a5feba839", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "7a87f27c1dd8" > > } > > ] > > } > > } > > In the second user, the linkedUsers attribute would be empty until the > split user was synced to domain 2. > > Similarly, the false negative use case (merging two users) looked like > this at the end: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | > false | > > This could be represented with the following SCIM user: > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > }, > > { > > "domain": "D2", > > "externalEntityId": "41206cc97c8b", > > "deletionRequired": true > > } > > ] > > } > > } > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. > On the other hand it puts extra burden on service providers. Since > the inception of SCIM, a key goal has been to foster adoption by > service providers by making things fit easily onto existing systems. > IMO the value gained by unique identifiers for multi-valued attributes > is not worth the demands put on a service provider. I also think that > vendors that have a non-SCIM-compliant API will choose to keep things > that way if the spec is too hard for them to implement. In a green > field environment we do have the luxury of mandating a model to make > certain operations more elegant. However, we can't ignore legacy > systems. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Ganesh, > > Nothing prevents you in your SCIM implementation (client or server) to > generate a unique identifier for each synchronized object and maintain > an internal mapping table ( you would have to map group membership as > well). > > This is what we are doing with Active Directory sources or targets: > > As we didn't find an immutable uniqueID in AD systems > (DN,samAccountName, UPN) are subject to change (even objectGuid can > change if an AD domain is migrated), we decided to generate and > maintain an internal table of ids. This fits your requirements as it > hides internal ids. > > This was written in dotnet and we have started a project to rewrite > our SCIM stack in PHP and will give it to the Open Source community. > This implementation will have a parameter : AllocateIds versus > UseExistingIDs. > > This will give the choice of "hiding" internalIDs or use them as > unique ID. > > You can also implement such feature without violating the SCIM specs, > or without asking to include it in the specs. > > -- > > Regards, > > Emmanuel Dreux > > http://www.cloudiway.com > > Tel: +33 4 26 78 17 58 > > Mobile: +33 6 47 81 26 70 > > skype: Emmanuel.Dreux > > *De :*Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoyé :* jeudi 9 août 2012 03:35 > *À :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Kelly, > > Thanks for your response. Let me first respond in brief to the two > main points you have made, and then elaborate on the first. > > 1.Why should domains not expose their internal identifiers to other > domains? > > a. > > We are designing a protocol for a federated system of domains, where > all domains are co-equal peers. (In physics too, N-body problems are > much harder than 2-body problems. :-) Therefore, assuming that there > are only two players in the interaction makes this tightly coupled in > a number of ways. We should rely on messaging and notification, with > encapsulation of domain-specific data. > > b. > > In any non-trivial data store, there will always be the ongoing need > to merge and split identities as and when "false negatives" and "false > positives" are discovered. A domain should be able to handle this > internal housekeeping freely, only notifying other domains when > convenient. Mapping of internal identifiers to external ones and > maintaining this mapping internally allows this loosely-coupled > housekeeping to take place. Sharing internal identifiers (or otherwise > outsourcing the mapping of internal to external identifiers) forces > housekeeping activities to be done in lock-step across domains. > > c. > > Asynchronous interaction is not just a matter of a suitable wire > protocol which can be designed later. The data model plays a crucial > role in enabling or constraining such interaction. A tightly-coupled > data model will force the use of synchronous interactions, and the > exposure of internal identifiers is a key part of this tight coupling. > > 2. The difficulty of assigning unique identifiers to the individual > values of multi-valued attributes: > > a. > > I'm not belittling the effort involved in migrating legacy data stores > to such a model. However, in the larger historical context of > cross-domain identity management, we are really at the very early > stages. If a relatively new discipline and a brand new spec are held > captive to legacy considerations, we are losing an opportunity to > provide a clean and elegant model to subsequent users of the spec, and > this will have repercussions over many years or even decades. > > b. > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can > transition to this model by offering both "SCIM-compliant" and > "non-SCIM-compliant" APIs to their customers and encouraging new > customers to adopt the "SCIM-compliant" API. Legacy customers can be > supported using a "non-SCIM-compliant" API for an arbitrarily long > period and gradually migrated to the SCIM-compliant API. The logistics > are not insurmountable, and shouldn't prevent the adoption of a > dictionary model for multi-valued attributes. > > Elaboration of Point 1: > > When we consider federated identity across more than one domain, we > have to assume that domains are not necessarily master-slave in their > interaction. The most generic interaction model is peer-to-peer, where > entity lifecycle events within a domain are notified to other domains > (when necessary) in an asynchronous manner (i.e., through messaging) > and the other domains are free to respond to these events in an > appropriate manner and at a time of their convenience. > > A key set of lifecycle events for an entity is the merging and > splitting of identity that is often required. > > The question "Is this one entity?" can be answered either yes > (positive) or no (negative). But sometimes, we can discover false > positives and false negatives in our data stores. > > Consider a case where customers sign up online, and two customers who > are privacy-conscious enter fake IDs such as "John Smith", and also > use the same date of birth (say, 1 Jan 1970) or similar attributes. > The front-end application may make an intelligent (but incorrect) > guess that these two persons are the same, and re-assign the same > identifier to the second person. This is a false positive. They appear > to be the same entity, but they're actually different. When the error > is discovered, the identities will need to be split, with a new > identifier generated for one of them. > > Consider the opposite case where a customer signs up through two > different portals or in two different sessions, using the names > "JSmith" and "JohnS". It is very likely that they will be treated as > two different customers and assigned two unique identifiers. This is a > false negative. They appear to be two entities, but are actually the > same. At a later stage, when the error is discovered, the identities > will have to be merged, and one of the identifiers will have to be > dropped. > > These are not theoretical use cases. They form a significant > proportion of the user base in most large Web-facing applications. > Let's see how these can be managed in a federated way by mapping > internal identifiers to external ones and only exposing external > identifiers to other domains. > > a. False positives: > > Domain 1 has the following information about a customer in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > When requesting the provisioning of this entity in Domain 2, the > following ID is returned by Domain 2: ff487230b3a0. > > Domain 1 then maintains the following in a mapping table and uses it > for translation when talking to Domain 2, taking care never to expose > its internal identifier: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > When the false positive is discovered and the entity is split, Domain > 1 creates a new internal identifier and now has the following entity > information. > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > Internal ID: a99a5feba839 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > This second entity with its own internal identifier is invisible to > Domain 2, and this is by design. Communication about the original > entity takes place as before by mapping "9caf78aac3d6" to > "ff487230b3a0" and vice-versa. At some convenient time (importantly, > this doesn't have to be at the time the split happens), Domain 2 can > be requested to provision a second entity, and when it responds with > an identifier of "7a87f27c1dd8", this can go into the mapping table as > a new record associated with the second entity's internal identifier. > > The mapping table now contains the following entries: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > > Domain 2 is not even aware that a split has happened, and the > provisioning that it does is not in lockstep with the split in > identity that occurred in Domain 1. > > (What is the "Primary flag" used for? We'll see when we cover the > treatment of false negatives.) > > b. False negatives: > > Domain 1 has the following information about what it thinks are two > distinct customers in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "JSmith", dob: "01-Jan-1970"} > > Internal ID: 273d36e30d09 > > Attributes: {name: "JohnS", dob: "01-Jan-1970"} > > When requesting the provisioning of these entities in Domain 2, the > following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > > Domain 1 then maintains the following in a mapping table and uses it > for translation when talking to Domain 2, taking care never to expose > its internal identifiers: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 273d36e30d09 | D2 | 41206cc97c8b | true | > > When the false negative is discovered and the two entities are merged, > Domain 1 drops one of the internal identifiers and rationalises the > name of the customer (say, to "John Smith"). Let's say it retains the > first ID "9caf78aac3d6" and drops the second "273d36e30d09". > > The mapping table now looks like this: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > > Now two external identifiers map to the same internal one, so inbound > communication from Domain 2 can be unambiguously translated to the > same entity internally. However, when going outwards, Domain 1 will > have to look up the translation table to determine the "primary" > external ID for this entity in Domain 2, which was decided to be > "ff487230b3a0". That's where the "Primary flag" comes in. The second > external ID "41206cc97c8b" is never used thereafter in outbound > communication. > > At some stage (importantly, not in lockstep with the identity merge), > Domain 2 can be requested to delete the customer record identified by > "41206cc97c8b", and the second entry in the mapping table can be > removed once this is acknowledged. > > This scheme will scale up to multiple domains, because the "External > Domain ID" column helps to keep track of which external ID is shared > with which Domain. (Why don't we use just one external ID for an > entity and share it with all external domains? Tight coupling again. > Just as OAuth allows an access token given to a third party to be > invalidated without affecting the access of other third parties, the > use of separate external identifiers for different domains allows > fine-grained control of identity federation.) > > The scheme also allows the splitting of an entity into more than two > entities, and the merging of more than two entities into a single one. > (Any organisation with a web-facing application will tell you how many > John Smiths there are who were born on 1 Jan 1970!) > > This is a fairly long-winded explanation, but this is why we need to > hide internal identifiers from other domains, and why mappings need to > be managed internally in each domain. Such a data model also allows us > to choose asynchronous protocols for propagation of identity events, > since there is no consistency requirement to update multiple domains > concurrently. > > Regards, > > Ganesh Prasad > > On 9 August 2012 04:55, Kelly Grizzle > wrote: > > Thanks for the feedback, Ganesh. I read through this and your InfoQ > article (http://www.infoq.com/articles/scim-data-model-limitations) > and have some thoughts. > > > The rest of the protocol does not meaningfully use the enterprise > client's identifier, the "external ID" > > > at all, even though it was ostensibly introduced to make things > friendlier for the client. > > The usage pattern for an external ID would be to search for a user by > externalId and use the ID of the returned user in any desired > operation. For example: > > GET /Users?filter=externalId eq "bjensen"&attributes=id > > { > > "totalResults": 1, > > "Resources": [ > > { > > "id": "2819c223-7f76-453a-919d-413861904646" > > } > > ] > > } > > Retrieve the ID from the response and use it. > > DELETE /Users/2819c223-7f76-453a-919d-413861904646 > > This does introduce an additional HTTP request if the client chooses > not to store the server's id. An issue was created to consider > allowing operations to use the externalId > (http://code.google.com/p/scim/issues/detail?id=35), but I believe the > general consensus has been to not include this in the spec. One main > point of contention is that much of the rest of the spec (eg -- group > membership references, manager references, etc...) require knowledge > of the server's identifier. Continuing this discussion on the IETF > list would be a good thing, though. > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains > > I think this comes down to a nomenclature problem. The server's ID > does not necessarily have to be the unique identifier that the > underlying identity store uses, it just has to be stable and unique. > In many cases, the underlying identity store will provide identifiers > with these properties already (eg -- a uuid) and it can be used by the > SCIM interface. The "externalId" is referring to the fact that the id > is maintained external to the SCIM server. As long as the server's > identifiers are stable and unique (which is mandated by the spec), I > don't see a problem. > > > The secret is that /every value needs a key/, and multi-valued > attributes lack that. So our solution is quite > > > simple - turn every list or array (of values) into a dictionary (of > key-value pairs) by providing each value > > > with a unique and meaning-free identifier. > > I agree that this would be useful, especially in the PATCH operation. > One reason that this wasn't included in the spec originally is that it > can put undue burden on the service provider. Many service providers > are putting SCIM interfaces in front of their existing identity stores > (eg -- directory servers, SaaS application databases, etc...). Many > of these do not have a unique identifier for multi-valued attributes. > By requiring this, a majority of the server providers would have to > start maintaining a unique key for each multi-valued attribute. I > believe this would be a roadblock for many implementers. > > > When the SCIM protocol uses PATCH, there are areas where it seems a > bit clumsy. > > I like the thoughts here. Your example reminds me of unified diffs > (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly > used with a patch program (pretty much the equivalent of the PATCH > verb). However, the three proposals seem to largely hinge on being > able to uniquely address each element within an object. Without these > it is not so easy to address each patch sub-operation (REPLACE, > INCLUDE, etc...) or provide a multi-status. > > > The 207 response would be interesting to consider for the bulk > endpoint > (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however. > > > There are other, non-data aspects of SCIM which may require review, > such as its synchronous request-response > > > interaction model, which is a form of tight coupling and could prove > to be a source of brittleness. > > I agree that we should explore optional asynchronous requests in 2.0. > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement > > (I posted this on the SCIM Google Group, and I was advised to > subscribe to the mailing list and post it here instead, so here goes.) > > Hi, > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian > insurance company, an experience I have written about as a eBook on > InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoestring). > > I have been following the SCIM spec off and on, and based on my > experience with a loosely-coupled architecture that I found to be > successful, I have the following 3 suggestions to make. > > 1. The enterprise client and the cloud provider should maintain their > own internal IDs for a resource, which they should not reveal to each > other. Both of them should map their internal IDs to a shared External > ID, and this is the only ID that should be exposed through the API. > The current specification's provision of an id (which is the external > ID and the only one to be transferred through the API) and an > "external ID" (which is the client's internal ID and should be hidden) > is diametrically opposite to this. > > 2. When dealing with multi-valued attributes of a resource (expressed > as arrays in JSON), they must be converted from an array into a > dictionary with unique keys (UUIDs generated by the cloud provider > when the attribute is created). Without unique keys for every > attribute value of a resource, manipulating it will be clumsy and > inelegant. > > 3. The PATCH command can be improved in 3 significant ways: > > 3a. Leverage the fact (from 2 above) that every value has a key, to > greatly simplify the API > > 3b. Use special verbs as nested operations of the PATCH command to > add, modify and delete attributes at any level > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 > OK" as the response to a PATCH (or BULK) command. > > To elaborate, > > 1. Revealing private IDs externally is a form of tight coupling. A > major requirement with Identity Management is to split (or merge) > identities when false positives (or false negatives) are detected, > i.e., when a resource is discovered to be more than one, or when > multiple resources are detected to be the same. If internal > identifiers are revealed to external domains, such clean-ups become > difficult, hence every domain that wants to expose references to a > resource must map its internal ID to and external one created for this > explicit purpose, and only reveal this. > > In the SCIM case, when an enterprise client POSTs a resource creation > request, the cloud provider must generate its own internal UUID as > well as an external UUID, map them together, and only return the > external UUID in the "Location:" header. The enterprise client should > map this external UUID to a newly-generated internal ID of its own. In > case the resource already has an identifier within the enterprise > client's domain, then this is the internal ID that must be mapped to > the external UUID returned through the POST response. > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g., > > "email-addrs" : > > [ > > "john_smith@yahoo.com ", > > "john.smith@gmail.com ", > > "jsmith1970@hotmail.com " > > < > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > ------------------------------------------------------------------------ > > This e-mail message, including any attachments, is for the sole use of > the person to whom it has been sent, and may contain information that > is confidential or legally protected. If you are not the intended > recipient or have received this message in error, you are not > authorized to copy, distribute, or otherwise use this message or its > attachments. Please notify the sender immediately by return e-mail and > permanently delete this message and any attachments. Gartner makes no > warranty that this e-mail is error or virus free. > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------060607020304010005070107 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Igor

On 8/10/2012 11:35 AM, Diodati,Mark wrote:

Hi Ganesh,

 

I am concerned about your second suggestion:

“2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.”

 

One of the primary reasons that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v1 or v2), but not one of them was conformant to the SPML standard because of complexity. If you are interested, I will forward you the research documents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial target applications (i.e., service providers). I am confident that a requirement for unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes to the service provider’s existing identity storage mechanisms.

Mark

 

 

 

From: Trey Drake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM
To: Ganesh and Sashi Prasad
Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below).  

 

The externalID is not part of the protocol.  It is an *optional* attribute within the *schema* specification.  As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clarify your suggestion.

 

I'm not tracking your coupling concern.  The client can search and hence retrieve resources on any attribute it chooses, externalId or otherwise.  Nothing mandates use of externalId.   

 

 

What do you mean by "candidate key"?  Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. [...] IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight coupling == simple" and "loose coupling == complex". That's contrary to my experience.

 

When I say "loose coupling", I mean "no unnecessary dependencies". Invariably, a reduction in dependencies leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the data model with a hub-and-spokes architecture. They're entirely orthogonal aspects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbitrary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal ID as part of the resource body, inside some attribute defined by them (but not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URIs using any attribute, including this internal ID

'GET /Users?myID=bjensen'

Since myID is a candidate key, the server will return exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other operations as usual.
 
So taking 'externalID' out of the protocol spec only does this:
1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings.
 
That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach.
 
I'll address the multi-valued attribute suggestion separately.
 
Regards,
Ganesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provided that example to illustrate that splitting and merging identities is a common requirement, and that decoupling local identifiers within a domain from shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain from introducing tight coupling. I would like to see a single identifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight coupling and ensures that both domains need simultaneously split or merge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their internal ids as part of the resource body, no one can stop them, and they can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. 

 

IMHO loose coupling is a much more complex solution. The reality is that each end-point has value to contribute and thus the single-owner model will eventually need to become multi-owner or multi-hub. 

 

That said i think the current model provides a practical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting to hear from the other members of the spec mailing list. You know where I stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains.

 

You could also model these ID mappings in the SCIM user as an extension but would probably not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| a99a5feba839       | D2                 | 7a87f27c1dd8       | true         |

 

This could be represented as two SCIM users that contain information about the entities on other domains.

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

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

  "id": "a99a5feba839",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the linkedUsers attribute would be empty until the split user was synced to domain 2.

 

 

Similarly, the false negative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| 9caf78aac3d6       | D2                 | 41206cc97c8b       | false        |

 

This could be represented with the following SCIM user:

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      },

      {

        "domain": "D2",

        "externalEntityId": "41206cc97c8b",

        "deletionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a key goal has been to foster adoption by service providers by making things fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that vendors that have a non-SCIM-compliant API will choose to keep things that way if the spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can’t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation (client or server) to generate a unique identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing with Active Directory sources or targets:

As we didn’t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits your requirements as it hides internal ids.

 

This was written in dotnet and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice of “hiding” internalIDs or use them as unique ID.

 

You can also implement such feature without violating the SCIM specs, or without asking to include it in the specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoyé : jeudi 9 août 2012 03:35
À : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Kelly,

Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first.

1.      Why should domains not expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when “false negatives” and “false positives” are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling.

2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both “SCIM-compliant” and “non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers can be supported using a “non-SCIM-compliant” API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is the merging and splitting of identity that is often required.

The question “Is this one entity?” can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as “John Smith”, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names “JSmith” and “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.

a. False positives:

Domain 1 has the following information about a customer in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information.

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

Internal ID: a99a5feba839

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's internal identifier.

The mapping table now contains the following entries:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1.

(What is the “Primary flag” used for? We'll see when we cover the treatment of false negatives.)

b. False negatives:

Domain 1 has the following information about what it thinks are two distinct customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “JSmith”, dob: “01-Jan-1970”}

Internal ID: 273d36e30d09

Attributes: {name: “JohnS”, dob: “01-Jan-1970”}

When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 273d36e30d09 | D2 | 41206cc97c8b | true |

When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the second “273d36e30d09”.

The mapping table now looks like this:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambiguously translated to the same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to determine the “primary” external ID for this entity in Domain 2, which was decided to be “ff487230b3a0”. That's where the “Primary flag” comes in. The second external ID “41206cc97c8b” is never used thereafter in outbound communication.

At some stage (importantly, not in lockstep with the identity merge), Domain 2 can be requested to delete the customer record identified by “41206cc97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

This scheme will scale up to multiple domains, because the “External Domain ID” column helps to keep track of which external ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling again. Just as OAuth allows an access token given to a third party to be invalidated without affecting the access of other third parties, the use of separate external identifiers for different domains allows fine-grained control of identity federation.)

The scheme also allows the splitting of an entity into more than two entities, and the merging of more than two entities into a single one. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This is a fairly long-winded explanation, but this is why we need to hide internal identifiers from other domains, and why mappings need to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of identity events, since there is no consistency requirement to update multiple domains concurrently.

Regards,

Ganesh Prasad

 

On 9 August 2012 04:55, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not meaningfully use the enterprise client’s identifier, the "external ID"

> at all, even though it was ostensibly introduced to make things friendlier for the client.

 

The usage pattern for an external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.  For example:

 

GET /Users?filter=externalId eq “bjensen”&attributes=id

 

{

  “totalResults”: 1,

  “Resources”: [

    {

      “id”: “2819c223-7f76-453a-919d-413861904646”

    }

  ]

}

 

Retrieve the ID from the response and use it.

 

DELETE /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if the client chooses not to store the server’s id.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/detail?id=35), but I believe the general consensus has been to not include this in the spec.  One main point of contention is that much of the rest of the spec (eg – group membership references, manager references, etc…) require knowledge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterprise client's ID are both "Internal IDs" with respect to their domains

 

I think this comes down to a nomenclature problem.  The server’s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the underlying identity store will provide identifiers with these properties already (eg – a uuid) and it can be used by the SCIM interface.  The “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server’s identifiers are stable and unique (which is mandated by the spec), I don’t see a problem.

 

 

> The secret is that every value needs a key, and multi-valued attributes lack that. So our solution is quite

> simple - turn every list or array (of values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free identifier.

 

I agree that this would be useful, especially in the PATCH operation.  One reason that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are putting SCIM interfaces in front of their existing identity stores (eg – directory servers, SaaS application databases, etc…).  Many of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers would have to start maintaining a unique key for each multi-valued attribute.  I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, there are areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of the PATCH verb).  However, the three proposals seem to largely hinge on being able to uniquely address each element within an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-status.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which may require review, such as its synchronous request-response

> interaction model, which is a form of tight coupling and could prove to be a source of brittleness.

 

I agree that we should explore optional asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for improvement

 

(I posted this on the SCIM Google Group, and I was advised to subscribe to the mailing list and post it here instead, so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience in Identity and Access Management is mainly through a 3-year project at an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoestring).

 

I have been following the SCIM spec off and on, and based on my experience with a loosely-coupled architecture that I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider should maintain their own internal IDs for a resource, which they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should be exposed through the API. The current specification's provision of an id (which is the external ID and the only one to be transferred through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significant ways:

3a. Leverage the fact (from 2 above) that every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tight coupling. A major requirement with Identity Management is to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the same. If internal identifiers are revealed to external domains, such clean-ups become difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one created for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client POSTs a resource creation request, the cloud provider must generate its own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated internal ID of its own. In case the resource already has an identifier within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its attributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

< 

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

 


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

 



This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.
 

_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------060607020304010005070107-- From g.c.prasad@gmail.com Fri Aug 10 15:39:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611C611E80AD for ; Fri, 10 Aug 2012 15:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nbw5AFB5bjbs for ; Fri, 10 Aug 2012 15:39:05 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8548211E80BA for ; Fri, 10 Aug 2012 15:38:58 -0700 (PDT) Received: by bkty7 with SMTP id y7so862686bkt.31 for ; Fri, 10 Aug 2012 15:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Kx8p+fq6e5EYwUUyUw8q6tjz2psnwU67NF/MxXUKiTc=; b=TAurlUJ9bAdb8JWrp08JxtavzEuJcgWxdO1Q0Z1OIhYfe8zbwVXXwOOe1fdGUILl47 S10xH+rlymxKHSd4kj5giHh/K5SlxQ2mLbnZmRmigGqmIy5yGEBKlWfQHs/xioUKKhKY 7ItAUIsI4QW5luLVZeMR8Fmn//ITZfs5e9mETS0RhTqxaDdkNFeqpMQPu1OpXDRJ1KPW 2Yb+98mWhL3qjLYLtHAodQEw1/1tkf0xSQAj+RYNuI0FH/PiXIpi4/4DV2XM4uUKB6ev Uk9PiKTDNODKLT1UCNVKixyWdtCIrW/RP9XLDNKwxWAyJ7cZutQBbxVvOKKCxClWaJUm IhUg== Received: by 10.204.157.143 with SMTP id b15mr1771764bkx.75.1344638337347; Fri, 10 Aug 2012 15:38:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Fri, 10 Aug 2012 15:38:36 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 08:38:36 +1000 Message-ID: To: Trey Drake Content-Type: multipart/alternative; boundary=0015175cd0de72f0fb04c6f102a6 Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle , Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:39:10 -0000 --0015175cd0de72f0fb04c6f102a6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trey, > The externalID is not part of the protocol. It is an *optional* attribute within the *schema* specification. I didn't realise SCIM was also specifying a User schema. Does this mean the User resource can only hold certain attributes as defined by this schema? If so, that's going to be a severe constraint, because client organisations are likely to require many specialised User attributes depending on the nature of their business, and they will expect to be able to store all of them, not just the subset defined by the SCIM spec. I hope the SCIM User schema is not trying to be just a representation of inetOrgPerson (the standard LDAP schema), because that could be severely limiting. Most organisations with their own LDAP end up extending inetOrgPerson, and they will expect that they can do the same in the cloud. > As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes Yes, that's what I meant, but in implementation, it may work out to be looser than that. The client should be able to specify any arbitrary attribute in the search parameters, even those that aren't attributes of the resource. If an attribute is not defined, or if the attribute exists but the value doesn't match any stored record, the SP will return no results. In the former case, it's a "400 Bad Request" and in the latter, it's a "404 Not Found". By "candidate key" (a data modelling term), I meant another attribute that also uniquely identifies a single record, but is not the official "primary key", i.e., the main ID. In this case, a client's internal identifier also uniquely identifies a record, but is not the ID used in the URI of RESTful operations. Look, this may seem to be splitting hairs since a determined client may be able to store and search by their own internal ID in either case (the current SCIM spec or my suggestion). The difference is philosophical. If the spec is showing how clients can store their internal IDs in the cloud by explicitly providing for such an attribute, that constitutes bad advice, IMO. If it turns a blind eye to what they store and they store internal IDs anyway, they're constraining themselves but the spec comes out smelling of roses because that's not "recommended practice". Ganesh On 11 August 2012 00:50, Trey Drake wrote: > Ganesh, > > I'll base my comments on your latest reply (below). > > The externalID is not part of the protocol. It is an *optional* attribut= e > within the *schema* specification. As for #2, the protocol spec works as > you describe if "arbitrary URI parameters" equate to resource attributes > (Allow generic search using 'GET /Users' and arbitrary URI parameters). > Please clarify your suggestion. > > I'm not tracking your coupling concern. The client can search and hence > retrieve resources on any attribute it chooses, externalId or otherwise. > Nothing mandates use of externalId. > > > What do you mean by "candidate key"? Given > > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> wrote: > >> > I think scim gets its current simplicity from its single owner hub >> spoke model implementing tight coupling. [...] IMHO loose coupling is a >> much more complex solution. >> >> Phil, >> >> I'm a bit surprised that you're implying "tight coupling =3D=3D simple" = and >> "loose coupling =3D=3D complex". That's contrary to my experience. >> >> When I say "loose coupling", I mean "no unnecessary dependencies". >> Invariably, a reduction in dependencies leads to greater simplicity. >> >> Let's not confuse reduction of dependencies in the data model with a >> hub-and-spokes architecture. They're entirely orthogonal aspects of the >> solution. >> >> All that my suggestion involves is, >> >> 1. Take 'external ID' out of the protocol. >> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >> >> No planned functionality is lost by this. >> >> 1. The client enterprise can still send its internal ID as part of the >> resource body, inside some attribute defined by them (but not defined by >> the protocol). Let's say they call it 'myID'. >> 2. The client enterprise can search for resource URIs using any >> attribute, including this internal ID >> 'GET /Users?myID=3Dbjensen' >> Since myID is a candidate key, the server will return exactly one URI, >> which is the canonical URI for the resource >> >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> >> 3. The client can use this URI to perform all other operations as usual. >> >> >> So taking 'externalID' out of the protocol spec only does this: >> >> 1. It avoids enshrining tight coupling in the protocol (If clients want = to tightly couple themselves to the cloud provider by sending their interna= l IDs, they can do so. Suicide is OK, but the protocol should not be guilty= of assisted suicide. ;-) >> >> 2. It encourages loose coupling by nudging clients towards maintaining t= heir own internal-to-external identifier mappings. >> >> >> That's what I'd like to see. I don't believe this complicates the protoc= ol. It simplifies it and it also lends itself to a loosely-coupled approach= . >> >> >> I'll address the multi-valued attribute suggestion separately. >> >> >> Regards, >> >> Ganesh >> >> >> >> >> On 10 August 2012 07:53, Phil Hunt wrote: >> >>> >>> >>> Phil >>> >>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>> wrote: >>> >>> > storing this information in a mapping table outside of the SCIM spec >>> is a great way to enable this solution. Part of the key here is that S= CIM >>> is just a piece of the architecture for this solution, and is only >>> responsible for the transport layer between domains. >>> >>> I wasn't suggesting that the mapping table be part of the SCIM spec. I >>> provided that example to illustrate that splitting and merging identiti= es >>> is a common requirement, and that decoupling local identifiers within a >>> domain from shared identifiers between domains was the best way to >>> facilitate it. >>> >>> I'm suggesting that the spec do less, not more. >>> >>> What the SCIM spec needs to do there is just refrain from introducing >>> tight coupling. I would like to see a single identifier exposed through= the >>> API, with the implication (and perhaps the recommendation) that it be t= he >>> shared one. Allowing one domain to expose its internal identifier to th= e >>> other creates tight coupling and ensures that both domains need >>> simultaneously split or merge identities, which is not desirable. So I >>> recommend _taking out_ the "external id" field from the API. The spec >>> shouldn't encourage tight coupling. If clients want to pass in their >>> internal ids as part of the resource body, no one can stop them, and th= ey >>> can always do a search on that attribute to retrieve the URI exactly as= you >>> visualise they will with the "external id", but let's not elevate an >>> anti-pattern to a recommendation by enshrining the "external id" as an >>> acceptable attribute. >>> >>> Am I making sense? >>> >>> >>> I see what you are saying. I think scim gets its current simplicity fro= m >>> its single owner hub spoke model implementing tight coupling. >>> >>> IMHO loose coupling is a much more complex solution. The reality is tha= t >>> each end-point has value to contribute and thus the single-owner model = will >>> eventually need to become multi-owner or multi-hub. >>> >>> That said i think the current model provides a practical starting point= . >>> >>> >>> > Regarding unique identifiers for multi-valued attributes there is a >>> trade-off involved. On one hand this makes PATCH semantics easier. On= the >>> other hand it puts extra burden on service providers. >>> >>> Precisely. The spec has to strike the right balance. It would be >>> interesting to hear from the other members of the spec mailing list. Yo= u >>> know where I stand on this. It would be good to hear the spectrum of >>> opinions. >>> >>> Regards, >>> Ganesh >>> >>> On 10 August 2012 00:28, Kelly Grizzle wro= te: >>> >>>> Thanks Emmanuel. I had started writing up a similar response. As >>>> you suggest, storing this information in a mapping table outside of th= e >>>> SCIM spec is a great way to enable this solution. Part of the key her= e is >>>> that SCIM is just a piece of the architecture for this solution, and i= s >>>> only responsible for the transport layer between domains.**** >>>> >>>> ** ** >>>> >>>> You could also model these ID mappings in the SCIM user as an extensio= n >>>> but would probably not want to expose these externally. Here is an ex= ample >>>> of how to model the end state of the false positive scenario (splittin= g a >>>> user):**** >>>> >>>> ** ** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>> true |**** >>>> >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>> true |**** >>>> >>>> ** ** >>>> >>>> This could be represented as two SCIM users that contain information >>>> about the entities on other domains.**** >>>> >>>> ** ** >>>> >>>> {**** >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>> >>>> "id": "9caf78aac3d6",**** >>>> >>>> "userName": "John Smith",**** >>>> >>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>> >>>> "linkedUsers": [**** >>>> >>>> {**** >>>> >>>> "domain": "D2",**** >>>> >>>> "externalEntityId": "ff487230b3a0"**** >>>> >>>> }**** >>>> >>>> ]**** >>>> >>>> }**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> {**** >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>> >>>> "id": "a99a5feba839",**** >>>> >>>> "userName": "John Smith",**** >>>> >>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>> >>>> "linkedUsers": [**** >>>> >>>> {**** >>>> >>>> "domain": "D2",**** >>>> >>>> "externalEntityId": "7a87f27c1dd8"**** >>>> >>>> }**** >>>> >>>> ]**** >>>> >>>> }**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> In the second user, the linkedUsers attribute would be empty until the >>>> split user was synced to domain 2.**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> Similarly, the false negative use case (merging two users) looked like >>>> this at the end:**** >>>> >>>> ** ** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>> true |**** >>>> >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>> false |**** >>>> >>>> ** ** >>>> >>>> This could be represented with the following SCIM user:**** >>>> >>>> ** ** >>>> >>>> {**** >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>> >>>> "id": "9caf78aac3d6",**** >>>> >>>> "userName": "John Smith",**** >>>> >>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>> >>>> "linkedUsers": [**** >>>> >>>> {**** >>>> >>>> "domain": "D2",**** >>>> >>>> "externalEntityId": "ff487230b3a0"**** >>>> >>>> },**** >>>> >>>> {**** >>>> >>>> "domain": "D2",**** >>>> >>>> "externalEntityId": "41206cc97c8b",**** >>>> >>>> "deletionRequired": true**** >>>> >>>> }**** >>>> >>>> ]**** >>>> >>>> }**** >>>> >>>> }**** >>>> >>>> ** ** >>>> >>>> ** ** >>>> >>>> Regarding unique identifiers for multi-valued attributes there is a >>>> trade-off involved. On one hand this makes PATCH semantics easier. O= n the >>>> other hand it puts extra burden on service providers. Since the incep= tion >>>> of SCIM, a key goal has been to foster adoption by service providers b= y >>>> making things fit easily onto existing systems. IMO the value gained = by >>>> unique identifiers for multi-valued attributes is not worth the demand= s put >>>> on a service provider. I also think that vendors that have a >>>> non-SCIM-compliant API will choose to keep things that way if the spec= is >>>> too hard for them to implement. In a green field environment we do ha= ve >>>> the luxury of mandating a model to make certain operations more elegan= t. >>>> However, we can=92t ignore legacy systems. **** >>>> >>>> ** ** >>>> >>>> --Kelly**** >>>> >>>> ** ** >>>> >>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>> Behalf Of *Emmanuel Dreux >>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>> *Cc:* scim@ietf.org >>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement***= * >>>> >>>> ** ** >>>> >>>> Hi Ganesh,**** >>>> >>>> ** ** >>>> >>>> Nothing prevents you in your SCIM implementation (client or server) to >>>> generate a unique identifier for each synchronized object and maintain= an >>>> internal mapping table ( you would have to map group membership as wel= l). >>>> **** >>>> >>>> ** ** >>>> >>>> This is what we are doing with Active Directory sources or targets:***= * >>>> >>>> As we didn=92t find an immutable uniqueID in AD systems >>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can ch= ange >>>> if an AD domain is migrated), we decided to generate and maintain an >>>> internal table of ids. This fits your requirements as it hides interna= l ids. >>>> **** >>>> >>>> ** ** >>>> >>>> This was written in dotnet and we have started a project to rewrite ou= r >>>> SCIM stack in PHP and will give it to the Open Source community. This >>>> implementation will have a parameter : AllocateIds versus UseExistingI= Ds. >>>> **** >>>> >>>> This will give the choice of =93hiding=94 internalIDs or use them as u= nique >>>> ID.**** >>>> >>>> ** ** >>>> >>>> You can also implement such feature without violating the SCIM specs, >>>> or without asking to include it in the specs.**** >>>> >>>> ** ** >>>> >>>> --**** >>>> >>>> Regards,**** >>>> >>>> Emmanuel Dreux**** >>>> >>>> http://www.cloudiway.com**** >>>> >>>> Tel: +33 4 26 78 17 58**** >>>> >>>> Mobile: +33 6 47 81 26 70**** >>>> >>>> skype: Emmanuel.Dreux**** >>>> >>>> ** ** >>>> >>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>> >>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>> *=C0 :* Kelly Grizzle >>>> *Cc :* scim@ietf.org >>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >>>> >>>> ** ** >>>> >>>> Hi Kelly,**** >>>> >>>> Thanks for your response. Let me first respond in brief to the two mai= n >>>> points you have made, and then elaborate on the first.**** >>>> >>>> **1. **Why should domains not expose their internal identifiers >>>> to other domains?**** >>>> >>>> a.**** >>>> >>>> We are designing a protocol for a federated system of domains, where >>>> all domains are co-equal peers. (In physics too, N-body problems are m= uch >>>> harder than 2-body problems. :-) Therefore, assuming that there are on= ly >>>> two players in the interaction makes this tightly coupled in a number = of >>>> ways. We should rely on messaging and notification, with encapsulation= of >>>> domain-specific data.**** >>>> >>>> b. **** >>>> >>>> In any non-trivial data store, there will always be the ongoing need t= o >>>> merge and split identities as and when =93false negatives=94 and =93fa= lse >>>> positives=94 are discovered. A domain should be able to handle this in= ternal >>>> housekeeping freely, only notifying other domains when convenient. Map= ping >>>> of internal identifiers to external ones and maintaining this mapping >>>> internally allows this loosely-coupled housekeeping to take place. Sha= ring >>>> internal identifiers (or otherwise outsourcing the mapping of internal= to >>>> external identifiers) forces housekeeping activities to be done in >>>> lock-step across domains.**** >>>> >>>> c.**** >>>> >>>> Asynchronous interaction is not just a matter of a suitable wire >>>> protocol which can be designed later. The data model plays a crucial r= ole >>>> in enabling or constraining such interaction. A tightly-coupled data m= odel >>>> will force the use of synchronous interactions, and the exposure of >>>> internal identifiers is a key part of this tight coupling.**** >>>> >>>> 2. The difficulty of assigning unique identifiers to the individual >>>> values of multi-valued attributes:**** >>>> >>>> a. **** >>>> >>>> I'm not belittling the effort involved in migrating legacy data stores >>>> to such a model. However, in the larger historical context of cross-do= main >>>> identity management, we are really at the very early stages. If a >>>> relatively new discipline and a brand new spec are held captive to leg= acy >>>> considerations, we are losing an opportunity to provide a clean and el= egant >>>> model to subsequent users of the spec, and this will have repercussion= s >>>> over many years or even decades.**** >>>> >>>> b. **** >>>> >>>> If incumbent cloud providers find it hard to immediately adopt the >>>> dictionary model for existing multi-valued attributes, they can transi= tion >>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-co= mpliant=94 >>>> APIs to their customers and encouraging new customers to adopt the >>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradua= lly >>>> migrated to the SCIM-compliant API. The logistics are not insurmountab= le, >>>> and shouldn't prevent the adoption of a dictionary model for multi-val= ued >>>> attributes.**** >>>> >>>> Elaboration of Point 1:**** >>>> >>>> When we consider federated identity across more than one domain, we >>>> have to assume that domains are not necessarily master-slave in their >>>> interaction. The most generic interaction model is peer-to-peer, where >>>> entity lifecycle events within a domain are notified to other domains = (when >>>> necessary) in an asynchronous manner (i.e., through messaging) and the >>>> other domains are free to respond to these events in an appropriate ma= nner >>>> and at a time of their convenience.**** >>>> >>>> A key set of lifecycle events for an entity is the merging and >>>> splitting of identity that is often required.**** >>>> >>>> The question =93Is this one entity?=94 can be answered either yes >>>> (positive) or no (negative). But sometimes, we can discover false posi= tives >>>> and false negatives in our data stores.**** >>>> >>>> Consider a case where customers sign up online, and two customers who >>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and als= o use the >>>> same date of birth (say, 1 Jan 1970) or similar attributes. The front-= end >>>> application may make an intelligent (but incorrect) guess that these t= wo >>>> persons are the same, and re-assign the same identifier to the second >>>> person. This is a false positive. They appear to be the same entity, b= ut >>>> they're actually different. When the error is discovered, the identiti= es >>>> will need to be split, with a new identifier generated for one of them= . >>>> **** >>>> >>>> Consider the opposite case where a customer signs up through two >>>> different portals or in two different sessions, using the names =93JSm= ith=94 >>>> and =93JohnS=94. It is very likely that they will be treated as two di= fferent >>>> customers and assigned two unique identifiers. This is a false negativ= e. >>>> They appear to be two entities, but are actually the same. At a later >>>> stage, when the error is discovered, the identities will have to be me= rged, >>>> and one of the identifiers will have to be dropped.**** >>>> >>>> These are not theoretical use cases. They form a significant proportio= n >>>> of the user base in most large Web-facing applications. Let's see how = these >>>> can be managed in a federated way by mapping internal identifiers to >>>> external ones and only exposing external identifiers to other domains.= * >>>> *** >>>> >>>> a. False positives:**** >>>> >>>> Domain 1 has the following information about a customer in its data >>>> store:**** >>>> >>>> Internal ID: 9caf78aac3d6**** >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>> >>>> When requesting the provisioning of this entity in Domain 2, the >>>> following ID is returned by Domain 2: ff487230b3a0.**** >>>> >>>> Domain 1 then maintains the following in a mapping table and uses it >>>> for translation when talking to Domain 2, taking care never to expose = its >>>> internal identifier:**** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>> >>>> When the false positive is discovered and the entity is split, Domain = 1 >>>> creates a new internal identifier and now has the following entity >>>> information.**** >>>> >>>> Internal ID: 9caf78aac3d6**** >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>> >>>> Internal ID: a99a5feba839**** >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>> >>>> This second entity with its own internal identifier is invisible to >>>> Domain 2, and this is by design. Communication about the original enti= ty >>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >>>> vice-versa. At some convenient time (importantly, this doesn't have to= be >>>> at the time the split happens), Domain 2 can be requested to provision= a >>>> second entity, and when it responds with an identifier of =937a87f27c1= dd8=94, >>>> this can go into the mapping table as a new record associated with the >>>> second entity's internal identifier.**** >>>> >>>> The mapping table now contains the following entries:**** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>> >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** >>>> >>>> Domain 2 is not even aware that a split has happened, and the >>>> provisioning that it does is not in lockstep with the split in identit= y >>>> that occurred in Domain 1.**** >>>> >>>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>>> treatment of false negatives.)**** >>>> >>>> b. False negatives:**** >>>> >>>> Domain 1 has the following information about what it thinks are two >>>> distinct customers in its data store:**** >>>> >>>> Internal ID: 9caf78aac3d6**** >>>> >>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** >>>> >>>> Internal ID: 273d36e30d09**** >>>> >>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** >>>> >>>> When requesting the provisioning of these entities in Domain 2, the >>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.= * >>>> *** >>>> >>>> Domain 1 then maintains the following in a mapping table and uses it >>>> for translation when talking to Domain 2, taking care never to expose = its >>>> internal identifiers:**** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>> >>>> | 273d36e30d09 | D2 | 41206cc97c8b | true |**** >>>> >>>> When the false negative is discovered and the two entities are merged, >>>> Domain 1 drops one of the internal identifiers and rationalises the na= me of >>>> the customer (say, to =93John Smith=94). Let's say it retains the firs= t ID >>>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** >>>> >>>> The mapping table now looks like this:**** >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag |**** >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>> >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** >>>> >>>> Now two external identifiers map to the same internal one, so inbound >>>> communication from Domain 2 can be unambiguously translated to the sam= e >>>> entity internally. However, when going outwards, Domain 1 will have to= look >>>> up the translation table to determine the =93primary=94 external ID fo= r this >>>> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's= where >>>> the =93Primary flag=94 comes in. The second external ID =9341206cc97c8= b=94 is never >>>> used thereafter in outbound communication.**** >>>> >>>> At some stage (importantly, not in lockstep with the identity merge), >>>> Domain 2 can be requested to delete the customer record identified by >>>> =9341206cc97c8b=94, and the second entry in the mapping table can be r= emoved >>>> once this is acknowledged.**** >>>> >>>> This scheme will scale up to multiple domains, because the =93External >>>> Domain ID=94 column helps to keep track of which external ID is shared= with >>>> which Domain. (Why don't we use just one external ID for an entity and >>>> share it with all external domains? Tight coupling again. Just as OAut= h >>>> allows an access token given to a third party to be invalidated withou= t >>>> affecting the access of other third parties, the use of separate exter= nal >>>> identifiers for different domains allows fine-grained control of ident= ity >>>> federation.)**** >>>> >>>> The scheme also allows the splitting of an entity into more than two >>>> entities, and the merging of more than two entities into a single one.= (Any >>>> organisation with a web-facing application will tell you how many John >>>> Smiths there are who were born on 1 Jan 1970!)**** >>>> >>>> This is a fairly long-winded explanation, but this is why we need to >>>> hide internal identifiers from other domains, and why mappings need to= be >>>> managed internally in each domain. Such a data model also allows us to >>>> choose asynchronous protocols for propagation of identity events, sinc= e >>>> there is no consistency requirement to update multiple domains concurr= ently. >>>> **** >>>> >>>> Regards, **** >>>> >>>> Ganesh Prasad**** >>>> >>>> ** ** >>>> >>>> On 9 August 2012 04:55, Kelly Grizzle >>>> wrote:**** >>>> >>>> Thanks for the feedback, Ganesh. I read through this and your InfoQ >>>> article (http://www.infoq.com/articles/scim-data-model-limitations) >>>> and have some thoughts.**** >>>> >>>> **** >>>> >>>> > The rest of the protocol does not meaningfully use the enterprise >>>> client=92s identifier, the "external ID"**** >>>> >>>> > at all, even though it was ostensibly introduced to make things >>>> friendlier for the client.**** >>>> >>>> **** >>>> >>>> The usage pattern for an external ID would be to search for a user by >>>> externalId and use the ID of the returned user in any desired operatio= n. >>>> For example:**** >>>> >>>> **** >>>> >>>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** >>>> >>>> **** >>>> >>>> {**** >>>> >>>> =93totalResults=94: 1,**** >>>> >>>> =93Resources=94: [**** >>>> >>>> {**** >>>> >>>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** >>>> >>>> }**** >>>> >>>> ]**** >>>> >>>> }**** >>>> >>>> **** >>>> >>>> Retrieve the ID from the response and use it.**** >>>> >>>> **** >>>> >>>> DELETE /Users/2819c223-7f76-453a-919d-413861904646**** >>>> >>>> **** >>>> >>>> This does introduce an additional HTTP request if the client chooses >>>> not to store the server=92s id. An issue was created to consider allo= wing >>>> operations to use the externalId ( >>>> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe th= e >>>> general consensus has been to not include this in the spec. One main = point >>>> of contention is that much of the rest of the spec (eg =96 group membe= rship >>>> references, manager references, etc=85) require knowledge of the serve= r=92s >>>> identifier. Continuing this discussion on the IETF list would be a go= od >>>> thing, though.**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> > the cloud provider's ID and the enterprise client's ID are both >>>> "Internal IDs" with respect to their domains**** >>>> >>>> **** >>>> >>>> I think this comes down to a nomenclature problem. The server=92s ID >>>> does not necessarily have to be the unique identifier that the underly= ing >>>> identity store uses, it just has to be stable and unique. In many cas= es, >>>> the underlying identity store will provide identifiers with these >>>> properties already (eg =96 a uuid) and it can be used by the SCIM inte= rface. >>>> The =93externalId=94 is referring to the fact that the id is maintaine= d >>>> external to the SCIM server. As long as the server=92s identifiers ar= e >>>> stable and unique (which is mandated by the spec), I don=92t see a pro= blem. >>>> **** >>>> >>>> **** >>>> >>>> **** >>>> >>>> > The secret is that *every value needs a key*, and multi-valued >>>> attributes lack that. So our solution is quite**** >>>> >>>> > simple - turn every list or array (of values) into a dictionary (of >>>> key-value pairs) by providing each value**** >>>> >>>> > with a unique and meaning-free identifier.**** >>>> >>>> **** >>>> >>>> I agree that this would be useful, especially in the PATCH operation. >>>> One reason that this wasn=92t included in the spec originally is that = it can >>>> put undue burden on the service provider. Many service providers are >>>> putting SCIM interfaces in front of their existing identity stores (eg= =96 >>>> directory servers, SaaS application databases, etc=85). Many of these= do not >>>> have a unique identifier for multi-valued attributes. By requiring th= is, a >>>> majority of the server providers would have to start maintaining a uni= que >>>> key for each multi-valued attribute. I believe this would be a roadbl= ock >>>> for many implementers.**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> > When the SCIM protocol uses PATCH, there are areas where it seems a >>>> bit clumsy.**** >>>> >>>> **** >>>> >>>> I like the thoughts here. Your example reminds me of unified diffs ( >>>> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >>>> used with a patch program (pretty much the equivalent of the PATCH ver= b). >>>> However, the three proposals seem to largely hinge on being able to >>>> uniquely address each element within an object. Without these it is n= ot so >>>> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or >>>> provide a multi-status.**** >>>> >>>> >>>> The 207 response would be interesting to consider for the bulk endpoin= t >>>> ( >>>> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resource= s), >>>> however.**** >>>> >>>> **** >>>> >>>> **** >>>> >>>> > There are other, non-data aspects of SCIM which may require review, >>>> such as its synchronous request-response**** >>>> >>>> > interaction model, which is a form of tight coupling and could prove >>>> to be a source of brittleness.**** >>>> >>>> **** >>>> >>>> I agree that we should explore optional asynchronous requests in 2.0.*= * >>>> ** >>>> >>>> **** >>>> >>>> Thanks again for your thoughts. I hope you stay involved in the >>>> discussion as work on SCIM 2.0 goes forward.**** >>>> >>>> **** >>>> >>>> --Kelly**** >>>> >>>> **** >>>> >>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>> Behalf Of *Ganesh and Sashi Prasad >>>> *Sent:* Wednesday, August 01, 2012 4:24 PM >>>> *To:* scim@ietf.org >>>> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** >>>> >>>> **** >>>> >>>> (I posted this on the SCIM Google Group, and I was advised to subscrib= e >>>> to the mailing list and post it here instead, so here goes.)**** >>>> >>>> **** >>>> >>>> Hi,**** >>>> >>>> **** >>>> >>>> My name is Ganesh Prasad, and my experience in Identity and Access >>>> Management is mainly through a 3-year project at an Australian insuran= ce >>>> company, an experience I have written about as a eBook on InfoQ ( >>>> http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** >>>> >>>> **** >>>> >>>> I have been following the SCIM spec off and on, and based on my >>>> experience with a loosely-coupled architecture that I found to be >>>> successful, I have the following 3 suggestions to make.**** >>>> >>>> **** >>>> >>>> 1. The enterprise client and the cloud provider should maintain their >>>> own internal IDs for a resource, which they should not reveal to each >>>> other. Both of them should map their internal IDs to a shared External= ID, >>>> and this is the only ID that should be exposed through the API. The cu= rrent >>>> specification's provision of an id (which is the external ID and the o= nly >>>> one to be transferred through the API) and an "external ID" (which is = the >>>> client's internal ID and should be hidden) is diametrically opposite t= o >>>> this.**** >>>> >>>> **** >>>> >>>> 2. When dealing with multi-valued attributes of a resource (expressed >>>> as arrays in JSON), they must be converted from an array into a dictio= nary >>>> with unique keys (UUIDs generated by the cloud provider when the attri= bute >>>> is created). Without unique keys for every attribute value of a resour= ce, >>>> manipulating it will be clumsy and inelegant.**** >>>> >>>> **** >>>> >>>> 3. The PATCH command can be improved in 3 significant ways:**** >>>> >>>> 3a. Leverage the fact (from 2 above) that every value has a key, to >>>> greatly simplify the API**** >>>> >>>> 3b. Use special verbs as nested operations of the PATCH command to add= , >>>> modify and delete attributes at any level**** >>>> >>>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 >>>> OK" as the response to a PATCH (or BULK) command.**** >>>> >>>> **** >>>> >>>> To elaborate,**** >>>> >>>> **** >>>> >>>> 1. Revealing private IDs externally is a form of tight coupling. A >>>> major requirement with Identity Management is to split (or merge) >>>> identities when false positives (or false negatives) are detected, i.e= ., >>>> when a resource is discovered to be more than one, or when multiple >>>> resources are detected to be the same. If internal identifiers are rev= ealed >>>> to external domains, such clean-ups become difficult, hence every doma= in >>>> that wants to expose references to a resource must map its internal ID= to >>>> and external one created for this explicit purpose, and only reveal th= is. >>>> **** >>>> >>>> **** >>>> >>>> In the SCIM case, when an enterprise client POSTs a resource creation >>>> request, the cloud provider must generate its own internal UUID as wel= l as >>>> an external UUID, map them together, and only return the external UUID= in >>>> the "Location:" header. The enterprise client should map this external= UUID >>>> to a newly-generated internal ID of its own. In case the resource alre= ady >>>> has an identifier within the enterprise client's domain, then this is = the >>>> internal ID that must be mapped to the external UUID returned through = the >>>> POST response.**** >>>> >>>> **** >>>> >>>> 2. If a resource is to be created, and one of its attributes is >>>> multi-valued, e.g.,**** >>>> >>>> **** >>>> >>>> "email-addrs" : **** >>>> >>>> [**** >>>> >>>> "john_smith@yahoo.com",**** >>>> >>>> "john.smith@gmail.com",**** >>>> >>>> "jsmith1970@hotmail.com"**** >>>> < >>>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> > --0015175cd0de72f0fb04c6f102a6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trey,

> The externalI= D is not part of the protocol. =A0It is an *optional* attribute within the = *schema* specification.

I didn't realise = SCIM was also specifying a User schema. Does this mean the User resource ca= n only hold certain attributes as defined by this schema? If so, that's= going to be a severe constraint, because client organisations are likely t= o require many specialised User attributes depending on the nature of their= business, and they will expect to be able to store all of them, not just t= he subset defined by the SCIM spec. I hope the SCIM User schema is not tryi= ng to be just a representation of inetOrgPerson (the standard LDAP schema),= because that could be severely limiting. Most organisations with their own= LDAP end up extending inetOrgPerson, and they will expect that they can do= the same in the cloud. --0015175cd0de72f0fb04c6f102a6-- From prvs=56278ac87=Mark.Diodati@gartner.com Fri Aug 10 15:48:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CB021F8568 for ; Fri, 10 Aug 2012 15:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBJViGiODegb for ; Fri, 10 Aug 2012 15:47:56 -0700 (PDT) Received: from zinc-main.gartner.com (zinc-main.gartner.com [207.140.148.90]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36D21F8543 for ; Fri, 10 Aug 2012 15:47:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAMx4JVAKQCMK/2dsb2JhbAA7CYJKpgiIYQGJSoIZBwEBAQMBAQEBCwwBOhAHAgYKCwIBCBEBAwEBAQoCFAEGByEGCxMBAwYIAgQBCQkIDAeFLoI1AwYRo3WFD4UMDYlOiiplEQmFamADiBmLXQECggFjiXaGMoEygV8 X-IronPort-AV: E=Sophos;i="4.77,748,1336363200"; d="scan'208,217";a="105549233" From: "Diodati,Mark" To: Ganesh and Sashi Prasad , "scim@ietf.org" Thread-Topic: [scim] SCIM Protocol - 3 suggestions for improvement Thread-Index: AQHNd0j6wo6qyXXntEGBKKHh9XVxypdTo+gA Date: Fri, 10 Aug 2012 22:47:51 +0000 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.130] Content-Type: multipart/alternative; boundary="_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4EE0Fwhistlerentgart_" MIME-Version: 1.0 Message-Id: <20120810224755.6D36D21F8543@ietfa.amsl.com> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:48:13 -0000 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4EE0Fwhistlerentgart_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ganesh, There is a user schema, but it is optional. Still, many of our clients are = looking for a common user schema. This was one of the criticisms of the pri= or specification and an initial requirement for SCIM. Best, Mark http://www.simplecloud.info/specs/draft-scim-core-schema-00.html http://blogs.gartner.com/mark-diodati/2011/05/06/scim-and-the-future-of-sta= ndards-based-provisioning/ http://blogs.gartner.com/mark-diodati/2010/08/20/consensus-on-the-future-of= -standards-based-provisioning-and-spml/ From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Friday, August 10, 2012 5:39 PM To: Trey Drake Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Trey, > The externalID is not part of the protocol. It is an *optional* attribut= e within the *schema* specification. I didn't realise SCIM was also specifying a User schema. Does this mean the= User resource can only hold certain attributes as defined by this schema? = If so, that's going to be a severe constraint, because client organisations= are likely to require many specialised User attributes depending on the na= ture of their business, and they will expect to be able to store all of the= m, not just the subset defined by the SCIM spec. I hope the SCIM User schem= a is not trying to be just a representation of inetOrgPerson (the standard = LDAP schema), because that could be severely limiting. Most organisations w= ith their own LDAP end up extending inetOrgPerson, and they will expect tha= t they can do the same in the cloud. > As for #2, the protocol spec works as you describe if "arbitrary URI para= meters" equate to resource attributes Yes, that's what I meant, but in implementation, it may work out to be loos= er than that. The client should be able to specify any arbitrary attribute = in the search parameters, even those that aren't attributes of the resource= . If an attribute is not defined, or if the attribute exists but the value = doesn't match any stored record, the SP will return no results. In the form= er case, it's a "400 Bad Request" and in the latter, it's a "404 Not Found"= . By "candidate key" (a data modelling term), I meant another attribute that = also uniquely identifies a single record, but is not the official "primary = key", i.e., the main ID. In this case, a client's internal identifier also = uniquely identifies a record, but is not the ID used in the URI of RESTful = operations. Look, this may seem to be splitting hairs since a determined client may be = able to store and search by their own internal ID in either case (the curre= nt SCIM spec or my suggestion). The difference is philosophical. If the spe= c is showing how clients can store their internal IDs in the cloud by expli= citly providing for such an attribute, that constitutes bad advice, IMO. If= it turns a blind eye to what they store and they store internal IDs anyway= , they're constraining themselves but the spec comes out smelling of roses = because that's not "recommended practice". Ganesh On 11 August 2012 00:50, Trey Drake > wrote: Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute = within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (Al= low generic search using 'GET /Users' and arbitrary URI parameters). Pleas= e clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence re= trieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > wrote: > I think scim gets its current simplicity from its single owner hub spoke= model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and= "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariab= ly, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-an= d-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the reso= urce body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, = including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, whic= h is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to = tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of= assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining thei= r own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol.= It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt > wrote: Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? I see what you are saying. I think scim gets its current simplicity from it= s single owner hub spoke model implementing tight coupling. IMHO loose coupling is a much more complex solution. The reality is that ea= ch end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub. That said i think the current model provides a practical starting point. > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can't ignore le= gacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the = translation table to determine the "primary" external ID for this entity in= Domain 2, which was decided to be "ff487230b3a0". That's where the "Primar= y flag" comes in. The second external ID "41206cc97c8b" is never used there= after in outbound communication. At some stage (importantly, not in lockstep with the identity merge), Domai= n 2 can be requested to delete the customer record identified by "41206cc97= c8b", and the second entry in the mapping table can be removed once this is= acknowledged. This scheme will scale up to multiple domains, because the "External Domain= ID" column helps to keep track of which external ID is shared with which D= omain. (Why don't we use just one external ID for an entity and share it wi= th all external domains? Tight coupling again. Just as OAuth allows an acce= ss token given to a third party to be invalidated without affecting the acc= ess of other third parties, the use of separate external identifiers for di= fferent domains allows fine-grained control of identity federation.) The scheme also allows the splitting of an entity into more than two entiti= es, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths th= ere are who were born on 1 Jan 1970!) This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed= internally in each domain. Such a data model also allows us to choose asyn= chronous protocols for propagation of identity events, since there is no co= nsistency requirement to update multiple domains concurrently. Regards, Ganesh Prasad On 9 August 2012 04:55, Kelly Grizzle > wrote: Thanks for the feedback, Ganesh. I read through this and your InfoQ articl= e (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. > The rest of the protocol does not meaningfully use the enterprise client'= s identifier, the "external ID" > at all, even though it was ostensibly introduced to make things friendlie= r for the client. The usage pattern for an external ID would be to search for a user by exter= nalId and use the ID of the returned user in any desired operation. For ex= ample: GET /Users?filter=3DexternalId eq "bjensen"&attributes=3Did { "totalResults": 1, "Resources": [ { "id": "2819c223-7f76-453a-919d-413861904646" } ] } Retrieve the ID from the response and use it. DELETE /Users/2819c223-7f76-453a-919d-413861904646 This does introduce an additional HTTP request if the client chooses not to= store the server's id. An issue was created to consider allowing operatio= ns to use the externalId (http://code.google.com/p/scim/issues/detail?id=3D= 35), but I believe the general consensus has been to not include this in th= e spec. One main point of contention is that much of the rest of the spec = (eg - group membership references, manager references, etc...) require know= ledge of the server's identifier. Continuing this discussion on the IETF l= ist would be a good thing, though. > the cloud provider's ID and the enterprise client's ID are both "Internal= IDs" with respect to their domains I think this comes down to a nomenclature problem. The server's ID does no= t necessarily have to be the unique identifier that the underlying identity= store uses, it just has to be stable and unique. In many cases, the under= lying identity store will provide identifiers with these properties already= (eg - a uuid) and it can be used by the SCIM interface. The "externalId" = is referring to the fact that the id is maintained external to the SCIM ser= ver. As long as the server's identifiers are stable and unique (which is m= andated by the spec), I don't see a problem. > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite > simple - turn every list or array (of values) into a dictionary (of key-v= alue pairs) by providing each value > with a unique and meaning-free identifier. I agree that this would be useful, especially in the PATCH operation. One = reason that this wasn't included in the spec originally is that it can put = undue burden on the service provider. Many service providers are putting S= CIM interfaces in front of their existing identity stores (eg - directory s= ervers, SaaS application databases, etc...). Many of these do not have a u= nique identifier for multi-valued attributes. By requiring this, a majorit= y of the server providers would have to start maintaining a unique key for = each multi-valued attribute. I believe this would be a roadblock for many = implementers. > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. I like the thoughts here. Your example reminds me of unified diffs (http:/= /en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, th= e three proposals seem to largely hinge on being able to uniquely address e= ach element within an object. Without these it is not so easy to address e= ach patch sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-statu= s. The 207 response would be interesting to consider for the bulk endpoint (ht= tp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. > There are other, non-data aspects of SCIM which may require review, such = as its synchronous request-response > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. I agree that we should explore optional asynchronous requests in 2.0. Thanks again for your thoughts. I hope you stay involved in the discussion= as work on SCIM 2.0 goes forward. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Wednesday, August 01, 2012 4:24 PM To: scim@ietf.org Subject: [scim] SCIM Protocol - 3 suggestions for improvement (I posted this on the SCIM Google Group, and I was advised to subscribe to = the mailing list and post it here instead, so here goes.) Hi, My name is Ganesh Prasad, and my experience in Identity and Access Manageme= nt is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com= /minibooks/Identity-Management-Shoestring). I have been following the SCIM spec off and on, and based on my experience = with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Bot= h of them should map their internal IDs to a shared External ID, and this i= s the only ID that should be exposed through the API. The current specifica= tion's provision of an id (which is the external ID and the only one to be = transferred through the API) and an "external ID" (which is the client's in= ternal ID and should be hidden) is diametrically opposite to this. 2. When dealing with multi-valued attributes of a resource (expressed as ar= rays in JSON), they must be converted from an array into a dictionary with = unique keys (UUIDs generated by the cloud provider when the attribute is cr= eated). Without unique keys for every attribute value of a resource, manipu= lating it will be clumsy and inelegant. 3. The PATCH command can be improved in 3 significant ways: 3a. Leverage the fact (from 2 above) that every value has a key, to greatly= simplify the API 3b. Use special verbs as nested operations of the PATCH command to add, mod= ify and delete attributes at any level 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as= the response to a PATCH (or BULK) command. To elaborate, 1. Revealing private IDs externally is a form of tight coupling. A major re= quirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is = discovered to be more than one, or when multiple resources are detected to = be the same. If internal identifiers are revealed to external domains, such= clean-ups become difficult, hence every domain that wants to expose refere= nces to a resource must map its internal ID to and external one created for= this explicit purpose, and only reveal this. In the SCIM case, when an enterprise client POSTs a resource creation reque= st, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "L= ocation:" header. The enterprise client should map this external UUID to a = newly-generated internal ID of its own. In case the resource already has an= identifier within the enterprise client's domain, then this is the interna= l ID that must be mapped to the external UUID returned through the POST res= ponse. 2. If a resource is to be created, and one of its attributes is multi-value= d, e.g., "email-addrs" : [ "john_smith@yahoo.com", "john.smith@gmail.com", "jsmith1970@hotmail.com" < _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ________________________________ This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute,= or otherwise use this message or its attachments. Please notify the sender= immediately by return e-mail and permanently delete this message and any a= ttachments. Gartner makes no warranty that this e-mail is error or virus fr= ee. --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4EE0Fwhistlerentgart_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ganesh,

 

There is a user schema,= but it is optional. Still, many of our clients are looking for a common us= er schema. This was one of the criticisms of the prior specification and an initial requirement for SCIM.

 

Best,

 

Mark

 

http://www.simplecloud.info/specs/draft-scim-core-= schema-00.html

http://blogs.= gartner.com/mark-diodati/2011/05/06/scim-and-the-future-of-standards-based-= provisioning/

= http://blogs.gartner.com/mark-diodati/2010/08/20/consensus-on-the-future-of= -standards-based-provisioning-and-spml/

 

 

From: Ganesh= and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Friday, August 10, 2012 5:39 PM
To: Trey Drake
Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Trey,

 

> Th= e externalID is not part of the protocol.  It is an *optional* attribu= te within the *schema* specification.

 

I didn't realise SCIM was also specifying a= User schema. Does this mean the User resource can only hold certain attrib= utes as defined by this schema? If so, that's going to be a severe constraint, because client organisations are likely to require ma= ny specialised User attributes depending on the nature of their business, a= nd they will expect to be able to store all of them, not just the subset de= fined by the SCIM spec. I hope the SCIM User schema is not trying to be just a representation of inetOrgPerso= n (the standard LDAP schema), because that could be severely limiting. Most= organisations with their own LDAP end up extending inetOrgPerson, and they= will expect that they can do the same in the cloud.

 

> As= for #2, the protocol spec works as you describe if "arbitrary URI par= ameters" equate to resource attributes 

 

Yes, that's what I meant, but in implementation, it = may work out to be looser than that. The client should be able to specify a= ny arbitrary attribute in the search parameters, even those that aren't att= ributes of the resource. If an attribute is not defined, or if the attribute exists but the value doesn't match any= stored record, the SP will return no results. In the former case, it's a &= quot;400 Bad Request" and in the latter, it's a "404 Not Found&qu= ot;.

 

By "candidate key" (a data modelling term)= , I meant another attribute that also uniquely identifies a single record, = but is not the official "primary key", i.e., the main ID. In this= case, a client's internal identifier also uniquely identifies a record, but is not the ID used in the URI of RESTful operations.

 

Look, this may seem to be splitting hairs since a de= termined client may be able to store and search by their own internal ID in= either case (the current SCIM spec or my suggestion). The difference is ph= ilosophical. If the spec is showing how clients can store their internal IDs in the cloud by explicitly provid= ing for such an attribute, that constitutes bad advice, IMO. If it turns a = blind eye to what they store and they store internal IDs anyway, they're co= nstraining themselves but the spec comes out smelling of roses because that's not "recommended practice&= quot;.

 

Ganesh

On 11 August 2012 00:50, Trey Drake <trey.drake@unboundid.com<= /a>> wrote:

Ganesh,

 

I'll base my comments on your latest reply (below). =  

 

The externalID is not part of the protocol.  It= is an *optional* attribute within the *schema* specification.  As for= #2, the protocol spec works as you describe if "arbitrary URI paramet= ers" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clar= ify your suggestion.

 

I'm not tracking your coupling concern.  The cl= ient can search and hence retrieve resources on any attribute it chooses, e= xternalId or otherwise.  Nothing mandates use of externalId.  &nb= sp;

 

 

What do you mean by "candidate key"?  = ;Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>  I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling. [...]&nb= sp;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight= coupling =3D=3D simple" and "loose coupling =3D=3D complex"= . That's contrary to my experience.

 

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the d= ata model with a hub-and-spokes architecture. They're entirely orthogonal a= spects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbit= rary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
 
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
 
T=
hat's what I'd like to see. I don't believe this complicates the protocol. =
It simplifies it and it also lends itself to a loosely-coupled approach.
 
I=
'll address the multi-valued attribute suggestion separately.
 
R=
egards,
G=
anesh
 
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w= rote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a g= reat way to enable this solution.  Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain= from introducing tight coupling. I would like to see a single identifier e= xposed through the API, with the implication (and perhaps the recommendatio= n) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight co= upling and ensures that both domains need simultaneously split or merge ide= ntities, which is not desirable. So I recommend _taking out_ the "exte= rnal id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their inter= nal ids as part of the resource body, no one can stop them, and they can al= ways do a search on that attribute to retrieve the URI exactly as you visua= lise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its cur= rent simplicity from its single owner hub spoke model implementing tight co= upling. 

 

IMHO loose coupling is a much more complex solution.= The reality is that each end-point has value to contribute and thus the si= ngle-owner model will eventually need to become multi-owner or multi-hub.&n= bsp;

 

That said i think the current model provides a pract= ical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved.  On one hand this makes PATCH semantics easier.  On = the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emman= uel.  I had started writing up a similar response.  As you sugges= t, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that= SCIM is just a piece of the architecture for this solution, and is only re= sponsible for the transport layer between domains.

 

You could al= so model these ID mappings in the SCIM user as an extension but would proba= bly not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| a99a5feba839   =     | D2        &nbs= p;        | 7a87f27c1dd8  &nbs= p;    | true        = |

 

This could b= e represented as two SCIM users that contain information about the entities= on other domains.

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }=

    ]

  }

}

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "a99= a5feba839",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "7a87f27c1dd8"

      }=

    ]

  }

}

 

In the secon= d user, the linkedUsers attribute would be empty until the split user was s= ynced to domain 2.

 

 

Similarly, t= he false negative use case (merging two users) looked like this at the end:=

 

| Internal Entity ID | External = Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6   =     | D2        &nbs= p;        | ff487230b3a0  &nbs= p;    | true        = |

| 9caf78aac3d6   =     | D2        &nbs= p;        | 41206cc97c8b  &nbs= p;    | false        |

 

This could b= e represented with the following SCIM user:

 

{

  "schemas": [&qu= ot;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federa= tion:1.0"],

  "id": "9ca= f78aac3d6",

  "userName": &qu= ot;John Smith",

  "urn:scim:schemas:ex= tension:federation:1.0": {

    "linkedU= sers": [

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "ff487230b3a0"

      }= ,

      {=

     &n= bsp;  "domain": "D2",

     &n= bsp;  "externalEntityId": "41206cc97c8b",

     &n= bsp;  "deletionRequired": true

      }=

    ]

  }

}

 

 

Regarding un= ique identifiers for multi-valued attributes there is a trade-off involved.=   On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception = of SCIM, a key goal has been to foster adoption by service providers by mak= ing things fit easily onto existing systems.  IMO the value gained by = unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think tha= t vendors that have a non-SCIM-compliant API will choose to keep things tha= t way if the spec is too hard for them to implement.  In a green field= environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we canR= 17;t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

= Hi Ganesh,

=  

Nothing prev= ents you in your SCIM implementation (client or server) to generate a uniqu= e identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).<= /span>

 

This is what= we are doing with Active Directory sources or targets:

As we didn&#= 8217;t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) ar= e subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids= . This fits your requirements as it hides internal ids.

 

This was wri= tten in dotnet and we have started a project to rewrite our SCIM stack in P= HP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will gi= ve the choice of “hiding” internalIDs or use them as unique ID.=

 

You can also= implement such feature without violating the SCIM specs, or without asking= to include it in the specs.

 

= --

= Regards,

= Emmanuel Dreux

= http://www.cloudiway= .com

= Tel: +33 4 2= 6 78 17 58

= Mobile: +33 6 4= 7 81 26 70

= skype: Emmanuel.Dreux

=  

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi = Kelly,

Tha= nks for your response. Let me first respond in brief to the two main points= you have made, and then elaborate on the first.

1.&nbs= p;     Why should domains not = expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when “false negative= s” and “false positives” are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both “SCIM-compliant” and &= #8220;non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. L= egacy customers can be supported using a “non-SCIM-compliant” A= PI for an arbitrarily long period and gradually migrated to the SCIM-compli= ant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Ela= boration of Point 1:

Whe= n we consider federated identity across more than one domain, we have to as= sume that domains are not necessarily master-slave in their interaction. Th= e most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified t= o other domains (when necessary) in an asynchronous manner (i.e., through m= essaging) and the other domains are free to respond to these events in an a= ppropriate manner and at a time of their convenience.

A k= ey set of lifecycle events for an entity is the merging and splitting of id= entity that is often required.

The= question “Is this one entity?” can be answered either yes (pos= itive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Con= sider a case where customers sign up online, and two customers who are priv= acy-conscious enter fake IDs such as “John Smith”, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Con= sider the opposite case where a customer signs up through two different por= tals or in two different sessions, using the names “JSmith” and= “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

The= se are not theoretical use cases. They form a significant proportion of the= user base in most large Web-facing applications. Let's see how these can b= e managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. = False positives:

Dom= ain 1 has the following information about a customer in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Whe= n requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifier:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

Whe= n the false positive is discovered and the entity is split, Domain 1 create= s a new internal identifier and now has the following entity information.

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Int= ernal ID: a99a5feba839

Att= ributes: {name: “John Smith”, dob: “01-Jan-1970”}

Thi= s second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes place = as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (imp= ortantly, this doesn't have to be at the time the split happens), Domain 2 = can be requested to provision a second entity, and when it responds with an= identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The= mapping table now contains the following entries:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| a99a5feba839 = | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happene= d, and the provisioning that it does is not in lockstep with the split in i= dentity that occurred in Domain 1.

(Wh= at is the “Primary flag” used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Dom= ain 1 has the following information about what it thinks are two distinct c= ustomers in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: “JSmith”, dob: “01-Jan-1970”}

Int= ernal ID: 273d36e30d09

Att= ributes: {name: “JohnS”, dob: “01-Jan-1970”}=

Whe= n requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifiers:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 273d36e30d09 = | D2 | 41206cc97c8b | true |

Whe= n the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the cu= stomer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the secon= d “273d36e30d09”.

The= mapping table now looks like this:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 = | D2 | 41206cc97c8b | false |

Now= two external identifiers map to the same internal one, so inbound communic= ation from Domain 2 can be unambiguously translated to the same entity inte= rnally. However, when going outwards, Domain 1 will have to look up the translation table to determine the ̶= 0;primary” external ID for this entity in Domain 2, which was decided= to be “ff487230b3a0”. That's where the “Primary flagR= 21; comes in. The second external ID “41206cc97c8b” is never us= ed thereafter in outbound communication.

At = some stage (importantly, not in lockstep with the identity merge), Domain 2= can be requested to delete the customer record identified by “41206c= c97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

Thi= s scheme will scale up to multiple domains, because the “External Dom= ain ID” column helps to keep track of which external ID is shared wit= h which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling ag= ain. Just as OAuth allows an access token given to a third party to be inva= lidated without affecting the access of other third parties, the use of sep= arate external identifiers for different domains allows fine-grained control of identity federation.)

The= scheme also allows the splitting of an entity into more than two entities,= and the merging of more than two entities into a single one. (Any organisa= tion with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

Thi= s is a fairly long-winded explanation, but this is why we need to hide inte= rnal identifiers from other domains, and why mappings need to be managed in= ternally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of i= dentity events, since there is no consistency requirement to update multipl= e domains concurrently.

Reg= ards,

Gan= esh Prasad

 

On 9 August 2012 04:55,= Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for t= he feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not mea= ningfully use the enterprise client’s identifier, the "external = ID"

> at al= l, even though it was ostensibly introduced to make things friendlier for t= he client.

 

The usage pa= ttern for an external ID would be to search for a user by externalId and us= e the ID of the returned user in any desired operation.  For example:

 

GET /Users?f= ilter=3DexternalId eq “bjensen”&attributes=3Did

 

{

  “totalResults”= ;: 1,

  “Resources”: = [

    {

      &= #8220;id”: “2819c223-7f76-453a-919d-413861904646”<= /p>

    }

  ]

}

 

Retrieve the= ID from the response and use it.

 

DELETE /User= s/2819c223-7f76-453a-919d-413861904646

 

This does in= troduce an additional HTTP request if the client chooses not to store the s= erver’s id.  An issue was created to consider allowing operation= s to use the externalId (http://code.google.com/p/scim/issues/= detail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One = main point of contention is that much of the rest of the spec (eg – g= roup membership references, manager references, etc…) require knowled= ge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enter= prise client's ID are both "Internal IDs" with respect to their d= omains

 

I think this= comes down to a nomenclature problem.  The server’s ID does not= necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the = underlying identity store will provide identifiers with these properties al= ready (eg – a uuid) and it can be used by the SCIM interface.  T= he “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server&= #8217;s identifiers are stable and unique (which is mandated by the spec), = I don’t see a problem.

 

 

> The secret is that every valu= e needs a key, and multi-valued attributes lack that. So our solution i= s quite

> simpl= e - turn every list or array (of values) into a dictionary (of key-value pa= irs) by providing each value

> with = a unique and meaning-free identifier.

 

I agree that= this would be useful, especially in the PATCH operation.  One reason = that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are= putting SCIM interfaces in front of their existing identity stores (eg = 211; directory servers, SaaS application databases, etc…).  Many= of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers wo= uld have to start maintaining a unique key for each multi-valued attribute.=   I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, th= ere are areas where it seems a bit clumsy.

 

I like the t= houghts here.  Your example reminds me of unified diffs (ht= tp://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent o= f the PATCH verb).  However, the three proposals seem to largely hinge= on being able to uniquely address each element within an object.  Wit= hout these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-stat= us.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci= m-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of = SCIM which may require review, such as its synchronous request-response

> inter= action model, which is a form of tight coupling and could prove to be a sou= rce of brittleness.

 

I agree that= we should explore optional asynchronous requests in 2.0.

 

Thanks again= for your thoughts.  I hope you stay involved in the discussion as wor= k on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org=
Subject: [scim] SCIM Protocol - 3 suggestions for improvement=

 

(I posted this on the SCIM Google Group, = and I was advised to subscribe to the mailing list and post it here instead= , so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experien= ce in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eB= ook on InfoQ (http://www.infoq.com/minibooks/Identity-Mana= gement-Shoestring).

 

I have been following the SCIM spec off a= nd on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud pr= ovider should maintain their own internal IDs for a resource, which they sh= ould not reveal to each other. Both of them should map their internal IDs t= o a shared External ID, and this is the only ID that should be exposed through the API. The current specificat= ion's provision of an id (which is the external ID and the only one to be t= ransferred through the API) and an "external ID" (which is the cl= ient's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attribu= tes of a resource (expressed as arrays in JSON), they must be converted fro= m an array into a dictionary with unique keys (UUIDs generated by the cloud= provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating = it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3= significant ways:

3a. Leverage the fact (from 2 above) that= every value has a key, to greatly simplify the API

3b. Use special verbs as nested operation= s of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "2= 07 Multi-Status" instead of "200 OK" as the response to a PA= TCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is to = split (or merge) identities when false positives (or false negatives) are d= etected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the sam= e. If internal identifiers are revealed to external domains, such clean-ups= become difficult, hence every domain that wants to expose references to a = resource must map its internal ID to and external one created for this explicit purpose, and only reveal thi= s.

 

In the SCIM case, when an enterprise clie= nt POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only = return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-gen= erated internal ID of its own. In case the resource already has an identifi= er within the enterprise client's domain, then this is the internal ID that= must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and on= e of its attributes is multi-valued, e.g.,

 

    "email-addrs" :&n= bsp;

    [

        "john_smith@yahoo.com= ",

        "john.smith@gmail.com= ",

        "jsmith1970@hotmail.com= "

< 

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

 


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

 

 



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.
 --_000_D8A3C5E7F4A8B44BB49BF6E8D140E4A60BF4EE0Fwhistlerentgart_-- From g.c.prasad@gmail.com Fri Aug 10 16:19:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833B311E80E1 for ; Fri, 10 Aug 2012 16:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raZdRGAkSw35 for ; Fri, 10 Aug 2012 16:19:27 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CA2C211E80AD for ; Fri, 10 Aug 2012 16:19:26 -0700 (PDT) Received: by bkty7 with SMTP id y7so871214bkt.31 for ; Fri, 10 Aug 2012 16:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KBuCV8j6GnYqULKXnwky58JtZ5fr8rMLCH7gzKwUBxM=; b=fIVrlXkipwncEkAAdjEUW17yddMToN87R3ugtrJ/+Ycz8jmjkTkAP68b95kh9aufpr RukfrKr3WdjHSHg2JevPLopoRw7tAxCpJSpwQV3XWHrXoIAJtKY/ICcLRkCSokn5oLz7 nFMNry+IEBj+4EMWzQw5ZbkLNuIMV029g3tNvBZWFEdbkhiVcRICrv7HYfnGbig0Icol u6uY3EjvtBYshm53SCBH9Q5Mo2Ljgg3fOvbAUwt3MO6bMbs2OlCXy5gtPOf4WfimfY77 db1byV+Yoz0ObeR2LJPl/FMreJHZMcUs0ByUfVgDvPW4rtVzd2ZsUOUlx1fqYDkZN9Mw VVLw== Received: by 10.204.156.87 with SMTP id v23mr1939081bkw.0.1344640765673; Fri, 10 Aug 2012 16:19:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Fri, 10 Aug 2012 16:19:05 -0700 (PDT) In-Reply-To: <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 09:19:05 +1000 Message-ID: To: "Diodati,Mark" Content-Type: multipart/alternative; boundary=0015175cba223042fe04c6f1931a Cc: "scim@ietf.org" , Phil Hunt , Kelly Grizzle , Trey Drake , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:19:32 -0000 --0015175cba223042fe04c6f1931a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuitive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of the specialised (and semantically less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the corresponding JSON object. All of them return "207 Multi-Status" with the "results" array holding individual status codes. In the current spec, (a) and (b) are done similarly but (c) is very different. Pro 3: Adoption of the standard by clients is likely to be higher because it's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier to implement because they have no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory format (where multi-valued attributes are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I could have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus implementation complexity (my suggestion). Both can hinder adoption of the spec by different parties. Here's what we need to discuss - Do the Pros make the suggestion worth adopting in spite of the Cons, or are the Cons so great that it's best to leave the spec as it is? Keep in mind that a complex spec that only favours incumbent cloud providers can cut both ways. It opens the door to a simpler interface offered by a new generation of nimbler SPs that don't have the same legacy issues, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, because the API interface is very complex and clumsy, as any new reader can attest. I was taken aback by the complexity when I saw it, which is why I was prompted to suggest something simpler. This is an issue where we need the opinions of many people, and they need to state their affiliations. If most people weighing in belong to incumbent SPs and they vote in favour of interface complexity to avoid implementation complexity, then it means the spec is not doing a good job of balancing the interests of various groups. I think we should also poll client organisations to see what they would want. (Gartner is trusted by enterprise clients to evaluate the capabilities of vendors (SPs). I believe Gartner should take the lead in representing client interests in this working group rather than those of incumbent vendors, which is what it seems like to me. Correct me if I'm being unfair.= ) Regards, Ganesh On 11 August 2012 01:35, Diodati,Mark wrote: > Hi Ganesh, > > > > I am concerned about your second suggestion: > > =932. When dealing with multi-valued attributes of a resource (expressed = as > arrays in JSON), they must be converted from an array into a dictionary > with unique keys (UUIDs generated by the cloud provider when the attribut= e > is created). Without unique keys for every attribute value of a resource, > manipulating it will be clumsy and inelegant.=94 > > > > One of the primary reasons that SPML failed was lack of adoption by > service providers due to its complexity. Very few target applications > implemented SPML. Most of the commercial provisioning systems had an SPML > interface (either v1 or v2), but not one of them was conformant to the SP= ML > standard because of complexity. If you are interested, I will forward you > the research documents that discuss these problems in detail. For SCIM to > be successful, it must be adopted by commercial target applications (i.e.= , > service providers). I am confident that a requirement for unique > identifiers with multi-valued attributes will preclude its adoption, > because it requires major changes to the service provider=92s existing > identity storage mechanisms. > > Mark > > > > > > > > *From:* Trey Drake [mailto:trey.drake@unboundid.com] > *Sent:* Friday, August 10, 2012 9:51 AM > > *To:* Ganesh and Sashi Prasad > *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt > > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > > > Ganesh, > > > > I'll base my comments on your latest reply (below). > > > > The externalID is not part of the protocol. It is an *optional* attribut= e > within the *schema* specification. As for #2, the protocol spec works as > you describe if "arbitrary URI parameters" equate to resource attributes > (Allow generic search using 'GET /Users' and arbitrary URI parameters). > Please clarify your suggestion. > > > > I'm not tracking your coupling concern. The client can search and hence > retrieve resources on any attribute it chooses, externalId or otherwise. > Nothing mandates use of externalId. > > > > > > What do you mean by "candidate key"? Given > > > > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> wrote: > > > I think scim gets its current simplicity from its single owner hub > spoke model implementing tight coupling. [...] IMHO loose coupling is a > much more complex solution. > > > > Phil, > > > > I'm a bit surprised that you're implying "tight coupling =3D=3D simple" a= nd > "loose coupling =3D=3D complex". That's contrary to my experience. > > > > When I say "loose coupling", I mean "no unnecessary dependencies". > Invariably, a reduction in dependencies leads to greater simplicity. > > > > Let's not confuse reduction of dependencies in the data model with a > hub-and-spokes architecture. They're entirely orthogonal aspects of the > solution. > > > > All that my suggestion involves is, > > > > 1. Take 'external ID' out of the protocol. > > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters > > > > No planned functionality is lost by this. > > > > 1. The client enterprise can still send its internal ID as part of the > resource body, inside some attribute defined by them (but not defined by > the protocol). Let's say they call it 'myID'. > > 2. The client enterprise can search for resource URIs using any attribute= , > including this internal ID > > 'GET /Users?myID=3Dbjensen' > > Since myID is a candidate key, the server will return exactly one URI, > which is the canonical URI for the resource > > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > > 3. The client can use this URI to perform all other operations as usual. > > > > So taking 'externalID' out of the protocol spec only does this: > > 1. It avoids enshrining tight coupling in the protocol (If clients want t= o tightly couple themselves to the cloud provider by sending their internal= IDs, they can do so. Suicide is OK, but the protocol should not be guilty = of assisted suicide. ;-) > > 2. It encourages loose coupling by nudging clients towards maintaining th= eir own internal-to-external identifier mappings. > > > > That's what I'd like to see. I don't believe this complicates the protoco= l. It simplifies it and it also lends itself to a loosely-coupled approach. > > > > I'll address the multi-valued attribute suggestion separately. > > > > Regards, > > Ganesh > > > > > > > > > > On 10 August 2012 07:53, Phil Hunt wrote: > > > > Phil > > > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > > > storing this information in a mapping table outside of the SCIM spec > is a great way to enable this solution. Part of the key here is that SCI= M > is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains. > > I wasn't suggesting that the mapping table be part of the SCIM spec. I > provided that example to illustrate that splitting and merging identities > is a common requirement, and that decoupling local identifiers within a > domain from shared identifiers between domains was the best way to > facilitate it. > > > > I'm suggesting that the spec do less, not more. > > > > What the SCIM spec needs to do there is just refrain from introducing > tight coupling. I would like to see a single identifier exposed through t= he > API, with the implication (and perhaps the recommendation) that it be the > shared one. Allowing one domain to expose its internal identifier to the > other creates tight coupling and ensures that both domains need > simultaneously split or merge identities, which is not desirable. So I > recommend _taking out_ the "external id" field from the API. The spec > shouldn't encourage tight coupling. If clients want to pass in their > internal ids as part of the resource body, no one can stop them, and they > can always do a search on that attribute to retrieve the URI exactly as y= ou > visualise they will with the "external id", but let's not elevate an > anti-pattern to a recommendation by enshrining the "external id" as an > acceptable attribute. > > > > Am I making sense? > > > > I see what you are saying. I think scim gets its current simplicity from > its single owner hub spoke model implementing tight coupling. > > > > IMHO loose coupling is a much more complex solution. The reality is that > each end-point has value to contribute and thus the single-owner model wi= ll > eventually need to become multi-owner or multi-hub. > > > > That said i think the current model provides a practical starting point. > > > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. > > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. You > know where I stand on this. It would be good to hear the spectrum of > opinions. > > > > Regards, > > Ganesh > > On 10 August 2012 00:28, Kelly Grizzle > wrote: > > Thanks Emmanuel. I had started writing up a similar response. As you > suggest, storing this information in a mapping table outside of the SCIM > spec is a great way to enable this solution. Part of the key here is tha= t > SCIM is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains. > > > > You could also model these ID mappings in the SCIM user as an extension > but would probably not want to expose these externally. Here is an examp= le > of how to model the end state of the false positive scenario (splitting a > user): > > > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | > true | > > > > This could be represented as two SCIM users that contain information abou= t > the entities on other domains. > > > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > } > > ] > > } > > } > > > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "a99a5feba839", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "7a87f27c1dd8" > > } > > ] > > } > > } > > > > In the second user, the linkedUsers attribute would be empty until the > split user was synced to domain 2. > > > > > > Similarly, the false negative use case (merging two users) looked like > this at the end: > > > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | > false | > > > > This could be represented with the following SCIM user: > > > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > }, > > { > > "domain": "D2", > > "externalEntityId": "41206cc97c8b", > > "deletionRequired": true > > } > > ] > > } > > } > > > > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. Since the inceptio= n > of SCIM, a key goal has been to foster adoption by service providers by > making things fit easily onto existing systems. IMO the value gained by > unique identifiers for multi-valued attributes is not worth the demands p= ut > on a service provider. I also think that vendors that have a > non-SCIM-compliant API will choose to keep things that way if the spec is > too hard for them to implement. In a green field environment we do have > the luxury of mandating a model to make certain operations more elegant. > However, we can=92t ignore legacy systems. > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > > > Hi Ganesh, > > > > Nothing prevents you in your SCIM implementation (client or server) to > generate a unique identifier for each synchronized object and maintain an > internal mapping table ( you would have to map group membership as well). > > > > This is what we are doing with Active Directory sources or targets: > > As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNam= e, > UPN) are subject to change (even objectGuid can change if an AD domain is > migrated), we decided to generate and maintain an internal table of ids. > This fits your requirements as it hides internal ids. > > > > This was written in dotnet and we have started a project to rewrite our > SCIM stack in PHP and will give it to the Open Source community. This > implementation will have a parameter : AllocateIds versus UseExistingIDs. > > This will give the choice of =93hiding=94 internalIDs or use them as uniq= ue ID. > > > > You can also implement such feature without violating the SCIM specs, or > without asking to include it in the specs. > > > > -- > > Regards, > > Emmanuel Dreux > > http://www.cloudiway.com > > Tel: +33 4 26 78 17 58 > > Mobile: +33 6 47 81 26 70 > > skype: Emmanuel.Dreux > > > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > > *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > > > Hi Kelly, > > Thanks for your response. Let me first respond in brief to the two main > points you have made, and then elaborate on the first. > > 1. Why should domains not expose their internal identifiers to other > domains? > > a. > > We are designing a protocol for a federated system of domains, where all > domains are co-equal peers. (In physics too, N-body problems are much > harder than 2-body problems. :-) Therefore, assuming that there are only > two players in the interaction makes this tightly coupled in a number of > ways. We should rely on messaging and notification, with encapsulation of > domain-specific data. > > b. > > In any non-trivial data store, there will always be the ongoing need to > merge and split identities as and when =93false negatives=94 and =93false > positives=94 are discovered. A domain should be able to handle this inter= nal > housekeeping freely, only notifying other domains when convenient. Mappin= g > of internal identifiers to external ones and maintaining this mapping > internally allows this loosely-coupled housekeeping to take place. Sharin= g > internal identifiers (or otherwise outsourcing the mapping of internal to > external identifiers) forces housekeeping activities to be done in > lock-step across domains. > > c. > > Asynchronous interaction is not just a matter of a suitable wire protocol > which can be designed later. The data model plays a crucial role in > enabling or constraining such interaction. A tightly-coupled data model > will force the use of synchronous interactions, and the exposure of > internal identifiers is a key part of this tight coupling. > > 2. The difficulty of assigning unique identifiers to the individual value= s > of multi-valued attributes: > > a. > > I'm not belittling the effort involved in migrating legacy data stores to > such a model. However, in the larger historical context of cross-domain > identity management, we are really at the very early stages. If a > relatively new discipline and a brand new spec are held captive to legacy > considerations, we are losing an opportunity to provide a clean and elega= nt > model to subsequent users of the spec, and this will have repercussions > over many years or even decades. > > b. > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can transitio= n > to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-compl= iant=94 > APIs to their customers and encouraging new customers to adopt the > =93SCIM-compliant=94 API. Legacy customers can be supported using a > =93non-SCIM-compliant=94 API for an arbitrarily long period and gradually > migrated to the SCIM-compliant API. The logistics are not insurmountable, > and shouldn't prevent the adoption of a dictionary model for multi-valued > attributes. > > Elaboration of Point 1: > > When we consider federated identity across more than one domain, we have > to assume that domains are not necessarily master-slave in their > interaction. The most generic interaction model is peer-to-peer, where > entity lifecycle events within a domain are notified to other domains (wh= en > necessary) in an asynchronous manner (i.e., through messaging) and the > other domains are free to respond to these events in an appropriate manne= r > and at a time of their convenience. > > A key set of lifecycle events for an entity is the merging and splitting > of identity that is often required. > > The question =93Is this one entity?=94 can be answered either yes (positi= ve) > or no (negative). But sometimes, we can discover false positives and fals= e > negatives in our data stores. > > Consider a case where customers sign up online, and two customers who are > privacy-conscious enter fake IDs such as =93John Smith=94, and also use t= he > same date of birth (say, 1 Jan 1970) or similar attributes. The front-end > application may make an intelligent (but incorrect) guess that these two > persons are the same, and re-assign the same identifier to the second > person. This is a false positive. They appear to be the same entity, but > they're actually different. When the error is discovered, the identities > will need to be split, with a new identifier generated for one of them. > > Consider the opposite case where a customer signs up through two differen= t > portals or in two different sessions, using the names =93JSmith=94 and = =93JohnS=94. > It is very likely that they will be treated as two different customers an= d > assigned two unique identifiers. This is a false negative. They appear to > be two entities, but are actually the same. At a later stage, when the > error is discovered, the identities will have to be merged, and one of th= e > identifiers will have to be dropped. > > These are not theoretical use cases. They form a significant proportion o= f > the user base in most large Web-facing applications. Let's see how these > can be managed in a federated way by mapping internal identifiers to > external ones and only exposing external identifiers to other domains. > > a. False positives: > > Domain 1 has the following information about a customer in its data store= : > > Internal ID: 9caf78aac3d6 > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} > > When requesting the provisioning of this entity in Domain 2, the followin= g > ID is returned by Domain 2: ff487230b3a0. > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifier: > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > When the false positive is discovered and the entity is split, Domain 1 > creates a new internal identifier and now has the following entity > information. > > Internal ID: 9caf78aac3d6 > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} > > Internal ID: a99a5feba839 > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} > > This second entity with its own internal identifier is invisible to Domai= n > 2, and this is by design. Communication about the original entity takes > place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and v= ice-versa. > At some convenient time (importantly, this doesn't have to be at the time > the split happens), Domain 2 can be requested to provision a second entit= y, > and when it responds with an identifier of =937a87f27c1dd8=94, this can g= o into > the mapping table as a new record associated with the second entity's > internal identifier. > > The mapping table now contains the following entries: > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > > Domain 2 is not even aware that a split has happened, and the provisionin= g > that it does is not in lockstep with the split in identity that occurred = in > Domain 1. > > (What is the =93Primary flag=94 used for? We'll see when we cover the > treatment of false negatives.) > > b. False negatives: > > Domain 1 has the following information about what it thinks are two > distinct customers in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} > > Internal ID: 273d36e30d09 > > Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} > > When requesting the provisioning of these entities in Domain 2, the > following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifiers: > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 273d36e30d09 | D2 | 41206cc97c8b | true | > > When the false negative is discovered and the two entities are merged, > Domain 1 drops one of the internal identifiers and rationalises the name = of > the customer (say, to =93John Smith=94). Let's say it retains the first I= D > =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. > > The mapping table now looks like this: > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > > Now two external identifiers map to the same internal one, so inbound > communication from Domain 2 can be unambiguously translated to the same > entity internally. However, when going outwards, Domain 1 will have to lo= ok > up the translation table to determine the =93primary=94 external ID for t= his > entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's wh= ere > the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never > used thereafter in outbound communication. > > At some stage (importantly, not in lockstep with the identity merge), > Domain 2 can be requested to delete the customer record identified by > =9341206cc97c8b=94, and the second entry in the mapping table can be remo= ved > once this is acknowledged. > > This scheme will scale up to multiple domains, because the =93External > Domain ID=94 column helps to keep track of which external ID is shared wi= th > which Domain. (Why don't we use just one external ID for an entity and > share it with all external domains? Tight coupling again. Just as OAuth > allows an access token given to a third party to be invalidated without > affecting the access of other third parties, the use of separate external > identifiers for different domains allows fine-grained control of identity > federation.) > > The scheme also allows the splitting of an entity into more than two > entities, and the merging of more than two entities into a single one. (A= ny > organisation with a web-facing application will tell you how many John > Smiths there are who were born on 1 Jan 1970!) > > This is a fairly long-winded explanation, but this is why we need to hide > internal identifiers from other domains, and why mappings need to be > managed internally in each domain. Such a data model also allows us to > choose asynchronous protocols for propagation of identity events, since > there is no consistency requirement to update multiple domains concurrent= ly. > > Regards, > > Ganesh Prasad > > > > On 9 August 2012 04:55, Kelly Grizzle wrote= : > > Thanks for the feedback, Ganesh. I read through this and your InfoQ > article (http://www.infoq.com/articles/scim-data-model-limitations) and > have some thoughts. > > > > > The rest of the protocol does not meaningfully use the enterprise > client=92s identifier, the "external ID" > > > at all, even though it was ostensibly introduced to make things > friendlier for the client. > > > > The usage pattern for an external ID would be to search for a user by > externalId and use the ID of the returned user in any desired operation. > For example: > > > > GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did > > > > { > > =93totalResults=94: 1, > > =93Resources=94: [ > > { > > =93id=94: =932819c223-7f76-453a-919d-413861904646=94 > > } > > ] > > } > > > > Retrieve the ID from the response and use it. > > > > DELETE /Users/2819c223-7f76-453a-919d-413861904646 > > > > This does introduce an additional HTTP request if the client chooses not > to store the server=92s id. An issue was created to consider allowing > operations to use the externalId ( > http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the > general consensus has been to not include this in the spec. One main poi= nt > of contention is that much of the rest of the spec (eg =96 group membersh= ip > references, manager references, etc=85) require knowledge of the server= =92s > identifier. Continuing this discussion on the IETF list would be a good > thing, though. > > > > > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains > > > > I think this comes down to a nomenclature problem. The server=92s ID doe= s > not necessarily have to be the unique identifier that the underlying > identity store uses, it just has to be stable and unique. In many cases, > the underlying identity store will provide identifiers with these > properties already (eg =96 a uuid) and it can be used by the SCIM interfa= ce. > The =93externalId=94 is referring to the fact that the id is maintained > external to the SCIM server. As long as the server=92s identifiers are > stable and unique (which is mandated by the spec), I don=92t see a proble= m. > > > > > > > The secret is that *every value needs a key*, and multi-valued > attributes lack that. So our solution is quite > > > simple - turn every list or array (of values) into a dictionary (of > key-value pairs) by providing each value > > > with a unique and meaning-free identifier. > > > > I agree that this would be useful, especially in the PATCH operation. On= e > reason that this wasn=92t included in the spec originally is that it can = put > undue burden on the service provider. Many service providers are putting > SCIM interfaces in front of their existing identity stores (eg =96 direct= ory > servers, SaaS application databases, etc=85). Many of these do not have = a > unique identifier for multi-valued attributes. By requiring this, a > majority of the server providers would have to start maintaining a unique > key for each multi-valued attribute. I believe this would be a roadblock > for many implementers. > > > > > > > When the SCIM protocol uses PATCH, there are areas where it seems a bit > clumsy. > > > > I like the thoughts here. Your example reminds me of unified diffs ( > http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly > used with a patch program (pretty much the equivalent of the PATCH verb). > However, the three proposals seem to largely hinge on being able to > uniquely address each element within an object. Without these it is not = so > easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or > provide a multi-status. > > > The 207 response would be interesting to consider for the bulk endpoint ( > http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however. > > > > > > > There are other, non-data aspects of SCIM which may require review, > such as its synchronous request-response > > > interaction model, which is a form of tight coupling and could prove to > be a source of brittleness. > > > > I agree that we should explore optional asynchronous requests in 2.0. > > > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward. > > > > --Kelly > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement > > > > (I posted this on the SCIM Google Group, and I was advised to subscribe t= o > the mailing list and post it here instead, so here goes.) > > > > Hi, > > > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian insurance > company, an experience I have written about as a eBook on InfoQ ( > http://www.infoq.com/minibooks/Identity-Management-Shoestring). > > > > I have been following the SCIM spec off and on, and based on my experienc= e > with a loosely-coupled architecture that I found to be successful, I have > the following 3 suggestions to make. > > > > 1. The enterprise client and the cloud provider should maintain their own > internal IDs for a resource, which they should not reveal to each other. > Both of them should map their internal IDs to a shared External ID, and > this is the only ID that should be exposed through the API. The current > specification's provision of an id (which is the external ID and the only > one to be transferred through the API) and an "external ID" (which is the > client's internal ID and should be hidden) is diametrically opposite to > this. > > > > 2. When dealing with multi-valued attributes of a resource (expressed as > arrays in JSON), they must be converted from an array into a dictionary > with unique keys (UUIDs generated by the cloud provider when the attribut= e > is created). Without unique keys for every attribute value of a resource, > manipulating it will be clumsy and inelegant. > > > > 3. The PATCH command can be improved in 3 significant ways: > > 3a. Leverage the fact (from 2 above) that every value has a key, to > greatly simplify the API > > 3b. Use special verbs as nested operations of the PATCH command to add, > modify and delete attributes at any level > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" > as the response to a PATCH (or BULK) command. > > > > To elaborate, > > > > 1. Revealing private IDs externally is a form of tight coupling. A major > requirement with Identity Management is to split (or merge) identities wh= en > false positives (or false negatives) are detected, i.e., when a resource = is > discovered to be more than one, or when multiple resources are detected t= o > be the same. If internal identifiers are revealed to external domains, su= ch > clean-ups become difficult, hence every domain that wants to expose > references to a resource must map its internal ID to and external one > created for this explicit purpose, and only reveal this. > > > > In the SCIM case, when an enterprise client POSTs a resource creation > request, the cloud provider must generate its own internal UUID as well a= s > an external UUID, map them together, and only return the external UUID in > the "Location:" header. The enterprise client should map this external UU= ID > to a newly-generated internal ID of its own. In case the resource already > has an identifier within the enterprise client's domain, then this is the > internal ID that must be mapped to the external UUID returned through the > POST response. > > > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g., > > > > "email-addrs" : > > [ > > "john_smith@yahoo.com", > > "john.smith@gmail.com", > > "jsmith1970@hotmail.com" > > < > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > ------------------------------ > > This e-mail message, including any attachments, is for the sole use of th= e > person to whom it has been sent, and may contain information that is > confidential or legally protected. If you are not the intended recipient = or > have received this message in error, you are not authorized to copy, > distribute, or otherwise use this message or its attachments. Please noti= fy > the sender immediately by return e-mail and permanently delete this messa= ge > and any attachments. Gartner makes no warranty that this e-mail is error = or > virus free. > --0015175cba223042fe04c6f1931a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =A0>=A0=A0I am concerned about your second suggestion:=A0=

Let's discuss that now.

Th= e trade-offs are very clear here.

Pros:

Pro 1. The API to manipu= late resources becomes so much cleaner, consistent and intuitive when every= individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current s= pec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to th= e current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3=
f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very in= tuitive.=A0
With my suggestion, here's how to delete a single= member from a group:

PATCH /Groups/acbf3ae7-846= 3-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more c= onsistent and more intuitive to a reader.

Pro 2: W= e can apply this mechanism consistently to three areas:
(a) Manip= ulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk oper= ations, where we simply use HTTP verbs instead of the specialised (and sema= ntically less ambiguous) verbs I suggested for attributes, the "key&qu= ot; becomes the URI, and the "value" becomes the corresponding JS= ON object.

All of them return "207 Multi-Status" with th= e "results" array holding individual status codes.

=
In the current spec, (a) and (b) are done similarly but (c) is v= ery different.

Pro 3: Adoption of the standard by clients is likely to= be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to im= plement because they have no legacy. They will probably use some form of No= SQL database and won't be constrained by the limitations of LDAP direct= ories.

Cons:

Con 1: Incumbent cloud p= roviders with existing data stores in a directory format (where multi-value= d attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each attrib= ute value as a sub-node with its own key. This will "hinder adoption o= f the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm b= iased of course, so I could have missed a Con or hyped a Pro :-).

In other words, we're debating= interface complexity (current spec) versus implementation complexity (my s= uggestion). Both can hinder adoption of the spec by different parties.

Here's what we need to discuss - Do the Pros make t= he suggestion worth adopting in spite of the Cons, or are the Cons so great= that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, a= nd there could be an exodus of clients to these new SPs. SCIM could end up = being obsoleted very soon, because the API interface is very complex and cl= umsy, as any new reader can attest. I was taken aback by the complexity whe= n I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peo= ple, and they need to state their affiliations. If most people weighing in = belong to incumbent SPs and they vote in favour of interface complexity to = avoid implementation complexity, then it means the spec is not doing a good= job of balancing the interests of various groups. I think we should also p= oll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate t= he capabilities of vendors (SPs). I believe Gartner should take the lead in= representing client interests in this working group rather than those of i= ncumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.)

Regards,
Ganesh



On 11 August = 2012 01:35, Diodati,Mark <Mark.Diodati@gartner.com> w= rote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0

=A0

=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM

To: Ganesh and Sashi Prasad
Cc: scim@ie= tf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0

=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0




On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0





I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0






I'm suggesting that the spec do less, not more.<=
/p>



=A0




What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0






Am I making sense?










=A0






I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0






IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0








=A0






That said i think the current model provides a pract=
ical starting point.=A0














=A0






>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.








=A0






Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec
 is a great way to enable this solution.=A0 Part of the key here is that SC=
IM is just a piece of the architecture for this solution, and is only respo=
nsible for the transport layer between domains.


=A0


You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example
 of how to model the end state of the false positive scenario (splitting a =
user):




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.




=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.




=A0


=A0


Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 with the following SCIM user:


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


=A0


Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other
 hand it puts extra burden on service providers.=A0 Since the inception of =
SCIM, a key goal has been to foster adoption by service providers by making=
 things fit easily onto existing systems.=A0 IMO the value gained by unique=
 identifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0


--Kelly


=A0






From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0


Hi Ganesh,


=A0

Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an
 internal mapping table ( you would have to map group membership as well).<=
/span>


=A0


This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain
 is migrated), we decided to generate and maintain an internal table of ids=
. This fits your requirements as it hides internal ids.


=A0


This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0


You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.




=A0


--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com




Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0



De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0


Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=






b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.




Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.




Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.




(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambiguously translated to the same entity inter=
nally. However, when going outwards,
 Domain 1 will have to look up the translation table to determine the =93pr=
imary=94 external ID for this entity in Domain 2, which was decided to be =
=93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The s=
econd external ID =9341206cc97c8b=94 is never used thereafter
 in outbound communication.


At s=
ome stage (importantly, not in lockstep with the identity merge), Domain 2 =
can be requested to delete the customer record identified by =9341206cc97c8=
b=94, and the second entry in the mapping
 table can be removed once this is acknowledged.


This=
 scheme will scale up to multiple domains, because the =93External Domain I=
D=94 column helps to keep track of which external ID is shared with which D=
omain. (Why don't we use just one external
 ID for an entity and share it with all external domains? Tight coupling ag=
ain. Just as OAuth allows an access token given to a third party to be inva=
lidated without affecting the access of other third parties, the use of sep=
arate external identifiers for different
 domains allows fine-grained control of identity federation.)


The =
scheme also allows the splitting of an entity into more than two entities, =
and the merging of more than two entities into a single one. (Any organisat=
ion with a web-facing application will
 tell you how many John Smiths there are who were born on 1 Jan 1970!)


This=
 is a fairly long-winded explanation, but this is why we need to hide inter=
nal identifiers from other domains, and why mappings need to be managed int=
ernally in each domain. Such a data
 model also allows us to choose asynchronous protocols for propagation of i=
dentity events, since there is no consistency requirement to update multipl=
e domains concurrently.


Rega=
rds, 



Gane=
sh Prasad


=A0




On 9 August 2012 04:55, Kelly Griz=
zle <ke=
lly.grizzle@sailpoint.com> wrote:






Thanks for the feedback, =
Ganesh.=A0 I read through this and your InfoQ article (=
http://www.infoq.com/articles/scim-data-model-limitations)
 and have some thoughts.


=A0


>
The rest of the protocol does not meani=
ngfully use the enterprise client=92s identifier, the "external ID&quo=
t;




> at all, even thoug=
h it was ostensibly introduced to make things friendlier for the client.




=A0


The usage pattern for an =
external ID would be to search for a user by externalId and use the ID of t=
he returned user in any desired operation.=A0 For
 example:


=A0


GET /Users?filter=3Dexter=
nalId eq =93bjensen=94&attributes=3Did


=A0


{


=A0 =93totalResults=94: 1,


=A0 =93Resources=94: [


=A0=A0=A0 {


=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45=
3a-919d-413861904646=94


=A0=A0=A0 }


=A0 ]


}


=A0


Retrieve the ID from the =
response and use it.


=A0


DELETE /Users/2819c223-7f=
76-453a-919d-413861904646


=A0


This does introduce an ad=
ditional HTTP request if the client chooses not to store the server=92s id.=
=A0 An issue was created to consider allowing operations
 to use the externalId (http://code.google.com/p/scim/issues/=
detail?id=3D35), but I believe
 the general consensus has been to not include this in the spec.=A0 One mai=
n point of contention is that much of the rest of the spec (eg =96 group me=
mbership references, manager references, etc=85) require knowledge of the s=
erver=92s identifier.=A0 Continuing this discussion
 on the IETF list would be a good thing, though.


=A0


=A0


>
the cloud provider's ID and the ent=
erprise client's ID are both "Internal IDs" with respect to t=
heir domains




=A0


I think this comes down t=
o a nomenclature problem.=A0 The server=92s ID does not necessarily have to=
 be the unique identifier that the underlying identity
 store uses, it just has to be stable and unique.=A0 In many cases, the und=
erlying identity store will provide identifiers with these properties alrea=
dy (eg =96 a uuid) and it can be used by the SCIM interface.=A0 The =93exte=
rnalId=94 is referring to the fact that the
 id is maintained external to the SCIM server.=A0 As long as the server=92s=
 identifiers are stable and unique (which is mandated by the spec), I don=
=92t see a problem.


=A0


=A0


>
The secret is that=A0every value nee=
ds a key, and multi-valued attributes lack that. So our solution is qui=
te




> simple - turn ever=
y list or array (of values) into a dictionary (of key-value pairs) by provi=
ding each value




> with a unique and =
meaning-free identifier.


=A0


I agree that this would b=
e useful, especially in the PATCH operation.=A0 One reason that this wasn=
=92t included in the spec originally is that it can
 put undue burden on the service provider.=A0 Many service providers are pu=
tting SCIM interfaces in front of their existing identity stores (eg =96 di=
rectory servers, SaaS application databases, etc=85).=A0 Many of these do n=
ot have a unique identifier for multi-valued
 attributes.=A0 By requiring this, a majority of the server providers would=
 have to start maintaining a unique key for each multi-valued attribute.=A0=
 I believe this would be a roadblock for many implementers.


=A0


=A0


>
When the SCIM protocol uses PATCH, ther=
e are areas where it seems a bit clumsy.


=A0


I like the thoughts here.=
=A0 Your example reminds me of unified diffs (http://en.wikipedi=
a.org/wiki/Diff#Unified_format),
 which are commonly used with a patch program (pretty much the equivalent o=
f the PATCH verb). =A0However, the three proposals seem to largely hinge on=
 being able to uniquely address each element within an object.=A0 Without t=
hese it is not so easy to address each
 patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<=
/span>




The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci=
m-api-00.html#bulk-resources),
 however.


=A0


=A0


>
There are other, non-data aspects of SC=
IM which may require review, such as its synchronous request-response




> interaction model,=
 which is a form of tight coupling and could prove to be a source of brittl=
eness.




=A0


I agree that we should ex=
plore optional asynchronous requests in 2.0.


=A0


Thanks again for your tho=
ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go=
es forward.




=A0


--Kelly


=A0




From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Ganesh and Sashi Prasad

Sent: Wednesday, August 01, 2012 4:24 PM

To: scim@ietf.org=


Subject: [scim] SCIM Protocol - 3 suggestions for improvement=









=A0




(I posted this on the SCIM Google Group, and I was a=
dvised to subscribe to the mailing list and post it here instead, so here g=
oes.)






=A0






Hi,






=A0






My name is Ganesh Prasad, and my experience in Ident=
ity and Access Management is mainly through a 3-year project at an Australi=
an insurance company, an experience I have written about as a eBook on Info=
Q (http://www.infoq.com/minibooks/Identity-Management-Shoe=
string).








=A0






I have been following the SCIM spec off and on, and =
based on my experience with a loosely-coupled architecture that I found to =
be successful, I have the following 3 suggestions to make.






=A0






1. The enterprise client and the cloud provider shou=
ld maintain their own internal IDs for a resource, which they should not re=
veal to each other. Both of them should map their internal IDs to a shared =
External ID, and this is
 the only ID that should be exposed through the API. The current specificat=
ion's provision of an id (which is the external ID and the only one to =
be transferred through the API) and an "external ID" (which is th=
e client's internal ID and should be hidden) is
 diametrically opposite to this.






=A0






2. When dealing with multi-valued attributes of a re=
source (expressed as arrays in JSON), they must be converted from an array =
into a dictionary with unique keys (UUIDs generated by the cloud provider w=
hen the attribute is created).
 Without unique keys for every attribute value of a resource, manipulating =
it will be clumsy and inelegant.






=A0






3. The PATCH command can be improved in 3 significan=
t ways:






3a. Leverage the fact (from 2 above) that every valu=
e has a key, to greatly simplify the API






3b. Use special verbs as nested operations of the PA=
TCH command to add, modify and delete attributes at any level






3c. Use the WebDAV status code of "207 Multi-St=
atus" instead of "200 OK" as the response to a PATCH (or BUL=
K) command.






=A0






To elaborate,






=A0






1. Revealing private IDs externally is a form of tig=
ht coupling. A major requirement with Identity Management is to split (or m=
erge) identities when false positives (or false negatives) are detected, i.=
e., when a resource is discovered
 to be more than one, or when multiple resources are detected to be the sam=
e. If internal identifiers are revealed to external domains, such clean-ups=
 become difficult, hence every domain that wants to expose references to a =
resource must map its internal ID
 to and external one created for this explicit purpose, and only reveal thi=
s.






=A0






In the SCIM case, when an enterprise client POSTs a =
resource creation request, the cloud provider must generate its own interna=
l UUID as well as an external UUID, map them together, and only return the =
external UUID in the "Location:"
 header. The enterprise client should map this external UUID to a newly-gen=
erated internal ID of its own. In case the resource already has an identifi=
er within the enterprise client's domain, then this is the internal ID =
that must be mapped to the external
 UUID returned through the POST response.






=A0






2. If a resource is to be created, and one of its at=
tributes is multi-valued, e.g.,






=A0






=A0 =A0 "email-addrs" :=A0






=A0 =A0 [






=A0 =A0 =A0 =A0 "john_smith@yahoo.com",






=A0 =A0 =A0 =A0 "john.smith@gmail.com",






=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"






<=A0


































_______________________________________________

scim mailing list

scim@ietf.org

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










=A0


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

=A0



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.

--0015175cba223042fe04c6f1931a-- From phil.hunt@oracle.com Fri Aug 10 17:38:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D549321F84DF for ; Fri, 10 Aug 2012 17:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.309 X-Spam-Level: X-Spam-Status: No, score=-9.309 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA9c86T7D150 for ; Fri, 10 Aug 2012 17:38:49 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8831521F84DC for ; Fri, 10 Aug 2012 17:38:49 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7B0cg2Q012241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 00:38:43 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7B0cfmF025264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 00:38:42 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7B0ceYu023434; Fri, 10 Aug 2012 19:38:40 -0500 Received: from [10.20.239.250] (/204.239.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 17:38:13 -0700 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-AD3F1D5B-5CC8-431A-878D-F6CA3DCC682C Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 10 Aug 2012 17:36:54 -0700 To: Ganesh and Sashi Prasad X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "Diodati, Mark" , Emmanuel Dreux , Trey Drake , Kelly Grizzle , "scim@ietf.org" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 00:38:55 -0000 --Apple-Mail-AD3F1D5B-5CC8-431A-878D-F6CA3DCC682C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ganesh, In your example you are conflating value with an attribute id. I find that c= onfusing.=20 I agree though that operations in patch could be a lot more explicit.=20 Eg explicitly deleting a value by saying delete or retire.=20 Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad wrot= e: > > I am concerned about your second suggestion:=20 >=20 > Let's discuss that now. >=20 > The trade-offs are very clear here. >=20 > Pros: >=20 > Pro 1. The API to manipulate resources becomes so much cleaner, consistent= and intuitive when every individual attribute value gets its own ID. >=20 > Here's how to delete a single member from a Group, as per the current spec= : >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current spe= c: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20 > With my suggestion, here's how to delete a single member from a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] > } >=20 > Here's how I suggest deleting ALL members from a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] > } >=20 > I'm sure you'll agree that this is simpler, more consistent and more intui= tive to a reader. >=20 > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attri= butes, the "key" becomes the URI, and the "value" becomes the corresponding J= SON object. >=20 > All of them return "207 Multi-Status" with the "results" array holding ind= ividual status codes. >=20 > In the current spec, (a) and (b) are done similarly but (c) is very differ= ent. >=20 > Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. >=20 > Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form of= NoSQL database and won't be constrained by the limitations of LDAP director= ies. >=20 > Cons: >=20 > Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values un= der a single attribute node) will find it difficult to migrate to this model= and store each attribute value as a sub-node with its own key. This will "h= inder adoption of the spec", which is what you fear. >=20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so I c= ould have missed a Con or hyped a Pro :-). >=20 > In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the sp= ec by different parties. >=20 > Here's what we need to discuss - Do the Pros make the suggestion worth ado= pting in spite of the Cons, or are the Cons so great that it's best to leave= the spec as it is? >=20 > Keep in mind that a complex spec that only favours incumbent cloud provide= rs can cut both ways. It opens the door to a simpler interface offered by a n= ew generation of nimbler SPs that don't have the same legacy issues, and the= re could be an exodus of clients to these new SPs. SCIM could end up being o= bsoleted very soon, because the API interface is very complex and clumsy, as= any new reader can attest. I was taken aback by the complexity when I saw i= t, which is why I was prompted to suggest something simpler. >=20 > This is an issue where we need the opinions of many people, and they need t= o state their affiliations. If most people weighing in belong to incumbent S= Ps and they vote in favour of interface complexity to avoid implementation c= omplexity, then it means the spec is not doing a good job of balancing the i= nterests of various groups. I think we should also poll client organisations= to see what they would want. >=20 > (Gartner is trusted by enterprise clients to evaluate the capabilities of v= endors (SPs). I believe Gartner should take the lead in representing client i= nterests in this working group rather than those of incumbent vendors, which= is what it seems like to me. Correct me if I'm being unfair.) >=20 > Regards, > Ganesh >=20 >=20 >=20 > On 11 August 2012 01:35, Diodati,Mark wrote: > Hi Ganesh, >=20 > =20 >=20 > I am concerned about your second suggestion: >=20 > =E2=80=9C2. When dealing with multi-valued attributes of a resource (expre= ssed as arrays in JSON), they must be converted from an array into a diction= ary with unique keys (UUIDs generated by the cloud provider when the attribu= te is created). Without unique keys for every attribute value of a resource,= manipulating it will be clumsy and inelegant.=E2=80=9D >=20 > =20 >=20 > One of the primary reasons that SPML failed was lack of adoption by servic= e providers due to its complexity. Very few target applications implemented S= PML. Most of the commercial provisioning systems had an SPML interface (eith= er v1 or v2), but not one of them was conformant to the SPML standard becaus= e of complexity. If you are interested, I will forward you the research docu= ments that discuss these problems in detail. For SCIM to be successful, it m= ust be adopted by commercial target applications (i.e., service providers). I= am confident that a requirement for unique identifiers with multi-valued at= tributes will preclude its adoption, because it requires major changes to th= e service provider=E2=80=99s existing identity storage mechanisms. >=20 > Mark >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: Trey Drake [mailto:trey.drake@unboundid.com]=20 > Sent: Friday, August 10, 2012 9:51 AM >=20 >=20 > To: Ganesh and Sashi Prasad > Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >=20 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > =20 >=20 > Ganesh, >=20 > =20 >=20 > I'll base my comments on your latest reply (below). =20 >=20 > =20 >=20 > The externalID is not part of the protocol. It is an *optional* attribute= within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters). Please c= larify your suggestion. >=20 > =20 >=20 > I'm not tracking your coupling concern. The client can search and hence r= etrieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. =20 >=20 > =20 >=20 > =20 >=20 > What do you mean by "candidate key"? Given=20 >=20 > =20 >=20 > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad wrote: >=20 > > I think scim gets its current simplicity from its single owner hub spok= e model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. >=20 > =20 >=20 > Phil, >=20 > =20 >=20 > I'm a bit surprised that you're implying "tight coupling =3D=3D simple" an= d "loose coupling =3D=3D complex". That's contrary to my experience. >=20 > =20 >=20 > When I say "loose coupling", I mean "no unnecessary dependencies". Invaria= bly, a reduction in dependencies leads to greater simplicity. >=20 > =20 >=20 > Let's not confuse reduction of dependencies in the data model with a hub-a= nd-spokes architecture. They're entirely orthogonal aspects of the solution.= >=20 > =20 >=20 > All that my suggestion involves is, >=20 > =20 >=20 > 1. Take 'external ID' out of the protocol. >=20 > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >=20 > =20 >=20 > No planned functionality is lost by this. >=20 > =20 >=20 > 1. The client enterprise can still send its internal ID as part of the res= ource body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. >=20 > 2. The client enterprise can search for resource URIs using any attribute,= including this internal ID >=20 > 'GET /Users?myID=3Dbjensen' >=20 > Since myID is a candidate key, the server will return exactly one URI, whi= ch is the canonical URI for the resource >=20 > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > 3. The client can use this URI to perform all other operations as usual. > =20 > So taking 'externalID' out of the protocol spec only does this: > 1. It avoids enshrining tight coupling in the protocol (If clients want to= tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of a= ssisted suicide. ;-) > 2. It encourages loose coupling by nudging clients towards maintaining the= ir own internal-to-external identifier mappings. > =20 > That's what I'd like to see. I don't believe this complicates the protocol= . It simplifies it and it also lends itself to a loosely-coupled approach. > =20 > I'll address the multi-valued attribute suggestion separately. > =20 > Regards, > Ganesh > =20 > =20 > =20 > =20 >=20 > On 10 August 2012 07:53, Phil Hunt wrote: >=20 >=20 >=20 > Phil >=20 >=20 > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad wr= ote: >=20 > > storing this information in a mapping table outside of the SCIM spec is= a great way to enable this solution. Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains.=20 >=20 > I wasn't suggesting that the mapping table be part of the SCIM spec. I pro= vided that example to illustrate that splitting and merging identities is a c= ommon requirement, and that decoupling local identifiers within a domain fro= m shared identifiers between domains was the best way to facilitate it. >=20 > =20 >=20 > I'm suggesting that the spec do less, not more. >=20 > =20 >=20 > What the SCIM spec needs to do there is just refrain from introducing tigh= t coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the shared= one. Allowing one domain to expose its internal identifier to the other cre= ates tight coupling and ensures that both domains need simultaneously split o= r merge identities, which is not desirable. So I recommend _taking out_ the "= external id" field from the API. The spec shouldn't encourage tight coupling= . If clients want to pass in their internal ids as part of the resource body= , no one can stop them, and they can always do a search on that attribute to= retrieve the URI exactly as you visualise they will with the "external id",= but let's not elevate an anti-pattern to a recommendation by enshrining the= "external id" as an acceptable attribute. >=20 > =20 >=20 > Am I making sense? >=20 > =20 >=20 > I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling.=20 >=20 > =20 >=20 > IMHO loose coupling is a much more complex solution. The reality is that e= ach end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub.=20 >=20 > =20 >=20 > That said i think the current model provides a practical starting point.=20= >=20 > =20 >=20 > > Regarding unique identifiers for multi-valued attributes there is a tra= de-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers.=20 >=20 >=20 > Precisely. The spec has to strike the right balance. It would be interesti= ng to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > On 10 August 2012 00:28, Kelly Grizzle wrote= : >=20 > Thanks Emmanuel. I had started writing up a similar response. As you sug= gest, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM is= just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. >=20 > =20 >=20 > You could also model these ID mappings in the SCIM user as an extension bu= t would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a user= ): >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >=20 > =20 >=20 > This could be represented as two SCIM users that contain information about= the entities on other domains. >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "a99a5feba839", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "7a87f27c1dd8" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > In the second user, the linkedUsers attribute would be empty until the spl= it user was synced to domain 2. >=20 > =20 >=20 > =20 >=20 > Similarly, the false negative use case (merging two users) looked like thi= s at the end: >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >=20 > =20 >=20 > This could be represented with the following SCIM user: >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > }, >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "41206cc97c8b", >=20 > "deletionRequired": true >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > =20 >=20 > Regarding unique identifiers for multi-valued attributes there is a trade-= off involved. On one hand this makes PATCH semantics easier. On the other h= and it puts extra burden on service providers. Since the inception of SCIM,= a key goal has been to foster adoption by service providers by making thing= s fit easily onto existing systems. IMO the value gained by unique identifi= ers for multi-valued attributes is not worth the demands put on a service pr= ovider. I also think that vendors that have a non-SCIM-compliant API will c= hoose to keep things that way if the spec is too hard for them to implement.= In a green field environment we do have the luxury of mandating a model to= make certain operations more elegant. However, we can=E2=80=99t ignore leg= acy systems. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Em= manuel Dreux > Sent: Thursday, August 09, 2012 3:18 AM > To: Ganesh and Sashi Prasad; Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Ganesh, >=20 > =20 >=20 > Nothing prevents you in your SCIM implementation (client or server) to gen= erate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). >=20 > =20 >=20 > This is what we are doing with Active Directory sources or targets: >=20 > As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAccou= ntName, UPN) are subject to change (even objectGuid can change if an AD doma= in is migrated), we decided to generate and maintain an internal table of id= s. This fits your requirements as it hides internal ids. >=20 > =20 >=20 > This was written in dotnet and we have started a project to rewrite our SC= IM stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. >=20 > This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or use t= hem as unique ID. >=20 > =20 >=20 > You can also implement such feature without violating the SCIM specs, or w= ithout asking to include it in the specs. >=20 > =20 >=20 > -- >=20 > Regards, >=20 > Emmanuel Dreux >=20 > http://www.cloudiway.com >=20 > Tel: +33 4 26 78 17 58 >=20 > Mobile: +33 6 47 81 26 70 >=20 > skype: Emmanuel.Dreux >=20 > =20 >=20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 > =C3=80 : Kelly Grizzle > Cc : scim@ietf.org > Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Kelly, > Thanks for your response. Let me first respond in brief to the two main po= ints you have made, and then elaborate on the first. > 1. Why should domains not expose their internal identifiers to other d= omains? > a. > We are designing a protocol for a federated system of domains, where all d= omains are co-equal peers. (In physics too, N-body problems are much harder t= han 2-body problems. :-) Therefore, assuming that there are only two players= in the interaction makes this tightly coupled in a number of ways. We shoul= d rely on messaging and notification, with encapsulation of domain-specific d= ata. > b. > In any non-trivial data store, there will always be the ongoing need to me= rge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D and =E2= =80=9Cfalse positives=E2=80=9D are discovered. A domain should be able to ha= ndle this internal housekeeping freely, only notifying other domains when co= nvenient. Mapping of internal identifiers to external ones and maintaining t= his mapping internally allows this loosely-coupled housekeeping to take plac= e. Sharing internal identifiers (or otherwise outsourcing the mapping of int= ernal to external identifiers) forces housekeeping activities to be done in l= ock-step across domains. > c. > Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling o= r constraining such interaction. A tightly-coupled data model will force the= use of synchronous interactions, and the exposure of internal identifiers i= s a key part of this tight coupling. > 2. The difficulty of assigning unique identifiers to the individual values= of multi-valued attributes: > a. > I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain ident= ity management, we are really at the very early stages. If a relatively new d= iscipline and a brand new spec are held captive to legacy considerations, we= are losing an opportunity to provide a clean and elegant model to subsequen= t users of the spec, and this will have repercussions over many years or eve= n decades. > b. > If incumbent cloud providers find it hard to immediately adopt the diction= ary model for existing multi-valued attributes, they can transition to this m= odel by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-SCIM= -compliant=E2=80=9D APIs to their customers and encouraging new customers to= adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be sup= ported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrarily l= ong period and gradually migrated to the SCIM-compliant API. The logistics a= re not insurmountable, and shouldn't prevent the adoption of a dictionary mo= del for multi-valued attributes. > Elaboration of Point 1: > When we consider federated identity across more than one domain, we have t= o assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle e= vents within a domain are notified to other domains (when necessary) in an a= synchronous manner (i.e., through messaging) and the other domains are free t= o respond to these events in an appropriate manner and at a time of their co= nvenience. > A key set of lifecycle events for an entity is the merging and splitting o= f identity that is often required. > The question =E2=80=9CIs this one entity?=E2=80=9D can be answered either y= es (positive) or no (negative). But sometimes, we can discover false positiv= es and false negatives in our data stores. > Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and al= so use the same date of birth (say, 1 Jan 1970) or similar attributes. The f= ront-end application may make an intelligent (but incorrect) guess that thes= e two persons are the same, and re-assign the same identifier to the second p= erson. This is a false positive. They appear to be the same entity, but they= 're actually different. When the error is discovered, the identities will ne= ed to be split, with a new identifier generated for one of them. > Consider the opposite case where a customer signs up through two different= portals or in two different sessions, using the names =E2=80=9CJSmith=E2=80= =9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated= as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped. > These are not theoretical use cases. They form a significant proportion of= the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external o= nes and only exposing external identifiers to other domains. > a. False positives: > Domain 1 has the following information about a customer in its data store:= > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > When requesting the provisioning of this entity in Domain 2, the following= ID is returned by Domain 2: ff487230b3a0. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifier: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > When the false positive is discovered and the entity is split, Domain 1 cr= eates a new internal identifier and now has the following entity information= . > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > Internal ID: a99a5feba839 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > This second entity with its own internal identifier is invisible to Domain= 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b= 3a0=E2=80=9D and vice-versa. At some convenient time (importantly, this does= n't have to be at the time the split happens), Domain 2 can be requested to p= rovision a second entity, and when it responds with an identifier of =E2=80=9C= 7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record as= sociated with the second entity's internal identifier. > The mapping table now contains the following entries: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > Domain 2 is not even aware that a split has happened, and the provisioning= that it does is not in lockstep with the split in identity that occurred in= Domain 1. > (What is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we co= ver the treatment of false negatives.) > b. False negatives: > Domain 1 has the following information about what it thinks are two distin= ct customers in its data store: > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > Internal ID: 273d36e30d09 > Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > When requesting the provisioning of these entities in Domain 2, the follow= ing IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifiers: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 273d36e30d09 | D2 | 41206cc97c8b | true | > When the false negative is discovered and the two entities are merged, Dom= ain 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the f= irst ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the second =E2=80=9C273d36e= 30d09=E2=80=9D. > The mapping table now looks like this: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > Now two external identifiers map to the same internal one, so inbound comm= unication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the t= ranslation table to determine the =E2=80=9Cprimary=E2=80=9D external ID for t= his entity in Domain 2, which was decided to be =E2=80=9Cff487230b3a0=E2=80=9D= . That's where the =E2=80=9CPrimary flag=E2=80=9D comes in. The second exter= nal ID =E2=80=9C41206cc97c8b=E2=80=9D is never used thereafter in outbound c= ommunication. > At some stage (importantly, not in lockstep with the identity merge), Doma= in 2 can be requested to delete the customer record identified by =E2=80=9C4= 1206cc97c8b=E2=80=9D, and the second entry in the mapping table can be remov= ed once this is acknowledged. > This scheme will scale up to multiple domains, because the =E2=80=9CExtern= al Domain ID=E2=80=9D column helps to keep track of which external ID is sha= red with which Domain. (Why don't we use just one external ID for an entity a= nd share it with all external domains? Tight coupling again. Just as OAuth a= llows an access token given to a third party to be invalidated without affec= ting the access of other third parties, the use of separate external identif= iers for different domains allows fine-grained control of identity federatio= n.) > The scheme also allows the splitting of an entity into more than two entit= ies, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths the= re are who were born on 1 Jan 1970!) > This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed i= nternally in each domain. Such a data model also allows us to choose asynchr= onous protocols for propagation of identity events, since there is no consis= tency requirement to update multiple domains concurrently. > Regards, > Ganesh Prasad > =20 >=20 > On 9 August 2012 04:55, Kelly Grizzle wrote:= >=20 > Thanks for the feedback, Ganesh. I read through this and your InfoQ artic= le (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. >=20 > =20 >=20 > > The rest of the protocol does not meaningfully use the enterprise client= =E2=80=99s identifier, the "external ID" >=20 > > at all, even though it was ostensibly introduced to make things friendli= er for the client. >=20 > =20 >=20 > The usage pattern for an external ID would be to search for a user by exte= rnalId and use the ID of the returned user in any desired operation. For ex= ample: >=20 > =20 >=20 > GET /Users?filter=3DexternalId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Di= d >=20 > =20 >=20 > { >=20 > =E2=80=9CtotalResults=E2=80=9D: 1, >=20 > =E2=80=9CResources=E2=80=9D: [ >=20 > { >=20 > =E2=80=9Cid=E2=80=9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2= =80=9D >=20 > } >=20 > ] >=20 > } >=20 > =20 >=20 > Retrieve the ID from the response and use it. >=20 > =20 >=20 > DELETE /Users/2819c223-7f76-453a-919d-413861904646 >=20 > =20 >=20 > This does introduce an additional HTTP request if the client chooses not t= o store the server=E2=80=99s id. An issue was created to consider allowing o= perations to use the externalId (http://code.google.com/p/scim/issues/detail= ?id=3D35), but I believe the general consensus has been to not include this i= n the spec. One main point of contention is that much of the rest of the sp= ec (eg =E2=80=93 group membership references, manager references, etc=E2=80=A6= ) require knowledge of the server=E2=80=99s identifier. Continuing this dis= cussion on the IETF list would be a good thing, though. >=20 > =20 >=20 > =20 >=20 > > the cloud provider's ID and the enterprise client's ID are both "Interna= l IDs" with respect to their domains >=20 > =20 >=20 > I think this comes down to a nomenclature problem. The server=E2=80=99s I= D does not necessarily have to be the unique identifier that the underlying i= dentity store uses, it just has to be stable and unique. In many cases, the= underlying identity store will provide identifiers with these properties al= ready (eg =E2=80=93 a uuid) and it can be used by the SCIM interface. The =E2= =80=9CexternalId=E2=80=9D is referring to the fact that the id is maintained= external to the SCIM server. As long as the server=E2=80=99s identifiers a= re stable and unique (which is mandated by the spec), I don=E2=80=99t see a p= roblem. >=20 > =20 >=20 > =20 >=20 > > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite >=20 > > simple - turn every list or array (of values) into a dictionary (of key-= value pairs) by providing each value >=20 > > with a unique and meaning-free identifier. >=20 > =20 >=20 > I agree that this would be useful, especially in the PATCH operation. One= reason that this wasn=E2=80=99t included in the spec originally is that it c= an put undue burden on the service provider. Many service providers are put= ting SCIM interfaces in front of their existing identity stores (eg =E2=80=93= directory servers, SaaS application databases, etc=E2=80=A6). Many of thes= e do not have a unique identifier for multi-valued attributes. By requiring= this, a majority of the server providers would have to start maintaining a u= nique key for each multi-valued attribute. I believe this would be a roadbl= ock for many implementers. >=20 > =20 >=20 > =20 >=20 > > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. >=20 > =20 >=20 > I like the thoughts here. Your example reminds me of unified diffs (http:= //en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, the= three proposals seem to largely hinge on being able to uniquely address eac= h element within an object. Without these it is not so easy to address each= patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus. >=20 >=20 > The 207 response would be interesting to consider for the bulk endpoint (h= ttp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. >=20 > =20 >=20 > =20 >=20 > > There are other, non-data aspects of SCIM which may require review, such= as its synchronous request-response >=20 > > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. >=20 > =20 >=20 > I agree that we should explore optional asynchronous requests in 2.0. >=20 > =20 >=20 > Thanks again for your thoughts. I hope you stay involved in the discussio= n as work on SCIM 2.0 goes forward. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ga= nesh and Sashi Prasad > Sent: Wednesday, August 01, 2012 4:24 PM > To: scim@ietf.org > Subject: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > (I posted this on the SCIM Google Group, and I was advised to subscribe to= the mailing list and post it here instead, so here goes.) >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > My name is Ganesh Prasad, and my experience in Identity and Access Managem= ent is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com/= minibooks/Identity-Management-Shoestring). >=20 > =20 >=20 > I have been following the SCIM spec off and on, and based on my experience= with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. >=20 > =20 >=20 > 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Both= of them should map their internal IDs to a shared External ID, and this is t= he only ID that should be exposed through the API. The current specification= 's provision of an id (which is the external ID and the only one to be trans= ferred through the API) and an "external ID" (which is the client's internal= ID and should be hidden) is diametrically opposite to this. >=20 > =20 >=20 > 2. When dealing with multi-valued attributes of a resource (expressed as a= rrays in JSON), they must be converted from an array into a dictionary with u= nique keys (UUIDs generated by the cloud provider when the attribute is crea= ted). Without unique keys for every attribute value of a resource, manipulat= ing it will be clumsy and inelegant. >=20 > =20 >=20 > 3. The PATCH command can be improved in 3 significant ways: >=20 > 3a. Leverage the fact (from 2 above) that every value has a key, to greatl= y simplify the API >=20 > 3b. Use special verbs as nested operations of the PATCH command to add, mo= dify and delete attributes at any level >=20 > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" a= s the response to a PATCH (or BULK) command. >=20 > =20 >=20 > To elaborate, >=20 > =20 >=20 > 1. Revealing private IDs externally is a form of tight coupling. A major r= equirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is d= iscovered to be more than one, or when multiple resources are detected to be= the same. If internal identifiers are revealed to external domains, such cl= ean-ups become difficult, hence every domain that wants to expose references= to a resource must map its internal ID to and external one created for this= explicit purpose, and only reveal this. >=20 > =20 >=20 > In the SCIM case, when an enterprise client POSTs a resource creation requ= est, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "Lo= cation:" header. The enterprise client should map this external UUID to a ne= wly-generated internal ID of its own. In case the resource already has an id= entifier within the enterprise client's domain, then this is the internal ID= that must be mapped to the external UUID returned through the POST response= . >=20 > =20 >=20 > 2. If a resource is to be created, and one of its attributes is multi-valu= ed, e.g., >=20 > =20 >=20 > "email-addrs" :=20 >=20 > [ >=20 > "john_smith@yahoo.com", >=20 > "john.smith@gmail.com", >=20 > "jsmith1970@hotmail.com" >=20 > <=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > =20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > =20 >=20 >=20 >=20 > This e-mail message, including any attachments, is for the sole use of the= person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have r= eceived this message in error, you are not authorized to copy, distribute, o= r otherwise use this message or its attachments. Please notify the sender im= mediately by return e-mail and permanently delete this message and any attac= hments. Gartner makes no warranty that this e-mail is error or virus free. >=20 --Apple-Mail-AD3F1D5B-5CC8-431A-878D-F6CA3DCC682C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Ganesh,
In your example you are conflating value with an attribute id. I= find that confusing. 

I agree though that ope= rations in patch could be a lot more explicit. 

Eg explicitly deleting a value by saying delete or retire. 

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <= ;g.c.prasad@gmail.com> wrote:=

 > &nbs= p;I am concerned about your second suggestion: 

<= /div>
Let's discuss that now.

The trade-offs ar= e very clear here.

Pros:

Pro 1. The API to manipul= ate resources becomes so much cleaner, consistent and intuitive when every i= ndividual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current spec:<= /div> 

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the cur= rent spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuiti= ve. 
With my suggestion, here's how to delete a single member= from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4= fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.<= span style=3D"font-family:monospace;font-size:11px;white-space:pre-wrap">281= 9c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent= and more intuitive to a reader.

Pro 2: We can appl= y this mechanism consistently to three areas:
(a) Manipulating mul= ti-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk opera= tions, where we simply use HTTP verbs instead of the specialised (and semant= ically less ambiguous) verbs I suggested for attributes, the "key" becomes t= he URI, and the "value" becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results"= array holding individual status codes.

In the curr= ent spec, (a) and (b) are done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely to b= e higher because it's simpler for them.

Pro 4: New (= not incumbent) cloud providers will probably find this easier to implement b= ecause they have no legacy. They will probably use some form of NoSQL databa= se and won't be constrained by the limitations of LDAP directories.

Cons:

Con 1: Incumbent cloud pr= oviders with existing data stores in a directory format (where multi-valued a= ttributes are stored as comma-separated values under a single attribute node= ) will find it difficult to migrate to this model and store each attribute v= alue as a sub-node with its own key. This will "hinder adoption of the spec"= , which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased= of course, so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface co= mplexity (current spec) versus implementation complexity (my suggestion). Bo= th can hinder adoption of the spec by different parties.

Here's what we need to discuss - Do the Pros make the su= ggestion worth adopting in spite of the Cons, or are the Cons so great that i= t's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud providers= can cut both ways. It opens the door to a simpler interface offered by a ne= w generation of nimbler SPs that don't have the same legacy issues, and ther= e could be an exodus of clients to these new SPs. SCIM could end up being ob= soleted very soon, because the API interface is very complex and clumsy, as a= ny new reader can attest. I was taken aback by the complexity when I saw it,= which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peop= le, and they need to state their affiliations. If most people weighing in be= long to incumbent SPs and they vote in favour of interface complexity to avo= id implementation complexity, then it means the spec is not doing a good job= of balancing the interests of various groups. I think we should also poll c= lient organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate th= e capabilities of vendors (SPs). I believe Gartner should take the lead in r= epresenting client interests in this working group rather than those of incu= mbent vendors, which is what it seems like to me. Correct me if I'm being un= fair.)

Regards,
Ganesh



On 11 August 20= 12 01:35, Diodati,Mark <Mark.Diodati@gartner.com> wrote= :

Hi Ganesh,

 

I am concerned about your s= econd suggestion:

=E2=80=9C2. When dealing wi= th multi-valued attributes of a resource (expressed as arrays in JSON), they= must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.=E2=80=9D

 

One of the primary reasons t= hat SPML failed was lack of adoption by service providers due to its complex= ity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v= 1 or v2), but not one of them was conformant to the SPML standard because of= complexity. If you are interested, I will forward you the research document= s that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial targ= et applications (i.e., service providers). I am confident that a requirement= for unique identifiers with multi-valued attributes will preclude its adopt= ion, because it requires major changes to the service provider=E2=80=99s existing identity storage mechani= sms.

Mark

 

 

 

From: Trey Drake [= mailto:trey.dr= ake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM

To: Ganesh and Sashi Prasad
Cc: scim@iet= f.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). &= nbsp;

 

The externalID is not part of the protocol.  It i= s an *optional* attribute within the *schema* specification.  As for #2= , the protocol spec works as you describe if "arbitrary URI parameters" equa= te to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clari= fy your suggestion.

 

I'm not tracking your coupling concern.  The cli= ent can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise.  Nothing mandates use of externalId.   =

 

 

What do you mean by "candidate key"?  Given = ;

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pra= sad <g.c.prasad= @gmail.com> wrote:

>  I think scim gets its current simplicity f= rom its single owner hub spoke model implementing tight coupling. [...] = ;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight coupl= ing =3D=3D simple" and "loose coupling =3D=3D complex". That's contrary to m= y experience.

 

When I say "loose coupling", I mean "no unnecessary d= ependencies". Invariably, a reduction in dependencies leads to greater simpl= icity.

 

Let's not confuse reduction of dependencies in the da= ta model with a hub-and-spokes architecture. They're entirely orthogonal asp= ects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbitr= ary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal I= D as part of the resource body, inside some attribute defined by them (but n= ot defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URIs= using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will return= exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861=
904646
3.=
 The client can use this URI to perform all other operations as usual.
 
So=
 taking 'externalID' out of the protocol spec only does this:
1.=
 It avoids enshrining tight coupling in the protocol (If clients want to tig=
htly couple themselves to the cloud provider by sending their internal IDs, t=
hey can do so. Suicide is OK, but the protocol should not be guilty of assis=
ted suicide. ;-)
2.=
 It encourages loose coupling by nudging clients towards maintaining their o=
wn internal-to-external identifier mappings.
 
Th=
at's what I'd like to see. I don't believe this complicates the protocol. It=
 simplifies it and it also lends itself to a loosely-coupled approach.
 
I'=
ll address the multi-valued attribute suggestion separately.
 
Re=
gards,
Ga=
nesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wro= te:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a gr= eat way to enable this solution.  Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provi= ded that example to illustrate that splitting and merging identities is a co= mmon requirement, and that decoupling local identifiers within a domain from= shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain f= rom introducing tight coupling. I would like to see a single identifier expo= sed through the API, with the implication (and perhaps the recommendation) t= hat it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight cou= pling and ensures that both domains need simultaneously split or merge ident= ities, which is not desirable. So I recommend _taking out_ the "external id"= field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their intern= al ids as part of the resource body, no one can stop them, and they can alwa= ys do a search on that attribute to retrieve the URI exactly as you visualis= e they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrinin= g the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its curr= ent simplicity from its single owner hub spoke model implementing tight coup= ling. 

 

IMHO loose coupling is a much more complex solution. T= he reality is that each end-point has value to contribute and thus the singl= e-owner model will eventually need to become multi-owner or multi-hub. =

 

That said i think the current model provides a practi= cal starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-of= f involved.  On one hand this makes PATCH semantics easier.  On th= e other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting= to hear from the other members of the spec mailing list. You know where I s= tand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoi= nt.com> wrote:

Thanks Emmanuel.  I ha= d started writing up a similar response.  As you suggest, storing this i= nformation in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only respo= nsible for the transport layer between domains.

 

You could also model these I= D mappings in the SCIM user as an extension but would probably not want to e= xpose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a u= ser):

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| a99a5feba839     &nb= sp; | D2           &n= bsp;     | 7a87f27c1dd8     &nb= sp; | true         |

 

This could be represented a= s two SCIM users that contain information about the entities on other domain= s.

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the lin= kedUsers attribute would be empty until the split user was synced to domain 2= .

 

 

Similarly, the false negati= ve use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | 41206cc97c8b     &nb= sp; | false        |

 

This could be represented w= ith the following SCIM user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      },

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "41206cc97c8b",

        "del= etionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifier= s for multi-valued attributes there is a trade-off involved.  On one ha= nd this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception o= f SCIM, a key goal has been to foster adoption by service providers by makin= g things fit easily onto existing systems.  IMO the value gained by uni= que identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that= vendors that have a non-SCIM-compliant API will choose to keep things that w= ay if the spec is too hard for them to implement.  In a green field env= ironment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in you= r SCIM implementation (client or server) to generate a unique identifier for= each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing w= ith Active Directory sources or targets:

As we didn=E2=80=99t find a= n immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to c= hange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids.= This fits your requirements as it hides internal ids.

 

This was written in dotnet a= nd we have started a project to rewrite our SCIM stack in PHP and will give i= t to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice o= f =E2=80=9Chiding=E2=80=9D internalIDs or use them as unique ID.

 

You can also implement such= feature without violating the SCIM specs, or without asking to include it i= n the specs.

 

--

Regards,=

Emmanuel Dreux<= /span>

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

Tel: +33 4 26 78 1= 7 58

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel= .Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi Ke= lly,

Thank= s for your response. Let me first respond in brief to the two main points yo= u have made, and then elaborate on the first.

1. = ;     Why should domains not ex= pose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elabo= ration of Point 1:

When w= e consider federated identity across more than one domain, we have to assume= that domains are not necessarily master-slave in their interaction. The mos= t generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to= other domains (when necessary) in an asynchronous manner (i.e., through mes= saging) and the other domains are free to respond to these events in an appr= opriate manner and at a time of their convenience.

A key= set of lifecycle events for an entity is the merging and splitting of ident= ity that is often required.

The q= uestion =E2=80=9CIs this one entity?=E2=80=9D can be answered either yes (po= sitive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Consi= der a case where customers sign up online, and two customers who are privacy= -conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrec= t) guess that these two persons are the same, and re-assign the same identif= ier to the second person. This is a false positive. They appear to be the sa= me entity, but they're actually different. When the error is discovered, the identities will need to be spl= it, with a new identifier generated for one of them.

Consi= der the opposite case where a customer signs up through two different portal= s or in two different sessions, using the names =E2=80=9CJSmith=E2=80=9D and= =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped.

These= are not theoretical use cases. They form a significant proportion of the us= er base in most large Web-facing applications. Let's see how these can be ma= naged in a federated way by mapping internal identifiers to external ones and only exposing external identifier= s to other domains.

a. Fa= lse positives:

Domai= n 1 has the following information about a customer in its data store:=

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

When r= equesting the provisioning of this entity in Domain 2, the following ID is r= eturned by Domain 2: ff487230b3a0.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

When t= he false positive is discovered and the entity is split, Domain 1 creates a n= ew internal identifier and now has the following entity information.<= /p>

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

Inter= nal ID: a99a5feba839

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

This s= econd entity with its own internal identifier is invisible to Domain 2, and t= his is by design. Communication about the original entity takes place as bef= ore by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b3a0=E2=80=9D and vice-versa. At some convenient time (= importantly, this doesn't have to be at the time the split happens), Domain 2= can be requested to provision a second entity, and when it responds with an= identifier of =E2=80=9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record associated with the second entity's inter= nal identifier.

The m= apping table now contains the following entries:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| a99a5feba839 | D2= | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, a= nd the provisioning that it does is not in lockstep with the split in identi= ty that occurred in Domain 1.

(What= is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we cover the= treatment of false negatives.)

b. Fa= lse negatives:

Domai= n 1 has the following information about what it thinks are two distinct cust= omers in its data store:

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}<= /span>

Inter= nal ID: 273d36e30d09

Attri= butes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}

When r= equesting the provisioning of these entities in Domain 2, the following IDs a= re returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifiers:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 273d36e30d09 | D2= | 41206cc97c8b | true |

When t= he false negative is discovered and the two entities are merged, Domain 1 dr= ops one of the internal identifiers and rationalises the name of the custome= r (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the first ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the se= cond =E2=80=9C273d36e30d09=E2=80=9D.

The m= apping table now looks like this:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 9caf78aac3d6 | D2= | 41206cc97c8b | false |

Now t= wo external identifiers map to the same internal one, so inbound communicati= on from Domain 2 can be unambiguously translated to the same entity internal= ly. However, when going outwards, Domain 1 will have to look up the translation table to determine the =E2=80= =9Cprimary=E2=80=9D external ID for this entity in Domain 2, which was decid= ed to be =E2=80=9Cff487230b3a0=E2=80=9D. That's where the =E2=80=9CPrimary f= lag=E2=80=9D comes in. The second external ID =E2=80=9C41206cc97c8b=E2=80=9D= is never used thereafter in outbound communication.

At so= me stage (importantly, not in lockstep with the identity merge), Domain 2 ca= n be requested to delete the customer record identified by =E2=80=9C41206cc9= 7c8b=E2=80=9D, and the second entry in the mapping table can be removed once this is acknowledged.

This s= cheme will scale up to multiple domains, because the =E2=80=9CExternal Domai= n ID=E2=80=9D column helps to keep track of which external ID is shared with= which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling aga= in. Just as OAuth allows an access token given to a third party to be invali= dated without affecting the access of other third parties, the use of separa= te external identifiers for different domains allows fine-grained control of identity federation.)

The s= cheme also allows the splitting of an entity into more than two entities, an= d the merging of more than two entities into a single one. (Any organisation= with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This i= s a fairly long-winded explanation, but this is why we need to hide internal= identifiers from other domains, and why mappings need to be managed interna= lly in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of id= entity events, since there is no consistency requirement to update multiple d= omains concurrently.

Regar= ds,

Ganes= h Prasad

 

On 9 August 2012 04:55, Kelly Grizz= le <kell= y.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ga= nesh.  I read through this and your InfoQ article (h= ttp://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not meaning= fully use the enterprise client=E2=80=99s identifier, the "external ID"

> at all, even though i= t was ostensibly introduced to make things friendlier for the client.=

 

The usage pattern for an ex= ternal ID would be to search for a user by externalId and use the ID of the r= eturned user in any desired operation.  For example:

 

GET /Users?filter=3Dexterna= lId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Did

 

{

  =E2=80=9CtotalResults=E2=80=9D: 1,

  =E2=80=9CResources=E2=80=9D: [

    {

      =E2=80=9Cid=E2=80= =9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2=80=9D

    }

  ]

}

 

Retrieve the ID from the re= sponse and use it.

 

DELETE /Users/2819c223-7f76= -453a-919d-413861904646

 

This does introduce an addi= tional HTTP request if the client chooses not to store the server=E2=80=99s i= d.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/de= tail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One m= ain point of contention is that much of the rest of the spec (eg =E2=80=93 g= roup membership references, manager references, etc=E2=80=A6) require knowle= dge of the server=E2=80=99s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterpris= e client's ID are both "Internal IDs" with respect to their domains

 

I think this comes down to a= nomenclature problem.  The server=E2=80=99s ID does not necessarily ha= ve to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the u= nderlying identity store will provide identifiers with these properties alre= ady (eg =E2=80=93 a uuid) and it can be used by the SCIM interface.  Th= e =E2=80=9CexternalId=E2=80=9D is referring to the fact that the id is maintained external to the SCIM server.  As long as the server=E2= =80=99s identifiers are stable and unique (which is mandated by the spec), I= don=E2=80=99t see a problem.

 

 

> The secret is that every value ne= eds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn every l= ist or array (of values) into a dictionary (of key-value pairs) by providing= each value

> with a unique and me= aning-free identifier.

 

I agree that this would be u= seful, especially in the PATCH operation.  One reason that this wasn=E2= =80=99t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are p= utting SCIM interfaces in front of their existing identity stores (eg =E2=80= =93 directory servers, SaaS application databases, etc=E2=80=A6).  Many= of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers wou= ld have to start maintaining a unique key for each multi-valued attribute.&n= bsp; I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, there a= re areas where it seems a bit clumsy.

 

I like the thoughts here.&n= bsp; Your example reminds me of unified diffs (http://en.wikipedia= .org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of= the PATCH verb).  However, the three proposals seem to largely hinge o= n being able to uniquely address each element within an object.  Withou= t these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-a= pi-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM= which may require review, such as its synchronous request-response

> interaction model, w= hich is a form of tight coupling and could prove to be a source of brittlene= ss.

 

I agree that we should expl= ore optional asynchronous requests in 2.0.

 

Thanks again for your thoug= hts.  I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org<= /a>
Subject: [scim] SCIM Protocol - 3 suggestions for improvement<= /p>

 

(I posted this on the SCIM Google Group, and I was ad= vised to subscribe to the mailing list and post it here instead, so here goe= s.)

 

Hi,

 

 

I have been following the SCIM spec off and on, and b= ased on my experience with a loosely-coupled architecture that I found to be= successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider shoul= d maintain their own internal IDs for a resource, which they should not reve= al to each other. Both of them should map their internal IDs to a shared Ext= ernal ID, and this is the only ID that should be exposed through the API. The current specificati= on's provision of an id (which is the external ID and the only one to be tra= nsferred through the API) and an "external ID" (which is the client's intern= al ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a res= ource (expressed as arrays in JSON), they must be converted from an array in= to a dictionary with unique keys (UUIDs generated by the cloud provider when= the attribute is created). Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significant= ways:

3a. Leverage the fact (from 2 above) that every value= has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PAT= CH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" i= nstead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tigh= t coupling. A major requirement with Identity Management is to split (or mer= ge) identities when false positives (or false negatives) are detected, i.e.,= when a resource is discovered to be more than one, or when multiple resources are detected to be the same= . If internal identifiers are revealed to external domains, such clean-ups b= ecome difficult, hence every domain that wants to expose references to a res= ource must map its internal ID to and external one created for this explicit purpose, and only reveal this= .

 

In the SCIM case, when an enterprise client POSTs a r= esource creation request, the cloud provider must generate its own internal U= UID as well as an external UUID, map them together, and only return the exte= rnal UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-gene= rated internal ID of its own. In case the resource already has an identifier= within the enterprise client's domain, then this is the internal ID that mu= st be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its att= ributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

< 

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

 


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

 



This e-mail message, including any attachments, is for the sole use of the p= erson to whom it has been sent, and may contain information that is confiden= tial or legally protected. If you are not the intended recipient or have rec= eived this message in error, you are not authorized to copy, distribute, or otherwise use this message o= r its attachments. Please notify the sender immediately by return e-mail and= permanently delete this message and any attachments. Gartner makes no warra= nty that this e-mail is error or virus free.

= --Apple-Mail-AD3F1D5B-5CC8-431A-878D-F6CA3DCC682C-- From phil.hunt@oracle.com Fri Aug 10 17:41:16 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43711E80AE for ; Fri, 10 Aug 2012 17:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxXPm-DbmSRq for ; Fri, 10 Aug 2012 17:41:11 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9643611E80BF for ; Fri, 10 Aug 2012 17:41:03 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7B0euCO029516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 00:40:57 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7B0euvS025945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 00:40:56 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7B0etlY003511; Fri, 10 Aug 2012 19:40:55 -0500 Received: from [25.71.113.241] (/74.198.150.241) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 17:40:44 -0700 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> From: Phil Hunt Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-43E66621-D52E-446E-BE07-D0B9A7A40D85 In-Reply-To: Message-Id: <118E4198-6AD4-4C56-B2A0-B870480619BA@oracle.com> Date: Fri, 10 Aug 2012 17:34:29 -0700 To: Ganesh and Sashi Prasad Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (9B206) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Emmanuel Dreux , "Diodati, Mark" , KellyGrizzle , Trey Drake , "scim@ietf.org" Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 00:41:16 -0000 --Apple-Mail-43E66621-D52E-446E-BE07-D0B9A7A40D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 See below.=20 Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad wrot= e: > > I am concerned about your second suggestion:=20 >=20 > Let's discuss that now. >=20 > The trade-offs are very clear here. >=20 > Pros: >=20 > Pro 1. The API to manipulate resources becomes so much cleaner, consistent= and intuitive when every individual attribute value gets its own ID. >=20 > Here's how to delete a single member from a Group, as per the current spec= : >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current spe= c: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20 > With my suggestion, here's how to delete a single member from a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] > } >=20 > Here's how I suggest deleting ALL members from a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] > } >=20 > I'm sure you'll agree that this is simpler, more consistent and more intui= tive to a reader. >=20 > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attri= butes, the "key" becomes the URI, and the "value" becomes the corresponding J= SON object. >=20 > All of them return "207 Multi-Status" with the "results" array holding ind= ividual status codes. >=20 > In the current spec, (a) and (b) are done similarly but (c) is very differ= ent. >=20 > Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. >=20 > Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form of= NoSQL database and won't be constrained by the limitations of LDAP director= ies. >=20 > Cons: >=20 > Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values un= der a single attribute node) will find it difficult to migrate to this model= and store each attribute value as a sub-node with its own key. This will "h= inder adoption of the spec", which is what you fear. >=20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so I c= ould have missed a Con or hyped a Pro :-). >=20 > In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the sp= ec by different parties. >=20 > Here's what we need to discuss - Do the Pros make the suggestion worth ado= pting in spite of the Cons, or are the Cons so great that it's best to leave= the spec as it is? >=20 > Keep in mind that a complex spec that only favours incumbent cloud provide= rs can cut both ways. It opens the door to a simpler interface offered by a n= ew generation of nimbler SPs that don't have the same legacy issues, and the= re could be an exodus of clients to these new SPs. SCIM could end up being o= bsoleted very soon, because the API interface is very complex and clumsy, as= any new reader can attest. I was taken aback by the complexity when I saw i= t, which is why I was prompted to suggest something simpler. >=20 > This is an issue where we need the opinions of many people, and they need t= o state their affiliations. If most people weighing in belong to incumbent S= Ps and they vote in favour of interface complexity to avoid implementation c= omplexity, then it means the spec is not doing a good job of balancing the i= nterests of various groups. I think we should also poll client organisations= to see what they would want. >=20 > (Gartner is trusted by enterprise clients to evaluate the capabilities of v= endors (SPs). I believe Gartner should take the lead in representing client i= nterests in this working group rather than those of incumbent vendors, which= is what it seems like to me. Correct me if I'm being unfair.) Big -1 While I very much respect analysts they are not protocol designers or implem= entors.=20 Many of us are also speaking for customers of many types and it isn't true t= hat those needs line up with the analysts opinion.=20 I doubt very much IETF would be prepared to redefine consensus giving any gr= oup higher weight.=20 >=20 > Regards, > Ganesh >=20 >=20 >=20 > On 11 August 2012 01:35, Diodati,Mark wrote: > Hi Ganesh, >=20 > =20 >=20 > I am concerned about your second suggestion: >=20 > =E2=80=9C2. When dealing with multi-valued attributes of a resource (expre= ssed as arrays in JSON), they must be converted from an array into a diction= ary with unique keys (UUIDs generated by the cloud provider when the attribu= te is created). Without unique keys for every attribute value of a resource,= manipulating it will be clumsy and inelegant.=E2=80=9D >=20 > =20 >=20 > One of the primary reasons that SPML failed was lack of adoption by servic= e providers due to its complexity. Very few target applications implemented S= PML. Most of the commercial provisioning systems had an SPML interface (eith= er v1 or v2), but not one of them was conformant to the SPML standard becaus= e of complexity. If you are interested, I will forward you the research docu= ments that discuss these problems in detail. For SCIM to be successful, it m= ust be adopted by commercial target applications (i.e., service providers). I= am confident that a requirement for unique identifiers with multi-valued at= tributes will preclude its adoption, because it requires major changes to th= e service provider=E2=80=99s existing identity storage mechanisms. >=20 > Mark >=20 > =20 >=20 > =20 >=20 > =20 >=20 > From: Trey Drake [mailto:trey.drake@unboundid.com]=20 > Sent: Friday, August 10, 2012 9:51 AM >=20 >=20 > To: Ganesh and Sashi Prasad > Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >=20 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > =20 >=20 > Ganesh, >=20 > =20 >=20 > I'll base my comments on your latest reply (below). =20 >=20 > =20 >=20 > The externalID is not part of the protocol. It is an *optional* attribute= within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters). Please c= larify your suggestion. >=20 > =20 >=20 > I'm not tracking your coupling concern. The client can search and hence r= etrieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. =20 >=20 > =20 >=20 > =20 >=20 > What do you mean by "candidate key"? Given=20 >=20 > =20 >=20 > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad wrote: >=20 > > I think scim gets its current simplicity from its single owner hub spok= e model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. >=20 > =20 >=20 > Phil, >=20 > =20 >=20 > I'm a bit surprised that you're implying "tight coupling =3D=3D simple" an= d "loose coupling =3D=3D complex". That's contrary to my experience. >=20 > =20 >=20 > When I say "loose coupling", I mean "no unnecessary dependencies". Invaria= bly, a reduction in dependencies leads to greater simplicity. >=20 > =20 >=20 > Let's not confuse reduction of dependencies in the data model with a hub-a= nd-spokes architecture. They're entirely orthogonal aspects of the solution.= >=20 > =20 >=20 > All that my suggestion involves is, >=20 > =20 >=20 > 1. Take 'external ID' out of the protocol. >=20 > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >=20 > =20 >=20 > No planned functionality is lost by this. >=20 > =20 >=20 > 1. The client enterprise can still send its internal ID as part of the res= ource body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. >=20 > 2. The client enterprise can search for resource URIs using any attribute,= including this internal ID >=20 > 'GET /Users?myID=3Dbjensen' >=20 > Since myID is a candidate key, the server will return exactly one URI, whi= ch is the canonical URI for the resource >=20 > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > 3. The client can use this URI to perform all other operations as usual. > =20 > So taking 'externalID' out of the protocol spec only does this: > 1. It avoids enshrining tight coupling in the protocol (If clients want to= tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of a= ssisted suicide. ;-) > 2. It encourages loose coupling by nudging clients towards maintaining the= ir own internal-to-external identifier mappings. > =20 > That's what I'd like to see. I don't believe this complicates the protocol= . It simplifies it and it also lends itself to a loosely-coupled approach. > =20 > I'll address the multi-valued attribute suggestion separately. > =20 > Regards, > Ganesh > =20 > =20 > =20 > =20 >=20 > On 10 August 2012 07:53, Phil Hunt wrote: >=20 >=20 >=20 > Phil >=20 >=20 > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad wr= ote: >=20 > > storing this information in a mapping table outside of the SCIM spec is= a great way to enable this solution. Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains.=20 >=20 > I wasn't suggesting that the mapping table be part of the SCIM spec. I pro= vided that example to illustrate that splitting and merging identities is a c= ommon requirement, and that decoupling local identifiers within a domain fro= m shared identifiers between domains was the best way to facilitate it. >=20 > =20 >=20 > I'm suggesting that the spec do less, not more. >=20 > =20 >=20 > What the SCIM spec needs to do there is just refrain from introducing tigh= t coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the shared= one. Allowing one domain to expose its internal identifier to the other cre= ates tight coupling and ensures that both domains need simultaneously split o= r merge identities, which is not desirable. So I recommend _taking out_ the "= external id" field from the API. The spec shouldn't encourage tight coupling= . If clients want to pass in their internal ids as part of the resource body= , no one can stop them, and they can always do a search on that attribute to= retrieve the URI exactly as you visualise they will with the "external id",= but let's not elevate an anti-pattern to a recommendation by enshrining the= "external id" as an acceptable attribute. >=20 > =20 >=20 > Am I making sense? >=20 > =20 >=20 > I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling.=20 >=20 > =20 >=20 > IMHO loose coupling is a much more complex solution. The reality is that e= ach end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub.=20 >=20 > =20 >=20 > That said i think the current model provides a practical starting point.=20= >=20 > =20 >=20 > > Regarding unique identifiers for multi-valued attributes there is a tra= de-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers.=20 >=20 >=20 > Precisely. The spec has to strike the right balance. It would be interesti= ng to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > On 10 August 2012 00:28, Kelly Grizzle wrote= : >=20 > Thanks Emmanuel. I had started writing up a similar response. As you sug= gest, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM is= just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. >=20 > =20 >=20 > You could also model these ID mappings in the SCIM user as an extension bu= t would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a user= ): >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >=20 > =20 >=20 > This could be represented as two SCIM users that contain information about= the entities on other domains. >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "a99a5feba839", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "7a87f27c1dd8" >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > In the second user, the linkedUsers attribute would be empty until the spl= it user was synced to domain 2. >=20 > =20 >=20 > =20 >=20 > Similarly, the false negative use case (merging two users) looked like thi= s at the end: >=20 > =20 >=20 > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >=20 > | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >=20 > | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >=20 > =20 >=20 > This could be represented with the following SCIM user: >=20 > =20 >=20 > { >=20 > "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed= eration:1.0"], >=20 > "id": "9caf78aac3d6", >=20 > "userName": "John Smith", >=20 > "urn:scim:schemas:extension:federation:1.0": { >=20 > "linkedUsers": [ >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "ff487230b3a0" >=20 > }, >=20 > { >=20 > "domain": "D2", >=20 > "externalEntityId": "41206cc97c8b", >=20 > "deletionRequired": true >=20 > } >=20 > ] >=20 > } >=20 > } >=20 > =20 >=20 > =20 >=20 > Regarding unique identifiers for multi-valued attributes there is a trade-= off involved. On one hand this makes PATCH semantics easier. On the other h= and it puts extra burden on service providers. Since the inception of SCIM,= a key goal has been to foster adoption by service providers by making thing= s fit easily onto existing systems. IMO the value gained by unique identifi= ers for multi-valued attributes is not worth the demands put on a service pr= ovider. I also think that vendors that have a non-SCIM-compliant API will c= hoose to keep things that way if the spec is too hard for them to implement.= In a green field environment we do have the luxury of mandating a model to= make certain operations more elegant. However, we can=E2=80=99t ignore leg= acy systems. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Em= manuel Dreux > Sent: Thursday, August 09, 2012 3:18 AM > To: Ganesh and Sashi Prasad; Kelly Grizzle > Cc: scim@ietf.org > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Ganesh, >=20 > =20 >=20 > Nothing prevents you in your SCIM implementation (client or server) to gen= erate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). >=20 > =20 >=20 > This is what we are doing with Active Directory sources or targets: >=20 > As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAccou= ntName, UPN) are subject to change (even objectGuid can change if an AD doma= in is migrated), we decided to generate and maintain an internal table of id= s. This fits your requirements as it hides internal ids. >=20 > =20 >=20 > This was written in dotnet and we have started a project to rewrite our SC= IM stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. >=20 > This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or use t= hem as unique ID. >=20 > =20 >=20 > You can also implement such feature without violating the SCIM specs, or w= ithout asking to include it in the specs. >=20 > =20 >=20 > -- >=20 > Regards, >=20 > Emmanuel Dreux >=20 > http://www.cloudiway.com >=20 > Tel: +33 4 26 78 17 58 >=20 > Mobile: +33 6 47 81 26 70 >=20 > skype: Emmanuel.Dreux >=20 > =20 >=20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 > =C3=80 : Kelly Grizzle > Cc : scim@ietf.org > Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > Hi Kelly, > Thanks for your response. Let me first respond in brief to the two main po= ints you have made, and then elaborate on the first. > 1. Why should domains not expose their internal identifiers to other d= omains? > a. > We are designing a protocol for a federated system of domains, where all d= omains are co-equal peers. (In physics too, N-body problems are much harder t= han 2-body problems. :-) Therefore, assuming that there are only two players= in the interaction makes this tightly coupled in a number of ways. We shoul= d rely on messaging and notification, with encapsulation of domain-specific d= ata. > b. > In any non-trivial data store, there will always be the ongoing need to me= rge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D and =E2= =80=9Cfalse positives=E2=80=9D are discovered. A domain should be able to ha= ndle this internal housekeeping freely, only notifying other domains when co= nvenient. Mapping of internal identifiers to external ones and maintaining t= his mapping internally allows this loosely-coupled housekeeping to take plac= e. Sharing internal identifiers (or otherwise outsourcing the mapping of int= ernal to external identifiers) forces housekeeping activities to be done in l= ock-step across domains. > c. > Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling o= r constraining such interaction. A tightly-coupled data model will force the= use of synchronous interactions, and the exposure of internal identifiers i= s a key part of this tight coupling. > 2. The difficulty of assigning unique identifiers to the individual values= of multi-valued attributes: > a. > I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain ident= ity management, we are really at the very early stages. If a relatively new d= iscipline and a brand new spec are held captive to legacy considerations, we= are losing an opportunity to provide a clean and elegant model to subsequen= t users of the spec, and this will have repercussions over many years or eve= n decades. > b. > If incumbent cloud providers find it hard to immediately adopt the diction= ary model for existing multi-valued attributes, they can transition to this m= odel by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-SCIM= -compliant=E2=80=9D APIs to their customers and encouraging new customers to= adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be sup= ported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrarily l= ong period and gradually migrated to the SCIM-compliant API. The logistics a= re not insurmountable, and shouldn't prevent the adoption of a dictionary mo= del for multi-valued attributes. > Elaboration of Point 1: > When we consider federated identity across more than one domain, we have t= o assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle e= vents within a domain are notified to other domains (when necessary) in an a= synchronous manner (i.e., through messaging) and the other domains are free t= o respond to these events in an appropriate manner and at a time of their co= nvenience. > A key set of lifecycle events for an entity is the merging and splitting o= f identity that is often required. > The question =E2=80=9CIs this one entity?=E2=80=9D can be answered either y= es (positive) or no (negative). But sometimes, we can discover false positiv= es and false negatives in our data stores. > Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and al= so use the same date of birth (say, 1 Jan 1970) or similar attributes. The f= ront-end application may make an intelligent (but incorrect) guess that thes= e two persons are the same, and re-assign the same identifier to the second p= erson. This is a false positive. They appear to be the same entity, but they= 're actually different. When the error is discovered, the identities will ne= ed to be split, with a new identifier generated for one of them. > Consider the opposite case where a customer signs up through two different= portals or in two different sessions, using the names =E2=80=9CJSmith=E2=80= =9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated= as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped. > These are not theoretical use cases. They form a significant proportion of= the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external o= nes and only exposing external identifiers to other domains. > a. False positives: > Domain 1 has the following information about a customer in its data store:= > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > When requesting the provisioning of this entity in Domain 2, the following= ID is returned by Domain 2: ff487230b3a0. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifier: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > When the false positive is discovered and the entity is split, Domain 1 cr= eates a new internal identifier and now has the following entity information= . > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > Internal ID: a99a5feba839 > Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970= =E2=80=9D} > This second entity with its own internal identifier is invisible to Domain= 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b= 3a0=E2=80=9D and vice-versa. At some convenient time (importantly, this does= n't have to be at the time the split happens), Domain 2 can be requested to p= rovision a second entity, and when it responds with an identifier of =E2=80=9C= 7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record as= sociated with the second entity's internal identifier. > The mapping table now contains the following entries: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > Domain 2 is not even aware that a split has happened, and the provisioning= that it does is not in lockstep with the split in identity that occurred in= Domain 1. > (What is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we co= ver the treatment of false negatives.) > b. False negatives: > Domain 1 has the following information about what it thinks are two distin= ct customers in its data store: > Internal ID: 9caf78aac3d6 > Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > Internal ID: 273d36e30d09 > Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} > When requesting the provisioning of these entities in Domain 2, the follow= ing IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. > Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifiers: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 273d36e30d09 | D2 | 41206cc97c8b | true | > When the false negative is discovered and the two entities are merged, Dom= ain 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the f= irst ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the second =E2=80=9C273d36e= 30d09=E2=80=9D. > The mapping table now looks like this: > | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > Now two external identifiers map to the same internal one, so inbound comm= unication from Domain 2 can be unambiguously translated to the same entity i= nternally. However, when going outwards, Domain 1 will have to look up the t= ranslation table to determine the =E2=80=9Cprimary=E2=80=9D external ID for t= his entity in Domain 2, which was decided to be =E2=80=9Cff487230b3a0=E2=80=9D= . That's where the =E2=80=9CPrimary flag=E2=80=9D comes in. The second exter= nal ID =E2=80=9C41206cc97c8b=E2=80=9D is never used thereafter in outbound c= ommunication. > At some stage (importantly, not in lockstep with the identity merge), Doma= in 2 can be requested to delete the customer record identified by =E2=80=9C4= 1206cc97c8b=E2=80=9D, and the second entry in the mapping table can be remov= ed once this is acknowledged. > This scheme will scale up to multiple domains, because the =E2=80=9CExtern= al Domain ID=E2=80=9D column helps to keep track of which external ID is sha= red with which Domain. (Why don't we use just one external ID for an entity a= nd share it with all external domains? Tight coupling again. Just as OAuth a= llows an access token given to a third party to be invalidated without affec= ting the access of other third parties, the use of separate external identif= iers for different domains allows fine-grained control of identity federatio= n.) > The scheme also allows the splitting of an entity into more than two entit= ies, and the merging of more than two entities into a single one. (Any organ= isation with a web-facing application will tell you how many John Smiths the= re are who were born on 1 Jan 1970!) > This is a fairly long-winded explanation, but this is why we need to hide i= nternal identifiers from other domains, and why mappings need to be managed i= nternally in each domain. Such a data model also allows us to choose asynchr= onous protocols for propagation of identity events, since there is no consis= tency requirement to update multiple domains concurrently. > Regards, > Ganesh Prasad > =20 >=20 > On 9 August 2012 04:55, Kelly Grizzle wrote:= >=20 > Thanks for the feedback, Ganesh. I read through this and your InfoQ artic= le (http://www.infoq.com/articles/scim-data-model-limitations) and have some= thoughts. >=20 > =20 >=20 > > The rest of the protocol does not meaningfully use the enterprise client= =E2=80=99s identifier, the "external ID" >=20 > > at all, even though it was ostensibly introduced to make things friendli= er for the client. >=20 > =20 >=20 > The usage pattern for an external ID would be to search for a user by exte= rnalId and use the ID of the returned user in any desired operation. For ex= ample: >=20 > =20 >=20 > GET /Users?filter=3DexternalId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Di= d >=20 > =20 >=20 > { >=20 > =E2=80=9CtotalResults=E2=80=9D: 1, >=20 > =E2=80=9CResources=E2=80=9D: [ >=20 > { >=20 > =E2=80=9Cid=E2=80=9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2= =80=9D >=20 > } >=20 > ] >=20 > } >=20 > =20 >=20 > Retrieve the ID from the response and use it. >=20 > =20 >=20 > DELETE /Users/2819c223-7f76-453a-919d-413861904646 >=20 > =20 >=20 > This does introduce an additional HTTP request if the client chooses not t= o store the server=E2=80=99s id. An issue was created to consider allowing o= perations to use the externalId (http://code.google.com/p/scim/issues/detail= ?id=3D35), but I believe the general consensus has been to not include this i= n the spec. One main point of contention is that much of the rest of the sp= ec (eg =E2=80=93 group membership references, manager references, etc=E2=80=A6= ) require knowledge of the server=E2=80=99s identifier. Continuing this dis= cussion on the IETF list would be a good thing, though. >=20 > =20 >=20 > =20 >=20 > > the cloud provider's ID and the enterprise client's ID are both "Interna= l IDs" with respect to their domains >=20 > =20 >=20 > I think this comes down to a nomenclature problem. The server=E2=80=99s I= D does not necessarily have to be the unique identifier that the underlying i= dentity store uses, it just has to be stable and unique. In many cases, the= underlying identity store will provide identifiers with these properties al= ready (eg =E2=80=93 a uuid) and it can be used by the SCIM interface. The =E2= =80=9CexternalId=E2=80=9D is referring to the fact that the id is maintained= external to the SCIM server. As long as the server=E2=80=99s identifiers a= re stable and unique (which is mandated by the spec), I don=E2=80=99t see a p= roblem. >=20 > =20 >=20 > =20 >=20 > > The secret is that every value needs a key, and multi-valued attributes l= ack that. So our solution is quite >=20 > > simple - turn every list or array (of values) into a dictionary (of key-= value pairs) by providing each value >=20 > > with a unique and meaning-free identifier. >=20 > =20 >=20 > I agree that this would be useful, especially in the PATCH operation. One= reason that this wasn=E2=80=99t included in the spec originally is that it c= an put undue burden on the service provider. Many service providers are put= ting SCIM interfaces in front of their existing identity stores (eg =E2=80=93= directory servers, SaaS application databases, etc=E2=80=A6). Many of thes= e do not have a unique identifier for multi-valued attributes. By requiring= this, a majority of the server providers would have to start maintaining a u= nique key for each multi-valued attribute. I believe this would be a roadbl= ock for many implementers. >=20 > =20 >=20 > =20 >=20 > > When the SCIM protocol uses PATCH, there are areas where it seems a bit c= lumsy. >=20 > =20 >=20 > I like the thoughts here. Your example reminds me of unified diffs (http:= //en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a= patch program (pretty much the equivalent of the PATCH verb). However, the= three proposals seem to largely hinge on being able to uniquely address eac= h element within an object. Without these it is not so easy to address each= patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus. >=20 >=20 > The 207 response would be interesting to consider for the bulk endpoint (h= ttp://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), how= ever. >=20 > =20 >=20 > =20 >=20 > > There are other, non-data aspects of SCIM which may require review, such= as its synchronous request-response >=20 > > interaction model, which is a form of tight coupling and could prove to b= e a source of brittleness. >=20 > =20 >=20 > I agree that we should explore optional asynchronous requests in 2.0. >=20 > =20 >=20 > Thanks again for your thoughts. I hope you stay involved in the discussio= n as work on SCIM 2.0 goes forward. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ga= nesh and Sashi Prasad > Sent: Wednesday, August 01, 2012 4:24 PM > To: scim@ietf.org > Subject: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > =20 >=20 > (I posted this on the SCIM Google Group, and I was advised to subscribe to= the mailing list and post it here instead, so here goes.) >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > My name is Ganesh Prasad, and my experience in Identity and Access Managem= ent is mainly through a 3-year project at an Australian insurance company, a= n experience I have written about as a eBook on InfoQ (http://www.infoq.com/= minibooks/Identity-Management-Shoestring). >=20 > =20 >=20 > I have been following the SCIM spec off and on, and based on my experience= with a loosely-coupled architecture that I found to be successful, I have t= he following 3 suggestions to make. >=20 > =20 >=20 > 1. The enterprise client and the cloud provider should maintain their own i= nternal IDs for a resource, which they should not reveal to each other. Both= of them should map their internal IDs to a shared External ID, and this is t= he only ID that should be exposed through the API. The current specification= 's provision of an id (which is the external ID and the only one to be trans= ferred through the API) and an "external ID" (which is the client's internal= ID and should be hidden) is diametrically opposite to this. >=20 > =20 >=20 > 2. When dealing with multi-valued attributes of a resource (expressed as a= rrays in JSON), they must be converted from an array into a dictionary with u= nique keys (UUIDs generated by the cloud provider when the attribute is crea= ted). Without unique keys for every attribute value of a resource, manipulat= ing it will be clumsy and inelegant. >=20 > =20 >=20 > 3. The PATCH command can be improved in 3 significant ways: >=20 > 3a. Leverage the fact (from 2 above) that every value has a key, to greatl= y simplify the API >=20 > 3b. Use special verbs as nested operations of the PATCH command to add, mo= dify and delete attributes at any level >=20 > 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" a= s the response to a PATCH (or BULK) command. >=20 > =20 >=20 > To elaborate, >=20 > =20 >=20 > 1. Revealing private IDs externally is a form of tight coupling. A major r= equirement with Identity Management is to split (or merge) identities when f= alse positives (or false negatives) are detected, i.e., when a resource is d= iscovered to be more than one, or when multiple resources are detected to be= the same. If internal identifiers are revealed to external domains, such cl= ean-ups become difficult, hence every domain that wants to expose references= to a resource must map its internal ID to and external one created for this= explicit purpose, and only reveal this. >=20 > =20 >=20 > In the SCIM case, when an enterprise client POSTs a resource creation requ= est, the cloud provider must generate its own internal UUID as well as an ex= ternal UUID, map them together, and only return the external UUID in the "Lo= cation:" header. The enterprise client should map this external UUID to a ne= wly-generated internal ID of its own. In case the resource already has an id= entifier within the enterprise client's domain, then this is the internal ID= that must be mapped to the external UUID returned through the POST response= . >=20 > =20 >=20 > 2. If a resource is to be created, and one of its attributes is multi-valu= ed, e.g., >=20 > =20 >=20 > "email-addrs" :=20 >=20 > [ >=20 > "john_smith@yahoo.com", >=20 > "john.smith@gmail.com", >=20 > "jsmith1970@hotmail.com" >=20 > <=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > =20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 > =20 >=20 >=20 >=20 > This e-mail message, including any attachments, is for the sole use of the= person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have r= eceived this message in error, you are not authorized to copy, distribute, o= r otherwise use this message or its attachments. Please notify the sender im= mediately by return e-mail and permanently delete this message and any attac= hments. Gartner makes no warranty that this e-mail is error or virus free. >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-43E66621-D52E-446E-BE07-D0B9A7A40D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
See below. 

Ph= il

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
 >  I am concerned about your second suggestion: 

Let's discuss that now.

The trade-offs are very c= lear here.

Pros:

Pro 1. The API to manipul= ate resources becomes so much cleaner, consistent and intuitive when every i= ndividual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current spec:<= /div> 

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the cur= rent spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuiti= ve. 
With my suggestion, here's how to delete a single member= from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4= fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.<= span style=3D"font-family:monospace;font-size:11px;white-space:pre-wrap">281= 9c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent= and more intuitive to a reader.

Pro 2: We can appl= y this mechanism consistently to three areas:
(a) Manipulating mul= ti-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk opera= tions, where we simply use HTTP verbs instead of the specialised (and semant= ically less ambiguous) verbs I suggested for attributes, the "key" becomes t= he URI, and the "value" becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results"= array holding individual status codes.

In the curr= ent spec, (a) and (b) are done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely to b= e higher because it's simpler for them.

Pro 4: New (= not incumbent) cloud providers will probably find this easier to implement b= ecause they have no legacy. They will probably use some form of NoSQL databa= se and won't be constrained by the limitations of LDAP directories.

Cons:

Con 1: Incumbent cloud pr= oviders with existing data stores in a directory format (where multi-valued a= ttributes are stored as comma-separated values under a single attribute node= ) will find it difficult to migrate to this model and store each attribute v= alue as a sub-node with its own key. This will "hinder adoption of the spec"= , which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased= of course, so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface co= mplexity (current spec) versus implementation complexity (my suggestion). Bo= th can hinder adoption of the spec by different parties.

Here's what we need to discuss - Do the Pros make the su= ggestion worth adopting in spite of the Cons, or are the Cons so great that i= t's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud providers= can cut both ways. It opens the door to a simpler interface offered by a ne= w generation of nimbler SPs that don't have the same legacy issues, and ther= e could be an exodus of clients to these new SPs. SCIM could end up being ob= soleted very soon, because the API interface is very complex and clumsy, as a= ny new reader can attest. I was taken aback by the complexity when I saw it,= which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peop= le, and they need to state their affiliations. If most people weighing in be= long to incumbent SPs and they vote in favour of interface complexity to avo= id implementation complexity, then it means the spec is not doing a good job= of balancing the interests of various groups. I think we should also poll c= lient organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate th= e capabilities of vendors (SPs). I believe Gartner should take the lead in r= epresenting client interests in this working group rather than those of incu= mbent vendors, which is what it seems like to me. Correct me if I'm being un= fair.)
Big -1

While I very much r= espect analysts they are not protocol designers or implementors. 
=

Many of us are also speaking for customers of many types= and it isn't true that those needs line up with the analysts opinion. =

I doubt very much IETF would be prepared to redefi= ne consensus giving any group higher weight. 

Regards,
Ganesh



On 11 August 20= 12 01:35, Diodati,Mark <Mark.Diodati@gartner.com> wrote= :

Hi Ganesh,

 

I am concerned about your s= econd suggestion:

=E2=80=9C2. When dealing wi= th multi-valued attributes of a resource (expressed as arrays in JSON), they= must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.=E2=80=9D

 

One of the primary reasons t= hat SPML failed was lack of adoption by service providers due to its complex= ity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v= 1 or v2), but not one of them was conformant to the SPML standard because of= complexity. If you are interested, I will forward you the research document= s that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial targ= et applications (i.e., service providers). I am confident that a requirement= for unique identifiers with multi-valued attributes will preclude its adopt= ion, because it requires major changes to the service provider=E2=80=99s existing identity storage mechani= sms.

Mark

 

 

 

From: Trey Drake [= mailto:trey.dr= ake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM

To: Ganesh and Sashi Prasad
Cc: scim@iet= f.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). &= nbsp;

 

The externalID is not part of the protocol.  It i= s an *optional* attribute within the *schema* specification.  As for #2= , the protocol spec works as you describe if "arbitrary URI parameters" equa= te to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clari= fy your suggestion.

 

I'm not tracking your coupling concern.  The cli= ent can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise.  Nothing mandates use of externalId.   =

 

 

What do you mean by "candidate key"?  Given = ;

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pra= sad <g.c.prasad= @gmail.com> wrote:

>  I think scim gets its current simplicity f= rom its single owner hub spoke model implementing tight coupling. [...] = ;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight coupl= ing =3D=3D simple" and "loose coupling =3D=3D complex". That's contrary to m= y experience.

 

When I say "loose coupling", I mean "no unnecessary d= ependencies". Invariably, a reduction in dependencies leads to greater simpl= icity.

 

Let's not confuse reduction of dependencies in the da= ta model with a hub-and-spokes architecture. They're entirely orthogonal asp= ects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbitr= ary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal I= D as part of the resource body, inside some attribute defined by them (but n= ot defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URIs= using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will return= exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861=
904646
3.=
 The client can use this URI to perform all other operations as usual.
 
So=
 taking 'externalID' out of the protocol spec only does this:
1.=
 It avoids enshrining tight coupling in the protocol (If clients want to tig=
htly couple themselves to the cloud provider by sending their internal IDs, t=
hey can do so. Suicide is OK, but the protocol should not be guilty of assis=
ted suicide. ;-)
2.=
 It encourages loose coupling by nudging clients towards maintaining their o=
wn internal-to-external identifier mappings.
 
Th=
at's what I'd like to see. I don't believe this complicates the protocol. It=
 simplifies it and it also lends itself to a loosely-coupled approach.
 
I'=
ll address the multi-valued attribute suggestion separately.
 
Re=
gards,
Ga=
nesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wro= te:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a gr= eat way to enable this solution.  Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provi= ded that example to illustrate that splitting and merging identities is a co= mmon requirement, and that decoupling local identifiers within a domain from= shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain f= rom introducing tight coupling. I would like to see a single identifier expo= sed through the API, with the implication (and perhaps the recommendation) t= hat it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight cou= pling and ensures that both domains need simultaneously split or merge ident= ities, which is not desirable. So I recommend _taking out_ the "external id"= field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their intern= al ids as part of the resource body, no one can stop them, and they can alwa= ys do a search on that attribute to retrieve the URI exactly as you visualis= e they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrinin= g the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its curr= ent simplicity from its single owner hub spoke model implementing tight coup= ling. 

 

IMHO loose coupling is a much more complex solution. T= he reality is that each end-point has value to contribute and thus the singl= e-owner model will eventually need to become multi-owner or multi-hub. =

 

That said i think the current model provides a practi= cal starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-of= f involved.  On one hand this makes PATCH semantics easier.  On th= e other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting= to hear from the other members of the spec mailing list. You know where I s= tand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoi= nt.com> wrote:

Thanks Emmanuel.  I ha= d started writing up a similar response.  As you suggest, storing this i= nformation in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only respo= nsible for the transport layer between domains.

 

You could also model these I= D mappings in the SCIM user as an extension but would probably not want to e= xpose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a u= ser):

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| a99a5feba839     &nb= sp; | D2           &n= bsp;     | 7a87f27c1dd8     &nb= sp; | true         |

 

This could be represented a= s two SCIM users that contain information about the entities on other domain= s.

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the lin= kedUsers attribute would be empty until the split user was synced to domain 2= .

 

 

Similarly, the false negati= ve use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | 41206cc97c8b     &nb= sp; | false        |

 

This could be represented w= ith the following SCIM user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      },

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "41206cc97c8b",

        "del= etionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifier= s for multi-valued attributes there is a trade-off involved.  On one ha= nd this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception o= f SCIM, a key goal has been to foster adoption by service providers by makin= g things fit easily onto existing systems.  IMO the value gained by uni= que identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that= vendors that have a non-SCIM-compliant API will choose to keep things that w= ay if the spec is too hard for them to implement.  In a green field env= ironment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in you= r SCIM implementation (client or server) to generate a unique identifier for= each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing w= ith Active Directory sources or targets:

As we didn=E2=80=99t find a= n immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to c= hange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids.= This fits your requirements as it hides internal ids.

 

This was written in dotnet a= nd we have started a project to rewrite our SCIM stack in PHP and will give i= t to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice o= f =E2=80=9Chiding=E2=80=9D internalIDs or use them as unique ID.

 

You can also implement such= feature without violating the SCIM specs, or without asking to include it i= n the specs.

 

--

Regards,=

Emmanuel Dreux<= /span>

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

Tel: +33 4 26 78 1= 7 58

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel= .Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi Ke= lly,

Thank= s for your response. Let me first respond in brief to the two main points yo= u have made, and then elaborate on the first.

1. = ;     Why should domains not ex= pose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elabo= ration of Point 1:

When w= e consider federated identity across more than one domain, we have to assume= that domains are not necessarily master-slave in their interaction. The mos= t generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to= other domains (when necessary) in an asynchronous manner (i.e., through mes= saging) and the other domains are free to respond to these events in an appr= opriate manner and at a time of their convenience.

A key= set of lifecycle events for an entity is the merging and splitting of ident= ity that is often required.

The q= uestion =E2=80=9CIs this one entity?=E2=80=9D can be answered either yes (po= sitive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Consi= der a case where customers sign up online, and two customers who are privacy= -conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrec= t) guess that these two persons are the same, and re-assign the same identif= ier to the second person. This is a false positive. They appear to be the sa= me entity, but they're actually different. When the error is discovered, the identities will need to be spl= it, with a new identifier generated for one of them.

Consi= der the opposite case where a customer signs up through two different portal= s or in two different sessions, using the names =E2=80=9CJSmith=E2=80=9D and= =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped.

These= are not theoretical use cases. They form a significant proportion of the us= er base in most large Web-facing applications. Let's see how these can be ma= naged in a federated way by mapping internal identifiers to external ones and only exposing external identifier= s to other domains.

a. Fa= lse positives:

Domai= n 1 has the following information about a customer in its data store:=

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

When r= equesting the provisioning of this entity in Domain 2, the following ID is r= eturned by Domain 2: ff487230b3a0.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

When t= he false positive is discovered and the entity is split, Domain 1 creates a n= ew internal identifier and now has the following entity information.<= /p>

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

Inter= nal ID: a99a5feba839

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

This s= econd entity with its own internal identifier is invisible to Domain 2, and t= his is by design. Communication about the original entity takes place as bef= ore by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b3a0=E2=80=9D and vice-versa. At some convenient time (= importantly, this doesn't have to be at the time the split happens), Domain 2= can be requested to provision a second entity, and when it responds with an= identifier of =E2=80=9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record associated with the second entity's inter= nal identifier.

The m= apping table now contains the following entries:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| a99a5feba839 | D2= | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, a= nd the provisioning that it does is not in lockstep with the split in identi= ty that occurred in Domain 1.

(What= is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we cover the= treatment of false negatives.)

b. Fa= lse negatives:

Domai= n 1 has the following information about what it thinks are two distinct cust= omers in its data store:

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}<= /span>

Inter= nal ID: 273d36e30d09

Attri= butes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}

When r= equesting the provisioning of these entities in Domain 2, the following IDs a= re returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifiers:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 273d36e30d09 | D2= | 41206cc97c8b | true |

When t= he false negative is discovered and the two entities are merged, Domain 1 dr= ops one of the internal identifiers and rationalises the name of the custome= r (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the first ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the se= cond =E2=80=9C273d36e30d09=E2=80=9D.

The m= apping table now looks like this:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 9caf78aac3d6 | D2= | 41206cc97c8b | false |

Now t= wo external identifiers map to the same internal one, so inbound communicati= on from Domain 2 can be unambiguously translated to the same entity internal= ly. However, when going outwards, Domain 1 will have to look up the translation table to determine the =E2=80= =9Cprimary=E2=80=9D external ID for this entity in Domain 2, which was decid= ed to be =E2=80=9Cff487230b3a0=E2=80=9D. That's where the =E2=80=9CPrimary f= lag=E2=80=9D comes in. The second external ID =E2=80=9C41206cc97c8b=E2=80=9D= is never used thereafter in outbound communication.

At so= me stage (importantly, not in lockstep with the identity merge), Domain 2 ca= n be requested to delete the customer record identified by =E2=80=9C41206cc9= 7c8b=E2=80=9D, and the second entry in the mapping table can be removed once this is acknowledged.

This s= cheme will scale up to multiple domains, because the =E2=80=9CExternal Domai= n ID=E2=80=9D column helps to keep track of which external ID is shared with= which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling aga= in. Just as OAuth allows an access token given to a third party to be invali= dated without affecting the access of other third parties, the use of separa= te external identifiers for different domains allows fine-grained control of identity federation.)

The s= cheme also allows the splitting of an entity into more than two entities, an= d the merging of more than two entities into a single one. (Any organisation= with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This i= s a fairly long-winded explanation, but this is why we need to hide internal= identifiers from other domains, and why mappings need to be managed interna= lly in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of id= entity events, since there is no consistency requirement to update multiple d= omains concurrently.

Regar= ds,

Ganes= h Prasad

 

On 9 August 2012 04:55, Kelly Grizz= le <kell= y.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ga= nesh.  I read through this and your InfoQ article (h= ttp://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not meaning= fully use the enterprise client=E2=80=99s identifier, the "external ID"

> at all, even though i= t was ostensibly introduced to make things friendlier for the client.=

 

The usage pattern for an ex= ternal ID would be to search for a user by externalId and use the ID of the r= eturned user in any desired operation.  For example:

 

GET /Users?filter=3Dexterna= lId eq =E2=80=9Cbjensen=E2=80=9D&attributes=3Did

 

{

  =E2=80=9CtotalResults=E2=80=9D: 1,

  =E2=80=9CResources=E2=80=9D: [

    {

      =E2=80=9Cid=E2=80= =9D: =E2=80=9C2819c223-7f76-453a-919d-413861904646=E2=80=9D

    }

  ]

}

 

Retrieve the ID from the re= sponse and use it.

 

DELETE /Users/2819c223-7f76= -453a-919d-413861904646

 

This does introduce an addi= tional HTTP request if the client chooses not to store the server=E2=80=99s i= d.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/de= tail?id=3D35), but I believe the general consensus has been to not include this in the spec.  One m= ain point of contention is that much of the rest of the spec (eg =E2=80=93 g= roup membership references, manager references, etc=E2=80=A6) require knowle= dge of the server=E2=80=99s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterpris= e client's ID are both "Internal IDs" with respect to their domains

 

I think this comes down to a= nomenclature problem.  The server=E2=80=99s ID does not necessarily ha= ve to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the u= nderlying identity store will provide identifiers with these properties alre= ady (eg =E2=80=93 a uuid) and it can be used by the SCIM interface.  Th= e =E2=80=9CexternalId=E2=80=9D is referring to the fact that the id is maintained external to the SCIM server.  As long as the server=E2= =80=99s identifiers are stable and unique (which is mandated by the spec), I= don=E2=80=99t see a problem.

 

 

> The secret is that every value ne= eds a key, and multi-valued attributes lack that. So our solution is qui= te

> simple - turn every l= ist or array (of values) into a dictionary (of key-value pairs) by providing= each value

> with a unique and me= aning-free identifier.

 

I agree that this would be u= seful, especially in the PATCH operation.  One reason that this wasn=E2= =80=99t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are p= utting SCIM interfaces in front of their existing identity stores (eg =E2=80= =93 directory servers, SaaS application databases, etc=E2=80=A6).  Many= of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers wou= ld have to start maintaining a unique key for each multi-valued attribute.&n= bsp; I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, there a= re areas where it seems a bit clumsy.

 

I like the thoughts here.&n= bsp; Your example reminds me of unified diffs (http://en.wikipedia= .org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of= the PATCH verb).  However, the three proposals seem to largely hinge o= n being able to uniquely address each element within an object.  Withou= t these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=E2=80=A6) or provide a multi-sta= tus.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-a= pi-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM= which may require review, such as its synchronous request-response

> interaction model, w= hich is a form of tight coupling and could prove to be a source of brittlene= ss.

 

I agree that we should expl= ore optional asynchronous requests in 2.0.

 

Thanks again for your thoug= hts.  I hope you stay involved in the discussion as work on SCIM 2.0 go= es forward.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org<= /a>
Subject: [scim] SCIM Protocol - 3 suggestions for improvement<= /p>

 

(I posted this on the SCIM Google Group, and I was ad= vised to subscribe to the mailing list and post it here instead, so here goe= s.)

 

Hi,

 

 

I have been following the SCIM spec off and on, and b= ased on my experience with a loosely-coupled architecture that I found to be= successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider shoul= d maintain their own internal IDs for a resource, which they should not reve= al to each other. Both of them should map their internal IDs to a shared Ext= ernal ID, and this is the only ID that should be exposed through the API. The current specificati= on's provision of an id (which is the external ID and the only one to be tra= nsferred through the API) and an "external ID" (which is the client's intern= al ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a res= ource (expressed as arrays in JSON), they must be converted from an array in= to a dictionary with unique keys (UUIDs generated by the cloud provider when= the attribute is created). Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significant= ways:

3a. Leverage the fact (from 2 above) that every value= has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PAT= CH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" i= nstead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tigh= t coupling. A major requirement with Identity Management is to split (or mer= ge) identities when false positives (or false negatives) are detected, i.e.,= when a resource is discovered to be more than one, or when multiple resources are detected to be the same= . If internal identifiers are revealed to external domains, such clean-ups b= ecome difficult, hence every domain that wants to expose references to a res= ource must map its internal ID to and external one created for this explicit purpose, and only reveal this= .

 

In the SCIM case, when an enterprise client POSTs a r= esource creation request, the cloud provider must generate its own internal U= UID as well as an external UUID, map them together, and only return the exte= rnal UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-gene= rated internal ID of its own. In case the resource already has an identifier= within the enterprise client's domain, then this is the internal ID that mu= st be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its att= ributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

< 

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

 


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

 



This e-mail message, including any attachments, is for the sole use of the p= erson to whom it has been sent, and may contain information that is confiden= tial or legally protected. If you are not the intended recipient or have rec= eived this message in error, you are not authorized to copy, distribute, or otherwise use this message o= r its attachments. Please notify the sender immediately by return e-mail and= permanently delete this message and any attachments. Gartner makes no warra= nty that this e-mail is error or virus free.

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-43E66621-D52E-446E-BE07-D0B9A7A40D85-- From prateek.mishra@oracle.com Fri Aug 10 18:12:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EA121F84D6 for ; Fri, 10 Aug 2012 18:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu-UWWfUBfcq for ; Fri, 10 Aug 2012 18:12:31 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 20EBE21F84D3 for ; Fri, 10 Aug 2012 18:12:30 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7B1CSbc028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Aug 2012 01:12:29 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7B1CReV004737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Aug 2012 01:12:28 GMT Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7B1CRNM015390 for ; Fri, 10 Aug 2012 20:12:27 -0500 Received: from [192.168.2.2] (/66.31.108.94) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 18:12:26 -0700 Message-ID: <5025B177.8020401@oracle.com> Date: Fri, 10 Aug 2012 21:12:23 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050406090800040504030300" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 01:12:32 -0000 This is a multi-part message in MIME format. --------------050406090800040504030300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Ganesh - we are all participating as individuals in IETF. Maybe you should consult the rules for working groups as explained in: http://tools.ietf.org/pdf/rfc2418.pdf It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal. All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available. - prateek On 8/10/2012 7:19 PM, Ganesh and Sashi Prasad wrote: > > I am concerned about your second suggestion: > > Let's discuss that now. > > The trade-offs are very clear here. > > Pros: > > Pro 1. The API to manipulate resources becomes so much cleaner, > consistent and intuitive when every individual attribute value gets > its own ID. > > Here's how to delete a single member from a Group, as per the current > spec: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host:example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } > > Here's how to delete ALL members from a group according to the current > spec: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host:example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } > > The two operations differ significantly, and it's not very intuitive. > With my suggestion, here's how to delete a single member from a group: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com > Accept: application/json Authorization: Bearer > h480djs93hd8 ETag: W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] } > Here's how I suggest deleting ALL members from a group: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com > Accept: application/json Authorization: Bearer > h480djs93hd8 ETag: W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] } > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader. > > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead > of the specialised (and semantically less ambiguous) verbs I suggested > for attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object. > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes. > > In the current spec, (a) and (b) are done similarly but (c) is very > different. > > Pro 3: Adoption of the standard by clients is likely to be higher > because it's simpler for them. > > Pro 4: New (not incumbent) cloud providers will probably find this > easier to implement because they have no legacy. They will probably > use some form of NoSQL database and won't be constrained by the > limitations of LDAP directories. > > Cons: > > Con 1: Incumbent cloud providers with existing data stores in a > directory format (where multi-valued attributes are stored as > comma-separated values under a single attribute node) will find it > difficult to migrate to this model and store each attribute value as a > sub-node with its own key. This will "hinder adoption of the spec", > which is what you fear. > > Have I summed up the Pros and Cons correctly? I'm biased of course, so > I could have missed a Con or hyped a Pro :-). > > In other words, we're debating interface complexity (current spec) > versus implementation complexity (my suggestion). Both can hinder > adoption of the spec by different parties. > > Here's what we need to discuss - Do the Pros make the suggestion worth > adopting in spite of the Cons, or are the Cons so great that it's best > to leave the spec as it is? > > Keep in mind that a complex spec that only favours incumbent cloud > providers can cut both ways. It opens the door to a simpler interface > offered by a new generation of nimbler SPs that don't have the same > legacy issues, and there could be an exodus of clients to these new > SPs. SCIM could end up being obsoleted very soon, because the API > interface is very complex and clumsy, as any new reader can attest. I > was taken aback by the complexity when I saw it, which is why I was > prompted to suggest something simpler. > > This is an issue where we need the opinions of many people, and they > need to state their affiliations. If most people weighing in belong to > incumbent SPs and they vote in favour of interface complexity to avoid > implementation complexity, then it means the spec is not doing a good > job of balancing the interests of various groups. I think we should > also poll client organisations to see what they would want. > > (Gartner is trusted by enterprise clients to evaluate the capabilities > of vendors (SPs). I believe Gartner should take the lead in > representing client interests in this working group rather than those > of incumbent vendors, which is what it seems like to me. Correct me if > I'm being unfair.) > > Regards, > Ganesh > > > > On 11 August 2012 01:35, Diodati,Mark > wrote: > > Hi Ganesh, > > I am concerned about your second suggestion: > > "2. When dealing with multi-valued attributes of a resource > (expressed as arrays in JSON), they must be converted from an > array into a dictionary with unique keys (UUIDs generated by the > cloud provider when the attribute is created). Without unique keys > for every attribute value of a resource, manipulating it will be > clumsy and inelegant." > > One of the primary reasons that SPML failed was lack of adoption > by service providers due to its complexity. Very few target > applications implemented SPML. Most of the commercial provisioning > systems had an SPML interface (either v1 or v2), but not one of > them was conformant to the SPML standard because of complexity. If > you are interested, I will forward you the research documents that > discuss these problems in detail. For SCIM to be successful, it > must be adopted by commercial target applications (i.e., service > providers). I am confident that a requirement for unique > identifiers with multi-valued attributes will preclude its > adoption, because it requires major changes to the service > provider's existing identity storage mechanisms. > > Mark > > *From:*Trey Drake [mailto:trey.drake@unboundid.com > ] > *Sent:* Friday, August 10, 2012 9:51 AM > > > *To:* Ganesh and Sashi Prasad > *Cc:* scim@ietf.org ; Emmanuel Dreux; Kelly > Grizzle; Phil Hunt > > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Ganesh, > > I'll base my comments on your latest reply (below). > > The externalID is not part of the protocol. It is an *optional* > attribute within the *schema* specification. As for #2, the > protocol spec works as you describe if "arbitrary URI parameters" > equate to resource attributes (Allow generic search using 'GET > /Users' and arbitrary URI parameters). Please clarify your > suggestion. > > I'm not tracking your coupling concern. The client can search and > hence retrieve resources on any attribute it chooses, externalId > or otherwise. Nothing mandates use of externalId. > > What do you mean by "candidate key"? Given > > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > > wrote: > > > I think scim gets its current simplicity from its single owner > hub spoke model implementing tight coupling. [...] IMHO loose > coupling is a much more complex solution. > > Phil, > > I'm a bit surprised that you're implying "tight coupling == > simple" and "loose coupling == complex". That's contrary to my > experience. > > When I say "loose coupling", I mean "no unnecessary dependencies". > Invariably, a reduction in dependencies leads to greater simplicity. > > Let's not confuse reduction of dependencies in the data model with > a hub-and-spokes architecture. They're entirely orthogonal aspects > of the solution. > > All that my suggestion involves is, > > 1. Take 'external ID' out of the protocol. > > 2. Allow generic search using 'GET /Users' and arbitrary URI > parameters > > No planned functionality is lost by this. > > 1. The client enterprise can still send its internal ID as part of > the resource body, inside some attribute defined by them (but not > defined by the protocol). Let's say they call it 'myID'. > > 2. The client enterprise can search for resource URIs using any > attribute, including this internal ID > > 'GET /Users?myID=bjensen' > > Since myID is a candidate key, the server will return exactly one > URI, which is the canonical URI for the resource > > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > > 3. The client can use this URI to perform all other operations as usual. > > > > So taking 'externalID' out of the protocol spec only does this: > > 1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-) > > 2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings. > > > > That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach. > > > > I'll address the multi-valued attribute suggestion separately. > > > > Regards, > > Ganesh > > > > > > > > On 10 August 2012 07:53, Phil Hunt > wrote: > > > > Phil > > > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > > wrote: > > > storing this information in a mapping table outside of the > SCIM spec is a great way to enable this solution. Part of the > key here is that SCIM is just a piece of the architecture for > this solution, and is only responsible for the transport layer > between domains. > > I wasn't suggesting that the mapping table be part of the SCIM > spec. I provided that example to illustrate that splitting and > merging identities is a common requirement, and that > decoupling local identifiers within a domain from shared > identifiers between domains was the best way to facilitate it. > > I'm suggesting that the spec do less, not more. > > What the SCIM spec needs to do there is just refrain from > introducing tight coupling. I would like to see a single > identifier exposed through the API, with the implication (and > perhaps the recommendation) that it be the shared one. > Allowing one domain to expose its internal identifier to the > other creates tight coupling and ensures that both domains > need simultaneously split or merge identities, which is not > desirable. So I recommend _taking out_ the "external id" field > from the API. The spec shouldn't encourage tight coupling. If > clients want to pass in their internal ids as part of the > resource body, no one can stop them, and they can always do a > search on that attribute to retrieve the URI exactly as you > visualise they will with the "external id", but let's not > elevate an anti-pattern to a recommendation by enshrining the > "external id" as an acceptable attribute. > > Am I making sense? > > I see what you are saying. I think scim gets its current > simplicity from its single owner hub spoke model implementing > tight coupling. > > IMHO loose coupling is a much more complex solution. The reality > is that each end-point has value to contribute and thus the > single-owner model will eventually need to become multi-owner or > multi-hub. > > That said i think the current model provides a practical starting > point. > > > Regarding unique identifiers for multi-valued attributes there > is a trade-off involved. On one hand this makes PATCH semantics > easier. On the other hand it puts extra burden on service providers. > > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing > list. You know where I stand on this. It would be good to hear the > spectrum of opinions. > > Regards, > > Ganesh > > On 10 August 2012 00:28, Kelly Grizzle > > > wrote: > > Thanks Emmanuel. I had started writing up a similar response. As > you suggest, storing this information in a mapping table outside > of the SCIM spec is a great way to enable this solution. Part of > the key here is that SCIM is just a piece of the architecture for > this solution, and is only responsible for the transport layer > between domains. > > You could also model these ID mappings in the SCIM user as an > extension but would probably not want to expose these externally. > Here is an example of how to model the end state of the false > positive scenario (splitting a user): > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > > This could be represented as two SCIM users that contain > information about the entities on other domains. > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > } > > ] > > } > > } > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "a99a5feba839", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "7a87f27c1dd8" > > } > > ] > > } > > } > > In the second user, the linkedUsers attribute would be empty until > the split user was synced to domain 2. > > Similarly, the false negative use case (merging two users) looked > like this at the end: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > > This could be represented with the following SCIM user: > > { > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"], > > "id": "9caf78aac3d6", > > "userName": "John Smith", > > "urn:scim:schemas:extension:federation:1.0": { > > "linkedUsers": [ > > { > > "domain": "D2", > > "externalEntityId": "ff487230b3a0" > > }, > > { > > "domain": "D2", > > "externalEntityId": "41206cc97c8b", > > "deletionRequired": true > > } > > ] > > } > > } > > Regarding unique identifiers for multi-valued attributes there is > a trade-off involved. On one hand this makes PATCH semantics > easier. On the other hand it puts extra burden on service > providers. Since the inception of SCIM, a key goal has been to > foster adoption by service providers by making things fit easily > onto existing systems. IMO the value gained by unique identifiers > for multi-valued attributes is not worth the demands put on a > service provider. I also think that vendors that have a > non-SCIM-compliant API will choose to keep things that way if the > spec is too hard for them to implement. In a green field > environment we do have the luxury of mandating a model to make > certain operations more elegant. However, we can't ignore legacy > systems. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Ganesh, > > Nothing prevents you in your SCIM implementation (client or > server) to generate a unique identifier for each synchronized > object and maintain an internal mapping table ( you would have to > map group membership as well). > > This is what we are doing with Active Directory sources or targets: > > As we didn't find an immutable uniqueID in AD systems > (DN,samAccountName, UPN) are subject to change (even objectGuid > can change if an AD domain is migrated), we decided to generate > and maintain an internal table of ids. This fits your requirements > as it hides internal ids. > > This was written in dotnet and we have started a project to > rewrite our SCIM stack in PHP and will give it to the Open Source > community. This implementation will have a parameter : AllocateIds > versus UseExistingIDs. > > This will give the choice of "hiding" internalIDs or use them as > unique ID. > > You can also implement such feature without violating the SCIM > specs, or without asking to include it in the specs. > > -- > > Regards, > > Emmanuel Dreux > > http://www.cloudiway.com > > Tel: +33 4 26 78 17 58 > > Mobile: +33 6 47 81 26 70 > > skype: Emmanuel.Dreux > > *De :*Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoyé :* jeudi 9 août 2012 03:35 > *À :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement > > Hi Kelly, > > Thanks for your response. Let me first respond in brief to the two > main points you have made, and then elaborate on the first. > > 1.Why should domains not expose their internal identifiers to > other domains? > > a. > > We are designing a protocol for a federated system of domains, > where all domains are co-equal peers. (In physics too, N-body > problems are much harder than 2-body problems. :-) Therefore, > assuming that there are only two players in the interaction makes > this tightly coupled in a number of ways. We should rely on > messaging and notification, with encapsulation of domain-specific > data. > > b. > > In any non-trivial data store, there will always be the ongoing > need to merge and split identities as and when "false negatives" > and "false positives" are discovered. A domain should be able to > handle this internal housekeeping freely, only notifying other > domains when convenient. Mapping of internal identifiers to > external ones and maintaining this mapping internally allows this > loosely-coupled housekeeping to take place. Sharing internal > identifiers (or otherwise outsourcing the mapping of internal to > external identifiers) forces housekeeping activities to be done in > lock-step across domains. > > c. > > Asynchronous interaction is not just a matter of a suitable wire > protocol which can be designed later. The data model plays a > crucial role in enabling or constraining such interaction. A > tightly-coupled data model will force the use of synchronous > interactions, and the exposure of internal identifiers is a key > part of this tight coupling. > > 2. The difficulty of assigning unique identifiers to the > individual values of multi-valued attributes: > > a. > > I'm not belittling the effort involved in migrating legacy data > stores to such a model. However, in the larger historical context > of cross-domain identity management, we are really at the very > early stages. If a relatively new discipline and a brand new spec > are held captive to legacy considerations, we are losing an > opportunity to provide a clean and elegant model to subsequent > users of the spec, and this will have repercussions over many > years or even decades. > > b. > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can > transition to this model by offering both "SCIM-compliant" and > "non-SCIM-compliant" APIs to their customers and encouraging new > customers to adopt the "SCIM-compliant" API. Legacy customers can > be supported using a "non-SCIM-compliant" API for an arbitrarily > long period and gradually migrated to the SCIM-compliant API. The > logistics are not insurmountable, and shouldn't prevent the > adoption of a dictionary model for multi-valued attributes. > > Elaboration of Point 1: > > When we consider federated identity across more than one domain, > we have to assume that domains are not necessarily master-slave in > their interaction. The most generic interaction model is > peer-to-peer, where entity lifecycle events within a domain are > notified to other domains (when necessary) in an asynchronous > manner (i.e., through messaging) and the other domains are free to > respond to these events in an appropriate manner and at a time of > their convenience. > > A key set of lifecycle events for an entity is the merging and > splitting of identity that is often required. > > The question "Is this one entity?" can be answered either yes > (positive) or no (negative). But sometimes, we can discover false > positives and false negatives in our data stores. > > Consider a case where customers sign up online, and two customers > who are privacy-conscious enter fake IDs such as "John Smith", and > also use the same date of birth (say, 1 Jan 1970) or similar > attributes. The front-end application may make an intelligent (but > incorrect) guess that these two persons are the same, and > re-assign the same identifier to the second person. This is a > false positive. They appear to be the same entity, but they're > actually different. When the error is discovered, the identities > will need to be split, with a new identifier generated for one of > them. > > Consider the opposite case where a customer signs up through two > different portals or in two different sessions, using the names > "JSmith" and "JohnS". It is very likely that they will be treated > as two different customers and assigned two unique identifiers. > This is a false negative. They appear to be two entities, but are > actually the same. At a later stage, when the error is discovered, > the identities will have to be merged, and one of the identifiers > will have to be dropped. > > These are not theoretical use cases. They form a significant > proportion of the user base in most large Web-facing applications. > Let's see how these can be managed in a federated way by mapping > internal identifiers to external ones and only exposing external > identifiers to other domains. > > a. False positives: > > Domain 1 has the following information about a customer in its > data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > When requesting the provisioning of this entity in Domain 2, the > following ID is returned by Domain 2: ff487230b3a0. > > Domain 1 then maintains the following in a mapping table and uses > it for translation when talking to Domain 2, taking care never to > expose its internal identifier: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > When the false positive is discovered and the entity is split, > Domain 1 creates a new internal identifier and now has the > following entity information. > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > Internal ID: a99a5feba839 > > Attributes: {name: "John Smith", dob: "01-Jan-1970"} > > This second entity with its own internal identifier is invisible > to Domain 2, and this is by design. Communication about the > original entity takes place as before by mapping "9caf78aac3d6" to > "ff487230b3a0" and vice-versa. At some convenient time > (importantly, this doesn't have to be at the time the split > happens), Domain 2 can be requested to provision a second entity, > and when it responds with an identifier of "7a87f27c1dd8", this > can go into the mapping table as a new record associated with the > second entity's internal identifier. > > The mapping table now contains the following entries: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true | > > Domain 2 is not even aware that a split has happened, and the > provisioning that it does is not in lockstep with the split in > identity that occurred in Domain 1. > > (What is the "Primary flag" used for? We'll see when we cover the > treatment of false negatives.) > > b. False negatives: > > Domain 1 has the following information about what it thinks are > two distinct customers in its data store: > > Internal ID: 9caf78aac3d6 > > Attributes: {name: "JSmith", dob: "01-Jan-1970"} > > Internal ID: 273d36e30d09 > > Attributes: {name: "JohnS", dob: "01-Jan-1970"} > > When requesting the provisioning of these entities in Domain 2, > the following IDs are returned by Domain 2: ff487230b3a0 and > 41206cc97c8b. > > Domain 1 then maintains the following in a mapping table and uses > it for translation when talking to Domain 2, taking care never to > expose its internal identifiers: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 273d36e30d09 | D2 | 41206cc97c8b | true | > > When the false negative is discovered and the two entities are > merged, Domain 1 drops one of the internal identifiers and > rationalises the name of the customer (say, to "John Smith"). > Let's say it retains the first ID "9caf78aac3d6" and drops the > second "273d36e30d09". > > The mapping table now looks like this: > > | Internal Entity ID | External Domain ID | External Entity ID | > Primary flag | > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true | > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false | > > Now two external identifiers map to the same internal one, so > inbound communication from Domain 2 can be unambiguously > translated to the same entity internally. However, when going > outwards, Domain 1 will have to look up the translation table to > determine the "primary" external ID for this entity in Domain 2, > which was decided to be "ff487230b3a0". That's where the "Primary > flag" comes in. The second external ID "41206cc97c8b" is never > used thereafter in outbound communication. > > At some stage (importantly, not in lockstep with the identity > merge), Domain 2 can be requested to delete the customer record > identified by "41206cc97c8b", and the second entry in the mapping > table can be removed once this is acknowledged. > > This scheme will scale up to multiple domains, because the > "External Domain ID" column helps to keep track of which external > ID is shared with which Domain. (Why don't we use just one > external ID for an entity and share it with all external domains? > Tight coupling again. Just as OAuth allows an access token given > to a third party to be invalidated without affecting the access of > other third parties, the use of separate external identifiers for > different domains allows fine-grained control of identity federation.) > > The scheme also allows the splitting of an entity into more than > two entities, and the merging of more than two entities into a > single one. (Any organisation with a web-facing application will > tell you how many John Smiths there are who were born on 1 Jan 1970!) > > This is a fairly long-winded explanation, but this is why we need > to hide internal identifiers from other domains, and why mappings > need to be managed internally in each domain. Such a data model > also allows us to choose asynchronous protocols for propagation of > identity events, since there is no consistency requirement to > update multiple domains concurrently. > > Regards, > > Ganesh Prasad > > On 9 August 2012 04:55, Kelly Grizzle > wrote: > > Thanks for the feedback, Ganesh. I read through this and your > InfoQ article > (http://www.infoq.com/articles/scim-data-model-limitations) and > have some thoughts. > > > The rest of the protocol does not meaningfully use the enterprise > client's identifier, the "external ID" > > > at all, even though it was ostensibly introduced to make things > friendlier for the client. > > The usage pattern for an external ID would be to search for a user > by externalId and use the ID of the returned user in any desired > operation. For example: > > GET /Users?filter=externalId eq "bjensen"&attributes=id > > { > > "totalResults": 1, > > "Resources": [ > > { > > "id": "2819c223-7f76-453a-919d-413861904646" > > } > > ] > > } > > Retrieve the ID from the response and use it. > > DELETE /Users/2819c223-7f76-453a-919d-413861904646 > > This does introduce an additional HTTP request if the client > chooses not to store the server's id. An issue was created to > consider allowing operations to use the externalId > (http://code.google.com/p/scim/issues/detail?id=35), but I believe > the general consensus has been to not include this in the spec. > One main point of contention is that much of the rest of the spec > (eg -- group membership references, manager references, etc...) > require knowledge of the server's identifier. Continuing this > discussion on the IETF list would be a good thing, though. > > > the cloud provider's ID and the enterprise client's ID are both > "Internal IDs" with respect to their domains > > I think this comes down to a nomenclature problem. The server's > ID does not necessarily have to be the unique identifier that the > underlying identity store uses, it just has to be stable and > unique. In many cases, the underlying identity store will provide > identifiers with these properties already (eg -- a uuid) and it > can be used by the SCIM interface. The "externalId" is referring > to the fact that the id is maintained external to the SCIM > server. As long as the server's identifiers are stable and unique > (which is mandated by the spec), I don't see a problem. > > > The secret is that /every value needs a key/, and multi-valued > attributes lack that. So our solution is quite > > > simple - turn every list or array (of values) into a dictionary > (of key-value pairs) by providing each value > > > with a unique and meaning-free identifier. > > I agree that this would be useful, especially in the PATCH > operation. One reason that this wasn't included in the spec > originally is that it can put undue burden on the service > provider. Many service providers are putting SCIM interfaces in > front of their existing identity stores (eg -- directory servers, > SaaS application databases, etc...). Many of these do not have a > unique identifier for multi-valued attributes. By requiring this, > a majority of the server providers would have to start maintaining > a unique key for each multi-valued attribute. I believe this > would be a roadblock for many implementers. > > > When the SCIM protocol uses PATCH, there are areas where it seems > a bit clumsy. > > I like the thoughts here. Your example reminds me of unified > diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which > are commonly used with a patch program (pretty much the equivalent > of the PATCH verb). However, the three proposals seem to largely > hinge on being able to uniquely address each element within an > object. Without these it is not so easy to address each patch > sub-operation (REPLACE, INCLUDE, etc...) or provide a multi-status. > > > The 207 response would be interesting to consider for the bulk > endpoint > (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), > however. > > > There are other, non-data aspects of SCIM which may require > review, such as its synchronous request-response > > > interaction model, which is a form of tight coupling and could > prove to be a source of brittleness. > > I agree that we should explore optional asynchronous requests in 2.0. > > Thanks again for your thoughts. I hope you stay involved in the > discussion as work on SCIM 2.0 goes forward. > > --Kelly > > *From:*scim-bounces@ietf.org > [mailto:scim-bounces@ietf.org ] *On > Behalf Of *Ganesh and Sashi Prasad > *Sent:* Wednesday, August 01, 2012 4:24 PM > *To:* scim@ietf.org > *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement > > (I posted this on the SCIM Google Group, and I was advised to > subscribe to the mailing list and post it here instead, so here goes.) > > Hi, > > My name is Ganesh Prasad, and my experience in Identity and Access > Management is mainly through a 3-year project at an Australian > insurance company, an experience I have written about as a eBook > on InfoQ > (http://www.infoq.com/minibooks/Identity-Management-Shoestring). > > I have been following the SCIM spec off and on, and based on my > experience with a loosely-coupled architecture that I found to be > successful, I have the following 3 suggestions to make. > > 1. The enterprise client and the cloud provider should maintain > their own internal IDs for a resource, which they should not > reveal to each other. Both of them should map their internal IDs > to a shared External ID, and this is the only ID that should be > exposed through the API. The current specification's provision of > an id (which is the external ID and the only one to be transferred > through the API) and an "external ID" (which is the client's > internal ID and should be hidden) is diametrically opposite to this. > > 2. When dealing with multi-valued attributes of a resource > (expressed as arrays in JSON), they must be converted from an > array into a dictionary with unique keys (UUIDs generated by the > cloud provider when the attribute is created). Without unique keys > for every attribute value of a resource, manipulating it will be > clumsy and inelegant. > > 3. The PATCH command can be improved in 3 significant ways: > > 3a. Leverage the fact (from 2 above) that every value has a key, > to greatly simplify the API > > 3b. Use special verbs as nested operations of the PATCH command to > add, modify and delete attributes at any level > > 3c. Use the WebDAV status code of "207 Multi-Status" instead of > "200 OK" as the response to a PATCH (or BULK) command. > > To elaborate, > > 1. Revealing private IDs externally is a form of tight coupling. A > major requirement with Identity Management is to split (or merge) > identities when false positives (or false negatives) are detected, > i.e., when a resource is discovered to be more than one, or when > multiple resources are detected to be the same. If internal > identifiers are revealed to external domains, such clean-ups > become difficult, hence every domain that wants to expose > references to a resource must map its internal ID to and external > one created for this explicit purpose, and only reveal this. > > In the SCIM case, when an enterprise client POSTs a resource > creation request, the cloud provider must generate its own > internal UUID as well as an external UUID, map them together, and > only return the external UUID in the "Location:" header. The > enterprise client should map this external UUID to a > newly-generated internal ID of its own. In case the resource > already has an identifier within the enterprise client's domain, > then this is the internal ID that must be mapped to the external > UUID returned through the POST response. > > 2. If a resource is to be created, and one of its attributes is > multi-valued, e.g., > > "email-addrs" : > > [ > > "john_smith@yahoo.com ", > > "john.smith@gmail.com ", > > "jsmith1970@hotmail.com " > > < > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > ------------------------------------------------------------------------ > > This e-mail message, including any attachments, is for the sole > use of the person to whom it has been sent, and may contain > information that is confidential or legally protected. If you are > not the intended recipient or have received this message in error, > you are not authorized to copy, distribute, or otherwise use this > message or its attachments. Please notify the sender immediately > by return e-mail and permanently delete this message and any > attachments. Gartner makes no warranty that this e-mail is error > or virus free. > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------050406090800040504030300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ganesh - we are all participating as individuals in IETF. Maybe you should consult the rules for working groups as explained in:

http://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal.

All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available.

- prateek


On 8/10/2012 7:19 PM, Ganesh and Sashi Prasad wrote:
 >  I am concerned about your second suggestion: 

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consistent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive. 
With my suggestion, here's how to delete a single member from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and more intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead of the specialised (and semantically less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results" array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely to be higher because it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this easier to implement because they have no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a directory format (where multi-valued attributes are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinder adoption of the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course, so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec) versus implementation complexity (my suggestion). Both can hinder adoption of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion worth adopting in spite of the Cons, or are the Cons so great that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud providers can cut both ways. It opens the door to a simpler interface offered by a new generation of nimbler SPs that don't have the same legacy issues, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, because the API interface is very complex and clumsy, as any new reader can attest. I was taken aback by the complexity when I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they need to state their affiliations. If most people weighing in belong to incumbent SPs and they vote in favour of interface complexity to avoid implementation complexity, then it means the spec is not doing a good job of balancing the interests of various groups. I think we should also poll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate the capabilities of vendors (SPs). I believe Gartner should take the lead in representing client interests in this working group rather than those of incumbent vendors, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

 

I am concerned about your second suggestion:

“2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.”

 

One of the primary reasons that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v1 or v2), but not one of them was conformant to the SPML standard because of complexity. If you are interested, I will forward you the research documents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial target applications (i.e., service providers). I am confident that a requirement for unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes to the service provider’s existing identity storage mechanisms.

Mark

 

 

 

From: Trey Drake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below).  

 

The externalID is not part of the protocol.  It is an *optional* attribute within the *schema* specification.  As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clarify your suggestion.

 

I'm not tracking your coupling concern.  The client can search and hence retrieve resources on any attribute it chooses, externalId or otherwise.  Nothing mandates use of externalId.   

 

 

What do you mean by "candidate key"?  Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. [...] IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight coupling == simple" and "loose coupling == complex". That's contrary to my experience.

 

When I say "loose coupling", I mean "no unnecessary dependencies". Invariably, a reduction in dependencies leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the data model with a hub-and-spokes architecture. They're entirely orthogonal aspects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbitrary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal ID as part of the resource body, inside some attribute defined by them (but not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URIs using any attribute, including this internal ID

'GET /Users?myID=bjensen'

Since myID is a candidate key, the server will return exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other operations as usual.
 
So taking 'externalID' out of the protocol spec only does this:
1. It avoids enshrining tight coupling in the protocol (If clients want to tightly couple themselves to the cloud provider by sending their internal IDs, they can do so. Suicide is OK, but the protocol should not be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards maintaining their own internal-to-external identifier mappings.
 
That's what I'd like to see. I don't believe this complicates the protocol. It simplifies it and it also lends itself to a loosely-coupled approach.
 
I'll address the multi-valued attribute suggestion separately.
 
Regards,
Ganesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provided that example to illustrate that splitting and merging identities is a common requirement, and that decoupling local identifiers within a domain from shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain from introducing tight coupling. I would like to see a single identifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight coupling and ensures that both domains need simultaneously split or merge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their internal ids as part of the resource body, no one can stop them, and they can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its current simplicity from its single owner hub spoke model implementing tight coupling. 

 

IMHO loose coupling is a much more complex solution. The reality is that each end-point has value to contribute and thus the single-owner model will eventually need to become multi-owner or multi-hub. 

 

That said i think the current model provides a practical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting to hear from the other members of the spec mailing list. You know where I stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the transport layer between domains.

 

You could also model these ID mappings in the SCIM user as an extension but would probably not want to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| a99a5feba839       | D2                 | 7a87f27c1dd8       | true         |

 

This could be represented as two SCIM users that contain information about the entities on other domains.

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

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

  "id": "a99a5feba839",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the linkedUsers attribute would be empty until the split user was synced to domain 2.

 

 

Similarly, the false negative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6       | D2                 | ff487230b3a0       | true         |

| 9caf78aac3d6       | D2                 | 41206cc97c8b       | false        |

 

This could be represented with the following SCIM user:

 

{

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

  "id": "9caf78aac3d6",

  "userName": "John Smith",

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

    "linkedUsers": [

      {

        "domain": "D2",

        "externalEntityId": "ff487230b3a0"

      },

      {

        "domain": "D2",

        "externalEntityId": "41206cc97c8b",

        "deletionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a key goal has been to foster adoption by service providers by making things fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that vendors that have a non-SCIM-compliant API will choose to keep things that way if the spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can’t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation (client or server) to generate a unique identifier for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing with Active Directory sources or targets:

As we didn’t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits your requirements as it hides internal ids.

 

This was written in dotnet and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice of “hiding” internalIDs or use them as unique ID.

 

You can also implement such feature without violating the SCIM specs, or without asking to include it in the specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoyé : jeudi 9 août 2012 03:35
À : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Kelly,

Thanks for your response. Let me first respond in brief to the two main points you have made, and then elaborate on the first.

1.      Why should domains not expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of domains, where all domains are co-equal peers. (In physics too, N-body problems are much harder than 2-body problems. :-) Therefore, assuming that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the ongoing need to merge and split identities as and when “false negatives” and “false positives” are discovered. A domain should be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones and maintaining this mapping internally allows this loosely-coupled housekeeping to take place. Sharing internal identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol which can be designed later. The data model plays a crucial role in enabling or constraining such interaction. A tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupling.

2. The difficulty of assigning unique identifiers to the individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to such a model. However, in the larger historical context of cross-domain identity management, we are really at the very early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to provide a clean and elegant model to subsequent users of the spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictionary model for existing multi-valued attributes, they can transition to this model by offering both “SCIM-compliant” and “non-SCIM-compliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers can be supported using a “non-SCIM-compliant” API for an arbitrarily long period and gradually migrated to the SCIM-compliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one domain, we have to assume that domains are not necessarily master-slave in their interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (when necessary) in an asynchronous manner (i.e., through messaging) and the other domains are free to respond to these events in an appropriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is the merging and splitting of identity that is often required.

The question “Is this one entity?” can be answered either yes (positive) or no (negative). But sometimes, we can discover false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two customers who are privacy-conscious enter fake IDs such as “John Smith”, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess that these two persons are the same, and re-assign the same identifier to the second person. This is a false positive. They appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through two different portals or in two different sessions, using the names “JSmith” and “JohnS”. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. They appear to be two entities, but are actually the same. At a later stage, when the error is discovered, the identities will have to be merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They form a significant proportion of the user base in most large Web-facing applications. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.

a. False positives:

Domain 1 has the following information about a customer in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

When requesting the provisioning of this entity in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifier:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When the false positive is discovered and the entity is split, Domain 1 creates a new internal identifier and now has the following entity information.

Internal ID: 9caf78aac3d6

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

Internal ID: a99a5feba839

Attributes: {name: “John Smith”, dob: “01-Jan-1970”}

This second entity with its own internal identifier is invisible to Domain 2, and this is by design. Communication about the original entity takes place as before by mapping “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (importantly, this doesn't have to be at the time the split happens), Domain 2 can be requested to provision a second entity, and when it responds with an identifier of “7a87f27c1dd8”, this can go into the mapping table as a new record associated with the second entity's internal identifier.

The mapping table now contains the following entries:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, and the provisioning that it does is not in lockstep with the split in identity that occurred in Domain 1.

(What is the “Primary flag” used for? We'll see when we cover the treatment of false negatives.)

b. False negatives:

Domain 1 has the following information about what it thinks are two distinct customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: “JSmith”, dob: “01-Jan-1970”}

Internal ID: 273d36e30d09

Attributes: {name: “JohnS”, dob: “01-Jan-1970”}

When requesting the provisioning of these entities in Domain 2, the following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintains the following in a mapping table and uses it for translation when talking to Domain 2, taking care never to expose its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 273d36e30d09 | D2 | 41206cc97c8b | true |

When the false negative is discovered and the two entities are merged, Domain 1 drops one of the internal identifiers and rationalises the name of the customer (say, to “John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the second “273d36e30d09”.

The mapping table now looks like this:

| Internal Entity ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now two external identifiers map to the same internal one, so inbound communication from Domain 2 can be unambiguously translated to the same entity internally. However, when going outwards, Domain 1 will have to look up the translation table to determine the “primary” external ID for this entity in Domain 2, which was decided to be “ff487230b3a0”. That's where the “Primary flag” comes in. The second external ID “41206cc97c8b” is never used thereafter in outbound communication.

At some stage (importantly, not in lockstep with the identity merge), Domain 2 can be requested to delete the customer record identified by “41206cc97c8b”, and the second entry in the mapping table can be removed once this is acknowledged.

This scheme will scale up to multiple domains, because the “External Domain ID” column helps to keep track of which external ID is shared with which Domain. (Why don't we use just one external ID for an entity and share it with all external domains? Tight coupling again. Just as OAuth allows an access token given to a third party to be invalidated without affecting the access of other third parties, the use of separate external identifiers for different domains allows fine-grained control of identity federation.)

The scheme also allows the splitting of an entity into more than two entities, and the merging of more than two entities into a single one. (Any organisation with a web-facing application will tell you how many John Smiths there are who were born on 1 Jan 1970!)

This is a fairly long-winded explanation, but this is why we need to hide internal identifiers from other domains, and why mappings need to be managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for propagation of identity events, since there is no consistency requirement to update multiple domains concurrently.

Regards,

Ganesh Prasad

 

On 9 August 2012 04:55, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks for the feedback, Ganesh.  I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations) and have some thoughts.

 

> The rest of the protocol does not meaningfully use the enterprise client’s identifier, the "external ID"

> at all, even though it was ostensibly introduced to make things friendlier for the client.

 

The usage pattern for an external ID would be to search for a user by externalId and use the ID of the returned user in any desired operation.  For example:

 

GET /Users?filter=externalId eq “bjensen”&attributes=id

 

{

  “totalResults”: 1,

  “Resources”: [

    {

      “id”: “2819c223-7f76-453a-919d-413861904646”

    }

  ]

}

 

Retrieve the ID from the response and use it.

 

DELETE /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if the client chooses not to store the server’s id.  An issue was created to consider allowing operations to use the externalId (http://code.google.com/p/scim/issues/detail?id=35), but I believe the general consensus has been to not include this in the spec.  One main point of contention is that much of the rest of the spec (eg – group membership references, manager references, etc…) require knowledge of the server’s identifier.  Continuing this discussion on the IETF list would be a good thing, though.

 

 

> the cloud provider's ID and the enterprise client's ID are both "Internal IDs" with respect to their domains

 

I think this comes down to a nomenclature problem.  The server’s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it just has to be stable and unique.  In many cases, the underlying identity store will provide identifiers with these properties already (eg – a uuid) and it can be used by the SCIM interface.  The “externalId” is referring to the fact that the id is maintained external to the SCIM server.  As long as the server’s identifiers are stable and unique (which is mandated by the spec), I don’t see a problem.

 

 

> The secret is that every value needs a key, and multi-valued attributes lack that. So our solution is quite

> simple - turn every list or array (of values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free identifier.

 

I agree that this would be useful, especially in the PATCH operation.  One reason that this wasn’t included in the spec originally is that it can put undue burden on the service provider.  Many service providers are putting SCIM interfaces in front of their existing identity stores (eg – directory servers, SaaS application databases, etc…).  Many of these do not have a unique identifier for multi-valued attributes.  By requiring this, a majority of the server providers would have to start maintaining a unique key for each multi-valued attribute.  I believe this would be a roadblock for many implementers.

 

 

> When the SCIM protocol uses PATCH, there are areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the equivalent of the PATCH verb).  However, the three proposals seem to largely hinge on being able to uniquely address each element within an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc…) or provide a multi-status.


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which may require review, such as its synchronous request-response

> interaction model, which is a form of tight coupling and could prove to be a source of brittleness.

 

I agree that we should explore optional asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for improvement

 

(I posted this on the SCIM Google Group, and I was advised to subscribe to the mailing list and post it here instead, so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience in Identity and Access Management is mainly through a 3-year project at an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoestring).

 

I have been following the SCIM spec off and on, and based on my experience with a loosely-coupled architecture that I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud provider should maintain their own internal IDs for a resource, which they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that should be exposed through the API. The current specification's provision of an id (which is the external ID and the only one to be transferred through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically opposite to this.

 

2. When dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique keys for every attribute value of a resource, manipulating it will be clumsy and inelegant.

 

3. The PATCH command can be improved in 3 significant ways:

3a. Leverage the fact (from 2 above) that every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations of the PATCH command to add, modify and delete attributes at any level

3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) command.

 

To elaborate,

 

1. Revealing private IDs externally is a form of tight coupling. A major requirement with Identity Management is to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, or when multiple resources are detected to be the same. If internal identifiers are revealed to external domains, such clean-ups become difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one created for this explicit purpose, and only reveal this.

 

In the SCIM case, when an enterprise client POSTs a resource creation request, the cloud provider must generate its own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The enterprise client should map this external UUID to a newly-generated internal ID of its own. In case the resource already has an identifier within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned through the POST response.

 

2. If a resource is to be created, and one of its attributes is multi-valued, e.g.,

 

    "email-addrs" : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

< 

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

 


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

 



This e-mail message, including any attachments, is for the sole use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Gartner makes no warranty that this e-mail is error or virus free.
 



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

--------------050406090800040504030300-- From g.c.prasad@gmail.com Fri Aug 10 20:23:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96F21F8564 for ; Fri, 10 Aug 2012 20:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxXBdShOgsos for ; Fri, 10 Aug 2012 20:23:51 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 494F221F855E for ; Fri, 10 Aug 2012 20:23:51 -0700 (PDT) Received: by bkty7 with SMTP id y7so915642bkt.31 for ; Fri, 10 Aug 2012 20:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=JuHn8oil0In3i0KAoCVNnhEGOtrQmFX4rMxaeMLe/fE=; b=Y4/4fTkpITX8ZhL4fck+Z33Tgv5MAerdifrOtozI1oI5F7JAQ7mA//g0IZRWFun/OP zY8fULoVB85XNdzLcL4CY6/VxlBdWKpIJjOwqSpqp6BCrdieDaUiVcxHd90rtj3UhcZW 3eeRWevVGilFZ5jK00PmfNB64yI/CBZyd0v0HBO3C9KfCXbvXIjkatol9zR2P8kfsHZh gCt6ZN2XtHsV3jkP5rdnRHyAOE9QuESZTxaNmgyTsZdL1FUL1IsWUEZGDWl4s2JQtT4L gQjqKl9f8X8tajSd4XLmrhZcwDPs7CKjx0QuYPCbn2I7/vxAPJZk0Fv7YFDdHjN43Ml6 csfQ== Received: by 10.204.133.194 with SMTP id g2mr1962799bkt.13.1344655430236; Fri, 10 Aug 2012 20:23:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Fri, 10 Aug 2012 20:23:29 -0700 (PDT) In-Reply-To: References: From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 13:23:29 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=00151759308443b91804c6f4fd84 Subject: Re: [scim] scim Digest, Vol 8, Issue 26 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 03:23:52 -0000 --00151759308443b91804c6f4fd84 Content-Type: text/plain; charset=ISO-8859-1 > > Ganesh - we are all participating as individuals in IETF. Maybe you should > consult the rules for working groups as explained in: > > http://tools.ietf.org/pdf/rfc2418.pdf > > It is irrelevant whether you belong to a very large technology company, or > are a technology analyst or whether you are just a great guy/gal. > > All the discussion has to be in the open and all sources (no confidential > research reports!) have to be publicly made available. > > - prateek > > Fair enough. I was just concerned listening to Mark's comments (about adoption being hindered because of complexity for SPs), that one interest group may have undue influence over the WG. if that's not the case, I'm happy :-). Regards, Ganesh --00151759308443b91804c6f4fd84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ganesh - we are all participating as individuals i= n IETF. Maybe you should consult the rules for working groups as explained in:

htt= p://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal.

All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available.

- prateek

Fair enough. I was just concerned listening= to Mark's comments (about adoption being hindered because of complexit= y for SPs), that one interest group may have undue influence over the WG. i= f that's not the case, I'm happy :-).

Regards,
Ganesh
--00151759308443b91804c6f4fd84-- From g.c.prasad@gmail.com Fri Aug 10 20:46:25 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9197511E80A3 for ; Fri, 10 Aug 2012 20:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAATUeF4Pw7b for ; Fri, 10 Aug 2012 20:46:20 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2D21F849C for ; Fri, 10 Aug 2012 20:46:19 -0700 (PDT) Received: by bkty7 with SMTP id y7so919197bkt.31 for ; Fri, 10 Aug 2012 20:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Au+csFrNp9Ew9OoU5EF9R3JUaIC9sS4ObkdgmbGujlw=; b=rFW/lBOmHKPk8+tS1HNkP3x/9WnOuua/k4kJaMst+ZLmCrNdnFWLVYIm7LwifaN0CF y5ydAkA/kIVPd6xSJszoY/eWPnyyOkafsa4pvhDz5nxsIR5r/ngZ9i+1pVCxr6an28ci nSWy97jkPJwiFoMhK+wez1DvduHhlESpz0nYdkqaBShfrobelm0+AToeIAorfg3PaDgB MAPbIcfsS/VRKwZFZ1oilvrGr/necXulAqCV74bch9Ucch5UY6dU6hCwxMkFQkvU3av+ zcuDoFn3xOGqbEZoZOc4dHGwUofGGNKmeML569UC++Qmod5AhnrJjgw2adCqto+Dxyds dYDA== Received: by 10.204.152.211 with SMTP id h19mr2023497bkw.45.1344656778191; Fri, 10 Aug 2012 20:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Fri, 10 Aug 2012 20:45:57 -0700 (PDT) In-Reply-To: References: From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 13:45:57 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=0015175cd13a9be46c04c6f54d3e Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 03:46:25 -0000 --0015175cd13a9be46c04c6f54d3e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value pair. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the attribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully-qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new keys for each individual value, otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this then becomes a composite attribute using dot notation for the key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resource structure. We can refer to every leaf value with a key that is the fully-qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly addressable attributes. INCLUDE to a collection and specify only the value. The key is generated and returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, return a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. If there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whether it existed before or not. Only errors possible are "400 Bad Request" and "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The implementation will determine whether the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {} ). I'll explain in a separate post why we need operation verbs like these that are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) > > > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux < > edreux@cloudiway.com>, Trey Drake , Kelly > Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > Ganesh, > > In your example you are conflating value with an attribute id. I find tha= t > confusing. > > I agree though that operations in patch could be a lot more explicit. > > Eg explicitly deleting a value by saying delete or retire. > > Phil > > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > > > I am concerned about your second suggestion: > > Let's discuss that now. > > The trade-offs are very clear here. > > Pros: > > Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t > and intuitive when every individual attribute value gets its own ID. > > Here's how to delete a single member from a Group, as per the current spe= c: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } > > > Here's how to delete ALL members from a group according to the current > spec: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } > > > The two operations differ significantly, and it's not very intuitive. > With my suggestion, here's how to delete a single member from a group: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] } > Here's how I suggest deleting ALL members from a group: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] } > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader. > > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead of > the specialised (and semantically less ambiguous) verbs I suggested for > attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object. > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes. > > In the current spec, (a) and (b) are done similarly but (c) is very > different. > > Pro 3: Adoption of the standard by clients is likely to be higher because > it's simpler for them. > > Pro 4: New (not incumbent) cloud providers will probably find this easier > to implement because they have no legacy. They will probably use some for= m > of NoSQL database and won't be constrained by the limitations of LDAP > directories. > > Cons: > > Con 1: Incumbent cloud providers with existing data stores in a directory > format (where multi-valued attributes are stored as comma-separated value= s > under a single attribute node) will find it difficult to migrate to this > model and store each attribute value as a sub-node with its own key. This > will "hinder adoption of the spec", which is what you fear. > > Have I summed up the Pros and Cons correctly? I'm biased of course, so I > could have missed a Con or hyped a Pro :-). > > In other words, we're debating interface complexity (current spec) versus > implementation complexity (my suggestion). Both can hinder adoption of th= e > spec by different parties. > > Here's what we need to discuss - Do the Pros make the suggestion worth > adopting in spite of the Cons, or are the Cons so great that it's best to > leave the spec as it is? > > Keep in mind that a complex spec that only favours incumbent cloud > providers can cut both ways. It opens the door to a simpler interface > offered by a new generation of nimbler SPs that don't have the same legac= y > issues, and there could be an exodus of clients to these new SPs. SCIM > could end up being obsoleted very soon, because the API interface is very > complex and clumsy, as any new reader can attest. I was taken aback by th= e > complexity when I saw it, which is why I was prompted to suggest somethin= g > simpler. > > This is an issue where we need the opinions of many people, and they need > to state their affiliations. If most people weighing in belong to incumbe= nt > SPs and they vote in favour of interface complexity to avoid implementati= on > complexity, then it means the spec is not doing a good job of balancing t= he > interests of various groups. I think we should also poll client > organisations to see what they would want. > > (Gartner is trusted by enterprise clients to evaluate the capabilities of > vendors (SPs). I believe Gartner should take the lead in representing > client interests in this working group rather than those of incumbent > vendors, which is what it seems like to me. Correct me if I'm being unfai= r.) > > Regards, > Ganesh > > > > On 11 August 2012 01:35, Diodati,Mark wrote: > >> Hi Ganesh, >> >> >> >> I am concerned about your second suggestion: >> >> =932. When dealing with multi-valued attributes of a resource (expressed= as >> arrays in JSON), they must be converted from an array into a dictionary >> with unique keys (UUIDs generated by the cloud provider when the attribu= te >> is created). Without unique keys for every attribute value of a resource= , >> manipulating it will be clumsy and inelegant.=94 >> >> >> >> One of the primary reasons that SPML failed was lack of adoption by >> service providers due to its complexity. Very few target applications >> implemented SPML. Most of the commercial provisioning systems had an SPM= L >> interface (either v1 or v2), but not one of them was conformant to the S= PML >> standard because of complexity. If you are interested, I will forward yo= u >> the research documents that discuss these problems in detail. For SCIM t= o >> be successful, it must be adopted by commercial target applications (i.e= ., >> service providers). I am confident that a requirement for unique >> identifiers with multi-valued attributes will preclude its adoption, >> because it requires major changes to the service provider=92s existing >> identity storage mechanisms. >> >> Mark >> >> >> >> >> >> >> >> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >> *Sent:* Friday, August 10, 2012 9:51 AM >> >> *To:* Ganesh and Sashi Prasad >> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >> >> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >> >> >> >> Ganesh, >> >> >> >> I'll base my comments on your latest reply (below). >> >> >> >> The externalID is not part of the protocol. It is an *optional* >> attribute within the *schema* specification. As for #2, the protocol sp= ec >> works as you describe if "arbitrary URI parameters" equate to resource >> attributes (Allow generic search using 'GET /Users' and arbitrary URI >> parameters). Please clarify your suggestion. >> >> >> >> I'm not tracking your coupling concern. The client can search and hence >> retrieve resources on any attribute it chooses, externalId or otherwise. >> Nothing mandates use of externalId. >> >> >> >> >> >> What do you mean by "candidate key"? Given >> >> >> >> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >> g.c.prasad@gmail.com> wrote: >> >> > I think scim gets its current simplicity from its single owner hub >> spoke model implementing tight coupling. [...] IMHO loose coupling is a >> much more complex solution. >> >> >> >> Phil, >> >> >> >> I'm a bit surprised that you're implying "tight coupling =3D=3D simple" = and >> "loose coupling =3D=3D complex". That's contrary to my experience. >> >> >> >> When I say "loose coupling", I mean "no unnecessary dependencies". >> Invariably, a reduction in dependencies leads to greater simplicity. >> >> >> >> Let's not confuse reduction of dependencies in the data model with a >> hub-and-spokes architecture. They're entirely orthogonal aspects of the >> solution. >> >> >> >> All that my suggestion involves is, >> >> >> >> 1. Take 'external ID' out of the protocol. >> >> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >> >> >> >> No planned functionality is lost by this. >> >> >> >> 1. The client enterprise can still send its internal ID as part of the >> resource body, inside some attribute defined by them (but not defined by >> the protocol). Let's say they call it 'myID'. >> >> 2. The client enterprise can search for resource URIs using any >> attribute, including this internal ID >> >> 'GET /Users?myID=3Dbjensen' >> >> Since myID is a candidate key, the server will return exactly one URI, >> which is the canonical URI for the resource >> >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> >> 3. The client can use this URI to perform all other operations as usual. >> >> >> >> So taking 'externalID' out of the protocol spec only does this: >> >> 1. It avoids enshrining tight coupling in the protocol (If clients want = to tightly couple themselves to the cloud provider by sending their interna= l IDs, they can do so. Suicide is OK, but the protocol should not be guilty= of assisted suicide. ;-) >> >> 2. It encourages loose coupling by nudging clients towards maintaining t= heir own internal-to-external identifier mappings. >> >> >> >> That's what I'd like to see. I don't believe this complicates the protoc= ol. It simplifies it and it also lends itself to a loosely-coupled approach= . >> >> >> >> I'll address the multi-valued attribute suggestion separately. >> >> >> >> Regards, >> >> Ganesh >> >> >> >> >> >> >> >> >> >> On 10 August 2012 07:53, Phil Hunt wrote: >> >> >> >> Phil >> >> >> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >> wrote: >> >> > storing this information in a mapping table outside of the SCIM spec >> is a great way to enable this solution. Part of the key here is that SC= IM >> is just a piece of the architecture for this solution, and is only >> responsible for the transport layer between domains. >> >> I wasn't suggesting that the mapping table be part of the SCIM spec. I >> provided that example to illustrate that splitting and merging identitie= s >> is a common requirement, and that decoupling local identifiers within a >> domain from shared identifiers between domains was the best way to >> facilitate it. >> >> >> >> I'm suggesting that the spec do less, not more. >> >> >> >> What the SCIM spec needs to do there is just refrain from introducing >> tight coupling. I would like to see a single identifier exposed through = the >> API, with the implication (and perhaps the recommendation) that it be th= e >> shared one. Allowing one domain to expose its internal identifier to the >> other creates tight coupling and ensures that both domains need >> simultaneously split or merge identities, which is not desirable. So I >> recommend _taking out_ the "external id" field from the API. The spec >> shouldn't encourage tight coupling. If clients want to pass in their >> internal ids as part of the resource body, no one can stop them, and the= y >> can always do a search on that attribute to retrieve the URI exactly as = you >> visualise they will with the "external id", but let's not elevate an >> anti-pattern to a recommendation by enshrining the "external id" as an >> acceptable attribute. >> >> >> >> Am I making sense? >> >> >> >> I see what you are saying. I think scim gets its current simplicity from >> its single owner hub spoke model implementing tight coupling. >> >> >> >> IMHO loose coupling is a much more complex solution. The reality is that >> each end-point has value to contribute and thus the single-owner model w= ill >> eventually need to become multi-owner or multi-hub. >> >> >> >> That said i think the current model provides a practical starting point. >> >> >> >> > Regarding unique identifiers for multi-valued attributes there is a >> trade-off involved. On one hand this makes PATCH semantics easier. On = the >> other hand it puts extra burden on service providers. >> >> >> Precisely. The spec has to strike the right balance. It would be >> interesting to hear from the other members of the spec mailing list. You >> know where I stand on this. It would be good to hear the spectrum of >> opinions. >> >> >> >> Regards, >> >> Ganesh >> >> On 10 August 2012 00:28, Kelly Grizzle >> wrote: >> >> Thanks Emmanuel. I had started writing up a similar response. As you >> suggest, storing this information in a mapping table outside of the SCIM >> spec is a great way to enable this solution. Part of the key here is th= at >> SCIM is just a piece of the architecture for this solution, and is only >> responsible for the transport layer between domains. >> >> >> >> You could also model these ID mappings in the SCIM user as an extension >> but would probably not want to expose these externally. Here is an exam= ple >> of how to model the end state of the false positive scenario (splitting = a >> user): >> >> >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true | >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | >> true | >> >> >> >> This could be represented as two SCIM users that contain information >> about the entities on other domains. >> >> >> >> { >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"], >> >> "id": "9caf78aac3d6", >> >> "userName": "John Smith", >> >> "urn:scim:schemas:extension:federation:1.0": { >> >> "linkedUsers": [ >> >> { >> >> "domain": "D2", >> >> "externalEntityId": "ff487230b3a0" >> >> } >> >> ] >> >> } >> >> } >> >> >> >> { >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"], >> >> "id": "a99a5feba839", >> >> "userName": "John Smith", >> >> "urn:scim:schemas:extension:federation:1.0": { >> >> "linkedUsers": [ >> >> { >> >> "domain": "D2", >> >> "externalEntityId": "7a87f27c1dd8" >> >> } >> >> ] >> >> } >> >> } >> >> >> >> In the second user, the linkedUsers attribute would be empty until the >> split user was synced to domain 2. >> >> >> >> >> >> Similarly, the false negative use case (merging two users) looked like >> this at the end: >> >> >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | >> true | >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | >> false | >> >> >> >> This could be represented with the following SCIM user: >> >> >> >> { >> >> "schemas": ["urn:scim:schemas:core:1.0", >> "urn:scim:schemas:extension:federation:1.0"], >> >> "id": "9caf78aac3d6", >> >> "userName": "John Smith", >> >> "urn:scim:schemas:extension:federation:1.0": { >> >> "linkedUsers": [ >> >> { >> >> "domain": "D2", >> >> "externalEntityId": "ff487230b3a0" >> >> }, >> >> { >> >> "domain": "D2", >> >> "externalEntityId": "41206cc97c8b", >> >> "deletionRequired": true >> >> } >> >> ] >> >> } >> >> } >> >> >> >> >> >> Regarding unique identifiers for multi-valued attributes there is a >> trade-off involved. On one hand this makes PATCH semantics easier. On = the >> other hand it puts extra burden on service providers. Since the incepti= on >> of SCIM, a key goal has been to foster adoption by service providers by >> making things fit easily onto existing systems. IMO the value gained by >> unique identifiers for multi-valued attributes is not worth the demands = put >> on a service provider. I also think that vendors that have a >> non-SCIM-compliant API will choose to keep things that way if the spec i= s >> too hard for them to implement. In a green field environment we do have >> the luxury of mandating a model to make certain operations more elegant. >> However, we can=92t ignore legacy systems. >> >> >> >> --Kelly >> >> >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Emmanuel Dreux >> *Sent:* Thursday, August 09, 2012 3:18 AM >> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >> >> >> >> Hi Ganesh, >> >> >> >> Nothing prevents you in your SCIM implementation (client or server) to >> generate a unique identifier for each synchronized object and maintain a= n >> internal mapping table ( you would have to map group membership as well)= . >> >> >> >> This is what we are doing with Active Directory sources or targets: >> >> As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNa= me, >> UPN) are subject to change (even objectGuid can change if an AD domain i= s >> migrated), we decided to generate and maintain an internal table of ids. >> This fits your requirements as it hides internal ids. >> >> >> >> This was written in dotnet and we have started a project to rewrite our >> SCIM stack in PHP and will give it to the Open Source community. This >> implementation will have a parameter : AllocateIds versus UseExistingIDs= . >> >> This will give the choice of =93hiding=94 internalIDs or use them as uni= que >> ID. >> >> >> >> You can also implement such feature without violating the SCIM specs, or >> without asking to include it in the specs. >> >> >> >> -- >> >> Regards, >> >> Emmanuel Dreux >> >> http://www.cloudiway.com >> >> Tel: +33 4 26 78 17 58 >> >> Mobile: +33 6 47 81 26 70 >> >> skype: Emmanuel.Dreux >> >> >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> >> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org >> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >> >> >> >> Hi Kelly, >> >> Thanks for your response. Let me first respond in brief to the two main >> points you have made, and then elaborate on the first. >> >> 1. Why should domains not expose their internal identifiers to >> other domains? >> >> a. >> >> We are designing a protocol for a federated system of domains, where all >> domains are co-equal peers. (In physics too, N-body problems are much >> harder than 2-body problems. :-) Therefore, assuming that there are only >> two players in the interaction makes this tightly coupled in a number of >> ways. We should rely on messaging and notification, with encapsulation o= f >> domain-specific data. >> >> b. >> >> In any non-trivial data store, there will always be the ongoing need to >> merge and split identities as and when =93false negatives=94 and =93fals= e >> positives=94 are discovered. A domain should be able to handle this inte= rnal >> housekeeping freely, only notifying other domains when convenient. Mappi= ng >> of internal identifiers to external ones and maintaining this mapping >> internally allows this loosely-coupled housekeeping to take place. Shari= ng >> internal identifiers (or otherwise outsourcing the mapping of internal t= o >> external identifiers) forces housekeeping activities to be done in >> lock-step across domains. >> >> c. >> >> Asynchronous interaction is not just a matter of a suitable wire protoco= l >> which can be designed later. The data model plays a crucial role in >> enabling or constraining such interaction. A tightly-coupled data model >> will force the use of synchronous interactions, and the exposure of >> internal identifiers is a key part of this tight coupling. >> >> 2. The difficulty of assigning unique identifiers to the individual >> values of multi-valued attributes: >> >> a. >> >> I'm not belittling the effort involved in migrating legacy data stores t= o >> such a model. However, in the larger historical context of cross-domain >> identity management, we are really at the very early stages. If a >> relatively new discipline and a brand new spec are held captive to legac= y >> considerations, we are losing an opportunity to provide a clean and eleg= ant >> model to subsequent users of the spec, and this will have repercussions >> over many years or even decades. >> >> b. >> >> If incumbent cloud providers find it hard to immediately adopt the >> dictionary model for existing multi-valued attributes, they can transiti= on >> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-comp= liant=94 >> APIs to their customers and encouraging new customers to adopt the >> =93SCIM-compliant=94 API. Legacy customers can be supported using a >> =93non-SCIM-compliant=94 API for an arbitrarily long period and graduall= y >> migrated to the SCIM-compliant API. The logistics are not insurmountable= , >> and shouldn't prevent the adoption of a dictionary model for multi-value= d >> attributes. >> >> Elaboration of Point 1: >> >> When we consider federated identity across more than one domain, we have >> to assume that domains are not necessarily master-slave in their >> interaction. The most generic interaction model is peer-to-peer, where >> entity lifecycle events within a domain are notified to other domains (w= hen >> necessary) in an asynchronous manner (i.e., through messaging) and the >> other domains are free to respond to these events in an appropriate mann= er >> and at a time of their convenience. >> >> A key set of lifecycle events for an entity is the merging and splitting >> of identity that is often required. >> >> The question =93Is this one entity?=94 can be answered either yes (posit= ive) >> or no (negative). But sometimes, we can discover false positives and fal= se >> negatives in our data stores. >> >> Consider a case where customers sign up online, and two customers who ar= e >> privacy-conscious enter fake IDs such as =93John Smith=94, and also use = the >> same date of birth (say, 1 Jan 1970) or similar attributes. The front-en= d >> application may make an intelligent (but incorrect) guess that these two >> persons are the same, and re-assign the same identifier to the second >> person. This is a false positive. They appear to be the same entity, but >> they're actually different. When the error is discovered, the identities >> will need to be split, with a new identifier generated for one of them. >> >> Consider the opposite case where a customer signs up through two >> different portals or in two different sessions, using the names =93JSmit= h=94 >> and =93JohnS=94. It is very likely that they will be treated as two diff= erent >> customers and assigned two unique identifiers. This is a false negative. >> They appear to be two entities, but are actually the same. At a later >> stage, when the error is discovered, the identities will have to be merg= ed, >> and one of the identifiers will have to be dropped. >> >> These are not theoretical use cases. They form a significant proportion >> of the user base in most large Web-facing applications. Let's see how th= ese >> can be managed in a federated way by mapping internal identifiers to >> external ones and only exposing external identifiers to other domains. >> >> a. False positives: >> >> Domain 1 has the following information about a customer in its data stor= e: >> >> Internal ID: 9caf78aac3d6 >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> >> When requesting the provisioning of this entity in Domain 2, the >> following ID is returned by Domain 2: ff487230b3a0. >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifier: >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> >> When the false positive is discovered and the entity is split, Domain 1 >> creates a new internal identifier and now has the following entity >> information. >> >> Internal ID: 9caf78aac3d6 >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> >> Internal ID: a99a5feba839 >> >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> >> This second entity with its own internal identifier is invisible to >> Domain 2, and this is by design. Communication about the original entity >> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >> vice-versa. At some convenient time (importantly, this doesn't have to b= e >> at the time the split happens), Domain 2 can be requested to provision a >> second entity, and when it responds with an identifier of =937a87f27c1dd= 8=94, >> this can go into the mapping table as a new record associated with the >> second entity's internal identifier. >> >> The mapping table now contains the following entries: >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >> >> Domain 2 is not even aware that a split has happened, and the >> provisioning that it does is not in lockstep with the split in identity >> that occurred in Domain 1. >> >> (What is the =93Primary flag=94 used for? We'll see when we cover the >> treatment of false negatives.) >> >> b. False negatives: >> >> Domain 1 has the following information about what it thinks are two >> distinct customers in its data store: >> >> Internal ID: 9caf78aac3d6 >> >> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >> >> Internal ID: 273d36e30d09 >> >> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >> >> When requesting the provisioning of these entities in Domain 2, the >> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >> >> Domain 1 then maintains the following in a mapping table and uses it for >> translation when talking to Domain 2, taking care never to expose its >> internal identifiers: >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> >> | 273d36e30d09 | D2 | 41206cc97c8b | true | >> >> When the false negative is discovered and the two entities are merged, >> Domain 1 drops one of the internal identifiers and rationalises the name= of >> the customer (say, to =93John Smith=94). Let's say it retains the first = ID >> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >> >> The mapping table now looks like this: >> >> | Internal Entity ID | External Domain ID | External Entity ID | Primary >> flag | >> >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >> >> Now two external identifiers map to the same internal one, so inbound >> communication from Domain 2 can be unambiguously translated to the same >> entity internally. However, when going outwards, Domain 1 will have to l= ook >> up the translation table to determine the =93primary=94 external ID for = this >> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That's w= here >> the =93Primary flag=94 comes in. The second external ID =9341206cc97c8b= =94 is never >> used thereafter in outbound communication. >> >> At some stage (importantly, not in lockstep with the identity merge), >> Domain 2 can be requested to delete the customer record identified by >> =9341206cc97c8b=94, and the second entry in the mapping table can be rem= oved >> once this is acknowledged. >> >> This scheme will scale up to multiple domains, because the =93External >> Domain ID=94 column helps to keep track of which external ID is shared w= ith >> which Domain. (Why don't we use just one external ID for an entity and >> share it with all external domains? Tight coupling again. Just as OAuth >> allows an access token given to a third party to be invalidated without >> affecting the access of other third parties, the use of separate externa= l >> identifiers for different domains allows fine-grained control of identit= y >> federation.) >> >> The scheme also allows the splitting of an entity into more than two >> entities, and the merging of more than two entities into a single one. (= Any >> organisation with a web-facing application will tell you how many John >> Smiths there are who were born on 1 Jan 1970!) >> >> This is a fairly long-winded explanation, but this is why we need to hid= e >> internal identifiers from other domains, and why mappings need to be >> managed internally in each domain. Such a data model also allows us to >> choose asynchronous protocols for propagation of identity events, since >> there is no consistency requirement to update multiple domains concurren= tly. >> >> Regards, >> >> Ganesh Prasad >> >> >> >> On 9 August 2012 04:55, Kelly Grizzle >> wrote: >> >> Thanks for the feedback, Ganesh. I read through this and your InfoQ >> article (http://www.infoq.com/articles/scim-data-model-limitations) and >> have some thoughts. >> >> >> >> > The rest of the protocol does not meaningfully use the enterprise >> client=92s identifier, the "external ID" >> >> > at all, even though it was ostensibly introduced to make things >> friendlier for the client. >> >> >> >> The usage pattern for an external ID would be to search for a user by >> externalId and use the ID of the returned user in any desired operation. >> For example: >> >> >> >> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >> >> >> >> { >> >> =93totalResults=94: 1, >> >> =93Resources=94: [ >> >> { >> >> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >> >> } >> >> ] >> >> } >> >> >> >> Retrieve the ID from the response and use it. >> >> >> >> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >> >> >> >> This does introduce an additional HTTP request if the client chooses not >> to store the server=92s id. An issue was created to consider allowing >> operations to use the externalId ( >> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the >> general consensus has been to not include this in the spec. One main po= int >> of contention is that much of the rest of the spec (eg =96 group members= hip >> references, manager references, etc=85) require knowledge of the server= =92s >> identifier. Continuing this discussion on the IETF list would be a good >> thing, though. >> >> >> >> >> >> > the cloud provider's ID and the enterprise client's ID are both >> "Internal IDs" with respect to their domains >> >> >> >> I think this comes down to a nomenclature problem. The server=92s ID do= es >> not necessarily have to be the unique identifier that the underlying >> identity store uses, it just has to be stable and unique. In many cases= , >> the underlying identity store will provide identifiers with these >> properties already (eg =96 a uuid) and it can be used by the SCIM interf= ace. >> The =93externalId=94 is referring to the fact that the id is maintained >> external to the SCIM server. As long as the server=92s identifiers are >> stable and unique (which is mandated by the spec), I don=92t see a probl= em. >> >> >> >> >> >> > The secret is that *every value needs a key*, and multi-valued >> attributes lack that. So our solution is quite >> >> > simple - turn every list or array (of values) into a dictionary (of >> key-value pairs) by providing each value >> >> > with a unique and meaning-free identifier. >> >> >> >> I agree that this would be useful, especially in the PATCH operation. >> One reason that this wasn=92t included in the spec originally is that it= can >> put undue burden on the service provider. Many service providers are >> putting SCIM interfaces in front of their existing identity stores (eg = =96 >> directory servers, SaaS application databases, etc=85). Many of these d= o not >> have a unique identifier for multi-valued attributes. By requiring this= , a >> majority of the server providers would have to start maintaining a uniqu= e >> key for each multi-valued attribute. I believe this would be a roadbloc= k >> for many implementers. >> >> >> >> >> >> > When the SCIM protocol uses PATCH, there are areas where it seems a >> bit clumsy. >> >> >> >> I like the thoughts here. Your example reminds me of unified diffs ( >> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >> used with a patch program (pretty much the equivalent of the PATCH verb)= . >> However, the three proposals seem to largely hinge on being able to >> uniquely address each element within an object. Without these it is not= so >> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or >> provide a multi-status. >> >> >> The 207 response would be interesting to consider for the bulk endpoint = ( >> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources)= , >> however. >> >> >> >> >> >> > There are other, non-data aspects of SCIM which may require review, >> such as its synchronous request-response >> >> > interaction model, which is a form of tight coupling and could prove t= o >> be a source of brittleness. >> >> >> >> I agree that we should explore optional asynchronous requests in 2.0. >> >> >> >> Thanks again for your thoughts. I hope you stay involved in the >> discussion as work on SCIM 2.0 goes forward. >> >> >> >> --Kelly >> >> >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Ganesh and Sashi Prasad >> *Sent:* Wednesday, August 01, 2012 4:24 PM >> *To:* scim@ietf.org >> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement >> >> >> >> (I posted this on the SCIM Google Group, and I was advised to subscribe >> to the mailing list and post it here instead, so here goes.) >> >> >> >> Hi, >> >> >> >> My name is Ganesh Prasad, and my experience in Identity and Access >> Management is mainly through a 3-year project at an Australian insurance >> company, an experience I have written about as a eBook on InfoQ ( >> http://www.infoq.com/minibooks/Identity-Management-Shoestring). >> >> >> >> I have been following the SCIM spec off and on, and based on my >> experience with a loosely-coupled architecture that I found to be >> successful, I have the following 3 suggestions to make. >> >> >> >> 1. The enterprise client and the cloud provider should maintain their ow= n >> internal IDs for a resource, which they should not reveal to each other. >> Both of them should map their internal IDs to a shared External ID, and >> this is the only ID that should be exposed through the API. The current >> specification's provision of an id (which is the external ID and the onl= y >> one to be transferred through the API) and an "external ID" (which is th= e >> client's internal ID and should be hidden) is diametrically opposite to >> this. >> >> >> >> 2. When dealing with multi-valued attributes of a resource (expressed as >> arrays in JSON), they must be converted from an array into a dictionary >> with unique keys (UUIDs generated by the cloud provider when the attribu= te >> is created). Without unique keys for every attribute value of a resource= , >> manipulating it will be clumsy and inelegant. >> >> >> >> 3. The PATCH command can be improved in 3 significant ways: >> >> 3a. Leverage the fact (from 2 above) that every value has a key, to >> greatly simplify the API >> >> 3b. Use special verbs as nested operations of the PATCH command to add, >> modify and delete attributes at any level >> >> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 OK" >> as the response to a PATCH (or BULK) command. >> >> >> >> To elaborate, >> >> >> >> 1. Revealing private IDs externally is a form of tight coupling. A major >> requirement with Identity Management is to split (or merge) identities w= hen >> false positives (or false negatives) are detected, i.e., when a resource= is >> discovered to be more than one, or when multiple resources are detected = to >> be the same. If internal identifiers are revealed to external domains, s= uch >> clean-ups become difficult, hence every domain that wants to expose >> references to a resource must map its internal ID to and external one >> created for this explicit purpose, and only reveal this. >> >> >> >> In the SCIM case, when an enterprise client POSTs a resource creation >> request, the cloud provider must generate its own internal UUID as well = as >> an external UUID, map them together, and only return the external UUID i= n >> the "Location:" header. The enterprise client should map this external U= UID >> to a newly-generated internal ID of its own. In case the resource alread= y >> has an identifier within the enterprise client's domain, then this is th= e >> internal ID that must be mapped to the external UUID returned through th= e >> POST response. >> >> >> >> 2. If a resource is to be created, and one of its attributes is >> multi-valued, e.g., >> >> >> >> "email-addrs" : >> >> [ >> >> "john_smith@yahoo.com", >> >> "john.smith@gmail.com", >> >> "jsmith1970@hotmail.com" >> >> < >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> >> ------------------------------ >> >> This e-mail message, including any attachments, is for the sole use of >> the person to whom it has been sent, and may contain information that is >> confidential or legally protected. If you are not the intended recipient= or >> have received this message in error, you are not authorized to copy, >> distribute, or otherwise use this message or its attachments. Please not= ify >> the sender immediately by return e-mail and permanently delete this mess= age >> and any attachments. Gartner makes no warranty that this e-mail is error= or >> virus free. >> > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015175cd13a9be46c04c6f54d3e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0In your example you are conflating value with an attribute id.=A0
I don't believe so.

I'm adopting a model where every attribute of the resource is = a key-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite= ), the key is the attribute name itself.=A0

S= imple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite= attributes, the key employs dot notation to specify the fully-qualified at= tribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-num= ber"
Value: "10"

Key: &qu= ot;address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting = that there be new keys for each individual value, otherwise they are imposs= ible to distinguish, and a positional index is inadequate. So we convert th= e array into a dictionary and this then becomes a composite attribute using= dot notation for the key.

Multi-valued attribute:

Key: &= quot;emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: &qu= ot;john_smith@yahoo.com"

So this allows us to apply uniform treatment to any arb= itrarily deep resource structure. We can refer to every leaf value with a k= ey that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and = specify only the value. The key is generated and returned. The fully-qualif= ied key is <collection-name>.<newly-generated-ID> and the value= is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the = key doesn't exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualifi= ed key. If there is already a key with that name, return a "409 Confli= ct".

FORCE the fully-qualified key to hold the given value, = regardless of whether it existed before or not. Only errors possible are &q= uot;400 Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualifie= d key. The implementation will determine whether the attribute will disappe= ar entirely or will exist holding a null value (the blank string "&quo= t; or the empty object {} ).

I'll explain in a separate post why we need operati= on verbs like these that are independent of the HTTP verbs.

<= /div>
Regards,
Ganesh

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

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

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



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

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

You can reach the person managing the list at
=A0 =A0 =A0 =A0 scim-owner@ietf.org<= /a>

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:= =A0Ganesh and Sashi Prasad <g.c.= prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <edreux@cloudiway.com>, Trey Drake <trey.drake@unboundid.com>, Kell= y Grizzle <kelly.grizzle@= sailpoint.com>, "scim@ietf.org= " <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Proto= col - 3 suggestions for improvement
G= anesh,

In your example you are conflating value wi= th an attribute id. I find that confusing.=A0

I agree though that operations in patch could be a lot = more explicit.=A0

Eg explicitly deleting a value b= y saying delete or retire.=A0

Phil

On 2012-08-1= 0, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I = am concerned about your second suggestion:=A0

Let= 's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipu= late resources becomes so much cleaner, consistent and intuitive when every= individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current s= pec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to th= e current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3=
f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very in= tuitive.=A0
With my suggestion, here's how to delete a single= member from a group:

PATCH /Groups/acbf3ae7-846= 3-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more c= onsistent and more intuitive to a reader.

Pro 2: W= e can apply this mechanism consistently to three areas:
(a) Manip= ulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk oper= ations, where we simply use HTTP verbs instead of the specialised (and sema= ntically less ambiguous) verbs I suggested for attributes, the "key&qu= ot; becomes the URI, and the "value" becomes the corresponding JS= ON object.

All of them return "207 Multi-Status" with th= e "results" array holding individual status codes.

=
In the current spec, (a) and (b) are done similarly but (c) is v= ery different.

Pro 3: Adoption of the standard by clients is likely to= be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to im= plement because they have no legacy. They will probably use some form of No= SQL database and won't be constrained by the limitations of LDAP direct= ories.

Cons:

Con 1: Incumbent cloud p= roviders with existing data stores in a directory format (where multi-value= d attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each attrib= ute value as a sub-node with its own key. This will "hinder adoption o= f the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm b= iased of course, so I could have missed a Con or hyped a Pro :-).

=
In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make t= he suggestion worth adopting in spite of the Cons, or are the Cons so great= that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, a= nd there could be an exodus of clients to these new SPs. SCIM could end up = being obsoleted very soon, because the API interface is very complex and cl= umsy, as any new reader can attest. I was taken aback by the complexity whe= n I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peo= ple, and they need to state their affiliations. If most people weighing in = belong to incumbent SPs and they vote in favour of interface complexity to = avoid implementation complexity, then it means the spec is not doing a good= job of balancing the interests of various groups. I think we should also p= oll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate t= he capabilities of vendors (SPs). I believe Gartner should take the lead in= representing client interests in this working group rather than those of i= ncumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.)

Regards,
Ganesh



<= div class=3D"gmail_quote">On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0

=A0

=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ie= tf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0

=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0




On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0







I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0






I'm suggesting that the spec do less, not more.<=
/p>



=A0




What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0






Am I making sense?










=A0






I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0






IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0










=A0






That said i think the current model provides a pract=
ical starting point.=A0














=A0






>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.










=A0






Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec
 is a great way to enable this solution.=A0 Part of the key here is that SC=
IM is just a piece of the architecture for this solution, and is only respo=
nsible for the transport layer between domains.


=A0


You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example
 of how to model the end state of the false positive scenario (splitting a =
user):




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.






=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.






=A0


=A0


Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 with the following SCIM user:


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


=A0


Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other
 hand it puts extra burden on service providers.=A0 Since the inception of =
SCIM, a key goal has been to foster adoption by service providers by making=
 things fit easily onto existing systems.=A0 IMO the value gained by unique=
 identifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0


--Kelly


=A0






From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0


Hi Ganesh,


=A0

Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an
 internal mapping table ( you would have to map group membership as well).<=
/span>


=A0


This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain
 is migrated), we decided to generate and maintain an internal table of ids=
. This fits your requirements as it hides internal ids.


=A0


This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0


You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.






=A0


--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com






Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0



De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0


Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=








b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.






Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:






| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.






Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.






(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:






| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambiguously translated to the same entity inter=
nally. However, when going outwards,
 Domain 1 will have to look up the translation table to determine the =93pr=
imary=94 external ID for this entity in Domain 2, which was decided to be =
=93ff487230b3a0=94. That's where the =93Primary flag=94 comes in. The s=
econd external ID =9341206cc97c8b=94 is never used thereafter
 in outbound communication.


At s=
ome stage (importantly, not in lockstep with the identity merge), Domain 2 =
can be requested to delete the customer record identified by =9341206cc97c8=
b=94, and the second entry in the mapping
 table can be removed once this is acknowledged.


This=
 scheme will scale up to multiple domains, because the =93External Domain I=
D=94 column helps to keep track of which external ID is shared with which D=
omain. (Why don't we use just one external
 ID for an entity and share it with all external domains? Tight coupling ag=
ain. Just as OAuth allows an access token given to a third party to be inva=
lidated without affecting the access of other third parties, the use of sep=
arate external identifiers for different
 domains allows fine-grained control of identity federation.)


The =
scheme also allows the splitting of an entity into more than two entities, =
and the merging of more than two entities into a single one. (Any organisat=
ion with a web-facing application will
 tell you how many John Smiths there are who were born on 1 Jan 1970!)


This=
 is a fairly long-winded explanation, but this is why we need to hide inter=
nal identifiers from other domains, and why mappings need to be managed int=
ernally in each domain. Such a data
 model also allows us to choose asynchronous protocols for propagation of i=
dentity events, since there is no consistency requirement to update multipl=
e domains concurrently.


Rega=
rds, 



Gane=
sh Prasad


=A0




On 9 August 2012 04:55, Kelly Griz=
zle <ke=
lly.grizzle@sailpoint.com> wrote:






Thanks for the feedback, =
Ganesh.=A0 I read through this and your InfoQ article (=
http://www.infoq.com/articles/scim-data-model-limitations)
 and have some thoughts.


=A0


>
The rest of the protocol does not meani=
ngfully use the enterprise client=92s identifier, the "external ID&quo=
t;






> at all, even thoug=
h it was ostensibly introduced to make things friendlier for the client.






=A0


The usage pattern for an =
external ID would be to search for a user by externalId and use the ID of t=
he returned user in any desired operation.=A0 For
 example:


=A0


GET /Users?filter=3Dexter=
nalId eq =93bjensen=94&attributes=3Did


=A0


{


=A0 =93totalResults=94: 1,


=A0 =93Resources=94: [


=A0=A0=A0 {


=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45=
3a-919d-413861904646=94


=A0=A0=A0 }


=A0 ]


}


=A0


Retrieve the ID from the =
response and use it.


=A0


DELETE /Users/2819c223-7f=
76-453a-919d-413861904646


=A0


This does introduce an ad=
ditional HTTP request if the client chooses not to store the server=92s id.=
=A0 An issue was created to consider allowing operations
 to use the externalId (http://code.google.com/p/scim/issues/=
detail?id=3D35), but I believe
 the general consensus has been to not include this in the spec.=A0 One mai=
n point of contention is that much of the rest of the spec (eg =96 group me=
mbership references, manager references, etc=85) require knowledge of the s=
erver=92s identifier.=A0 Continuing this discussion
 on the IETF list would be a good thing, though.


=A0


=A0


>
the cloud provider's ID and the ent=
erprise client's ID are both "Internal IDs" with respect to t=
heir domains






=A0


I think this comes down t=
o a nomenclature problem.=A0 The server=92s ID does not necessarily have to=
 be the unique identifier that the underlying identity
 store uses, it just has to be stable and unique.=A0 In many cases, the und=
erlying identity store will provide identifiers with these properties alrea=
dy (eg =96 a uuid) and it can be used by the SCIM interface.=A0 The =93exte=
rnalId=94 is referring to the fact that the
 id is maintained external to the SCIM server.=A0 As long as the server=92s=
 identifiers are stable and unique (which is mandated by the spec), I don=
=92t see a problem.


=A0


=A0


>
The secret is that=A0every value nee=
ds a key, and multi-valued attributes lack that. So our solution is qui=
te






> simple - turn ever=
y list or array (of values) into a dictionary (of key-value pairs) by provi=
ding each value






> with a unique and =
meaning-free identifier.


=A0


I agree that this would b=
e useful, especially in the PATCH operation.=A0 One reason that this wasn=
=92t included in the spec originally is that it can
 put undue burden on the service provider.=A0 Many service providers are pu=
tting SCIM interfaces in front of their existing identity stores (eg =96 di=
rectory servers, SaaS application databases, etc=85).=A0 Many of these do n=
ot have a unique identifier for multi-valued
 attributes.=A0 By requiring this, a majority of the server providers would=
 have to start maintaining a unique key for each multi-valued attribute.=A0=
 I believe this would be a roadblock for many implementers.


=A0


=A0


>
When the SCIM protocol uses PATCH, ther=
e are areas where it seems a bit clumsy.


=A0


I like the thoughts here.=
=A0 Your example reminds me of unified diffs (http://en.wikipedi=
a.org/wiki/Diff#Unified_format),
 which are commonly used with a patch program (pretty much the equivalent o=
f the PATCH verb). =A0However, the three proposals seem to largely hinge on=
 being able to uniquely address each element within an object.=A0 Without t=
hese it is not so easy to address each
 patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<=
/span>




The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci=
m-api-00.html#bulk-resources),
 however.


=A0


=A0


>
There are other, non-data aspects of SC=
IM which may require review, such as its synchronous request-response






> interaction model,=
 which is a form of tight coupling and could prove to be a source of brittl=
eness.






=A0


I agree that we should ex=
plore optional asynchronous requests in 2.0.


=A0


Thanks again for your tho=
ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go=
es forward.






=A0


--Kelly


=A0




From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Ganesh and Sashi Prasad

Sent: Wednesday, August 01, 2012 4:24 PM

To: scim@ietf.org=


Subject: [scim] SCIM Protocol - 3 suggestions for improvement=









=A0




(I posted this on the SCIM Google Group, and I was a=
dvised to subscribe to the mailing list and post it here instead, so here g=
oes.)






=A0






Hi,






=A0






My name is Ganesh Prasad, and my experience in Ident=
ity and Access Management is mainly through a 3-year project at an Australi=
an insurance company, an experience I have written about as a eBook on Info=
Q (http://www.infoq.com/minibooks/Identity-Management-Shoe=
string).










=A0






I have been following the SCIM spec off and on, and =
based on my experience with a loosely-coupled architecture that I found to =
be successful, I have the following 3 suggestions to make.






=A0






1. The enterprise client and the cloud provider shou=
ld maintain their own internal IDs for a resource, which they should not re=
veal to each other. Both of them should map their internal IDs to a shared =
External ID, and this is
 the only ID that should be exposed through the API. The current specificat=
ion's provision of an id (which is the external ID and the only one to =
be transferred through the API) and an "external ID" (which is th=
e client's internal ID and should be hidden) is
 diametrically opposite to this.






=A0






2. When dealing with multi-valued attributes of a re=
source (expressed as arrays in JSON), they must be converted from an array =
into a dictionary with unique keys (UUIDs generated by the cloud provider w=
hen the attribute is created).
 Without unique keys for every attribute value of a resource, manipulating =
it will be clumsy and inelegant.






=A0






3. The PATCH command can be improved in 3 significan=
t ways:






3a. Leverage the fact (from 2 above) that every valu=
e has a key, to greatly simplify the API






3b. Use special verbs as nested operations of the PA=
TCH command to add, modify and delete attributes at any level






3c. Use the WebDAV status code of "207 Multi-St=
atus" instead of "200 OK" as the response to a PATCH (or BUL=
K) command.






=A0






To elaborate,






=A0






1. Revealing private IDs externally is a form of tig=
ht coupling. A major requirement with Identity Management is to split (or m=
erge) identities when false positives (or false negatives) are detected, i.=
e., when a resource is discovered
 to be more than one, or when multiple resources are detected to be the sam=
e. If internal identifiers are revealed to external domains, such clean-ups=
 become difficult, hence every domain that wants to expose references to a =
resource must map its internal ID
 to and external one created for this explicit purpose, and only reveal thi=
s.






=A0






In the SCIM case, when an enterprise client POSTs a =
resource creation request, the cloud provider must generate its own interna=
l UUID as well as an external UUID, map them together, and only return the =
external UUID in the "Location:"
 header. The enterprise client should map this external UUID to a newly-gen=
erated internal ID of its own. In case the resource already has an identifi=
er within the enterprise client's domain, then this is the internal ID =
that must be mapped to the external
 UUID returned through the POST response.






=A0






2. If a resource is to be created, and one of its at=
tributes is multi-valued, e.g.,






=A0






=A0 =A0 "email-addrs" :=A0






=A0 =A0 [






=A0 =A0 =A0 =A0 "john_smith@yahoo.com",






=A0 =A0 =A0 =A0 "john.smith@gmail.com",






=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"






<=A0


































_______________________________________________

scim mailing list

scim@ietf.org

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










=A0


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

=A0



This e-mail message, including any attachments, is for the sole use of the = person to whom it has been sent, and may contain information that is confid= ential or legally protected. If you are not the intended recipient or have = received this message in error, you are not authorized to copy, distribute, or otherwise use this message = or its attachments. Please notify the sender immediately by return e-mail a= nd permanently delete this message and any attachments. Gartner makes no wa= rranty that this e-mail is error or virus free.


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


--0015175cd13a9be46c04c6f54d3e-- From phil.hunt@oracle.com Fri Aug 10 21:00:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6B11E80A2 for ; Fri, 10 Aug 2012 21:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3iOg3ECXQ69 for ; Fri, 10 Aug 2012 21:00:37 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id A915711E8087 for ; Fri, 10 Aug 2012 21:00:36 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7B40Y7U006824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 04:00:34 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7B40XLC000318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 04:00:33 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7B40WdC031162; Fri, 10 Aug 2012 23:00:32 -0500 Received: from [101.223.60.15] (/68.146.185.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Aug 2012 21:00:04 -0700 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-848BC556-8414-4E9E-A180-0CBD66AB2555 Message-Id: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Fri, 10 Aug 2012 21:59:29 -0600 To: Ganesh and Sashi Prasad X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 04:00:41 -0000 --Apple-Mail-848BC556-8414-4E9E-A180-0CBD66AB2555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the multi-value example you gave you used the value as the attribute nam= e key.=20 That means a lot more complex indexing structure. Better to just say delete a= specific value.=20 The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad wrot= e: > > In your example you are conflating value with an attribute id.=20 >=20 > I don't believe so. >=20 > I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. >=20 > For non-repeating attributes (both simple and composite), the key is the a= ttribute name itself.=20 >=20 > Simple attribute: >=20 > Key: "dob" > Value: "01 Jan 1970" >=20 > For composite attributes, the key employs dot notation to specify the full= y-qualified attribute name, e.g., "address.postcode". >=20 > Composite attribute: >=20 > Key: "address.street-number" > Value: "10" >=20 > Key: "address.suburb" > Value: "East Camden" >=20 > For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish,= and a positional index is inadequate. So we convert the array into a dictio= nary and this then becomes a composite attribute using dot notation for the k= ey. >=20 > Multi-valued attribute: >=20 > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" > Value: "john_smith@yahoo.com" >=20 > So this allows us to apply uniform treatment to any arbitrarily deep resou= rce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. >=20 > The verbs are just unambiguous operations on these (now) explicitly addres= sable attributes. >=20 > INCLUDE to a collection and specify only the value. The key is generated a= nd returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. >=20 > REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". >=20 > PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". >=20 > FORCE the fully-qualified key to hold the given value, regardless of wheth= er it existed before or not. Only errors possible are "400 Bad Request" and "= 500 Internal Error". >=20 > RETIRE an attribute or a collection given its fully-qualified key. The imp= lementation will determine whether the attribute will disappear entirely or w= ill exist holding a null value (the blank string "" or the empty object {} )= . >=20 > I'll explain in a separate post why we need operation verbs like these tha= t are independent of the HTTP verbs. >=20 > Regards, > Ganesh >=20 > On 11 August 2012 10:38, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >=20 >=20 > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux , Trey Drake , Kelly Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > Ganesh, >=20 > In your example you are conflating value with an attribute id. I find that= confusing.=20 >=20 > I agree though that operations in patch could be a lot more explicit.=20 >=20 > Eg explicitly deleting a value by saying delete or retire.=20 >=20 > Phil >=20 > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad wr= ote: >=20 >> > I am concerned about your second suggestion:=20 >>=20 >> Let's discuss that now. >>=20 >> The trade-offs are very clear here. >>=20 >> Pros: >>=20 >> Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t and intuitive when every individual attribute value gets its own ID. >>=20 >> Here's how to delete a single member from a Group, as per the current spe= c: >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >>=20 >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "members": [ >> { >> "display": "Babs Jensen", >> "value": "2819c223-7f76-453a-919d-413861904646" >> "operation": "delete" >> } >> ] >> } >>=20 >> Here's how to delete ALL members from a group according to the current sp= ec: >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >>=20 >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "meta": { >> "attributes": [ >> "members" >> ] >> } >> } >>=20 >> The two operations differ significantly, and it's not very intuitive.=20 >> With my suggestion, here's how to delete a single member from a group: >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >>=20 >> { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >> } >> } >> ] >> } >>=20 >> Here's how I suggest deleting ALL members from a group: >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >>=20 >> { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members" >> } >> } >> ] >> } >>=20 >> I'm sure you'll agree that this is simpler, more consistent and more intu= itive to a reader. >>=20 >> Pro 2: We can apply this mechanism consistently to three areas: >> (a) Manipulating multi-valued attributes of a resource >> (b) Manipulating members of a group >> (c) Performing bulk operations, where we simply use HTTP verbs instead of= the specialised (and semantically less ambiguous) verbs I suggested for att= ributes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. >>=20 >> All of them return "207 Multi-Status" with the "results" array holding in= dividual status codes. >>=20 >> In the current spec, (a) and (b) are done similarly but (c) is very diffe= rent. >>=20 >> Pro 3: Adoption of the standard by clients is likely to be higher because= it's simpler for them. >>=20 >> Pro 4: New (not incumbent) cloud providers will probably find this easier= to implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP directo= ries. >>=20 >> Cons: >>=20 >> Con 1: Incumbent cloud providers with existing data stores in a directory= format (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mode= l and store each attribute value as a sub-node with its own key. This will "= hinder adoption of the spec", which is what you fear. >>=20 >> Have I summed up the Pros and Cons correctly? I'm biased of course, so I c= ould have missed a Con or hyped a Pro :-). >>=20 >> In other words, we're debating interface complexity (current spec) versus= implementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. >>=20 >> Here's what we need to discuss - Do the Pros make the suggestion worth ad= opting in spite of the Cons, or are the Cons so great that it's best to leav= e the spec as it is? >>=20 >> Keep in mind that a complex spec that only favours incumbent cloud provid= ers can cut both ways. It opens the door to a simpler interface offered by a= new generation of nimbler SPs that don't have the same legacy issues, and t= here could be an exodus of clients to these new SPs. SCIM could end up being= obsoleted very soon, because the API interface is very complex and clumsy, a= s any new reader can attest. I was taken aback by the complexity when I saw i= t, which is why I was prompted to suggest something simpler. >>=20 >> This is an issue where we need the opinions of many people, and they need= to state their affiliations. If most people weighing in belong to incumbent= SPs and they vote in favour of interface complexity to avoid implementation= complexity, then it means the spec is not doing a good job of balancing the= interests of various groups. I think we should also poll client organisatio= ns to see what they would want. >>=20 >> (Gartner is trusted by enterprise clients to evaluate the capabilities of= vendors (SPs). I believe Gartner should take the lead in representing clien= t interests in this working group rather than those of incumbent vendors, wh= ich is what it seems like to me. Correct me if I'm being unfair.) >>=20 >> Regards, >> Ganesh >>=20 >>=20 >>=20 >> On 11 August 2012 01:35, Diodati,Mark wrote: >> Hi Ganesh, >>=20 >> =20 >>=20 >> I am concerned about your second suggestion: >>=20 >> =E2=80=9C2. When dealing with multi-valued attributes of a resource (expr= essed as arrays in JSON), they must be converted from an array into a dictio= nary with unique keys (UUIDs generated by the cloud provider when the attrib= ute is created). Without unique keys for every attribute value of a resource= , manipulating it will be clumsy and inelegant.=E2=80=9D >>=20 >> =20 >>=20 >> One of the primary reasons that SPML failed was lack of adoption by servi= ce providers due to its complexity. Very few target applications implemented= SPML. Most of the commercial provisioning systems had an SPML interface (ei= ther v1 or v2), but not one of them was conformant to the SPML standard beca= use of complexity. If you are interested, I will forward you the research do= cuments that discuss these problems in detail. For SCIM to be successful, it= must be adopted by commercial target applications (i.e., service providers)= . I am confident that a requirement for unique identifiers with multi-valued= attributes will preclude its adoption, because it requires major changes to= the service provider=E2=80=99s existing identity storage mechanisms. >>=20 >> Mark >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> From: Trey Drake [mailto:trey.drake@unboundid.com]=20 >> Sent: Friday, August 10, 2012 9:51 AM >>=20 >>=20 >> To: Ganesh and Sashi Prasad >> Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>=20 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >> =20 >>=20 >> Ganesh, >>=20 >> =20 >>=20 >> I'll base my comments on your latest reply (below). =20 >>=20 >> =20 >>=20 >> The externalID is not part of the protocol. It is an *optional* attribut= e within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters). Please c= larify your suggestion. >>=20 >> =20 >>=20 >> I'm not tracking your coupling concern. The client can search and hence r= etrieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> What do you mean by "candidate key"? Given=20 >>=20 >> =20 >>=20 >> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad wrote: >>=20 >> > I think scim gets its current simplicity from its single owner hub spo= ke model implementing tight coupling. [...] IMHO loose coupling is a much mo= re complex solution. >>=20 >> =20 >>=20 >> Phil, >>=20 >> =20 >>=20 >> I'm a bit surprised that you're implying "tight coupling =3D=3D simple" a= nd "loose coupling =3D=3D complex". That's contrary to my experience. >>=20 >> =20 >>=20 >> When I say "loose coupling", I mean "no unnecessary dependencies". Invari= ably, a reduction in dependencies leads to greater simplicity. >>=20 >> =20 >>=20 >> Let's not confuse reduction of dependencies in the data model with a hub-= and-spokes architecture. They're entirely orthogonal aspects of the solution= . >>=20 >> =20 >>=20 >> All that my suggestion involves is, >>=20 >> =20 >>=20 >> 1. Take 'external ID' out of the protocol. >>=20 >> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >>=20 >> =20 >>=20 >> No planned functionality is lost by this. >>=20 >> =20 >>=20 >> 1. The client enterprise can still send its internal ID as part of the re= source body, inside some attribute defined by them (but not defined by the p= rotocol). Let's say they call it 'myID'. >>=20 >> 2. The client enterprise can search for resource URIs using any attribute= , including this internal ID >>=20 >> 'GET /Users?myID=3Dbjensen' >>=20 >> Since myID is a candidate key, the server will return exactly one URI, wh= ich is the canonical URI for the resource >>=20 >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> 3. The client can use this URI to perform all other operations as usual. >> =20 >> So taking 'externalID' out of the protocol spec only does this: >> 1. It avoids enshrining tight coupling in the protocol (If clients want t= o tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of a= ssisted suicide. ;-) >> 2. It encourages loose coupling by nudging clients towards maintaining th= eir own internal-to-external identifier mappings. >> =20 >> That's what I'd like to see. I don't believe this complicates the protoco= l. It simplifies it and it also lends itself to a loosely-coupled approach. >> =20 >> I'll address the multi-valued attribute suggestion separately. >> =20 >> Regards, >> Ganesh >> =20 >> =20 >> =20 >> =20 >>=20 >> On 10 August 2012 07:53, Phil Hunt wrote: >>=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad w= rote: >>=20 >> > storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM is= just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains.=20 >>=20 >> I wasn't suggesting that the mapping table be part of the SCIM spec. I pr= ovided that example to illustrate that splitting and merging identities is a= common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. >>=20 >> =20 >>=20 >> I'm suggesting that the spec do less, not more. >>=20 >> =20 >>=20 >> What the SCIM spec needs to do there is just refrain from introducing tig= ht coupling. I would like to see a single identifier exposed through the API= , with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other cr= eates tight coupling and ensures that both domains need simultaneously split= or merge identities, which is not desirable. So I recommend _taking out_ th= e "external id" field from the API. The spec shouldn't encourage tight coupl= ing. If clients want to pass in their internal ids as part of the resource b= ody, no one can stop them, and they can always do a search on that attribute= to retrieve the URI exactly as you visualise they will with the "external i= d", but let's not elevate an anti-pattern to a recommendation by enshrining t= he "external id" as an acceptable attribute. >>=20 >> =20 >>=20 >> Am I making sense? >>=20 >> =20 >>=20 >> I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling.=20 >>=20 >> =20 >>=20 >> IMHO loose coupling is a much more complex solution. The reality is that e= ach end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub.=20 >>=20 >> =20 >>=20 >> That said i think the current model provides a practical starting point.=20= >>=20 >> =20 >>=20 >> > Regarding unique identifiers for multi-valued attributes there is a tr= ade-off involved. On one hand this makes PATCH semantics easier. On the ot= her hand it puts extra burden on service providers.=20 >>=20 >>=20 >> Precisely. The spec has to strike the right balance. It would be interest= ing to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> On 10 August 2012 00:28, Kelly Grizzle wrot= e: >>=20 >> Thanks Emmanuel. I had started writing up a similar response. As you su= ggest, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM is= just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. >>=20 >> =20 >>=20 >> You could also model these ID mappings in the SCIM user as an extension b= ut would probably not want to expose these externally. Here is an example o= f how to model the end state of the false positive scenario (splitting a use= r): >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >>=20 >> =20 >>=20 >> This could be represented as two SCIM users that contain information abou= t the entities on other domains. >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fe= deration:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fe= deration:1.0"], >>=20 >> "id": "a99a5feba839", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "7a87f27c1dd8" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> In the second user, the linkedUsers attribute would be empty until the sp= lit user was synced to domain 2. >>=20 >> =20 >>=20 >> =20 >>=20 >> Similarly, the false negative use case (merging two users) looked like th= is at the end: >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >>=20 >> =20 >>=20 >> This could be represented with the following SCIM user: >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fe= deration:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> }, >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "41206cc97c8b", >>=20 >> "deletionRequired": true >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> =20 >>=20 >> Regarding unique identifiers for multi-valued attributes there is a trade= -off involved. On one hand this makes PATCH semantics easier. On the other= hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making thi= ngs fit easily onto existing systems. IMO the value gained by unique identi= fiers for multi-valued attributes is not worth the demands put on a service p= rovider. I also think that vendors that have a non-SCIM-compliant API will c= hoose to keep things that way if the spec is too hard for them to implement.= In a green field environment we do have the luxury of mandating a model to= make certain operations more elegant. However, we can=E2=80=99t ignore leg= acy systems. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of E= mmanuel Dreux >> Sent: Thursday, August 09, 2012 3:18 AM >> To: Ganesh and Sashi Prasad; Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Ganesh, >>=20 >> =20 >>=20 >> Nothing prevents you in your SCIM implementation (client or server) to ge= nerate a unique identifier for each synchronized object and maintain an inte= rnal mapping table ( you would have to map group membership as well). >>=20 >> =20 >>=20 >> This is what we are doing with Active Directory sources or targets: >>=20 >> As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAcco= untName, UPN) are subject to change (even objectGuid can change if an AD dom= ain is migrated), we decided to generate and maintain an internal table of i= ds. This fits your requirements as it hides internal ids. >>=20 >> =20 >>=20 >> This was written in dotnet and we have started a project to rewrite our S= CIM stack in PHP and will give it to the Open Source community. This impleme= ntation will have a parameter : AllocateIds versus UseExistingIDs. >>=20 >> This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or use t= hem as unique ID. >>=20 >> =20 >>=20 >> You can also implement such feature without violating the SCIM specs, or w= ithout asking to include it in the specs. >>=20 >> =20 >>=20 >> -- >>=20 >> Regards, >>=20 >> Emmanuel Dreux >>=20 >> http://www.cloudiway.com >>=20 >> Tel: +33 4 26 78 17 58 >>=20 >> Mobile: +33 6 47 81 26 70 >>=20 >> skype: Emmanuel.Dreux >>=20 >> =20 >>=20 >> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 >> =C3=80 : Kelly Grizzle >> Cc : scim@ietf.org >> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Kelly, >> Thanks for your response. Let me first respond in brief to the two main p= oints you have made, and then elaborate on the first. >> 1. Why should domains not expose their internal identifiers to other= domains? >> a. >> We are designing a protocol for a federated system of domains, where all d= omains are co-equal peers. (In physics too, N-body problems are much harder t= han 2-body problems. :-) Therefore, assuming that there are only two players= in the interaction makes this tightly coupled in a number of ways. We shoul= d rely on messaging and notification, with encapsulation of domain-specific d= ata. >> b. >> In any non-trivial data store, there will always be the ongoing need to m= erge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D and =E2= =80=9Cfalse positives=E2=80=9D are discovered. A domain should be able to ha= ndle this internal housekeeping freely, only notifying other domains when co= nvenient. Mapping of internal identifiers to external ones and maintaining t= his mapping internally allows this loosely-coupled housekeeping to take plac= e. Sharing internal identifiers (or otherwise outsourcing the mapping of int= ernal to external identifiers) forces housekeeping activities to be done in l= ock-step across domains. >> c. >> Asynchronous interaction is not just a matter of a suitable wire protocol= which can be designed later. The data model plays a crucial role in enablin= g or constraining such interaction. A tightly-coupled data model will force t= he use of synchronous interactions, and the exposure of internal identifiers= is a key part of this tight coupling. >> 2. The difficulty of assigning unique identifiers to the individual value= s of multi-valued attributes: >> a. >> I'm not belittling the effort involved in migrating legacy data stores to= such a model. However, in the larger historical context of cross-domain ide= ntity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations,= we are losing an opportunity to provide a clean and elegant model to subseq= uent users of the spec, and this will have repercussions over many years or e= ven decades. >> b. >> If incumbent cloud providers find it hard to immediately adopt the dictio= nary model for existing multi-valued attributes, they can transition to this= model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-SC= IM-compliant=E2=80=9D APIs to their customers and encouraging new customers t= o adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be su= pported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrarily l= ong period and gradually migrated to the SCIM-compliant API. The logistics a= re not insurmountable, and shouldn't prevent the adoption of a dictionary mo= del for multi-valued attributes. >> Elaboration of Point 1: >> When we consider federated identity across more than one domain, we have t= o assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle e= vents within a domain are notified to other domains (when necessary) in an a= synchronous manner (i.e., through messaging) and the other domains are free t= o respond to these events in an appropriate manner and at a time of their co= nvenience. >> A key set of lifecycle events for an entity is the merging and splitting o= f identity that is often required. >> The question =E2=80=9CIs this one entity?=E2=80=9D can be answered either= yes (positive) or no (negative). But sometimes, we can discover false posit= ives and false negatives in our data stores. >> Consider a case where customers sign up online, and two customers who are= privacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and a= lso use the same date of birth (say, 1 Jan 1970) or similar attributes. The f= ront-end application may make an intelligent (but incorrect) guess that thes= e two persons are the same, and re-assign the same identifier to the second p= erson. This is a false positive. They appear to be the same entity, but they= 're actually different. When the error is discovered, the identities will ne= ed to be split, with a new identifier generated for one of them. >> Consider the opposite case where a customer signs up through two differen= t portals or in two different sessions, using the names =E2=80=9CJSmith=E2=80= =9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated= as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped. >> These are not theoretical use cases. They form a significant proportion o= f the user base in most large Web-facing applications. Let's see how these c= an be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. >> a. False positives: >> Domain 1 has the following information about a customer in its data store= : >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-197= 0=E2=80=9D} >> When requesting the provisioning of this entity in Domain 2, the followin= g ID is returned by Domain 2: ff487230b3a0. >> Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifier: >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> When the false positive is discovered and the entity is split, Domain 1 c= reates a new internal identifier and now has the following entity informatio= n. >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-197= 0=E2=80=9D} >> Internal ID: a99a5feba839 >> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-197= 0=E2=80=9D} >> This second entity with its own internal identifier is invisible to Domai= n 2, and this is by design. Communication about the original entity takes pl= ace as before by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230= b3a0=E2=80=9D and vice-versa. At some convenient time (importantly, this doe= sn't have to be at the time the split happens), Domain 2 can be requested to= provision a second entity, and when it responds with an identifier of =E2=80= =9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record= associated with the second entity's internal identifier. >> The mapping table now contains the following entries: >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >> Domain 2 is not even aware that a split has happened, and the provisionin= g that it does is not in lockstep with the split in identity that occurred i= n Domain 1. >> (What is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we c= over the treatment of false negatives.) >> b. False negatives: >> Domain 1 has the following information about what it thinks are two disti= nct customers in its data store: >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2= =80=9D} >> Internal ID: 273d36e30d09 >> Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80= =9D} >> When requesting the provisioning of these entities in Domain 2, the follo= wing IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >> Domain 1 then maintains the following in a mapping table and uses it for t= ranslation when talking to Domain 2, taking care never to expose its interna= l identifiers: >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 273d36e30d09 | D2 | 41206cc97c8b | true | >> When the false negative is discovered and the two entities are merged, Do= main 1 drops one of the internal identifiers and rationalises the name of th= e customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the f= irst ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the second =E2=80=9C273d36e= 30d09=E2=80=9D. >> The mapping table now looks like this: >> | Internal Entity ID | External Domain ID | External Entity ID | Primary f= lag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >> Now two external identifiers map to the same internal one, so inbound com= munication from Domain 2 can be unambi >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-848BC556-8414-4E9E-A180-0CBD66AB2555 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

For the multi-value ex= ample you gave you used the value as the attribute name key. 

That means a lot more complex indexing structure. Better to j= ust say delete a specific value. 

The spec alr= eady allows multiple values to have tags like home, work, etc.
Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Pra= sad <g.c.prasad@gmail.com>= wrote:

= > In your example you are conflating value with an attribute id.&nbs= p;

I don't believe so.

I'm adopting a model where every attribute of the resource is a key= -value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite)= , the key is the attribute name itself. 

= Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes= , the key employs dot notation to specify the fully-qualified attribute name= , e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that t= here be new keys for each individual value, otherwise they are impossible to= distinguish, and a positional index is inadequate. So we convert the array i= nto a dictionary and this then becomes a composite attribute using dot notat= ion for the key.

Multi-valued attribute:

Key: "e= mails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbi= trarily deep resource structure. We can refer to every leaf value with a key= that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly add= ressable attributes.

INCLUDE to a collection and sp= ecify only the value. The key is generated and returned. The fully-qualified= key is <collection-name>.<newly-generated-ID> and the value is w= hat was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the k= ey doesn't exist, return a "404 Not Found".

PLACE a= value at the logical location implied by the fully-qualified key. If there i= s already a key with that name, return a "409 Conflict".

FORCE the fully-qualified key to hold the given value, r= egardless of whether it existed before or not. Only errors possible are "400= Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified= key. The implementation will determine whether the attribute will disappear= entirely or will exist holding a null value (the blank string "" or the emp= ty object {} ).

I'll explain in a separate post why we need operation ve= rbs like these that are independent of the HTTP verbs.

<= div>Regards,
Ganesh

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

htt= ps://www.ietf.org/mailman/listinfo/scim

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



Send scim mailing list submissions to
        scim@ietf.org

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

You can reach the person managing the list at
        scim-owne= r@ietf.org

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt= )


---------- Forwarded message ----------
From: Phil Hunt <= phil.hunt@oracle.com>
To:&= nbsp;Ganesh and Sashi Prasad <g.c= .prasad@gmail.com>
Cc: "Diodati, Mark" <Mar= k.Diodati@gartner.com>, Emmanuel Dreux <edreux@cloudiway.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle &= lt;kelly.grizzle@sailpoint.co= m>, "scim@ietf.org" <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM P= rotocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value w= ith an attribute id. I find that confusing. 

I agree though that operations in patch could be a lot m= ore explicit. 

Eg explicitly deleting a value b= y saying delete or retire. 

Phil

On 2012-08= -10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am concerned about your second suggestion: 

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipul= ate resources becomes so much cleaner, consistent and intuitive when every i= ndividual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current spec:<= /div> 

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the cur= rent spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuiti= ve. 
With my suggestion, here's how to delete a single member= from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4= fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.<= span style=3D"font-family:monospace;font-size:11px;white-space:pre-wrap">281= 9c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent= and more intuitive to a reader.

Pro 2: We can appl= y this mechanism consistently to three areas:
(a) Manipulating mul= ti-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk opera= tions, where we simply use HTTP verbs instead of the specialised (and semant= ically less ambiguous) verbs I suggested for attributes, the "key" becomes t= he URI, and the "value" becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results"= array holding individual status codes.

In the curr= ent spec, (a) and (b) are done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely to b= e higher because it's simpler for them.

Pro 4: New (= not incumbent) cloud providers will probably find this easier to implement b= ecause they have no legacy. They will probably use some form of NoSQL databa= se and won't be constrained by the limitations of LDAP directories.

Cons:

Con 1: Incumbent cloud pr= oviders with existing data stores in a directory format (where multi-valued a= ttributes are stored as comma-separated values under a single attribute node= ) will find it difficult to migrate to this model and store each attribute v= alue as a sub-node with its own key. This will "hinder adoption of the spec"= , which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased= of course, so I could have missed a Con or hyped a Pro :-).

I= n other words, we're debating interface complexity (current spec) versus imp= lementation complexity (my suggestion). Both can hinder adoption of the spec= by different parties.

Here's what we need to discuss - Do the Pros make the su= ggestion worth adopting in spite of the Cons, or are the Cons so great that i= t's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud providers= can cut both ways. It opens the door to a simpler interface offered by a ne= w generation of nimbler SPs that don't have the same legacy issues, and ther= e could be an exodus of clients to these new SPs. SCIM could end up being ob= soleted very soon, because the API interface is very complex and clumsy, as a= ny new reader can attest. I was taken aback by the complexity when I saw it,= which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peop= le, and they need to state their affiliations. If most people weighing in be= long to incumbent SPs and they vote in favour of interface complexity to avo= id implementation complexity, then it means the spec is not doing a good job= of balancing the interests of various groups. I think we should also poll c= lient organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate th= e capabilities of vendors (SPs). I believe Gartner should take the lead in r= epresenting client interests in this working group rather than those of incu= mbent vendors, which is what it seems like to me. Correct me if I'm being un= fair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <Mark.= Diodati@gartner.com> wrote:

Hi Ganesh,

 

I am concerned about your s= econd suggestion:

=E2=80=9C2. When dealing wi= th multi-valued attributes of a resource (expressed as arrays in JSON), they= must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.=E2=80=9D

 

One of the primary reasons t= hat SPML failed was lack of adoption by service providers due to its complex= ity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v= 1 or v2), but not one of them was conformant to the SPML standard because of= complexity. If you are interested, I will forward you the research document= s that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial targ= et applications (i.e., service providers). I am confident that a requirement= for unique identifiers with multi-valued attributes will preclude its adopt= ion, because it requires major changes to the service provider=E2=80=99s existing identity storage mechani= sms.

Mark

 

 

 

From: Trey Drake [= mailto:trey.dr= ake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@iet= f.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). &= nbsp;

 

The externalID is not part of the protocol.  It i= s an *optional* attribute within the *schema* specification.  As for #2= , the protocol spec works as you describe if "arbitrary URI parameters" equa= te to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clari= fy your suggestion.

 

I'm not tracking your coupling concern.  The cli= ent can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise.  Nothing mandates use of externalId.   =

 

 

What do you mean by "candidate key"?  Given = ;

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pra= sad <g.c.prasad= @gmail.com> wrote:

>  I think scim gets its current simplicity f= rom its single owner hub spoke model implementing tight coupling. [...] = ;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight coupl= ing =3D=3D simple" and "loose coupling =3D=3D complex". That's contrary to m= y experience.

 

When I say "loose coupling", I mean "no unnecessary d= ependencies". Invariably, a reduction in dependencies leads to greater simpl= icity.

 

Let's not confuse reduction of dependencies in the da= ta model with a hub-and-spokes architecture. They're entirely orthogonal asp= ects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbitr= ary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal I= D as part of the resource body, inside some attribute defined by them (but n= ot defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URIs= using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will return= exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861=
904646
3.=
 The client can use this URI to perform all other operations as usual.
 
So=
 taking 'externalID' out of the protocol spec only does this:
1.=
 It avoids enshrining tight coupling in the protocol (If clients want to tig=
htly couple themselves to the cloud provider by sending their internal IDs, t=
hey can do so. Suicide is OK, but the protocol should not be guilty of assis=
ted suicide. ;-)
2.=
 It encourages loose coupling by nudging clients towards maintaining their o=
wn internal-to-external identifier mappings.
 
Th=
at's what I'd like to see. I don't believe this complicates the protocol. It=
 simplifies it and it also lends itself to a loosely-coupled approach.
 
I'=
ll address the multi-valued attribute suggestion separately.
 
Re=
gards,
Ga=
nesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wro= te:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a gr= eat way to enable this solution.  Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provi= ded that example to illustrate that splitting and merging identities is a co= mmon requirement, and that decoupling local identifiers within a domain from= shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain f= rom introducing tight coupling. I would like to see a single identifier expo= sed through the API, with the implication (and perhaps the recommendation) t= hat it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight cou= pling and ensures that both domains need simultaneously split or merge ident= ities, which is not desirable. So I recommend _taking out_ the "external id"= field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their intern= al ids as part of the resource body, no one can stop them, and they can alwa= ys do a search on that attribute to retrieve the URI exactly as you visualis= e they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrinin= g the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its curr= ent simplicity from its single owner hub spoke model implementing tight coup= ling. 

 

IMHO loose coupling is a much more complex solution. T= he reality is that each end-point has value to contribute and thus the singl= e-owner model will eventually need to become multi-owner or multi-hub. =

 

That said i think the current model provides a practi= cal starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-of= f involved.  On one hand this makes PATCH semantics easier.  On th= e other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting= to hear from the other members of the spec mailing list. You know where I s= tand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoi= nt.com> wrote:

Thanks Emmanuel.  I ha= d started writing up a similar response.  As you suggest, storing this i= nformation in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only respo= nsible for the transport layer between domains.

 

You could also model these I= D mappings in the SCIM user as an extension but would probably not want to e= xpose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a u= ser):

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| a99a5feba839     &nb= sp; | D2           &n= bsp;     | 7a87f27c1dd8     &nb= sp; | true         |

 

This could be represented a= s two SCIM users that contain information about the entities on other domain= s.

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the lin= kedUsers attribute would be empty until the split user was synced to domain 2= .

 

 

Similarly, the false negati= ve use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | 41206cc97c8b     &nb= sp; | false        |

 

This could be represented w= ith the following SCIM user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUsers": [

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      },

      {

        "dom= ain": "D2",

        "ext= ernalEntityId": "41206cc97c8b",

        "del= etionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identifier= s for multi-valued attributes there is a trade-off involved.  On one ha= nd this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception o= f SCIM, a key goal has been to foster adoption by service providers by makin= g things fit easily onto existing systems.  IMO the value gained by uni= que identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that= vendors that have a non-SCIM-compliant API will choose to keep things that w= ay if the spec is too hard for them to implement.  In a green field env= ironment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

 

Nothing prevents you in you= r SCIM implementation (client or server) to generate a unique identifier for= each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing w= ith Active Directory sources or targets:

As we didn=E2=80=99t find a= n immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to c= hange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids.= This fits your requirements as it hides internal ids.

 

This was written in dotnet a= nd we have started a project to rewrite our SCIM stack in PHP and will give i= t to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice o= f =E2=80=9Chiding=E2=80=9D internalIDs or use them as unique ID.

 

You can also implement such= feature without violating the SCIM specs, or without asking to include it i= n the specs.

 

--

Regards,=

Emmanuel Dreux<= /span>

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

Tel: +33 4 26 78 1= 7 58

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel= .Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi Ke= lly,

Thank= s for your response. Let me first respond in brief to the two main points yo= u have made, and then elaborate on the first.

1. = ;     Why should domains not ex= pose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elabo= ration of Point 1:

When w= e consider federated identity across more than one domain, we have to assume= that domains are not necessarily master-slave in their interaction. The mos= t generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to= other domains (when necessary) in an asynchronous manner (i.e., through mes= saging) and the other domains are free to respond to these events in an appr= opriate manner and at a time of their convenience.

A key= set of lifecycle events for an entity is the merging and splitting of ident= ity that is often required.

The q= uestion =E2=80=9CIs this one entity?=E2=80=9D can be answered either yes (po= sitive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Consi= der a case where customers sign up online, and two customers who are privacy= -conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrec= t) guess that these two persons are the same, and re-assign the same identif= ier to the second person. This is a false positive. They appear to be the sa= me entity, but they're actually different. When the error is discovered, the identities will need to be spl= it, with a new identifier generated for one of them.

Consi= der the opposite case where a customer signs up through two different portal= s or in two different sessions, using the names =E2=80=9CJSmith=E2=80=9D and= =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped.

These= are not theoretical use cases. They form a significant proportion of the us= er base in most large Web-facing applications. Let's see how these can be ma= naged in a federated way by mapping internal identifiers to external ones and only exposing external identifier= s to other domains.

a. Fa= lse positives:

Domai= n 1 has the following information about a customer in its data store:=

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

When r= equesting the provisioning of this entity in Domain 2, the following ID is r= eturned by Domain 2: ff487230b3a0.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

When t= he false positive is discovered and the entity is split, Domain 1 creates a n= ew internal identifier and now has the following entity information.<= /p>

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

Inter= nal ID: a99a5feba839

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

This s= econd entity with its own internal identifier is invisible to Domain 2, and t= his is by design. Communication about the original entity takes place as bef= ore by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b3a0=E2=80=9D and vice-versa. At some convenient time (= importantly, this doesn't have to be at the time the split happens), Domain 2= can be requested to provision a second entity, and when it responds with an= identifier of =E2=80=9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record associated with the second entity's inter= nal identifier.

The m= apping table now contains the following entries:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| a99a5feba839 | D2= | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened, a= nd the provisioning that it does is not in lockstep with the split in identi= ty that occurred in Domain 1.

(What= is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we cover the= treatment of false negatives.)

b. Fa= lse negatives:

Domai= n 1 has the following information about what it thinks are two distinct cust= omers in its data store:

Inter= nal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}<= /span>

Inter= nal ID: 273d36e30d09

Attri= butes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}

When r= equesting the provisioning of these entities in Domain 2, the following IDs a= re returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifiers:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 273d36e30d09 | D2= | 41206cc97c8b | true |

When t= he false negative is discovered and the two entities are merged, Domain 1 dr= ops one of the internal identifiers and rationalises the name of the custome= r (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the first ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the se= cond =E2=80=9C273d36e30d09=E2=80=9D.

The m= apping table now looks like this:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

| 9caf78aac3d6 | D2= | 41206cc97c8b | false |

Now t= wo external identifiers map to the same internal one, so inbound communicati= on from Domain 2 can be unambi

___________________________= ____________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listin= fo/scim
= --Apple-Mail-848BC556-8414-4E9E-A180-0CBD66AB2555-- From trey.drake@unboundid.com Fri Aug 10 21:55:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE221F84D2 for ; Fri, 10 Aug 2012 21:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SeexuxSf-52 for ; Fri, 10 Aug 2012 21:55:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64C0621F84CF for ; Fri, 10 Aug 2012 21:55:19 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3772751obb.31 for ; Fri, 10 Aug 2012 21:55:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=5ginqkbn7FyrMLHrcGE0b+4fNxkvH6360DBpJV6QjjY=; b=RUG2gSvivsaPhzpMesLXBBb8PDHncEnRTCMKfjrEvklCS05aM36lNCMTnZNdefwwLH IDrnlRE8Ykc+DWQfVDmS/8oHtnjxJQFJHNm5KfFSzjJVxFszNbgxOFjOVH4zI7smVOxd /cy+GGsUglw8UxV6ywm7rRUmBpY2j541ReksvsND77d1Ml5JwMjbgq6R174bnGH3yWAP sPhHBRB8jUmq0Q28vrL38tjqgUoqzj1Tsny6lXY/eoz+i5cE7dukfcSFlRzjnUMdRhQK jpnrVHjW051ZqT19tjHM4ZrA6thc47XauaCDXatLgCasi9YmTyIFO+xo9JtWTmsxbqw1 I+JA== Received: by 10.182.78.228 with SMTP id e4mr741641obx.77.1344660918749; Fri, 10 Aug 2012 21:55:18 -0700 (PDT) Received: from [10.0.1.41] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id kc5sm795477obb.21.2012.08.10.21.55.17 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 21:55:18 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-B77299C0-3EA8-4514-96F5-E227097B78C6 Message-Id: <486995E4-4B9B-436B-9D74-BFF509A28B16@unboundid.com> X-Mailer: iPhone Mail (9B206) From: Trey Drake Date: Fri, 10 Aug 2012 23:55:14 -0500 To: Ganesh and Sashi Prasad X-Gm-Message-State: ALoCoQmCY9um4mz+76nyhleJBX5dXMY+qUIMZ3Uq3g570W1sTvq9pZzN0BcXZrftUMFFlFz46ZoL Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 26 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 04:55:20 -0000 --Apple-Mail-B77299C0-3EA8-4514-96F5-E227097B78C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I believe Mark's comments are sound as they speak directly to the failure of= SPML viz. lessons learned. Since inception, SCIM has had an eye towards ea= sing the pain for SPs. History has proven that failure to do so may result i= n a technically solid spec with zero adoption. =20 On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad = wrote: > Ganesh - we are all participating as individuals in IETF. Maybe you should= consult the rules for working groups as explained in: >=20 > http://tools.ietf.org/pdf/rfc2418.pdf >=20 > It is irrelevant whether you belong to a very large technology company, or= are a technology analyst or whether you are just a great guy/gal.=20 >=20 > All the discussion has to be in the open and all sources (no confidential r= esearch reports!) have to be publicly made available. >=20 > - prateek >=20 > Fair enough. I was just concerned listening to Mark's comments (about adop= tion being hindered because of complexity for SPs), that one interest group m= ay have undue influence over the WG. if that's not the case, I'm happy :-). >=20 > Regards, > Ganesh > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-B77299C0-3EA8-4514-96F5-E227097B78C6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
I believe Mark's comments are sound as they speak directly to the failure of SPML viz. lessons learned.  Since inception, SCIM has had an eye towards easing the pain for SPs.  History has proven that failure to do so may result in a technically solid spec with zero adoption.  


On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

Ganesh - we are all participating as individuals in IETF. Maybe you should consult the rules for working groups as explained in:

http://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal.

All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available.

- prateek

Fair enough. I was just concerned listening to Mark's comments (about adoption being hindered because of complexity for SPs), that one interest group may have undue influence over the WG. if that's not the case, I'm happy :-).

Regards,
Ganesh
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--Apple-Mail-B77299C0-3EA8-4514-96F5-E227097B78C6-- From rsand@idfoundry.com Fri Aug 10 22:22:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE6011E8087 for ; Fri, 10 Aug 2012 22:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMCscpPDRAci for ; Fri, 10 Aug 2012 22:22:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 743CE21F84FD for ; Fri, 10 Aug 2012 22:22:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2356366vbb.31 for ; Fri, 10 Aug 2012 22:22:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=5D7vn7+NrBDeQoGFVIHe6AdN2WNW1z5WSCTLNjImIcE=; b=RhE6NNAFDsw/8fMab5XrQkqLCBVDEDyJrgdoOGyFRyhHcO2rGZuGbRQFbeijRfA5ae 8ergwYwgFHBanMCMQhXLh7+u/MqCzY7HzzomAvGL+U4PjQ4awRn53VRg4XHCDY32XLOJ Z9W6mC2Y9sxHTKidrqDUKU0oTnhOsQ+zwZweHZ7BILiBsD+Fsq7qPoOTCD/cWHDW2BA8 0HM9c3ua1yFfZAJVK5blV7/CJFJK/CdLGI+YMqFAMwkF8p/eUGLiiLKXkqHomsSmpYqc F3r8NWToOTu+uyyXXknGAC3q7DGpbyVeNz7bOarxvv5UK2vA57KG9+q04NpU8RACpC7r ACNg== Received: by 10.58.58.200 with SMTP id t8mr4926324veq.47.1344662562519; Fri, 10 Aug 2012 22:22:42 -0700 (PDT) From: Richard Sand References: <486995E4-4B9B-436B-9D74-BFF509A28B16@unboundid.com> In-Reply-To: <486995E4-4B9B-436B-9D74-BFF509A28B16@unboundid.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJXVy7+xi3ZxDe+cLrUfJJiqKDcvQJ3u9xzAjVP/3iWGumhkA== Date: Sat, 11 Aug 2012 01:22:37 -0400 Message-ID: <6f344e6811813c86837ef682c044b818@mail.gmail.com> To: Trey Drake , Ganesh and Sashi Prasad Content-Type: multipart/related; boundary=047d7b5d325e61b95704c6f6a64f X-Gm-Message-State: ALoCoQmsn9Q/CW9rEfH3NU68UFaf9pL2MrWQqz1ZmnFyypAOhFt3GPV9AxyfNRCvx8E9BmcmbzDe Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 26 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 05:22:45 -0000 --047d7b5d325e61b95704c6f6a64f Content-Type: multipart/alternative; boundary=047d7b5d325e61b95104c6f6a64e --047d7b5d325e61b95104c6f6a64e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I=E2=80=99d like to jump in here too in support of Mark=E2=80=99s comments.= I see many on the SCIM list who were former members or contributors to the OASIS PSTC and the failings of SPML should be well know. What SPML failed to do was provide a simple language for specific tasks =E2=80=93 if a company just ne= eded to set up an endpoint to enable/disable accounts or perform password resets, SPML was not purpose-build for this, and set requirements conformance that made it ill-suited towards one-off usage as a tool to solve a specific integration problem. SCIM as it is now addresses some of these shortcomings =E2=80=93 it does not require much of a burden to the SP, it language handl= es identity management requirements at a slightly higher level than just directory-style object-crud operations. So I would not deviate from these principles, as lack of them did in what was otherwise a useful and functional spec in SPML. Standard Schema of course is another topic that SPML never adequately addressed. Richard Sand | Managing Director PO Box 91824 | Austin | Texas 78709-1824 | USA Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754 Mobile: +1 267 984 3651 [image: Description: logo - small] *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf Of *Trey Drake *Sent:* Saturday, August 11, 2012 12:55 AM *To:* Ganesh and Sashi Prasad *Cc:* scim@ietf.org *Subject:* Re: [scim] scim Digest, Vol 8, Issue 26 I believe Mark's comments are sound as they speak directly to the failure of SPML viz. lessons learned. Since inception, SCIM has had an eye towards easing the pain for SPs. History has proven that failure to do so may result in a technically solid spec with zero adoption. On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad wrote: Ganesh - we are all participating as individuals in IETF. Maybe you should consult the rules for working groups as explained in: http://tools.ietf.org/pdf/rfc2418.pdf It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal. All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available. - prateek Fair enough. I was just concerned listening to Mark's comments (about adoption being hindered because of complexity for SPs), that one interest group may have undue influence over the WG. if that's not the case, I'm happy :-). Regards, Ganesh _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --047d7b5d325e61b95104c6f6a64e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I=E2=80=99d like to jump in here too in support of Mark=E2= =80=99s comments. I see many on the SCIM list who were former members or co= ntributors to the OASIS PSTC and the failings of SPML should be well know. = What SPML failed to do was provide a simple language for specific tasks =E2= =80=93 if a company just needed to set up an endpoint to enable/disable acc= ounts or perform password resets, SPML was not purpose-build for this, and = set requirements conformance that made it ill-suited towards one-off usage = as a tool to solve a specific integration problem. SCIM as it is now addres= ses some of these shortcomings =E2=80=93 it does not require much of a burd= en to the SP, it language handles identity management requirements at a sli= ghtly higher level than just directory-style object-crud operations. So I w= ould not deviate from these principles, as lack of them did in what was oth= erwise a useful and functional spec in SPML.

=C2=A0

Standard Schema of course is anot= her topic that SPML never adequately addressed.

=C2=A0

Richard Sand | Managin= g Director
PO Box 91824 | Austin | Texas 78709-1824 |= USA
Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754
Mobile: += 1 267 984 3651
3D"Description:

=

=C2=A0

From: scim-bounces@ietf.org [m= ailto:scim-bounces@ietf.org] <= b>On Behalf Of Trey Drake
Sent: Saturday, August 11, 2012 12:55 AM
To: Ganesh and Sa= shi Prasad
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 26

=C2=A0

I believ= e Mark's comments are sound as they speak directly to the failure of SP= ML viz. lessons learned. =C2=A0Since inception, SCIM has had an eye towards= easing the pain for SPs. =C2=A0History has proven that failure to do so ma= y result in a technically solid spec with zero adoption. =C2=A0

=C2=A0


On Aug 10, 2012, at 10:23= PM, Ganesh and Sashi Prasad <g.= c.prasad@gmail.com> wrote:

=

Ganesh - we are all participating as individuals in IETF. Maybe you should = consult the rules for working groups as explained in:

http://tools.ietf.org= /pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company,= or are a technology analyst or whether you are just a great guy/gal.
<= br>All the discussion has to be in the open and all sources (no confidentia= l research reports!) have to be publicly made available.

- prateek

Fair enough= . I was just concerned listening to Mark's comments (about adoption bei= ng hindered because of complexity for SPs), that one interest group may hav= e undue influence over the WG. if that's not the case, I'm happy :-= ).

=C2=A0

Regards,

Ganesh

<= div>

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

--047d7b5d325e61b95104c6f6a64e-- --047d7b5d325e61b95704c6f6a64f Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 1c2c4120124d9304_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDyRXhpZgAATU0AKgAAAAgABAE7AAIAAAANAAAISodpAAQA AAABAAAIWJydAAEAAAAaAAAQ0OocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFJpY2hhcmQgU2FuZAAA AAWQAwACAAAAFAAAEKaQBAACAAAAFAAAELqSkQACAAAAAzc1AACSkgACAAAAAzc1AADqHAAHAAAI DAAACJoAAAAAHOoAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAyMDExOjA4OjA0IDE5OjQ4OjM4ADIwMTE6MDg6MDQgMTk6NDg6MzgA AABSAGkAYwBoAGEAcgBkACAAUwBhAG4AZAAAAP/hCx9odHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvADw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+ DQo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIj48cmRmOlJERiB4bWxuczpyZGY9 Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYx YiIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIi8+PHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6ZmFmNWJkZDUtYmEzZC0xMWRhLWFkMzEtZDMzZDc1MTgy ZjFiIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPjx4bXA6Q3JlYXRl RGF0ZT4yMDExLTA4LTA0VDE5OjQ4OjM4Ljc0NTwveG1wOkNyZWF0ZURhdGU+PC9yZGY6RGVzY3Jp cHRpb24+PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6ZmFmNWJkZDUtYmEzZC0xMWRh LWFkMzEtZDMzZDc1MTgyZjFiIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRz LzEuMS8iPjxkYzpjcmVhdG9yPjxyZGY6U2VxIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+PHJkZjpsaT5SaWNoYXJkIFNhbmQ8L3JkZjpsaT48 L3JkZjpTZXE+DQoJCQk8L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+PC9yZGY6UkRGPjwv eDp4bXBtZXRhPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8P3hwYWNrZXQgZW5kPSd3Jz8+/9sAQwACAQECAQECAgICAgICAgMFAwMDAwMGBAQD BQcGBwcHBgcHCAkLCQgICggHBwoNCgoLDAwMDAcJDg8NDA4LDAwM/9sAQwECAgIDAwMGAwMGDAgH CAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA HwDzAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5 +v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR AD8A/XT9mX/gp78J/wBrf9pL4ifCfwbqGt3PjH4XXF1a69DdaVLbQQyW141nKElYbZMTKQMdQMji vnvxD/wc9fsn+FvEWo6Xd+IPGiXel3ctnOF8LXbqJIpGjYAgcjcp5718u/8ABBEf8b2/22f+wz4g /wDUlnryX/g3h/Y4+Fv7YH7Xn7UVn8UfAXhrx1baBqFtNpqavZrcLZPLqGprKyA/dLiNAfZBQOx9 5f8AEUv+yOAc+IvG/wD4Sd5/8TXVfBX/AIOPv2TPjd8RdK8L2nj7U9D1TW7qOysW1rw/e2VrPPIw VENwYzFFliBmVkXOOeRn0hv+CJn7JQBI/Z9+GPH/AFBkr8qf+Dpb/gn38Gf2Rfgb8L9a+GPw78O+ B9Q1rWL3Tr9tIjNtHeQi08xQ6A7SQy8NjcMkZwaBqzP31hk8xSSGBBxhu3FeQ/tW/tI3fwJtNEt9 HsbbU9c1q4ZIrectsEa8ZwrA7mdkUc8/NxxXVfs16rc+IP2cvAV9eXEtzeX3hvTrieeQ5eWR7WMs 59ySSfrXhHwpjX9qP9snVPFTsZ/D3g4oLHqVkKsyQEegZxLMO4wueDw0kQ2Tftp/8FcfhN/wTcv/ AAhpHxl1PVtO17xZp8l9AmkaPcX8DeSY0mwyBtoDyKAG5IOa8TH/AAdMfsjH/mYvG/8A4Sd5/wDE 18c/8Hbmow6R+11+zhd3Okp4gtbSwvZ5tJckJqiJf2bNbEhWOJQDGcKx+boeleLP/wAFBfg0rnP/ AASr8Ng+n9oXYI6jp/Yv+cUi+W6P0vb/AIOlv2Rtp/4qLxv/AOEnef8AxNez/s2/8Fof2ff2o/g9 8QviBoXiu60rwf8AC1YJPEep65p0umxWSzCQxYEg3SFjGVVUBZnZVVSzAV+S/wCz9+1x8D/jb8fv Angm9/4Jh+F/Dtp4y8R6foM+qyXtzKmlpdXMcDXLI2kRhhGHLkF0B243L1H0D/wck/shfDD9jL/g mBaWXwq8DeHfANp4s+IukDWIdGtBbpqXk2WpPF5oHDbGAYDsRQFj6Dvv+Do79kK0vpYofFfjG8ij bCzReEtQVJRnhlEkauARjGVB55Gcioz/AMHSn7I7H/kYvG//AISd5/8AE1B/wS8/4I/fsy/Eb/gn Z8EvEviL4L+CPEPiDxP4M0vWdU1HU7P7Xc3d1c2qTTOXck4LucKMKowAAABXvL/8ESv2SjGR/wAM +/DHOP8AoDoKBaHS/sRf8FOfgr/wUS0vVJ/hT4yj1260PYdR064tJ9P1CyVyQjtBOiOY2wQJE3Jk Fd24EDL/AGSf+Crnwd/bX+P/AI0+GfgLUdcuvFfgAXH9rw3ekzWsMQguvskmyRhtfEvAweRz0r8t v+CMnwu0T9nr/g5T+PfgbwhZnR/Cui6Lr1lY2CyvIkECX+lvHGGclmClm27iSABzUv8Awbcf8plf 2qD/ALOtD/y4aB2P3XY4U14T+3n/AMFEPhr/AME3vhlo/i34pXur2Gi63qg0e1k0/TZb52uDDLOF KRgkDZDIc9OMda92b7pr8k/+Dw3/AJMF+HH/AGUGL/01ajQJI+z/ANrD/grl8Ff2Kvhl8NfF/jzW dastE+Kwjm0OS10ee7kFu0Mcz3MqRqWSOOOaIsAC/wA+FRiCB9A/D74jaF8WfBWleJfC+sab4g8P 65Al3Yalp9ylxa3kTDKyRyKSrKfUHr71+Ef/AAcgwrc/sQ/sNROWCTeH5I2K9QDp+kg4zUVwn7R3 /Brj8a5ZLf7R8Vv2YPFepLGokfybdZnKscYY/wBn6ltDKGObe6xyPMwIQGj9/iMgivmX9jz/AIK0 fBv9urxR490j4e6jrt7f/DWET62l5pE1qsal5ox5ZcfOd0EnA5xg967v9jD9t/4cft7/AAWsfHnw z1+PWtIuT5N1buphvdJuQMvbXUDfNFKvv8rKVdGdHV2/Hf8A4NjBj9oP9sfoc6Yo/wDJzU6AsfZd r/wdO/sjXNtHIviHxvscBlz4Uu8kEfT+VSn/AIOlP2Ryf+Ri8b/+Enef/E18K/8ABq5+wz8IP2wP g18Vrr4n/Dnwn46udC1LS4LCXV7FLhrOOS2lZ1Qn7oYqCfev1d/4cmfsl7f+TfPhh/4J0oDRHG/s x/8ABwL+y1+1d8WNI8D+HfHt7p3ifxDOtrpVtrei3emx6hO2dsKTyJ5Ilc4VEaQGRyFQMxArq/26 /wDgsf8ABH/gnN8S9H8J/E/VPENhrGuab/a9olhos98jQebJFuLRggHfG3HXGD3r8lf+DmT9iD4U /sSfFP8AZ81P4T+CdJ8AXPiWfVDqQ0cPDDO9nPpjW0gjyVV0a4l+ZVBO4bicDHX/APByzH4ck/4L Ffs1r4x/sz/hEW03SRrn9oELaGwOuyi588ngReUX3exNA0j7Q/4ilv2R/wDoYvG3/hJ3n/xNLD/w dKfsiyyqreJvGcSMeXfwle7VHrwhP5Cub/4Rv/gk8zEGX9lHn/p+sR/7P/k1w37TOif8Erbf9nvx rJpU37Og1VdFuzY/2BeRtqf2jyW8nyBbMZi/mbMbAfcYoCy7H3P4g/4KofBHRv2Ib79oiy8X/wDC QfCnTXgin1TS7KaaeKSa7is1ie2ZVmjkE08YZHRXUMCQBXoH7I/7VfhD9tv9n7QPid4CuL678J+J GuRYy3lq9rM5t7qW1l3RtgriWGQDPUAHuK/nv/Y+0/WLn/g19/azMkdw9iPH2hNCOWi81LzQGuGV cnBCCMsfQLycV+kX/BvT+3F8Gfhx/wAEl/hn4Z8SfFj4c+G/Eeg3Osx6hpmr+I7SxvLUy6ze3Ee6 OWRWw0M0ThgNpDjBoE0fpyeBXzpqH/BUX4S6T+33p/7NM2oa3/wtTUk8yC0XSpTZsv2CTUCTcY2c W8Tnr1GOtdOf+CiP7P5GP+F5/B3n/qdNN/8Aj1fkjB8SfDvxb/4PAfA2veFdf0TxPod5ausGo6Tf RX1pMyeEr1XCyxEoSrAggN1HIoBK5+6VFFFAj8Uf+CCRz/wXa/baPprPiH/1Jp6+Y/8AgjL/AMFR /hl/wTC/as/aN1L4lQ+KJYfGeqJa6aui2C3hDW1/qLS790ibRiePHXPzDjHP9BPw/wD2W/hp8H/i Fr/jDwp8PfA/hfxX4qeSTWta0rQrWz1DV2kl86RrieNBJMXlJdi5OXO45JzXCah/wSv/AGZdXv7i 7vP2dfgZdXV3K08803gXS5JJpGOWd2MGWYkkknJPrQUpdz5E/wCIsb9lzHNh8Vv/AAnof/kivz0/ 4OAP+Cvnw1/4KqeAPhn4L+FGjeOrjVdG1qe4f+0tNjgN1LPCLeC3gSOV3kld3wBgdVAyWwP2/P8A wSe/ZcQbh+zd8Bcjkf8AFA6V/wDGK6H4Yf8ABPr4D/BLxfb6/wCDPgl8I/CWvWfMGpaN4P06xvIe MfLLFCrr+BoC63Ryvxd8Z3f7Nn7E/hrw/dFIfET6HaaBtRgyxOlsiXDhhwQqhsEfxFa7f9j34S/8 Km+CenQXEJi1XVP9Ovww+dXcDYh9NkYQEeoY96u/Fb9mjR/jJ420PWdYv9X2aAytb2EMsS2kh8wO +9WjZjvwqsQwyqgcck+iISqMWPTv6Yp30IaPxL/4Odcj/gpL+x5g8/2gn/p506v21Tqfr61wHxZ/ ZU+GXx48UaJrnjj4c+BfGWteG23aRf65oVrqFzpTb1k3QSSozRHeitlCDlVPau+T5CAf4jwfXqaQ yQ9DX5lf8HXfgHV/GX/BLm21DTbGa9tPCXjTTtY1V41LC0tPIu7UytjkKJbmIE/whsniv01qvqul 22s6bcWl5bwXdrdRNDNDNGJI5kYEMrKeCpBIIPUGgD8bf+CfH/BzD+z7+zv+xF8KfAHirSfiVB4h 8C+F9P8AD979k0eC5t55LWBYDLE/nglH8ssAwVhnBGRk+xv/AMHY/wCy5sP/ABL/AIrk46f8I9D/ APJFfW8//BKn9mC/neWb9nH4ESySHLSN4C0os5POSfI5PPXnNN/4dOfstj/m234C/wDhA6V/8YoK umfk3/wQZ+KMf7Yf/Bfz48fGPw3pOrWfhPV9C1a8xfIvn2Iu7+wFtFPsZkSWRbeVtgdv9XJgsFJr yP8AYO/bn8Mf8Edv+CxH7SVz8YNF8VxxatqOr6WI9Js0uJ7eSXVRewStG8keYpYCrK65yHQ4Kksv 9Cfwg+BXgj4BeFjofgTwb4U8FaL5zTHT9A0mDTbQyEYL+VCiLuIAycc4rn/jJ+xZ8Hv2jdeg1L4h fCj4a+O9QtYvIhu/EXhiy1SeKMHIRXnidlXJPANAcyPhdf8Ag7G/ZcAx9g+Kxz/1L0P/AMkV8E/8 F+/+C03ws/4Kf/s/eBvh98L9G8dSatp3ilNXll1TTorZJSbS5tY7eJFleSSV5LlcAKB8uMksBX7W Sf8ABJ/9lsKf+MbvgLjHP/FAaV/8Yrd+G/8AwT3+AnwW8XW3iLwh8EfhD4U1+wYyW+p6P4O0+xvL cnglJYoldT9DQJNH5Af8HN/g7UPhz+zD+xb4f1WJYNU0GwuNOvIw4ZYpobTSo5FyODhlIz0r9yPH vw+0P4qeDNS8O+JdG0zxBoGswm1vtO1G2S5tb2JsZSSNwVZT6Edq5n42fsrfDL9pcaUPiN8OvAvj 5dDaR9NXxHoNrqn2B5NvmND5yN5ZbYmSuM7F9BXeR5JDdj0Oe1ANn4bfthf8EnPjH/wRT+NV3+0X +yHqmq6n4FsB9o8ReEZ3e9msLJSXkhmiyG1DTlBYZJ+1W4PmKx2tNHyX/Bqv4kPi74oftWasyxRS at4cs75o4slYjLPqMhVT3A3HBPJ4781+/MoGwn0Ga86+EX7J/wAMvgRf+JbnwV8PfBPhK58ZSiXX ZdH0W3sm1dgGH7/y0G8AvIcHIzJIcZdiQaelj+ff/g3d/wCCvfwn/wCCYfwo+IWnfEmDxdNceL73 Trqw/sXTUvEVIbd0cOTIm05cY4ORzX6Mn/g7G/ZcZeLD4rZ/7F6H/wCSK+sR/wAEoP2XF2r/AMM3 fAUDhR/xQOlc8f8AXCn/APDpz9lxeR+zd8Bcjp/xQOlf/GKAumfht/wW0/4Ka+C/+Cx/x5+AHhn4 OaB4ynvtC1C609Bq1lHbPqV3qU+npBFBGkjsdptm3MwUDeMZAJr2z/g5J8C6Z8U/+Cyv7M3hfXIG utE8T2Gj6TqEUcrQvLbXGvSxSqHUhkJR2AYEEE5BFfsT8H/2Gvgp+zz4nGt+Afg/8LvBGtiJoRqG geFbDTbvyyPmTzYYlbac8jODWj8SP2TvhZ8ZviJo3i3xf8NvAXirxX4b8saVrOr6Ba3uoaX5cvnR +RPIjSRbJD5i7GG1uRg0BfsfnX+2R/wamfBP4hfCS5T4Kzal8NfHNkHmsptR1e91bS9RbBxb3STy SSRISABLCQyZ3FJQNh/Lv9nD4afBb9h39paf4Sftz/ATXrG5SRbtPEthr+rLPaQSEBJHtrO58m8s W2Pia0HmIVdGSVw4T+pksF71wfxy/ZZ+Gf7TNpp1t8SPh34E8f22kO8lhF4k0G11VbJ2ADGITxuE JCgHb1AA7UApPqct8B/gf8DvEX7Idp4P+HXh7wDqPwT8S6ZLFBp+jQwz6LqtpOGEpOzKTeZlt7MS xbcWO6vxA/bq/ZN/4Jvfsi/tXeLvht4ml/aX0XX/AAtJbLeWfh+e0vdOg+0WkN5GIpbpXnceVcxg l2JyCCSRk/vh8Fv2cPh/+zf4futJ+HXgfwn4D0m9nN1cWPh/SoNNtZZiAplaKFVQyEBQXwSQoGcA VyPxO/4J7/AT43+Or7xR40+CXwk8X+JtUMYvtX1vwjp9/fXflxpFH5k0sLO+2NI0GScKiqMADACd j+eP/hGv+CYA/wCY1+15/wB+NK/+M10//BFPwd4B8Xf8HAPgG4+A+neO7j4ZeFLXU9UMvil7ZtVh tv7EubOW5n+zgRqjXt3FGgGTiSPO07lT92v+HTv7LY5H7NvwF4/6kHSv/jFejfBP9mb4cfs36feW fw7+H/gjwDZ6g6yXcHhvQ7bS47plyFaRYEQORk4JBxk0Bc7sdKKOlFBJ/9k= --047d7b5d325e61b95704c6f6a64f-- From g.c.prasad@gmail.com Sat Aug 11 01:30:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B5221F8587 for ; Sat, 11 Aug 2012 01:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0frXyl9RfNf for ; Sat, 11 Aug 2012 01:30:52 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2C521F848A for ; Sat, 11 Aug 2012 01:30:51 -0700 (PDT) Received: by bkty7 with SMTP id y7so970936bkt.31 for ; Sat, 11 Aug 2012 01:30:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t9Lkky2f5KISZVU8sNxS0XgnB1e8B1u7GaguYM/e5KU=; b=HJW8+MJqZZdK9wU3syPoLBZ1UkxpPR744zpD3oAk2iizpHdlT/z3EGXZu29RUmFpV9 k7ATnHkBgaC0KXuVjlnatj65zbb4O9mSvETWy0RZ4F+vnJTbDzWtxxUeqrfSX3P68Wpa a3D8rFkQ3XqrnQ/LYbpMAHSEkVo3uyAcvGi3Jk/hKj+LsSWWoOy4E5qfr6DP1V39y7Gp FqKfEFoiHqexlZfOtnU0IMC7R4Blou7MH1/5W3+hJ+YFChK8GZenGnovLViQIFlDZ+Kg m7S5TJkBSeYD463k2DN2jlpZt9c4gnUxYUYoAkSmJbdl4pm4f41cUWyuXjjI4SAX/9xi wYkw== Received: by 10.204.154.211 with SMTP id p19mr2190449bkw.12.1344673849394; Sat, 11 Aug 2012 01:30:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 01:30:29 -0700 (PDT) In-Reply-To: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 18:30:29 +1000 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175cd13021c81204c6f9476c Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 08:30:56 -0000 --0015175cd13021c81204c6f9476c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > For the multi-value example you gave you used the value as the attribute name key. Now I'm confused :-). I don't believe any of my examples ever used a value as the key. Could you please show me which example you mean, and which parts of it you believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt wrote: > > For the multi-value example you gave you used the value as the attribute > name key. > > That means a lot more complex indexing structure. Better to just say > delete a specific value. > > The spec already allows multiple values to have tags like home, work, etc= . > > Phil > > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > > > In your example you are conflating value with an attribute id. > > I don't believe so. > > I'm adopting a model where every attribute of the resource is a key-value > pair. The key is a name or ID. > > For non-repeating attributes (both simple and composite), the key is the > attribute name itself. > > Simple attribute: > > Key: "dob" > Value: "01 Jan 1970" > > For composite attributes, the key employs dot notation to specify the > fully-qualified attribute name, e.g., "address.postcode". > > Composite attribute: > > Key: "address.street-number" > Value: "10" > > Key: "address.suburb" > Value: "East Camden" > > For repeating (multi-valued) attributes, I'm suggesting that there be new > keys for each individual value, otherwise they are impossible to > distinguish, and a positional index is inadequate. So we convert the arra= y > into a dictionary and this then becomes a composite attribute using dot > notation for the key. > > Multi-valued attribute: > > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" > Value: "john_smith@yahoo.com" > > So this allows us to apply uniform treatment to any arbitrarily deep > resource structure. We can refer to every leaf value with a key that is t= he > fully-qualified name using dot notation. > > The verbs are just unambiguous operations on these (now) explicitly > addressable attributes. > > INCLUDE to a collection and specify only the value. The key is generated > and returned. The fully-qualified key is > . and the value is what was specifie= d > in the INCLUDE. > > REPLACE a fully-qualified key with a new value. If the key doesn't exist, > return a "404 Not Found". > > PLACE a value at the logical location implied by the fully-qualified key. > If there is already a key with that name, return a "409 Conflict". > > FORCE the fully-qualified key to hold the given value, regardless of > whether it existed before or not. Only errors possible are "400 Bad > Request" and "500 Internal Error". > > RETIRE an attribute or a collection given its fully-qualified key. The > implementation will determine whether the attribute will disappear entire= ly > or will exist holding a null value (the blank string "" or the empty obje= ct > {} ). > > I'll explain in a separate post why we need operation verbs like these > that are independent of the HTTP verbs. > > Regards, > Ganesh > > On 11 August 2012 10:38, wrote: > >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/scim >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send scim mailing list submissions to >> scim@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >> >> You can reach the person managing the list at >> scim-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >> >> Today's Topics: >> >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >> >> >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux < >> edreux@cloudiway.com>, Trey Drake , Kelly >> Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >> Ganesh, >> >> In your example you are conflating value with an attribute id. I find >> that confusing. >> >> I agree though that operations in patch could be a lot more explicit. >> >> Eg explicitly deleting a value by saying delete or retire. >> >> Phil >> >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >> wrote: >> >> > I am concerned about your second suggestion: >> >> Let's discuss that now. >> >> The trade-offs are very clear here. >> >> Pros: >> >> Pro 1. The API to manipulate resources becomes so much cleaner, >> consistent and intuitive when every individual attribute value gets its = own >> ID. >> >> Here's how to delete a single member from a Group, as per the current >> spec: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >> >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "members": [ >> { >> "display": "Babs Jensen", >> "value": "2819c223-7f76-453a-919d-413861904646" >> "operation": "delete" >> } >> ] >> } >> >> >> Here's how to delete ALL members from a group according to the current >> spec: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >> >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "meta": { >> "attributes": [ >> "members" >> ] >> } >> } >> >> >> The two operations differ significantly, and it's not very intuitive. >> With my suggestion, here's how to delete a single member from a group: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >> } >> } >> ] } >> Here's how I suggest deleting ALL members from a group: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members" >> } >> } >> ] } >> >> I'm sure you'll agree that this is simpler, more consistent and more >> intuitive to a reader. >> >> Pro 2: We can apply this mechanism consistently to three areas: >> (a) Manipulating multi-valued attributes of a resource >> (b) Manipulating members of a group >> (c) Performing bulk operations, where we simply use HTTP verbs instead o= f >> the specialised (and semantically less ambiguous) verbs I suggested for >> attributes, the "key" becomes the URI, and the "value" becomes the >> corresponding JSON object. >> >> All of them return "207 Multi-Status" with the "results" array holding >> individual status codes. >> >> In the current spec, (a) and (b) are done similarly but (c) is very >> different. >> >> Pro 3: Adoption of the standard by clients is likely to be higher becaus= e >> it's simpler for them. >> >> Pro 4: New (not incumbent) cloud providers will probably find this easie= r >> to implement because they have no legacy. They will probably use some fo= rm >> of NoSQL database and won't be constrained by the limitations of LDAP >> directories. >> >> Cons: >> >> Con 1: Incumbent cloud providers with existing data stores in a director= y >> format (where multi-valued attributes are stored as comma-separated valu= es >> under a single attribute node) will find it difficult to migrate to this >> model and store each attribute value as a sub-node with its own key. Thi= s >> will "hinder adoption of the spec", which is what you fear. >> >> Have I summed up the Pros and Cons correctly? I'm biased of course, so I >> could have missed a Con or hyped a Pro :-). >> >> In other words, we're debating interface complexity (current spec) versu= s >> implementation complexity (my suggestion). Both can hinder adoption of t= he >> spec by different parties. >> >> Here's what we need to discuss - Do the Pros make the suggestion worth >> adopting in spite of the Cons, or are the Cons so great that it's best t= o >> leave the spec as it is? >> >> Keep in mind that a complex spec that only favours incumbent cloud >> providers can cut both ways. It opens the door to a simpler interface >> offered by a new generation of nimbler SPs that don't have the same lega= cy >> issues, and there could be an exodus of clients to these new SPs. SCIM >> could end up being obsoleted very soon, because the API interface is ver= y >> complex and clumsy, as any new reader can attest. I was taken aback by t= he >> complexity when I saw it, which is why I was prompted to suggest somethi= ng >> simpler. >> >> This is an issue where we need the opinions of many people, and they nee= d >> to state their affiliations. If most people weighing in belong to incumb= ent >> SPs and they vote in favour of interface complexity to avoid implementat= ion >> complexity, then it means the spec is not doing a good job of balancing = the >> interests of various groups. I think we should also poll client >> organisations to see what they would want. >> >> (Gartner is trusted by enterprise clients to evaluate the capabilities o= f >> vendors (SPs). I believe Gartner should take the lead in representing >> client interests in this working group rather than those of incumbent >> vendors, which is what it seems like to me. Correct me if I'm being unfa= ir.) >> >> Regards, >> Ganesh >> >> >> >> On 11 August 2012 01:35, Diodati,Mark wrote: >> >>> Hi Ganesh, >>> >>> >>> >>> I am concerned about your second suggestion: >>> >>> =932. When dealing with multi-valued attributes of a resource (expresse= d >>> as arrays in JSON), they must be converted from an array into a diction= ary >>> with unique keys (UUIDs generated by the cloud provider when the attrib= ute >>> is created). Without unique keys for every attribute value of a resourc= e, >>> manipulating it will be clumsy and inelegant.=94 >>> >>> >>> >>> One of the primary reasons that SPML failed was lack of adoption by >>> service providers due to its complexity. Very few target applications >>> implemented SPML. Most of the commercial provisioning systems had an SP= ML >>> interface (either v1 or v2), but not one of them was conformant to the = SPML >>> standard because of complexity. If you are interested, I will forward y= ou >>> the research documents that discuss these problems in detail. For SCIM = to >>> be successful, it must be adopted by commercial target applications (i.= e., >>> service providers). I am confident that a requirement for unique >>> identifiers with multi-valued attributes will preclude its adoption, >>> because it requires major changes to the service provider=92s existing >>> identity storage mechanisms. >>> >>> Mark >>> >>> >>> >>> >>> >>> >>> >>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>> *Sent:* Friday, August 10, 2012 9:51 AM >>> >>> *To:* Ganesh and Sashi Prasad >>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>> >>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>> >>> >>> >>> Ganesh, >>> >>> >>> >>> I'll base my comments on your latest reply (below). >>> >>> >>> >>> The externalID is not part of the protocol. It is an *optional* >>> attribute within the *schema* specification. As for #2, the protocol s= pec >>> works as you describe if "arbitrary URI parameters" equate to resource >>> attributes (Allow generic search using 'GET /Users' and arbitrary URI >>> parameters). Please clarify your suggestion. >>> >>> >>> >>> I'm not tracking your coupling concern. The client can search and henc= e >>> retrieve resources on any attribute it chooses, externalId or otherwise= . >>> Nothing mandates use of externalId. >>> >>> >>> >>> >>> >>> What do you mean by "candidate key"? Given >>> >>> >>> >>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>> g.c.prasad@gmail.com> wrote: >>> >>> > I think scim gets its current simplicity from its single owner hub >>> spoke model implementing tight coupling. [...] IMHO loose coupling is a >>> much more complex solution. >>> >>> >>> >>> Phil, >>> >>> >>> >>> I'm a bit surprised that you're implying "tight coupling =3D=3D simple"= and >>> "loose coupling =3D=3D complex". That's contrary to my experience. >>> >>> >>> >>> When I say "loose coupling", I mean "no unnecessary dependencies". >>> Invariably, a reduction in dependencies leads to greater simplicity. >>> >>> >>> >>> Let's not confuse reduction of dependencies in the data model with a >>> hub-and-spokes architecture. They're entirely orthogonal aspects of the >>> solution. >>> >>> >>> >>> All that my suggestion involves is, >>> >>> >>> >>> 1. Take 'external ID' out of the protocol. >>> >>> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >>> >>> >>> >>> No planned functionality is lost by this. >>> >>> >>> >>> 1. The client enterprise can still send its internal ID as part of the >>> resource body, inside some attribute defined by them (but not defined b= y >>> the protocol). Let's say they call it 'myID'. >>> >>> 2. The client enterprise can search for resource URIs using any >>> attribute, including this internal ID >>> >>> 'GET /Users?myID=3Dbjensen' >>> >>> Since myID is a candidate key, the server will return exactly one URI, >>> which is the canonical URI for the resource >>> >>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>> >>> 3. The client can use this URI to perform all other operations as usual= . >>> >>> >>> >>> So taking 'externalID' out of the protocol spec only does this: >>> >>> 1. It avoids enshrining tight coupling in the protocol (If clients want= to tightly couple themselves to the cloud provider by sending their intern= al IDs, they can do so. Suicide is OK, but the protocol should not be guilt= y of assisted suicide. ;-) >>> >>> 2. It encourages loose coupling by nudging clients towards maintaining = their own internal-to-external identifier mappings. >>> >>> >>> >>> That's what I'd like to see. I don't believe this complicates the proto= col. It simplifies it and it also lends itself to a loosely-coupled approac= h. >>> >>> >>> >>> I'll address the multi-valued attribute suggestion separately. >>> >>> >>> >>> Regards, >>> >>> Ganesh >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 10 August 2012 07:53, Phil Hunt wrote: >>> >>> >>> >>> Phil >>> >>> >>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>> wrote: >>> >>> > storing this information in a mapping table outside of the SCIM >>> spec is a great way to enable this solution. Part of the key here is t= hat >>> SCIM is just a piece of the architecture for this solution, and is only >>> responsible for the transport layer between domains. >>> >>> I wasn't suggesting that the mapping table be part of the SCIM spec. I >>> provided that example to illustrate that splitting and merging identiti= es >>> is a common requirement, and that decoupling local identifiers within a >>> domain from shared identifiers between domains was the best way to >>> facilitate it. >>> >>> >>> >>> I'm suggesting that the spec do less, not more. >>> >>> >>> >>> What the SCIM spec needs to do there is just refrain from introducing >>> tight coupling. I would like to see a single identifier exposed through= the >>> API, with the implication (and perhaps the recommendation) that it be t= he >>> shared one. Allowing one domain to expose its internal identifier to th= e >>> other creates tight coupling and ensures that both domains need >>> simultaneously split or merge identities, which is not desirable. So I >>> recommend _taking out_ the "external id" field from the API. The spec >>> shouldn't encourage tight coupling. If clients want to pass in their >>> internal ids as part of the resource body, no one can stop them, and th= ey >>> can always do a search on that attribute to retrieve the URI exactly as= you >>> visualise they will with the "external id", but let's not elevate an >>> anti-pattern to a recommendation by enshrining the "external id" as an >>> acceptable attribute. >>> >>> >>> >>> Am I making sense? >>> >>> >>> >>> I see what you are saying. I think scim gets its current simplicity fro= m >>> its single owner hub spoke model implementing tight coupling. >>> >>> >>> >>> IMHO loose coupling is a much more complex solution. The reality is tha= t >>> each end-point has value to contribute and thus the single-owner model = will >>> eventually need to become multi-owner or multi-hub. >>> >>> >>> >>> That said i think the current model provides a practical starting point= . >>> >>> >>> >>> > Regarding unique identifiers for multi-valued attributes there is a >>> trade-off involved. On one hand this makes PATCH semantics easier. On= the >>> other hand it puts extra burden on service providers. >>> >>> >>> Precisely. The spec has to strike the right balance. It would be >>> interesting to hear from the other members of the spec mailing list. Yo= u >>> know where I stand on this. It would be good to hear the spectrum of >>> opinions. >>> >>> >>> >>> Regards, >>> >>> Ganesh >>> >>> On 10 August 2012 00:28, Kelly Grizzle >>> wrote: >>> >>> Thanks Emmanuel. I had started writing up a similar response. As you >>> suggest, storing this information in a mapping table outside of the SCI= M >>> spec is a great way to enable this solution. Part of the key here is t= hat >>> SCIM is just a piece of the architecture for this solution, and is only >>> responsible for the transport layer between domains. >>> >>> >>> >>> You could also model these ID mappings in the SCIM user as an extension >>> but would probably not want to expose these externally. Here is an exa= mple >>> of how to model the end state of the false positive scenario (splitting= a >>> user): >>> >>> >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>> true | >>> >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>> true | >>> >>> >>> >>> This could be represented as two SCIM users that contain information >>> about the entities on other domains. >>> >>> >>> >>> { >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"], >>> >>> "id": "9caf78aac3d6", >>> >>> "userName": "John Smith", >>> >>> "urn:scim:schemas:extension:federation:1.0": { >>> >>> "linkedUsers": [ >>> >>> { >>> >>> "domain": "D2", >>> >>> "externalEntityId": "ff487230b3a0" >>> >>> } >>> >>> ] >>> >>> } >>> >>> } >>> >>> >>> >>> { >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"], >>> >>> "id": "a99a5feba839", >>> >>> "userName": "John Smith", >>> >>> "urn:scim:schemas:extension:federation:1.0": { >>> >>> "linkedUsers": [ >>> >>> { >>> >>> "domain": "D2", >>> >>> "externalEntityId": "7a87f27c1dd8" >>> >>> } >>> >>> ] >>> >>> } >>> >>> } >>> >>> >>> >>> In the second user, the linkedUsers attribute would be empty until the >>> split user was synced to domain 2. >>> >>> >>> >>> >>> >>> Similarly, the false negative use case (merging two users) looked like >>> this at the end: >>> >>> >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>> true | >>> >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>> false | >>> >>> >>> >>> This could be represented with the following SCIM user: >>> >>> >>> >>> { >>> >>> "schemas": ["urn:scim:schemas:core:1.0", >>> "urn:scim:schemas:extension:federation:1.0"], >>> >>> "id": "9caf78aac3d6", >>> >>> "userName": "John Smith", >>> >>> "urn:scim:schemas:extension:federation:1.0": { >>> >>> "linkedUsers": [ >>> >>> { >>> >>> "domain": "D2", >>> >>> "externalEntityId": "ff487230b3a0" >>> >>> }, >>> >>> { >>> >>> "domain": "D2", >>> >>> "externalEntityId": "41206cc97c8b", >>> >>> "deletionRequired": true >>> >>> } >>> >>> ] >>> >>> } >>> >>> } >>> >>> >>> >>> >>> >>> Regarding unique identifiers for multi-valued attributes there is a >>> trade-off involved. On one hand this makes PATCH semantics easier. On= the >>> other hand it puts extra burden on service providers. Since the incept= ion >>> of SCIM, a key goal has been to foster adoption by service providers by >>> making things fit easily onto existing systems. IMO the value gained b= y >>> unique identifiers for multi-valued attributes is not worth the demands= put >>> on a service provider. I also think that vendors that have a >>> non-SCIM-compliant API will choose to keep things that way if the spec = is >>> too hard for them to implement. In a green field environment we do hav= e >>> the luxury of mandating a model to make certain operations more elegant= . >>> However, we can=92t ignore legacy systems. >>> >>> >>> >>> --Kelly >>> >>> >>> >>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >>> Of *Emmanuel Dreux >>> *Sent:* Thursday, August 09, 2012 3:18 AM >>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>> *Cc:* scim@ietf.org >>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>> >>> >>> >>> Hi Ganesh, >>> >>> >>> >>> Nothing prevents you in your SCIM implementation (client or server) to >>> generate a unique identifier for each synchronized object and maintain = an >>> internal mapping table ( you would have to map group membership as well= ). >>> >>> >>> >>> This is what we are doing with Active Directory sources or targets: >>> >>> As we didn=92t find an immutable uniqueID in AD systems >>> (DN,samAccountName, UPN) are subject to change (even objectGuid can cha= nge >>> if an AD domain is migrated), we decided to generate and maintain an >>> internal table of ids. This fits your requirements as it hides internal= ids. >>> >>> >>> >>> This was written in dotnet and we have started a project to rewrite our >>> SCIM stack in PHP and will give it to the Open Source community. This >>> implementation will have a parameter : AllocateIds versus UseExistingID= s. >>> >>> This will give the choice of =93hiding=94 internalIDs or use them as un= ique >>> ID. >>> >>> >>> >>> You can also implement such feature without violating the SCIM specs, o= r >>> without asking to include it in the specs. >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Emmanuel Dreux >>> >>> http://www.cloudiway.com >>> >>> Tel: +33 4 26 78 17 58 >>> >>> Mobile: +33 6 47 81 26 70 >>> >>> skype: Emmanuel.Dreux >>> >>> >>> >>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>> >>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>> *=C0 :* Kelly Grizzle >>> *Cc :* scim@ietf.org >>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>> >>> >>> >>> Hi Kelly, >>> >>> Thanks for your response. Let me first respond in brief to the two main >>> points you have made, and then elaborate on the first. >>> >>> 1. Why should domains not expose their internal identifiers to >>> other domains? >>> >>> a. >>> >>> We are designing a protocol for a federated system of domains, where al= l >>> domains are co-equal peers. (In physics too, N-body problems are much >>> harder than 2-body problems. :-) Therefore, assuming that there are onl= y >>> two players in the interaction makes this tightly coupled in a number o= f >>> ways. We should rely on messaging and notification, with encapsulation = of >>> domain-specific data. >>> >>> b. >>> >>> In any non-trivial data store, there will always be the ongoing need to >>> merge and split identities as and when =93false negatives=94 and =93fal= se >>> positives=94 are discovered. A domain should be able to handle this int= ernal >>> housekeeping freely, only notifying other domains when convenient. Mapp= ing >>> of internal identifiers to external ones and maintaining this mapping >>> internally allows this loosely-coupled housekeeping to take place. Shar= ing >>> internal identifiers (or otherwise outsourcing the mapping of internal = to >>> external identifiers) forces housekeeping activities to be done in >>> lock-step across domains. >>> >>> c. >>> >>> Asynchronous interaction is not just a matter of a suitable wire >>> protocol which can be designed later. The data model plays a crucial ro= le >>> in enabling or constraining such interaction. A tightly-coupled data mo= del >>> will force the use of synchronous interactions, and the exposure of >>> internal identifiers is a key part of this tight coupling. >>> >>> 2. The difficulty of assigning unique identifiers to the individual >>> values of multi-valued attributes: >>> >>> a. >>> >>> I'm not belittling the effort involved in migrating legacy data stores >>> to such a model. However, in the larger historical context of cross-dom= ain >>> identity management, we are really at the very early stages. If a >>> relatively new discipline and a brand new spec are held captive to lega= cy >>> considerations, we are losing an opportunity to provide a clean and ele= gant >>> model to subsequent users of the spec, and this will have repercussions >>> over many years or even decades. >>> >>> b. >>> >>> If incumbent cloud providers find it hard to immediately adopt the >>> dictionary model for existing multi-valued attributes, they can transit= ion >>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-com= pliant=94 >>> APIs to their customers and encouraging new customers to adopt the >>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradual= ly >>> migrated to the SCIM-compliant API. The logistics are not insurmountabl= e, >>> and shouldn't prevent the adoption of a dictionary model for multi-valu= ed >>> attributes. >>> >>> Elaboration of Point 1: >>> >>> When we consider federated identity across more than one domain, we hav= e >>> to assume that domains are not necessarily master-slave in their >>> interaction. The most generic interaction model is peer-to-peer, where >>> entity lifecycle events within a domain are notified to other domains (= when >>> necessary) in an asynchronous manner (i.e., through messaging) and the >>> other domains are free to respond to these events in an appropriate man= ner >>> and at a time of their convenience. >>> >>> A key set of lifecycle events for an entity is the merging and splittin= g >>> of identity that is often required. >>> >>> The question =93Is this one entity?=94 can be answered either yes (posi= tive) >>> or no (negative). But sometimes, we can discover false positives and fa= lse >>> negatives in our data stores. >>> >>> Consider a case where customers sign up online, and two customers who >>> are privacy-conscious enter fake IDs such as =93John Smith=94, and also= use the >>> same date of birth (say, 1 Jan 1970) or similar attributes. The front-e= nd >>> application may make an intelligent (but incorrect) guess that these tw= o >>> persons are the same, and re-assign the same identifier to the second >>> person. This is a false positive. They appear to be the same entity, bu= t >>> they're actually different. When the error is discovered, the identitie= s >>> will need to be split, with a new identifier generated for one of them. >>> >>> Consider the opposite case where a customer signs up through two >>> different portals or in two different sessions, using the names =93JSmi= th=94 >>> and =93JohnS=94. It is very likely that they will be treated as two dif= ferent >>> customers and assigned two unique identifiers. This is a false negative= . >>> They appear to be two entities, but are actually the same. At a later >>> stage, when the error is discovered, the identities will have to be mer= ged, >>> and one of the identifiers will have to be dropped. >>> >>> These are not theoretical use cases. They form a significant proportion >>> of the user base in most large Web-facing applications. Let's see how t= hese >>> can be managed in a federated way by mapping internal identifiers to >>> external ones and only exposing external identifiers to other domains. >>> >>> a. False positives: >>> >>> Domain 1 has the following information about a customer in its data >>> store: >>> >>> Internal ID: 9caf78aac3d6 >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> >>> When requesting the provisioning of this entity in Domain 2, the >>> following ID is returned by Domain 2: ff487230b3a0. >>> >>> Domain 1 then maintains the following in a mapping table and uses it fo= r >>> translation when talking to Domain 2, taking care never to expose its >>> internal identifier: >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> >>> When the false positive is discovered and the entity is split, Domain 1 >>> creates a new internal identifier and now has the following entity >>> information. >>> >>> Internal ID: 9caf78aac3d6 >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> >>> Internal ID: a99a5feba839 >>> >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> >>> This second entity with its own internal identifier is invisible to >>> Domain 2, and this is by design. Communication about the original entit= y >>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >>> vice-versa. At some convenient time (importantly, this doesn't have to = be >>> at the time the split happens), Domain 2 can be requested to provision = a >>> second entity, and when it responds with an identifier of =937a87f27c1d= d8=94, >>> this can go into the mapping table as a new record associated with the >>> second entity's internal identifier. >>> >>> The mapping table now contains the following entries: >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>> >>> Domain 2 is not even aware that a split has happened, and the >>> provisioning that it does is not in lockstep with the split in identity >>> that occurred in Domain 1. >>> >>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>> treatment of false negatives.) >>> >>> b. False negatives: >>> >>> Domain 1 has the following information about what it thinks are two >>> distinct customers in its data store: >>> >>> Internal ID: 9caf78aac3d6 >>> >>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>> >>> Internal ID: 273d36e30d09 >>> >>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>> >>> When requesting the provisioning of these entities in Domain 2, the >>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>> >>> Domain 1 then maintains the following in a mapping table and uses it fo= r >>> translation when talking to Domain 2, taking care never to expose its >>> internal identifiers: >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> >>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>> >>> When the false negative is discovered and the two entities are merged, >>> Domain 1 drops one of the internal identifiers and rationalises the nam= e of >>> the customer (say, to =93John Smith=94). Let's say it retains the first= ID >>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>> >>> The mapping table now looks like this: >>> >>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y >>> flag | >>> >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>> >>> Now two external identifiers map to the same internal one, so inbound >>> communication from Domain 2 can be unambi >>> >> _______________________________________________ > > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015175cd13021c81204c6f9476c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 For the multi-value example you gave you used the value as the attribute na= me key.=A0

Now I'm confused :-). I don't believe= any of my examples ever used a value as the key.

Could you please show me which example you mean, and which parts of it you = believe to be the value?

Regards,
Ganesh= =A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wrote:

For the mu= lti-value example you gave you used the value as the attribute name key.=A0=

That means a lot more complex indexing structure. Bette= r to just say delete a specific value.=A0

The spec= already allows multiple values to have tags like home, work, etc.

Phil

On 2= 012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=
>=A0In your example you are conflating value with an attr= ibute id.=A0

I don't believe so.

I'm adop= ting a model where every attribute of the resource is a key-value pair. The= key is a name or ID.

For non-repeating attributes (both simple and composite= ), the key is the attribute name itself.=A0

S= imple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite= attributes, the key employs dot notation to specify the fully-qualified at= tribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-num= ber"
Value: "10"

Key: &qu= ot;address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting = that there be new keys for each individual value, otherwise they are imposs= ible to distinguish, and a positional index is inadequate. So we convert th= e array into a dictionary and this then becomes a composite attribute using= dot notation for the key.

Multi-valued attribute:

Key: &= quot;emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: &qu= ot;john_smith@yah= oo.com"

So this allows us to apply uniform treatment to any arb= itrarily deep resource structure. We can refer to every leaf value with a k= ey that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and = specify only the value. The key is generated and returned. The fully-qualif= ied key is <collection-name>.<newly-generated-ID> and the value= is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the = key doesn't exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualifi= ed key. If there is already a key with that name, return a "409 Confli= ct".

FORCE the fully-qualified key to hold the given value, = regardless of whether it existed before or not. Only errors possible are &q= uot;400 Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualifie= d key. The implementation will determine whether the attribute will disappe= ar entirely or will exist holding a null value (the blank string "&quo= t; or the empty object {} ).

I'll explain in a separate post why we need operati= on verbs like these that are independent of the HTTP verbs.

<= /div>
Regards,
Ganesh

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

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.co= m>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sai= lpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Proto= col - 3 suggestions for improvement
G= anesh,

In your example you are conflating value wi= th an attribute id. I find that confusing.=A0

I agree though that operations in patch could be a lot = more explicit.=A0

Eg explicitly deleting a value b= y saying delete or retire.=A0

Phil

On 2012-08-1= 0, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I = am concerned about your second suggestion:=A0

Let= 's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipu= late resources becomes so much cleaner, consistent and intuitive when every= individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current s= pec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to th= e current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3=
f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very in= tuitive.=A0
With my suggestion, here's how to delete a single= member from a group:

PATCH /Groups/acbf3ae7-846= 3-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more c= onsistent and more intuitive to a reader.

Pro 2: W= e can apply this mechanism consistently to three areas:
(a) Manip= ulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk oper= ations, where we simply use HTTP verbs instead of the specialised (and sema= ntically less ambiguous) verbs I suggested for attributes, the "key&qu= ot; becomes the URI, and the "value" becomes the corresponding JS= ON object.

All of them return "207 Multi-Status" with th= e "results" array holding individual status codes.

=
In the current spec, (a) and (b) are done similarly but (c) is v= ery different.

Pro 3: Adoption of the standard by clients is likely to= be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to im= plement because they have no legacy. They will probably use some form of No= SQL database and won't be constrained by the limitations of LDAP direct= ories.

Cons:

Con 1: Incumbent cloud p= roviders with existing data stores in a directory format (where multi-value= d attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each attrib= ute value as a sub-node with its own key. This will "hinder adoption o= f the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm b= iased of course, so I could have missed a Con or hyped a Pro :-).

=
In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make t= he suggestion worth adopting in spite of the Cons, or are the Cons so great= that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, a= nd there could be an exodus of clients to these new SPs. SCIM could end up = being obsoleted very soon, because the API interface is very complex and cl= umsy, as any new reader can attest. I was taken aback by the complexity whe= n I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peo= ple, and they need to state their affiliations. If most people weighing in = belong to incumbent SPs and they vote in favour of interface complexity to = avoid implementation complexity, then it means the spec is not doing a good= job of balancing the interests of various groups. I think we should also p= oll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate t= he capabilities of vendors (SPs). I believe Gartner should take the lead in= representing client interests in this working group rather than those of i= ncumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.)

Regards,
Ganesh



<= div class=3D"gmail_quote">On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0

=A0

=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ie= tf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0

=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0




On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0









I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0






I'm suggesting that the spec do less, not more.<=
/p>



=A0




What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0






Am I making sense?










=A0






I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0






IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0












=A0






That said i think the current model provides a pract=
ical starting point.=A0














=A0






>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.












=A0






Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec
 is a great way to enable this solution.=A0 Part of the key here is that SC=
IM is just a piece of the architecture for this solution, and is only respo=
nsible for the transport layer between domains.


=A0


You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example
 of how to model the end state of the false positive scenario (splitting a =
user):




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.








=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=









=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=









=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.








=A0


=A0


Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0


| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0




This could be represented=
 with the following SCIM user:


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=









=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


=A0


Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other
 hand it puts extra burden on service providers.=A0 Since the inception of =
SCIM, a key goal has been to foster adoption by service providers by making=
 things fit easily onto existing systems.=A0 IMO the value gained by unique=
 identifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0


--Kelly


=A0






From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0


Hi Ganesh,


=A0

Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an
 internal mapping table ( you would have to map group membership as well).<=
/span>


=A0


This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain
 is migrated), we decided to generate and maintain an internal table of ids=
. This fits your requirements as it hides internal ids.


=A0


This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0


You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.








=A0


--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com








Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0



De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0


Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=










b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.








Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:








| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.








Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.








(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:








| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_____________= __________________________________

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

--0015175cd13021c81204c6f9476c-- From g.c.prasad@gmail.com Sat Aug 11 02:01:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB65921F84DD for ; Sat, 11 Aug 2012 02:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFcFSVSopghd for ; Sat, 11 Aug 2012 02:01:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B56421F84D8 for ; Sat, 11 Aug 2012 02:01:09 -0700 (PDT) Received: by bkty7 with SMTP id y7so976199bkt.31 for ; Sat, 11 Aug 2012 02:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=12RaTiEqD9KNHpzO7UBgfj+43nEh3fOzhVskKfiHXcI=; b=m0kBTk1Ubjl58cnuT9l54ixpX9FO0DW27JvwCEnQhGvM4TK2SMCUqMGmnvbe3ZIrLM I2eRK4jGHROGgtyOC64J+ZFbqYfhQnAmREOqDKc21BcaF/qssUR8lYrKrTrjhesYKsy0 q+tuBSpYUqfRXTHo+s9bnNITmvdy15IisQdlXs/+L81Q+1eMfFqz3IWfoKwudGjJM0q9 sR15xoV+nuxMJ12jRyvMVmsoU12xjVsNQUjYHk/V6z/R6jQNEqi2fNtI/6HVYjF1XWPV mhqqzzUXSJ4jOt7HylcVZKRaO+MEtkJHIizt2VBcyv/NrHcsjb2mExfaWw1qqy/v4ELX dALQ== Received: by 10.205.137.8 with SMTP id im8mr2022572bkc.135.1344675668157; Sat, 11 Aug 2012 02:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 02:00:47 -0700 (PDT) In-Reply-To: References: From: Ganesh and Sashi Prasad Date: Sat, 11 Aug 2012 19:00:47 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/related; boundary=0015175dd5c889e81d04c6f9b310 Subject: Re: [scim] scim Digest, Vol 8, Issue 29 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 09:01:11 -0000 --0015175dd5c889e81d04c6f9b310 Content-Type: multipart/alternative; boundary=0015175dd5c889e81904c6f9b30f --0015175dd5c889e81904c6f9b30f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A couple of you have mentioned the failure of SPML, with conjectures as to why it failed. Let me share my experience with it. I tried to implement an SPML-based provisioning system 3-4 years ago and gave up, not because of a lack of language features but simply because I found the messages were too heavyweight for something that was just a shell. There was little attention paid to the data model (a common failing in many protocol designs, IMO). The payload was the real thing, and that was entirely the organisation's responsibility. I finally designed a provisioning scheme with specific attention to data, that was loosely-coupled and idempotent, and which (most importantly) worked. It's described on pages 124-128 of my eBook . So yes, SPML failed, but the lessons I drew from that are quite different from what others seem to be drawing. The spec needs to deliver value, and that was what was missing in SPML. My two cents. Regards, Ganesh On 11 August 2012 15:22, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: scim Digest, Vol 8, Issue 26 (Trey Drake) > 2. Re: scim Digest, Vol 8, Issue 26 (Richard Sand) > > > ---------- Forwarded message ---------- > From: Trey Drake > To: Ganesh and Sashi Prasad > Cc: "scim@ietf.org" > Date: Fri, 10 Aug 2012 23:55:14 -0500 > Subject: Re: [scim] scim Digest, Vol 8, Issue 26 > I believe Mark's comments are sound as they speak directly to the failure > of SPML viz. lessons learned. Since inception, SCIM has had an eye towar= ds > easing the pain for SPs. History has proven that failure to do so may > result in a technically solid spec with zero adoption. > > > On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> wrote: > > Ganesh - we are all participating as individuals in IETF. Maybe you shoul= d >> consult the rules for working groups as explained in: >> >> http://tools.ietf.org/pdf/rfc2418.pdf >> >> It is irrelevant whether you belong to a very large technology company, >> or are a technology analyst or whether you are just a great guy/gal. >> >> All the discussion has to be in the open and all sources (no confidentia= l >> research reports!) have to be publicly made available. >> >> - prateek >> >> Fair enough. I was just concerned listening to Mark's comments (about > adoption being hindered because of complexity for SPs), that one interest > group may have undue influence over the WG. if that's not the case, I'm > happy :-). > > Regards, > Ganesh > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > ---------- Forwarded message ---------- > From: Richard Sand > To: Trey Drake , Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> > Cc: scim@ietf.org > Date: Sat, 11 Aug 2012 01:22:37 -0400 > Subject: Re: [scim] scim Digest, Vol 8, Issue 26 > > I=92d like to jump in here too in support of Mark=92s comments. I see man= y on > the SCIM list who were former members or contributors to the OASIS PSTC a= nd > the failings of SPML should be well know. What SPML failed to do was > provide a simple language for specific tasks =96 if a company just needed= to > set up an endpoint to enable/disable accounts or perform password resets, > SPML was not purpose-build for this, and set requirements conformance tha= t > made it ill-suited towards one-off usage as a tool to solve a specific > integration problem. SCIM as it is now addresses some of these shortcomin= gs > =96 it does not require much of a burden to the SP, it language handles > identity management requirements at a slightly higher level than just > directory-style object-crud operations. So I would not deviate from these > principles, as lack of them did in what was otherwise a useful and > functional spec in SPML. > > > > Standard Schema of course is another topic that SPML never adequately > addressed. > > > > Richard Sand | Managing Director > PO Box 91824 | Austin | Texas 78709-1824 | USA > Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754 > Mobile: +1 267 984 3651 > [image: Description: logo - small] > > > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Trey Drake > *Sent:* Saturday, August 11, 2012 12:55 AM > *To:* Ganesh and Sashi Prasad > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 26 > > > > I believe Mark's comments are sound as they speak directly to the failure > of SPML viz. lessons learned. Since inception, SCIM has had an eye towar= ds > easing the pain for SPs. History has proven that failure to do so may > result in a technically solid spec with zero adoption. > > > > > On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> wrote: > > Ganesh - we are all participating as individuals in IETF. Maybe you shoul= d > consult the rules for working groups as explained in: > > http://tools.ietf.org/pdf/rfc2418.pdf > > It is irrelevant whether you belong to a very large technology company, o= r > are a technology analyst or whether you are just a great guy/gal. > > All the discussion has to be in the open and all sources (no confidential > research reports!) have to be publicly made available. > > - prateek > > Fair enough. I was just concerned listening to Mark's comments (about > adoption being hindered because of complexity for SPs), that one interest > group may have undue influence over the WG. if that's not the case, I'm > happy :-). > > > > Regards, > > Ganesh > > _______________________________________________ > 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 > > --0015175dd5c889e81904c6f9b30f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
A couple of you have mentioned the failure of SPML, with conjectures a= s to why it failed. Let me share my experience with it.

I tried to implement an SPML-based provisioning system 3-4 years ago = and gave up, not because of a lack of language features but simply because = I found the messages were too heavyweight for something that was just a she= ll.=A0There was little attention paid to the data model (a common failing i= n many protocol designs, IMO).=A0The payload was the real thing, and that w= as entirely the organisation's responsibility.

I finally designed a provisioning scheme with specific = attention to data, that was loosely-coupled and idempotent, and which (most= importantly) worked. It's described on pages 124-128 of my=A0eBook=A0.

So yes, SPML failed, but the lessons I drew from that a= re quite different from what others seem to be drawing. The spec needs to d= eliver value, and that was what was missing in SPML.

My two cents.

Regards,
Ganesh
On 11 August 2012 15:22, &l= t;scim-request@i= etf.org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



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

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

You can reach the person managing the list at
=A0 =A0 =A0 =A0 scim-owner@ietf.org<= /a>

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

Today's Topics:

=A0 =A01. Re: scim Digest, Vol 8, Issue 26 (Trey Drake)
=A0 =A02. Re: scim Digest, Vol 8, Issue 26 (Richard Sand)


---------- Forwarded message ----------
From:=A0Trey Drake <<= a href=3D"mailto:trey.drake@unboundid.com">trey.drake@unboundid.com>=
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug= 2012 23:55:14 -0500
Subject:=A0Re: [scim] scim Digest, Vol 8, Issue 26<= br>
I believe Mark's comments are sound as they speak directly to the = failure of SPML viz. lessons learned. =A0Since inception, SCIM has had an e= ye towards easing the pain for SPs. =A0History has proven that failure to d= o so may result in a technically solid spec with zero adoption. =A0


On Aug 10, 2012, at 10:23 PM, Ganesh and= Sashi Prasad <g.c.prasad@gmail.com> wrote:

Ganesh - we are all participating as individu= als in IETF. Maybe you should consult the rules for working groups as explained in:

htt= p://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal.

All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made available.

- prateek

Fair enough. I was just concerned listening= to Mark's comments (about adoption being hindered because of complexit= y for SPs), that one interest group may have undue influence over the WG. i= f that's not the case, I'm happy :-).

Regards,
Ganesh
___________________= ____________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim


---------- Forwarded message ----------
From:=A0Richa= rd Sand <rsand@idfoundry.com&= gt;
To:=A0Trey Drake <trey.drake= @unboundid.com>, Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0scim@ietf.org
Date:=A0Sat, 11 Aug 2012 01:22:37 -0400
Subject:=A0Re: [scim] scim Diges= t, Vol 8, Issue 26

I=92= d like to jump in here too in support of Mark=92s comments. I see many on t= he SCIM list who were former members or contributors to the OASIS PSTC and = the failings of SPML should be well know. What SPML failed to do was provid= e a simple language for specific tasks =96 if a company just needed to set = up an endpoint to enable/disable accounts or perform password resets, SPML = was not purpose-build for this, and set requirements conformance that made = it ill-suited towards one-off usage as a tool to solve a specific integrati= on problem. SCIM as it is now addresses some of these shortcomings =96 it d= oes not require much of a burden to the SP, it language handles identity ma= nagement requirements at a slightly higher level than just directory-style = object-crud operations. So I would not deviate from these principles, as la= ck of them did in what was otherwise a useful and functional spec in SPML.<= /span>

=A0

Standard Schema of course is another= topic that SPML never adequately addressed.

=A0

Richard Sand | Managing Directo= r
PO Box 91824 | Austin | Texas 78709-1824 |= USA
Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754
Mobile: +1 267 984 3651
3D"Description:

= =A0

From: scim-bounc= es@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Trey Drake
Sent: Saturday, August 11, 2012 12:55 AM
To: Ganesh and Sa= shi Prasad
Cc: scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue = 26

=A0

I believe M= ark's comments are sound as they speak directly to the failure of SPML = viz. lessons learned. =A0Since inception, SCIM has had an eye towards easin= g the pain for SPs. =A0History has proven that failure to do so may result = in a technically solid spec with zero adoption. =A0

=A0


On Aug 10, 2012, at 10:23 PM,= Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=

Ganesh - we are all participating as individuals in IETF. Maybe you should = consult the rules for working groups as explained in:

http://tools.ietf.org= /pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company,= or are a technology analyst or whether you are just a great guy/gal.
<= br>All the discussion has to be in the open and all sources (no confidentia= l research reports!) have to be publicly made available.

- prateek

Fair enough= . I was just concerned listening to Mark's comments (about adoption bei= ng hindered because of complexity for SPs), that one interest group may hav= e undue influence over the WG. if that's not the case, I'm happy :-= ).

=A0

= Regards,

Ganesh

<= /blockquote>

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


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


--0015175dd5c889e81904c6f9b30f-- --0015175dd5c889e81d04c6f9b310 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 1c2c4120124d9304_0.1 /9j/4AAQSkZJRgABAQEAYABgAAD/4RDyRXhpZgAATU0AKgAAAAgABAE7AAIAAAANAAAISodpAAQA AAABAAAIWJydAAEAAAAaAAAQ0OocAAcAAAgMAAAAPgAAAAAc6gAAAAgAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFJpY2hhcmQgU2FuZAAA AAWQAwACAAAAFAAAEKaQBAACAAAAFAAAELqSkQACAAAAAzc1AACSkgACAAAAAzc1AADqHAAHAAAI DAAACJoAAAAAHOoAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAyMDExOjA4OjA0IDE5OjQ4OjM4ADIwMTE6MDg6MDQgMTk6NDg6MzgA AABSAGkAYwBoAGEAcgBkACAAUwBhAG4AZAAAAP/hCx9odHRwOi8vbnMuYWRvYmUuY29tL3hhcC8x LjAvADw/eHBhY2tldCBiZWdpbj0n77u/JyBpZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJz8+ DQo8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIj48cmRmOlJERiB4bWxuczpyZGY9 Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSJ1dWlkOmZhZjViZGQ1LWJhM2QtMTFkYS1hZDMxLWQzM2Q3NTE4MmYx YiIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvIi8+PHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6ZmFmNWJkZDUtYmEzZC0xMWRhLWFkMzEtZDMzZDc1MTgy ZjFiIiB4bWxuczp4bXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPjx4bXA6Q3JlYXRl RGF0ZT4yMDExLTA4LTA0VDE5OjQ4OjM4Ljc0NTwveG1wOkNyZWF0ZURhdGU+PC9yZGY6RGVzY3Jp cHRpb24+PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9InV1aWQ6ZmFmNWJkZDUtYmEzZC0xMWRh LWFkMzEtZDMzZDc1MTgyZjFiIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRz LzEuMS8iPjxkYzpjcmVhdG9yPjxyZGY6U2VxIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcv MTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+PHJkZjpsaT5SaWNoYXJkIFNhbmQ8L3JkZjpsaT48 L3JkZjpTZXE+DQoJCQk8L2RjOmNyZWF0b3I+PC9yZGY6RGVzY3JpcHRpb24+PC9yZGY6UkRGPjwv eDp4bXBtZXRhPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8P3hwYWNrZXQgZW5kPSd3Jz8+/9sAQwACAQECAQECAgICAgICAgMFAwMDAwMGBAQD BQcGBwcHBgcHCAkLCQgICggHBwoNCgoLDAwMDAcJDg8NDA4LDAwM/9sAQwECAgIDAwMGAwMGDAgH CAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA HwDzAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMC BAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYn KCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeY mZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5 +v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwAB AgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMR AD8A/XT9mX/gp78J/wBrf9pL4ifCfwbqGt3PjH4XXF1a69DdaVLbQQyW141nKElYbZMTKQMdQMji vnvxD/wc9fsn+FvEWo6Xd+IPGiXel3ctnOF8LXbqJIpGjYAgcjcp5718u/8ABBEf8b2/22f+wz4g /wDUlnryX/g3h/Y4+Fv7YH7Xn7UVn8UfAXhrx1baBqFtNpqavZrcLZPLqGprKyA/dLiNAfZBQOx9 5f8AEUv+yOAc+IvG/wD4Sd5/8TXVfBX/AIOPv2TPjd8RdK8L2nj7U9D1TW7qOysW1rw/e2VrPPIw VENwYzFFliBmVkXOOeRn0hv+CJn7JQBI/Z9+GPH/AFBkr8qf+Dpb/gn38Gf2Rfgb8L9a+GPw78O+ B9Q1rWL3Tr9tIjNtHeQi08xQ6A7SQy8NjcMkZwaBqzP31hk8xSSGBBxhu3FeQ/tW/tI3fwJtNEt9 HsbbU9c1q4ZIrectsEa8ZwrA7mdkUc8/NxxXVfs16rc+IP2cvAV9eXEtzeX3hvTrieeQ5eWR7WMs 59ySSfrXhHwpjX9qP9snVPFTsZ/D3g4oLHqVkKsyQEegZxLMO4wueDw0kQ2Tftp/8FcfhN/wTcv/ AAhpHxl1PVtO17xZp8l9AmkaPcX8DeSY0mwyBtoDyKAG5IOa8TH/AAdMfsjH/mYvG/8A4Sd5/wDE 18c/8Hbmow6R+11+zhd3Okp4gtbSwvZ5tJckJqiJf2bNbEhWOJQDGcKx+boeleLP/wAFBfg0rnP/ AASr8Ng+n9oXYI6jp/Yv+cUi+W6P0vb/AIOlv2Rtp/4qLxv/AOEnef8AxNez/s2/8Fof2ff2o/g9 8QviBoXiu60rwf8AC1YJPEep65p0umxWSzCQxYEg3SFjGVVUBZnZVVSzAV+S/wCz9+1x8D/jb8fv Angm9/4Jh+F/Dtp4y8R6foM+qyXtzKmlpdXMcDXLI2kRhhGHLkF0B243L1H0D/wck/shfDD9jL/g mBaWXwq8DeHfANp4s+IukDWIdGtBbpqXk2WpPF5oHDbGAYDsRQFj6Dvv+Do79kK0vpYofFfjG8ij bCzReEtQVJRnhlEkauARjGVB55Gcioz/AMHSn7I7H/kYvG//AISd5/8AE1B/wS8/4I/fsy/Eb/gn Z8EvEviL4L+CPEPiDxP4M0vWdU1HU7P7Xc3d1c2qTTOXck4LucKMKowAAABXvL/8ESv2SjGR/wAM +/DHOP8AoDoKBaHS/sRf8FOfgr/wUS0vVJ/hT4yj1260PYdR064tJ9P1CyVyQjtBOiOY2wQJE3Jk Fd24EDL/AGSf+Crnwd/bX+P/AI0+GfgLUdcuvFfgAXH9rw3ekzWsMQguvskmyRhtfEvAweRz0r8t v+CMnwu0T9nr/g5T+PfgbwhZnR/Cui6Lr1lY2CyvIkECX+lvHGGclmClm27iSABzUv8Awbcf8plf 2qD/ALOtD/y4aB2P3XY4U14T+3n/AMFEPhr/AME3vhlo/i34pXur2Gi63qg0e1k0/TZb52uDDLOF KRgkDZDIc9OMda92b7pr8k/+Dw3/AJMF+HH/AGUGL/01ajQJI+z/ANrD/grl8Ff2Kvhl8NfF/jzW dastE+Kwjm0OS10ee7kFu0Mcz3MqRqWSOOOaIsAC/wA+FRiCB9A/D74jaF8WfBWleJfC+sab4g8P 65Al3Yalp9ylxa3kTDKyRyKSrKfUHr71+Ef/AAcgwrc/sQ/sNROWCTeH5I2K9QDp+kg4zUVwn7R3 /Brj8a5ZLf7R8Vv2YPFepLGokfybdZnKscYY/wBn6ltDKGObe6xyPMwIQGj9/iMgivmX9jz/AIK0 fBv9urxR490j4e6jrt7f/DWET62l5pE1qsal5ox5ZcfOd0EnA5xg967v9jD9t/4cft7/AAWsfHnw z1+PWtIuT5N1buphvdJuQMvbXUDfNFKvv8rKVdGdHV2/Hf8A4NjBj9oP9sfoc6Yo/wDJzU6AsfZd r/wdO/sjXNtHIviHxvscBlz4Uu8kEfT+VSn/AIOlP2Ryf+Ri8b/+Enef/E18K/8ABq5+wz8IP2wP g18Vrr4n/Dnwn46udC1LS4LCXV7FLhrOOS2lZ1Qn7oYqCfev1d/4cmfsl7f+TfPhh/4J0oDRHG/s x/8ABwL+y1+1d8WNI8D+HfHt7p3ifxDOtrpVtrei3emx6hO2dsKTyJ5Ilc4VEaQGRyFQMxArq/26 /wDgsf8ABH/gnN8S9H8J/E/VPENhrGuab/a9olhos98jQebJFuLRggHfG3HXGD3r8lf+DmT9iD4U /sSfFP8AZ81P4T+CdJ8AXPiWfVDqQ0cPDDO9nPpjW0gjyVV0a4l+ZVBO4bicDHX/APByzH4ck/4L Ffs1r4x/sz/hEW03SRrn9oELaGwOuyi588ngReUX3exNA0j7Q/4ilv2R/wDoYvG3/hJ3n/xNLD/w dKfsiyyqreJvGcSMeXfwle7VHrwhP5Cub/4Rv/gk8zEGX9lHn/p+sR/7P/k1w37TOif8Erbf9nvx rJpU37Og1VdFuzY/2BeRtqf2jyW8nyBbMZi/mbMbAfcYoCy7H3P4g/4KofBHRv2Ib79oiy8X/wDC QfCnTXgin1TS7KaaeKSa7is1ie2ZVmjkE08YZHRXUMCQBXoH7I/7VfhD9tv9n7QPid4CuL678J+J GuRYy3lq9rM5t7qW1l3RtgriWGQDPUAHuK/nv/Y+0/WLn/g19/azMkdw9iPH2hNCOWi81LzQGuGV cnBCCMsfQLycV+kX/BvT+3F8Gfhx/wAEl/hn4Z8SfFj4c+G/Eeg3Osx6hpmr+I7SxvLUy6ze3Ee6 OWRWw0M0ThgNpDjBoE0fpyeBXzpqH/BUX4S6T+33p/7NM2oa3/wtTUk8yC0XSpTZsv2CTUCTcY2c W8Tnr1GOtdOf+CiP7P5GP+F5/B3n/qdNN/8Aj1fkjB8SfDvxb/4PAfA2veFdf0TxPod5ausGo6Tf RX1pMyeEr1XCyxEoSrAggN1HIoBK5+6VFFFAj8Uf+CCRz/wXa/baPprPiH/1Jp6+Y/8AgjL/AMFR /hl/wTC/as/aN1L4lQ+KJYfGeqJa6aui2C3hDW1/qLS790ibRiePHXPzDjHP9BPw/wD2W/hp8H/i Fr/jDwp8PfA/hfxX4qeSTWta0rQrWz1DV2kl86RrieNBJMXlJdi5OXO45JzXCah/wSv/AGZdXv7i 7vP2dfgZdXV3K08803gXS5JJpGOWd2MGWYkkknJPrQUpdz5E/wCIsb9lzHNh8Vv/AAnof/kivz0/ 4OAP+Cvnw1/4KqeAPhn4L+FGjeOrjVdG1qe4f+0tNjgN1LPCLeC3gSOV3kld3wBgdVAyWwP2/P8A wSe/ZcQbh+zd8Bcjkf8AFA6V/wDGK6H4Yf8ABPr4D/BLxfb6/wCDPgl8I/CWvWfMGpaN4P06xvIe MfLLFCrr+BoC63Ryvxd8Z3f7Nn7E/hrw/dFIfET6HaaBtRgyxOlsiXDhhwQqhsEfxFa7f9j34S/8 Km+CenQXEJi1XVP9Ovww+dXcDYh9NkYQEeoY96u/Fb9mjR/jJ420PWdYv9X2aAytb2EMsS2kh8wO +9WjZjvwqsQwyqgcck+iISqMWPTv6Yp30IaPxL/4Odcj/gpL+x5g8/2gn/p506v21Tqfr61wHxZ/ ZU+GXx48UaJrnjj4c+BfGWteG23aRf65oVrqFzpTb1k3QSSozRHeitlCDlVPau+T5CAf4jwfXqaQ yQ9DX5lf8HXfgHV/GX/BLm21DTbGa9tPCXjTTtY1V41LC0tPIu7UytjkKJbmIE/whsniv01qvqul 22s6bcWl5bwXdrdRNDNDNGJI5kYEMrKeCpBIIPUGgD8bf+CfH/BzD+z7+zv+xF8KfAHirSfiVB4h 8C+F9P8AD979k0eC5t55LWBYDLE/nglH8ssAwVhnBGRk+xv/AMHY/wCy5sP/ABL/AIrk46f8I9D/ APJFfW8//BKn9mC/neWb9nH4ESySHLSN4C0os5POSfI5PPXnNN/4dOfstj/m234C/wDhA6V/8YoK umfk3/wQZ+KMf7Yf/Bfz48fGPw3pOrWfhPV9C1a8xfIvn2Iu7+wFtFPsZkSWRbeVtgdv9XJgsFJr yP8AYO/bn8Mf8Edv+CxH7SVz8YNF8VxxatqOr6WI9Js0uJ7eSXVRewStG8keYpYCrK65yHQ4Kksv 9Cfwg+BXgj4BeFjofgTwb4U8FaL5zTHT9A0mDTbQyEYL+VCiLuIAycc4rn/jJ+xZ8Hv2jdeg1L4h fCj4a+O9QtYvIhu/EXhiy1SeKMHIRXnidlXJPANAcyPhdf8Ag7G/ZcAx9g+Kxz/1L0P/AMkV8E/8 F+/+C03ws/4Kf/s/eBvh98L9G8dSatp3ilNXll1TTorZJSbS5tY7eJFleSSV5LlcAKB8uMksBX7W Sf8ABJ/9lsKf+MbvgLjHP/FAaV/8Yrd+G/8AwT3+AnwW8XW3iLwh8EfhD4U1+wYyW+p6P4O0+xvL cnglJYoldT9DQJNH5Af8HN/g7UPhz+zD+xb4f1WJYNU0GwuNOvIw4ZYpobTSo5FyODhlIz0r9yPH vw+0P4qeDNS8O+JdG0zxBoGswm1vtO1G2S5tb2JsZSSNwVZT6Edq5n42fsrfDL9pcaUPiN8OvAvj 5dDaR9NXxHoNrqn2B5NvmND5yN5ZbYmSuM7F9BXeR5JDdj0Oe1ANn4bfthf8EnPjH/wRT+NV3+0X +yHqmq6n4FsB9o8ReEZ3e9msLJSXkhmiyG1DTlBYZJ+1W4PmKx2tNHyX/Bqv4kPi74oftWasyxRS at4cs75o4slYjLPqMhVT3A3HBPJ4781+/MoGwn0Ga86+EX7J/wAMvgRf+JbnwV8PfBPhK58ZSiXX ZdH0W3sm1dgGH7/y0G8AvIcHIzJIcZdiQaelj+ff/g3d/wCCvfwn/wCCYfwo+IWnfEmDxdNceL73 Trqw/sXTUvEVIbd0cOTIm05cY4ORzX6Mn/g7G/ZcZeLD4rZ/7F6H/wCSK+sR/wAEoP2XF2r/AMM3 fAUDhR/xQOlc8f8AXCn/APDpz9lxeR+zd8Bcjp/xQOlf/GKAumfht/wW0/4Ka+C/+Cx/x5+AHhn4 OaB4ynvtC1C609Bq1lHbPqV3qU+npBFBGkjsdptm3MwUDeMZAJr2z/g5J8C6Z8U/+Cyv7M3hfXIG utE8T2Gj6TqEUcrQvLbXGvSxSqHUhkJR2AYEEE5BFfsT8H/2Gvgp+zz4nGt+Afg/8LvBGtiJoRqG geFbDTbvyyPmTzYYlbac8jODWj8SP2TvhZ8ZviJo3i3xf8NvAXirxX4b8saVrOr6Ba3uoaX5cvnR +RPIjSRbJD5i7GG1uRg0BfsfnX+2R/wamfBP4hfCS5T4Kzal8NfHNkHmsptR1e91bS9RbBxb3STy SSRISABLCQyZ3FJQNh/Lv9nD4afBb9h39paf4Sftz/ATXrG5SRbtPEthr+rLPaQSEBJHtrO58m8s W2Pia0HmIVdGSVw4T+pksF71wfxy/ZZ+Gf7TNpp1t8SPh34E8f22kO8lhF4k0G11VbJ2ADGITxuE JCgHb1AA7UApPqct8B/gf8DvEX7Idp4P+HXh7wDqPwT8S6ZLFBp+jQwz6LqtpOGEpOzKTeZlt7MS xbcWO6vxA/bq/ZN/4Jvfsi/tXeLvht4ml/aX0XX/AAtJbLeWfh+e0vdOg+0WkN5GIpbpXnceVcxg l2JyCCSRk/vh8Fv2cPh/+zf4futJ+HXgfwn4D0m9nN1cWPh/SoNNtZZiAplaKFVQyEBQXwSQoGcA VyPxO/4J7/AT43+Or7xR40+CXwk8X+JtUMYvtX1vwjp9/fXflxpFH5k0sLO+2NI0GScKiqMADACd j+eP/hGv+CYA/wCY1+15/wB+NK/+M10//BFPwd4B8Xf8HAPgG4+A+neO7j4ZeFLXU9UMvil7ZtVh tv7EubOW5n+zgRqjXt3FGgGTiSPO07lT92v+HTv7LY5H7NvwF4/6kHSv/jFejfBP9mb4cfs36feW fw7+H/gjwDZ6g6yXcHhvQ7bS47plyFaRYEQORk4JBxk0Bc7sdKKOlFBJ/9k= --0015175dd5c889e81d04c6f9b310-- From phil.hunt@oracle.com Sat Aug 11 08:12:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A9321F852E for ; Sat, 11 Aug 2012 08:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kw5FPs1ax54e for ; Sat, 11 Aug 2012 08:12:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0F10621F84F3 for ; Sat, 11 Aug 2012 08:12:41 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7BFCcTc024057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 15:12:39 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7BFCcT8011761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 15:12:38 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7BFCcCd026195; Sat, 11 Aug 2012 10:12:38 -0500 Received: from [101.220.236.12] (/68.146.185.64) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Aug 2012 08:12:36 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_99F4E03B-9CD5-4CE1-846C-33C1DB268D26" From: Phil Hunt In-Reply-To: Date: Sat, 11 Aug 2012 09:12:35 -0600 Message-Id: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:12:46 -0000 --Apple-Mail=_99F4E03B-9CD5-4CE1-846C-33C1DB268D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ganesh, Here's the sample that concerned me... > The two operations differ significantly, and it's not very intuitive.=20= > With my suggestion, here's how to delete a single member from a group: >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" >=20 > { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] > } You gave other examples of an attribute with an identifier that matched = that value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of = the extra indexing to support this. Just use the value as the item you = wish to delete. I agree, the delete value operation could be more explicit and clear in = general. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > > For the multi-value example you gave you used the value as the = attribute name key.=20 >=20 > Now I'm confused :-). I don't believe any of my examples ever used a = value as the key. >=20 > Could you please show me which example you mean, and which parts of it = you believe to be the value? >=20 > Regards, > Ganesh=20 >=20 > On 11 August 2012 13:59, Phil Hunt wrote: >=20 > For the multi-value example you gave you used the value as the = attribute name key.=20 >=20 > That means a lot more complex indexing structure. Better to just say = delete a specific value.=20 >=20 > The spec already allows multiple values to have tags like home, work, = etc. >=20 > Phil >=20 > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad = wrote: >=20 >> > In your example you are conflating value with an attribute id.=20 >>=20 >> I don't believe so. >>=20 >> I'm adopting a model where every attribute of the resource is a = key-value pair. The key is a name or ID. >>=20 >> For non-repeating attributes (both simple and composite), the key is = the attribute name itself.=20 >>=20 >> Simple attribute: >>=20 >> Key: "dob" >> Value: "01 Jan 1970" >>=20 >> For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode". >>=20 >> Composite attribute: >>=20 >> Key: "address.street-number" >> Value: "10" >>=20 >> Key: "address.suburb" >> Value: "East Camden" >>=20 >> For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to = distinguish, and a positional index is inadequate. So we convert the = array into a dictionary and this then becomes a composite attribute = using dot notation for the key. >>=20 >> Multi-valued attribute: >>=20 >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >> Value: "john_smith@yahoo.com" >>=20 >> So this allows us to apply uniform treatment to any arbitrarily deep = resource structure. We can refer to every leaf value with a key that is = the fully-qualified name using dot notation. >>=20 >> The verbs are just unambiguous operations on these (now) explicitly = addressable attributes. >>=20 >> INCLUDE to a collection and specify only the value. The key is = generated and returned. The fully-qualified key is = . and the value is what was = specified in the INCLUDE. >>=20 >> REPLACE a fully-qualified key with a new value. If the key doesn't = exist, return a "404 Not Found". >>=20 >> PLACE a value at the logical location implied by the fully-qualified = key. If there is already a key with that name, return a "409 Conflict". >>=20 >> FORCE the fully-qualified key to hold the given value, regardless of = whether it existed before or not. Only errors possible are "400 Bad = Request" and "500 Internal Error". >>=20 >> RETIRE an attribute or a collection given its fully-qualified key. = The implementation will determine whether the attribute will disappear = entirely or will exist holding a null value (the blank string "" or the = empty object {} ). >>=20 >> I'll explain in a separate post why we need operation verbs like = these that are independent of the HTTP verbs. >>=20 >> Regards, >> Ganesh >>=20 >> On 11 August 2012 10:38, wrote: >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >>=20 >> https://www.ietf.org/mailman/listinfo/scim >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send scim mailing list submissions to >> scim@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >>=20 >> You can reach the person managing the list at >> scim-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >>=20 >> Today's Topics: >>=20 >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux = , Trey Drake , Kelly = Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >> Ganesh, >>=20 >> In your example you are conflating value with an attribute id. I find = that confusing.=20 >>=20 >> I agree though that operations in patch could be a lot more explicit.=20= >>=20 >> Eg explicitly deleting a value by saying delete or retire.=20 >>=20 >> Phil >>=20 >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad = wrote: >>=20 >>> > I am concerned about your second suggestion:=20 >>>=20 >>> Let's discuss that now. >>>=20 >>> The trade-offs are very clear here. >>>=20 >>> Pros: >>>=20 >>> Pro 1. The API to manipulate resources becomes so much cleaner, = consistent and intuitive when every individual attribute value gets its = own ID. >>>=20 >>> Here's how to delete a single member from a Group, as per the = current spec: >>>=20 >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>>=20 >>> { >>> "schemas": ["urn:scim:schemas:core:1.0"], >>> "members": [ >>> { >>> "display": "Babs Jensen", >>> "value": "2819c223-7f76-453a-919d-413861904646" >>> "operation": "delete" >>> } >>> ] >>> } >>>=20 >>> Here's how to delete ALL members from a group according to the = current spec: >>>=20 >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>>=20 >>> { >>> "schemas": ["urn:scim:schemas:core:1.0"], >>> "meta": { >>> "attributes": [ >>> "members" >>> ] >>> } >>> } >>>=20 >>> The two operations differ significantly, and it's not very = intuitive.=20 >>> With my suggestion, here's how to delete a single member from a = group: >>>=20 >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>>=20 >>> { >>> "operations" : [ >>> { >>> "RETIRE" : { >>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>> } >>> } >>> ] >>> } >>>=20 >>> Here's how I suggest deleting ALL members from a group: >>>=20 >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>>=20 >>> { >>> "operations" : [ >>> { >>> "RETIRE" : { >>> "key" : "members" >>> } >>> } >>> ] >>> } >>>=20 >>> I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader. >>>=20 >>> Pro 2: We can apply this mechanism consistently to three areas: >>> (a) Manipulating multi-valued attributes of a resource >>> (b) Manipulating members of a group >>> (c) Performing bulk operations, where we simply use HTTP verbs = instead of the specialised (and semantically less ambiguous) verbs I = suggested for attributes, the "key" becomes the URI, and the "value" = becomes the corresponding JSON object. >>>=20 >>> All of them return "207 Multi-Status" with the "results" array = holding individual status codes. >>>=20 >>> In the current spec, (a) and (b) are done similarly but (c) is very = different. >>>=20 >>> Pro 3: Adoption of the standard by clients is likely to be higher = because it's simpler for them. >>>=20 >>> Pro 4: New (not incumbent) cloud providers will probably find this = easier to implement because they have no legacy. They will probably use = some form of NoSQL database and won't be constrained by the limitations = of LDAP directories. >>>=20 >>> Cons: >>>=20 >>> Con 1: Incumbent cloud providers with existing data stores in a = directory format (where multi-valued attributes are stored as = comma-separated values under a single attribute node) will find it = difficult to migrate to this model and store each attribute value as a = sub-node with its own key. This will "hinder adoption of the spec", = which is what you fear. >>>=20 >>> Have I summed up the Pros and Cons correctly? I'm biased of course, = so I could have missed a Con or hyped a Pro :-). >>>=20 >>> In other words, we're debating interface complexity (current spec) = versus implementation complexity (my suggestion). Both can hinder = adoption of the spec by different parties. >>>=20 >>> Here's what we need to discuss - Do the Pros make the suggestion = worth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is? >>>=20 >>> Keep in mind that a complex spec that only favours incumbent cloud = providers can cut both ways. It opens the door to a simpler interface = offered by a new generation of nimbler SPs that don't have the same = legacy issues, and there could be an exodus of clients to these new SPs. = SCIM could end up being obsoleted very soon, because the API interface = is very complex and clumsy, as any new reader can attest. I was taken = aback by the complexity when I saw it, which is why I was prompted to = suggest something simpler. >>>=20 >>> This is an issue where we need the opinions of many people, and they = need to state their affiliations. If most people weighing in belong to = incumbent SPs and they vote in favour of interface complexity to avoid = implementation complexity, then it means the spec is not doing a good = job of balancing the interests of various groups. I think we should also = poll client organisations to see what they would want. >>>=20 >>> (Gartner is trusted by enterprise clients to evaluate the = capabilities of vendors (SPs). I believe Gartner should take the lead in = representing client interests in this working group rather than those of = incumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.) >>>=20 >>> Regards, >>> Ganesh >>>=20 >>>=20 >>>=20 >>> On 11 August 2012 01:35, Diodati,Mark = wrote: >>> Hi Ganesh, >>>=20 >>> =20 >>> I am concerned about your second suggestion: >>>=20 >>> =932. When dealing with multi-valued attributes of a resource = (expressed as arrays in JSON), they must be converted from an array into = a dictionary with unique keys (UUIDs generated by the cloud provider = when the attribute is created). Without unique keys for every attribute = value of a resource, manipulating it will be clumsy and inelegant.=94 >>>=20 >>> =20 >>> One of the primary reasons that SPML failed was lack of adoption by = service providers due to its complexity. Very few target applications = implemented SPML. Most of the commercial provisioning systems had an = SPML interface (either v1 or v2), but not one of them was conformant to = the SPML standard because of complexity. If you are interested, I will = forward you the research documents that discuss these problems in = detail. For SCIM to be successful, it must be adopted by commercial = target applications (i.e., service providers). I am confident that a = requirement for unique identifiers with multi-valued attributes will = preclude its adoption, because it requires major changes to the service = provider=92s existing identity storage mechanisms. >>>=20 >>> Mark >>>=20 >>> =20 >>> =20 >>> =20 >>> From: Trey Drake [mailto:trey.drake@unboundid.com]=20 >>> Sent: Friday, August 10, 2012 9:51 AM >>>=20 >>>=20 >>> To: Ganesh and Sashi Prasad >>> Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>=20 >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>> Ganesh, >>>=20 >>> =20 >>> I'll base my comments on your latest reply (below). =20 >>>=20 >>> =20 >>> The externalID is not part of the protocol. It is an *optional* = attribute within the *schema* specification. As for #2, the protocol = spec works as you describe if "arbitrary URI parameters" equate to = resource attributes (Allow generic search using 'GET /Users' and = arbitrary URI parameters). Please clarify your suggestion. >>>=20 >>> =20 >>> I'm not tracking your coupling concern. The client can search and = hence retrieve resources on any attribute it chooses, externalId or = otherwise. Nothing mandates use of externalId. =20 >>>=20 >>> =20 >>> =20 >>> What do you mean by "candidate key"? Given=20 >>>=20 >>> =20 >>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad = wrote: >>>=20 >>> > I think scim gets its current simplicity from its single owner = hub spoke model implementing tight coupling. [...] IMHO loose coupling = is a much more complex solution. >>>=20 >>> =20 >>> Phil, >>>=20 >>> =20 >>> I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. >>>=20 >>> =20 >>> When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >>>=20 >>> =20 >>> Let's not confuse reduction of dependencies in the data model with a = hub-and-spokes architecture. They're entirely orthogonal aspects of the = solution. >>>=20 >>> =20 >>> All that my suggestion involves is, >>>=20 >>> =20 >>> 1. Take 'external ID' out of the protocol. >>>=20 >>> 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >>>=20 >>> =20 >>> No planned functionality is lost by this. >>>=20 >>> =20 >>> 1. The client enterprise can still send its internal ID as part of = the resource body, inside some attribute defined by them (but not = defined by the protocol). Let's say they call it 'myID'. >>>=20 >>> 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID >>>=20 >>> 'GET /Users?myID=3Dbjensen' >>>=20 >>> Since myID is a candidate key, the server will return exactly one = URI, which is the canonical URI for the resource >>>=20 >>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>> 3. The client can use this URI to perform all other operations as = usual. >>> =20 >>> So taking 'externalID' out of the protocol spec only does this: >>> 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) >>> 2. It encourages loose coupling by nudging clients towards = maintaining their own internal-to-external identifier mappings. >>> =20 >>> That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >>> =20 >>> I'll address the multi-valued attribute suggestion separately. >>> =20 >>> Regards, >>> Ganesh >>> =20 >>> =20 >>> =20 >>> =20 >>> On 10 August 2012 07:53, Phil Hunt wrote: >>>=20 >>>=20 >>>=20 >>> Phil >>>=20 >>>=20 >>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >>>=20 >>> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>>=20 >>> I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>>=20 >>> =20 >>> I'm suggesting that the spec do less, not more. >>>=20 >>> =20 >>> What the SCIM spec needs to do there is just refrain from = introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute. >>>=20 >>> =20 >>> Am I making sense? >>>=20 >>> =20 >>> I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >>>=20 >>> =20 >>> IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >>>=20 >>> =20 >>> That said i think the current model provides a practical starting = point.=20 >>>=20 >>> =20 >>> > Regarding unique identifiers for multi-valued attributes there is = a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>>=20 >>>=20 >>> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>>=20 >>> =20 >>> Regards, >>>=20 >>> Ganesh >>>=20 >>> On 10 August 2012 00:28, Kelly Grizzle = wrote: >>>=20 >>> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>>=20 >>> =20 >>> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>>=20 >>> =20 >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>=20 >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | = true | >>>=20 >>> =20 >>> This could be represented as two SCIM users that contain information = about the entities on other domains. >>>=20 >>> =20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "a99a5feba839", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "7a87f27c1dd8" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>>=20 >>> =20 >>> =20 >>> Similarly, the false negative use case (merging two users) looked = like this at the end: >>>=20 >>> =20 >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | = true | >>>=20 >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>>=20 >>> =20 >>> This could be represented with the following SCIM user: >>>=20 >>> =20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> }, >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "41206cc97c8b", >>>=20 >>> "deletionRequired": true >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>> =20 >>> Regarding unique identifiers for multi-valued attributes there is a = trade-off involved. On one hand this makes PATCH semantics easier. On = the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>>=20 >>> =20 >>> --Kelly >>>=20 >>> =20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Emmanuel Dreux >>> Sent: Thursday, August 09, 2012 3:18 AM >>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>> Cc: scim@ietf.org >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>> Hi Ganesh, >>>=20 >>> =20 >>> Nothing prevents you in your SCIM implementation (client or server) = to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>>=20 >>> =20 >>> This is what we are doing with Active Directory sources or targets: >>>=20 >>> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>>=20 >>> =20 >>> This was written in dotnet and we have started a project to rewrite = our SCIM stack in PHP and will give it to the Open Source community. = This implementation will have a parameter : AllocateIds versus = UseExistingIDs. >>>=20 >>> This will give the choice of =93hiding=94 internalIDs or use them as = unique ID. >>>=20 >>> =20 >>> You can also implement such feature without violating the SCIM = specs, or without asking to include it in the specs. >>>=20 >>> =20 >>> -- >>>=20 >>> Regards, >>>=20 >>> Emmanuel Dreux >>>=20 >>> http://www.cloudiway.com >>>=20 >>> Tel: +33 4 26 78 17 58 >>>=20 >>> Mobile: +33 6 47 81 26 70 >>>=20 >>> skype: Emmanuel.Dreux >>>=20 >>> =20 >>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >>> =C0 : Kelly Grizzle >>> Cc : scim@ietf.org >>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>> Hi Kelly, >>> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >>> 1. Why should domains not expose their internal identifiers to = other domains? >>> a. >>> We are designing a protocol for a federated system of domains, where = all domains are co-equal peers. (In physics too, N-body problems are = much harder than 2-body problems. :-) Therefore, assuming that there are = only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >>> b. >>> In any non-trivial data store, there will always be the ongoing need = to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >>> c. >>> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >>> 2. The difficulty of assigning unique identifiers to the individual = values of multi-valued attributes: >>> a. >>> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >>> b. >>> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >>> Elaboration of Point 1: >>> When we consider federated identity across more than one domain, we = have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >>> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >>> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >>> Consider a case where customers sign up online, and two customers = who are privacy-conscious enter fake IDs such as =93John Smith=94, and = also use the same date of birth (say, 1 Jan 1970) or similar attributes. = The front-end application may make an intelligent (but incorrect) guess = that these two persons are the same, and re-assign the same identifier = to the second person. This is a false positive. They appear to be the = same entity, but they're actually different. When the error is = discovered, the identities will need to be split, with a new identifier = generated for one of them. >>> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >>> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >>> a. False positives: >>> Domain 1 has the following information about a customer in its data = store: >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >>> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifier: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> When the false positive is discovered and the entity is split, = Domain 1 creates a new internal identifier and now has the following = entity information. >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> Internal ID: a99a5feba839 >>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>> This second entity with its own internal identifier is invisible to = Domain 2, and this is by design. Communication about the original entity = takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 = and vice-versa. At some convenient time (importantly, this doesn't have = to be at the time the split happens), Domain 2 can be requested to = provision a second entity, and when it responds with an identifier of = =937a87f27c1dd8=94, this can go into the mapping table as a new record = associated with the second entity's internal identifier. >>> The mapping table now contains the following entries: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >>> (What is the =93Primary flag=94 used for? We'll see when we cover = the treatment of false negatives.) >>> b. False negatives: >>> Domain 1 has the following information about what it thinks are two = distinct customers in its data store: >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>> Internal ID: 273d36e30d09 >>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>> When requesting the provisioning of these entities in Domain 2, the = following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >>> The mapping table now looks like this: >>> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>> Now two external identifiers map to the same internal one, so = inbound communication from Domain 2 can be unambi >>=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 --Apple-Mail=_99F4E03B-9CD5-4CE1-846C-33C1DB268D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
The two operations differ = significantly, and it's not very intuitive. 
With my = suggestion, here's how to delete a single member from a = group:

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : = [
{
"key" : = "members.
= }
] }




Phil

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





On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad = wrote:

>  For the multi-value example you gave you used the value as the attribute = name key. 

Now I'm confused :-). I don't believe = any of my examples ever used a value as the = key.

Could you please show me which example you mean, and which parts of it = you believe to be the = value?

Regards,
Ganesh 

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wrote:

For the multi-value example you gave you = used the value as the attribute name key. 

That means a lot more complex indexing structure. = Better to just say delete a specific = value. 

The spec already allows multiple = values to have tags like home, work, etc.

Phil

On = 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value = with an attribute id. 

I don't believe = so.

I'm adopting a model where every attribute of the = resource is a key-value pair. The key is a name or ID.

For non-repeating attributes (both simple and = composite), the key is the attribute name = itself. 

Simple = attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite = attributes, the key employs dot notation to specify the fully-qualified = attribute name, e.g., "address.postcode".

Composite attribute:

Key: = "address.street-number"
Value: = "10"

Key: "address.suburb"
Value: = "East Camden"

For repeating (multi-valued) attributes, I'm suggesting = that there be new keys for each individual value, otherwise they are = impossible to distinguish, and a positional index is inadequate. So we = convert the array into a dictionary and this then becomes a composite = attribute using dot notation for the key.

Multi-valued = attribute:

Key: = "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any = arbitrarily deep resource structure. We can refer to every leaf value = with a key that is the fully-qualified name using dot = notation.

The verbs are just unambiguous operations on these (now) explicitly = addressable attributes.

INCLUDE to a collection = and specify only the value. The key is generated and returned. The = fully-qualified key is = <collection-name>.<newly-generated-ID> and the value is what = was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If = the key doesn't exist, return a "404 Not = Found".

PLACE a value at the logical location = implied by the fully-qualified key. If there is already a key with that = name, return a "409 Conflict".

FORCE the fully-qualified key to hold the given = value, regardless of whether it existed before or not. Only errors = possible are "400 Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its = fully-qualified key. The implementation will determine whether the = attribute will disappear entirely or will exist holding a null value = (the blank string "" or the empty object {} ).

I'll explain in a separate post why we need = operation verbs like these that are independent of the HTTP = verbs.

Regards,
Ganesh

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

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil = Hunt)


---------- Forwarded message ----------
From: Phil Hunt = <phil.hunt@oracle.com>
To: Ganesh and = Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudiway.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" = <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] = SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your = example you are conflating value with an attribute id. I find that = confusing. 

I agree though that operations in patch could be a = lot more explicit. 

Eg explicitly deleting = a value by saying delete or = retire. 

Phil

On 2012-08-10, at 16:19, = Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am concerned about your second = suggestion: 

Let's discuss that = now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to = manipulate resources becomes so much cleaner, consistent and intuitive = when every individual attribute value gets its own = ID.

Here's how to delete a single member from a Group, as per the current = spec:

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com=

   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the = current spec:

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com=

   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very = intuitive. 
With my suggestion, here's how to delete a = single member from a group:

= PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
= "operations" : [
= {
= "RETIRE" : {
= "key" : "members.2819c2= 23-7f76-453a-919d-413861904646"
= }
= }
= ] }
Here's how I suggest deleting ALL members from a = group:

= PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
= "operations" : [
= {
= "RETIRE" : {
= "key" : "members"
= }
= }
= ] }

I'm sure you'll agree that this is simpler, more = consistent and more intuitive to a reader.

Pro = 2: We can apply this mechanism consistently to three = areas:
(a) Manipulating multi-valued attributes of a = resource
(b) Manipulating members of a group
(c) Performing bulk = operations, where we simply use HTTP verbs instead of the specialised = (and semantically less ambiguous) verbs I suggested for attributes, the = "key" becomes the URI, and the "value" becomes the corresponding JSON = object.

All of them return "207 Multi-Status" with the = "results" array holding individual status = codes.

In the current spec, (a) and (b) are = done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely = to be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to = implement because they have no legacy. They will probably use some form = of NoSQL database and won't be constrained by the limitations of LDAP = directories.

Cons:

Con 1: Incumbent = cloud providers with existing data stores in a directory format (where = multi-valued attributes are stored as comma-separated values under a = single attribute node) will find it difficult to migrate to this model = and store each attribute value as a sub-node with its own key. This will = "hinder adoption of the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm = biased of course, so I could have missed a Con or hyped a Pro = :-).

In other words, we're debating interface complexity = (current spec) versus implementation complexity (my suggestion). Both = can hinder adoption of the spec by different parties.

Here's what we need to discuss - Do the Pros make = the suggestion worth adopting in spite of the Cons, or are the Cons so = great that it's best to leave the spec as it = is?

Keep in mind that a complex spec that only favours incumbent cloud = providers can cut both ways. It opens the door to a simpler interface = offered by a new generation of nimbler SPs that don't have the same = legacy issues, and there could be an exodus of clients to these new SPs. = SCIM could end up being obsoleted very soon, because the API interface = is very complex and clumsy, as any new reader can attest. I was taken = aback by the complexity when I saw it, which is why I was prompted to = suggest something simpler.

This is an issue where we need the opinions of many = people, and they need to state their affiliations. If most people = weighing in belong to incumbent SPs and they vote in favour of interface = complexity to avoid implementation complexity, then it means the spec is = not doing a good job of balancing the interests of various groups. I = think we should also poll client organisations to see what they would = want.

(Gartner is trusted by enterprise clients to = evaluate the capabilities of vendors (SPs). I believe Gartner should = take the lead in representing client interests in this working group = rather than those of incumbent vendors, which is what it seems like to = me. Correct me if I'm being unfair.)
=

Regards,
Ganesh



=
On 11 August 2012 01:35, Diodati,Mark <Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

 

I am concerned about your second suggestion:

=932. When dealing with multi-valued attributes of = a resource (expressed as arrays in JSON), they must be converted from an = array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is = created). Without unique keys for every attribute value of a resource, = manipulating it will be clumsy and inelegant.=94

 

One of the primary reasons that SPML failed was = lack of adoption by service providers due to its complexity. Very few = target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface = (either v1 or v2), but not one of them was conformant to the SPML = standard because of complexity. If you are interested, I will forward = you the research documents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial = target applications (i.e., service providers). I am confident that a = requirement for unique identifiers with multi-valued attributes will = preclude its adoption, because it requires major changes to the service provider=92s existing identity storage = mechanisms.

Mark

 
 
 

From: Trey Drake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil = Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Ganesh,

 

I'll base my comments on your latest reply = (below).  

 

The externalID is not part of the protocol. =  It is an *optional* attribute within the *schema* specification. =  As for #2, the protocol spec works as you describe if "arbitrary = URI parameters" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please = clarify your suggestion.

 

I'm not tracking your coupling concern. =  The client can search and hence retrieve resources on any = attribute it chooses, externalId or otherwise.  Nothing mandates = use of externalId.   

 
 

What do you mean by "candidate key"? =  Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and = Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling. = [...] IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying = "tight coupling =3D=3D simple" and "loose coupling =3D=3D complex". = That's contrary to my experience.

 

When I say "loose coupling", I mean "no = unnecessary dependencies". Invariably, a reduction in dependencies leads = to greater simplicity.

 

Let's not confuse reduction of dependencies = in the data model with a hub-and-spokes architecture. They're entirely = orthogonal aspects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the = protocol.

2. Allow generic search using 'GET /Users' = and arbitrary URI parameters

 

No planned functionality is lost by = this.

 

1. The client enterprise can still send its = internal ID as part of the resource body, inside some attribute defined = by them (but not defined by the protocol). Let's say they call it = 'myID'.

2. The client enterprise can search for = resource URIs using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server = will return exactly one URI, which is the canonical URI for the = resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413=
861904646
3. The =
client can use this URI to perform all other operations as =
usual.
 
So taking =
'externalID' out of the protocol spec only does this:
1. It =
avoids enshrining tight coupling in the protocol (If clients want to =
tightly couple themselves to the cloud provider by sending their =
internal IDs, they can do so. Suicide is OK, but the protocol should not =
be guilty of assisted suicide. ;-)
2. It =
encourages loose coupling by nudging clients towards maintaining their =
own internal-to-external identifier mappings.
 
That's =
what I'd like to see. I don't believe this complicates the protocol. It =
simplifies it and it also lends itself to a loosely-coupled =
approach.
 
I'll =
address the multi-valued attribute suggestion separately.
 
Regards,
Ganesh
 
 
 
 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution.  Part of the key here is that = SCIM is just a piece of the architecture for this solution, and is only = responsible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I = provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not = more.

 

What the SCIM spec needs to do there is just = refrain from introducing tight coupling. I would like to see a single = identifier exposed through the API, with the implication (and perhaps = the recommendation) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight = coupling and ensures that both domains need simultaneously split or = merge identities, which is not desirable. So I recommend _taking out_ = the "external id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their = internal ids as part of the resource body, no one can stop them, and = they can always do a search on that attribute to retrieve the URI = exactly as you visualise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim = gets its current simplicity from its single owner hub spoke model = implementing tight coupling. 

 

IMHO loose coupling is a much more complex = solution. The reality is that each end-point has value to contribute and = thus the single-owner model will eventually need to become multi-owner = or multi-hub. 

 

That said i think the current model provides = a practical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 


Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle = <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting = a user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  = "urn:scim:schemas:extension:federation:1.0": {

    "linkedUsers": = [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  = "urn:scim:schemas:extension:federation:1.0": {

    "linkedUsers": = [

      {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 
 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  = "urn:scim:schemas:extension:federation:1.0": {

    "linkedUsers": = [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      },

      {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      }

    ]

  }

}

 
 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems.  IMO = the value gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of = ids. This fits your requirements as it hides internal = ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 = 78 17 58

Mobile: +33 6 47 = 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the first.

1.      Why should domains not expose their internal identifiers to = other domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are = notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or = similar attributes. The front-end application may make an intelligent (but = incorrect) guess that these two persons are the same, and re-assign the = same identifier to the second person. This is a false positive. They = appear to be the same entity, but they're actually different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be = treated as two different customers and assigned two unique identifiers. This is = a false negative. They appear to be two entities, but are actually the = same. At a later stage, when the error is discovered, the identities = will have to be merged, and one of the identifiers will have to be dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing external = identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenient time = (importantly, this doesn't have to be at the time the split happens), = Domain 2 can be requested to provision a second entity, and when it = responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the second entity's = internal identifier.

The = mapping table now contains the following entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be = unambi

=
__________= _____________________________________

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

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

= --Apple-Mail=_99F4E03B-9CD5-4CE1-846C-33C1DB268D26-- From trey.drake@unboundid.com Sat Aug 11 08:37:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7D21F8585 for ; Sat, 11 Aug 2012 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFp0RLTTdyFz for ; Sat, 11 Aug 2012 08:37:05 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBEA321F8498 for ; Sat, 11 Aug 2012 08:37:04 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4639147obb.31 for ; Sat, 11 Aug 2012 08:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=pCVAXuk9BgfIwGIJ0zd9MO9OgL8sZUE+SsQAVe2DVMk=; b=fWjwqla9LrqNbBARFsFLEBRHUE6MHmPWQ67IgMnNFxPnbo2sVINF2Becarnbc2xOmc Hh4OaBxiOP3JSr7MZrhIfaIyFVKymaUwLyiv15FV/aYAbvhAnFA2hj6pMuJOAbIJB+/4 0tREL1UqdPqFYLd5uCXydbkNIHARQrRZDO4IrZSQkph1kLTiRvxh7k1EqSVXFxmF4bjq aZfzcCA8Yq3Ti2f/tCgcyb2Er3wnDnMyV0KM28Ly2YzFYEam10v5xQXnF5+yQx8GFY24 jMzAYHItvC6GPmGxO7N3mj7W/dOvXXh+0DoWVpzvTcqrTn7gcrtfie12fOXAfWE7RMnt ZuIA== Received: by 10.60.8.71 with SMTP id p7mr5416568oea.56.1344699424237; Sat, 11 Aug 2012 08:37:04 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id l9sm1255269oeg.3.2012.08.11.08.37.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 08:37:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DED0DF71-B24D-4893-B215-600F6BDCD6FA" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: Date: Sat, 11 Aug 2012 10:37:03 -0500 Message-Id: <6E9D2F48-003F-40EA-B5FB-05033ADBA957@unboundid.com> References: To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQkreLMM3Iwz1LlkB4HFRUdoJK7qjQG/pKr/QtNHaNKXPCf0bdbCACbtbcMrNJkzSj8WYYJi Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 29 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:37:15 -0000 --Apple-Mail=_DED0DF71-B24D-4893-B215-600F6BDCD6FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It seems to me you are missing context. Discussions on SPML, and for = that matter other schemes, have been had and documented (look over = chartering slides, email threads, BoF script, as well as the numerous = blog posts that have been written about SCIM). =20 On Aug 11, 2012, at 4:00 AM, Ganesh and Sashi Prasad = wrote: > A couple of you have mentioned the failure of SPML, with conjectures = as to why it failed. Let me share my experience with it. >=20 > I tried to implement an SPML-based provisioning system 3-4 years ago = and gave up, not because of a lack of language features but simply = because I found the messages were too heavyweight for something that was = just a shell. There was little attention paid to the data model (a = common failing in many protocol designs, IMO). The payload was the real = thing, and that was entirely the organisation's responsibility. >=20 > I finally designed a provisioning scheme with specific attention to = data, that was loosely-coupled and idempotent, and which (most = importantly) worked. It's described on pages 124-128 of my eBook . >=20 > So yes, SPML failed, but the lessons I drew from that are quite = different from what others seem to be drawing. The spec needs to deliver = value, and that was what was missing in SPML. >=20 > My two cents. >=20 > Regards, > Ganesh >=20 > On 11 August 2012 15:22, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: scim Digest, Vol 8, Issue 26 (Trey Drake) > 2. Re: scim Digest, Vol 8, Issue 26 (Richard Sand) >=20 >=20 > ---------- Forwarded message ---------- > From: Trey Drake > To: Ganesh and Sashi Prasad > Cc: "scim@ietf.org" > Date: Fri, 10 Aug 2012 23:55:14 -0500 > Subject: Re: [scim] scim Digest, Vol 8, Issue 26 > I believe Mark's comments are sound as they speak directly to the = failure of SPML viz. lessons learned. Since inception, SCIM has had an = eye towards easing the pain for SPs. History has proven that failure to = do so may result in a technically solid spec with zero adoption. =20 >=20 >=20 > On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad = wrote: >=20 >> Ganesh - we are all participating as individuals in IETF. Maybe you = should consult the rules for working groups as explained in: >>=20 >> http://tools.ietf.org/pdf/rfc2418.pdf >>=20 >> It is irrelevant whether you belong to a very large technology = company, or are a technology analyst or whether you are just a great = guy/gal.=20 >>=20 >> All the discussion has to be in the open and all sources (no = confidential research reports!) have to be publicly made available. >>=20 >> - prateek >>=20 >> Fair enough. I was just concerned listening to Mark's comments (about = adoption being hindered because of complexity for SPs), that one = interest group may have undue influence over the WG. if that's not the = case, I'm happy :-). >>=20 >> Regards, >> Ganesh >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > ---------- Forwarded message ---------- > From: Richard Sand > To: Trey Drake , Ganesh and Sashi Prasad = > Cc: scim@ietf.org > Date: Sat, 11 Aug 2012 01:22:37 -0400 > Subject: Re: [scim] scim Digest, Vol 8, Issue 26 > I=92d like to jump in here too in support of Mark=92s comments. I see = many on the SCIM list who were former members or contributors to the = OASIS PSTC and the failings of SPML should be well know. What SPML = failed to do was provide a simple language for specific tasks =96 if a = company just needed to set up an endpoint to enable/disable accounts or = perform password resets, SPML was not purpose-build for this, and set = requirements conformance that made it ill-suited towards one-off usage = as a tool to solve a specific integration problem. SCIM as it is now = addresses some of these shortcomings =96 it does not require much of a = burden to the SP, it language handles identity management requirements = at a slightly higher level than just directory-style object-crud = operations. So I would not deviate from these principles, as lack of = them did in what was otherwise a useful and functional spec in SPML. >=20 > =20 > Standard Schema of course is another topic that SPML never adequately = addressed. >=20 > =20 > Richard Sand | Managing Director=20 > PO Box 91824 | Austin | Texas 78709-1824 | USA=20 > Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754 > Mobile: +1 267 984 3651 > >=20 > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Trey Drake > Sent: Saturday, August 11, 2012 12:55 AM > To: Ganesh and Sashi Prasad > Cc: scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 26 >=20 > =20 > I believe Mark's comments are sound as they speak directly to the = failure of SPML viz. lessons learned. Since inception, SCIM has had an = eye towards easing the pain for SPs. History has proven that failure to = do so may result in a technically solid spec with zero adoption. =20 >=20 > =20 >=20 > On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi Prasad = wrote: >=20 > Ganesh - we are all participating as individuals in IETF. Maybe you = should consult the rules for working groups as explained in: >=20 > http://tools.ietf.org/pdf/rfc2418.pdf >=20 > It is irrelevant whether you belong to a very large technology = company, or are a technology analyst or whether you are just a great = guy/gal.=20 >=20 > All the discussion has to be in the open and all sources (no = confidential research reports!) have to be publicly made available. >=20 > - prateek >=20 > Fair enough. I was just concerned listening to Mark's comments (about = adoption being hindered because of complexity for SPs), that one = interest group may have undue influence over the WG. if that's not the = case, I'm happy :-). >=20 > =20 > Regards, >=20 > Ganesh >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_DED0DF71-B24D-4893-B215-600F6BDCD6FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 It = seems to me you are missing context.  Discussions on SPML, and for = that matter other schemes, have been had and documented (look over = chartering slides, email threads, BoF script, as well as the numerous = blog posts that have been written about SCIM). =  

On Aug 11, 2012, at 4:00 AM, Ganesh and = Sashi Prasad <g.c.prasad@gmail.com> = wrote:

A couple of you have mentioned the failure of SPML, = with conjectures as to why it failed. Let me share my experience with = it.

I tried to implement an SPML-based = provisioning system 3-4 years ago and gave up, not because of a lack of = language features but simply because I found the messages were too = heavyweight for something that was just a shell. There was little = attention paid to the data model (a common failing in many protocol = designs, IMO). The payload was the real thing, and that was = entirely the organisation's responsibility.

I finally designed a provisioning scheme with = specific attention to data, that was loosely-coupled and idempotent, and = which (most importantly) worked. It's described on pages 124-128 of = my eBook .

So yes, SPML failed, but the lessons I drew from = that are quite different from what others seem to be drawing. The spec = needs to deliver value, and that was what was missing in = SPML.

My two = cents.

Regards,
Ganesh

On 11 August 2012 15:22, <scim-request@ietf.org> wrote:
If you have received = this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: scim Digest, Vol 8, Issue 26 (Trey Drake)
   2. Re: scim Digest, Vol 8, Issue 26 (Richard Sand)


---------- Forwarded message ----------
From: Trey Drake = <trey.drake@unboundid.com><= br>To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "scim@ietf.org" <scim@ietf.org>
Date: Fri, = 10 Aug 2012 23:55:14 -0500
Subject: Re: [scim] scim Digest, Vol = 8, Issue 26
I believe Mark's comments are sound as they speak directly to the = failure of SPML viz. lessons learned.  Since inception, SCIM has = had an eye towards easing the pain for SPs.  History has proven = that failure to do so may result in a technically solid spec with zero = adoption.  


On Aug 10, 2012, at 10:23 PM, Ganesh and Sashi = Prasad <g.c.prasad@gmail.com> = wrote:

Ganesh = - we are all participating as individuals in IETF. Maybe you should consult the rules for working groups as explained in:

http://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology company, or are a technology analyst or whether you are just a great guy/gal.

All the discussion has to be in the open and all sources (no confidential research reports!) have to be publicly made = available.

- prateek

Fair enough. I was just concerned = listening to Mark's comments (about adoption being hindered because of = complexity for SPs), that one interest group may have undue influence = over the WG. if that's not the case, I'm happy :-).

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


---------- Forwarded message = ----------
From: Richard Sand <rsand@idfoundry.com>
To: Trey Drake <trey.drake@unboundid.com>,= Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:&n= bsp;scim@ietf.org
Date: Sat, 11 Aug 2012 01:22:37 -0400
Subject: Re: [scim] = scim Digest, Vol 8, Issue 26

I=92d like to jump in here too in support of = Mark=92s comments. I see many on the SCIM list who were former members = or contributors to the OASIS PSTC and the failings of SPML should be = well know. What SPML failed to do was provide a simple language for = specific tasks =96 if a company just needed to set up an endpoint to = enable/disable accounts or perform password resets, SPML was not = purpose-build for this, and set requirements conformance that made it = ill-suited towards one-off usage as a tool to solve a specific = integration problem. SCIM as it is now addresses some of these = shortcomings =96 it does not require much of a burden to the SP, it = language handles identity management requirements at a slightly higher = level than just directory-style object-crud operations. So I would not = deviate from these principles, as lack of them did in what was otherwise = a useful and functional spec in SPML.

 

Standard Schema of course is another topic that = SPML never adequately addressed.

 

Richard Sand | Managing Director
PO Box 91824 | Austin | Texas 78709-1824 | USA =
Office: +1 888 612 8820 ext 02 | = Fax: +1 866 304 3754
Mobile: +1 267 984 3651
<image001.jpg>

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Trey = Drake
Sent: Saturday, August 11, 2012 12:55 AM
To: Ganesh and = Sashi Prasad
Cc: scim@ietf.org
Subject: Re: [scim] scim = Digest, Vol 8, Issue 26

 

I believe Mark's comments are sound as they speak = directly to the failure of SPML viz. lessons learned.  Since = inception, SCIM has had an eye towards easing the pain for SPs. =  History has proven that failure to do so may result in a = technically solid spec with zero adoption.  

 


On Aug 10, 2012, = at 10:23 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

Ganesh - we are all participating as individuals in IETF. Maybe you = should consult the rules for working groups as explained in:

http://tools.ietf.org/pdf/rfc2418.pdf

It is irrelevant whether you belong to a very large technology = company, or are a technology analyst or whether you are just a great = guy/gal.

All the discussion has to be in the open and all = sources (no confidential research reports!) have to be publicly made = available.

- prateek

Fair enough. I = was just concerned listening to Mark's comments (about adoption being = hindered because of complexity for SPs), that one interest group may = have undue influence over the WG. if that's not the case, I'm happy = :-).

 

Regards,

Ganesh

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


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


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

= --Apple-Mail=_DED0DF71-B24D-4893-B215-600F6BDCD6FA-- From g.c.prasad@gmail.com Sat Aug 11 08:50:48 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138521F8510 for ; Sat, 11 Aug 2012 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fQ5vHk652kD for ; Sat, 11 Aug 2012 08:50:44 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9A3A21F8532 for ; Sat, 11 Aug 2012 08:50:41 -0700 (PDT) Received: by bkty7 with SMTP id y7so1058396bkt.31 for ; Sat, 11 Aug 2012 08:50: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:from:date:message-id:subject:to :cc:content-type; bh=xvQ00Zo8vStBe9r88QbHMBklYJR0w0IX8maup9llgeA=; b=Ve9yKx3xhr2yFJVoUg46j6B/5YL3qGBihzRSVmlorg0/QBNiP86UjzMegmB1IArfi/ blOGby2sTy+kpWT0m7T8gbPARSRWp5fBW00i/BbGfb8nkR/3ol4/mPjsj0VDLMfE76Th MOzK+Hb/6hoZ8u+mY7JYfQ8R2D/y8QEE93y1sqaG2R++dNhs5lKuRV3NJ+4lMLvq2fZn K/PJVBmCwcsx+2zV7BTk58QevJCpozWWPTxS40nSdyn7CnrCcaOpwj0Ggh4XK5D9deuo WDX9pZ3SFyr08AzQjXS9nmTwLX2LtoYPXnzG4bQAKpr3oagfgBQxL5uC7ghgBmWiiUBL KAEQ== Received: by 10.204.154.211 with SMTP id p19mr2472469bkw.12.1344700240165; Sat, 11 Aug 2012 08:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 08:50:19 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 01:50:19 +1000 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175cd13024fc4b04c6ff6c63 Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:50:48 -0000 --0015175cd13024fc4b04c6ff6c63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Phil, The reason we cannot use the value itself to identify an element is that this method will only work for simple elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for each customer, with each address element having sub-elements like street number, street name, suburb, etc.), then it would be clumsy to supply the entire value of the array element because it's itself a dictionary. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt wrote: > Ganesh, > > Here's the sample that concerned me... > > The two operations differ significantly, and it's not very intuitive. > With my suggestion, here's how to delete a single member from a group: > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] } > > > > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys. > > Given that multi-values must be each unique, I don't see the point of the > extra indexing to support this. Just use the value as the item you wish t= o > delete. > > I agree, the delete value operation could be more explicit and clear in > general. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > > > For the multi-value example you gave you used the value as the > attribute name key. > > Now I'm confused :-). I don't believe any of my examples ever used a valu= e > as the key. > > Could you please show me which example you mean, and which parts of it yo= u > believe to be the value? > > Regards, > Ganesh > > On 11 August 2012 13:59, Phil Hunt wrote: > >> >> For the multi-value example you gave you used the value as the attribute >> name key. >> >> That means a lot more complex indexing structure. Better to just say >> delete a specific value. >> >> The spec already allows multiple values to have tags like home, work, et= c. >> >> Phil >> >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >> wrote: >> >> > In your example you are conflating value with an attribute id. >> >> I don't believe so. >> >> I'm adopting a model where every attribute of the resource is a key-valu= e >> pair. The key is a name or ID. >> >> For non-repeating attributes (both simple and composite), the key is the >> attribute name itself. >> >> Simple attribute: >> >> Key: "dob" >> Value: "01 Jan 1970" >> >> For composite attributes, the key employs dot notation to specify the >> fully-qualified attribute name, e.g., "address.postcode". >> >> Composite attribute: >> >> Key: "address.street-number" >> Value: "10" >> >> Key: "address.suburb" >> Value: "East Camden" >> >> For repeating (multi-valued) attributes, I'm suggesting that there be ne= w >> keys for each individual value, otherwise they are impossible to >> distinguish, and a positional index is inadequate. So we convert the arr= ay >> into a dictionary and this then becomes a composite attribute using dot >> notation for the key. >> >> Multi-valued attribute: >> >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >> Value: "john_smith@yahoo.com" >> >> So this allows us to apply uniform treatment to any arbitrarily deep >> resource structure. We can refer to every leaf value with a key that is = the >> fully-qualified name using dot notation. >> >> The verbs are just unambiguous operations on these (now) explicitly >> addressable attributes. >> >> INCLUDE to a collection and specify only the value. The key is generated >> and returned. The fully-qualified key is >> . and the value is what was specifi= ed >> in the INCLUDE. >> >> REPLACE a fully-qualified key with a new value. If the key doesn't exist= , >> return a "404 Not Found". >> >> PLACE a value at the logical location implied by the fully-qualified key= . >> If there is already a key with that name, return a "409 Conflict". >> >> FORCE the fully-qualified key to hold the given value, regardless of >> whether it existed before or not. Only errors possible are "400 Bad >> Request" and "500 Internal Error". >> >> RETIRE an attribute or a collection given its fully-qualified key. The >> implementation will determine whether the attribute will disappear entir= ely >> or will exist holding a null value (the blank string "" or the empty obj= ect >> {} ). >> >> I'll explain in a separate post why we need operation verbs like these >> that are independent of the HTTP verbs. >> >> Regards, >> Ganesh >> >> On 11 August 2012 10:38, wrote: >> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send scim mailing list submissions to >>> scim@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/scim >>> or, via email, send a message with subject or body 'help' to >>> scim-request@ietf.org >>> >>> You can reach the person managing the list at >>> scim-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of scim digest..." >>> >>> Today's Topics: >>> >>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Phil Hunt >>> To: Ganesh and Sashi Prasad >>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>> edreux@cloudiway.com>, Trey Drake , Kelly >>> Grizzle , "scim@ietf.org" >>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>> Ganesh, >>> >>> In your example you are conflating value with an attribute id. I find >>> that confusing. >>> >>> I agree though that operations in patch could be a lot more explicit. >>> >>> Eg explicitly deleting a value by saying delete or retire. >>> >>> Phil >>> >>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >>> wrote: >>> >>> > I am concerned about your second suggestion: >>> >>> Let's discuss that now. >>> >>> The trade-offs are very clear here. >>> >>> Pros: >>> >>> Pro 1. The API to manipulate resources becomes so much cleaner, >>> consistent and intuitive when every individual attribute value gets its= own >>> ID. >>> >>> Here's how to delete a single member from a Group, as per the current >>> spec: >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>> >>> { >>> "schemas": ["urn:scim:schemas:core:1.0"], >>> "members": [ >>> { >>> "display": "Babs Jensen", >>> "value": "2819c223-7f76-453a-919d-413861904646" >>> "operation": "delete" >>> } >>> ] >>> } >>> >>> >>> Here's how to delete ALL members from a group according to the current >>> spec: >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>> Host: example.com >>> Accept: application/json >>> Authorization: Bearer h480djs93hd8 >>> ETag: W/"a330bc54f0671c9" >>> >>> { >>> "schemas": ["urn:scim:schemas:core:1.0"], >>> "meta": { >>> "attributes": [ >>> "members" >>> ] >>> } >>> } >>> >>> >>> The two operations differ significantly, and it's not very intuitive. >>> With my suggestion, here's how to delete a single member from a group: >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" { >>> "operations" : [ >>> { >>> "RETIRE" : { >>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>> } >>> } >>> ] } >>> Here's how I suggest deleting ALL members from a group: >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" { >>> "operations" : [ >>> { >>> "RETIRE" : { >>> "key" : "members" >>> } >>> } >>> ] } >>> >>> I'm sure you'll agree that this is simpler, more consistent and more >>> intuitive to a reader. >>> >>> Pro 2: We can apply this mechanism consistently to three areas: >>> (a) Manipulating multi-valued attributes of a resource >>> (b) Manipulating members of a group >>> (c) Performing bulk operations, where we simply use HTTP verbs instead >>> of the specialised (and semantically less ambiguous) verbs I suggested = for >>> attributes, the "key" becomes the URI, and the "value" becomes the >>> corresponding JSON object. >>> >>> All of them return "207 Multi-Status" with the "results" array holding >>> individual status codes. >>> >>> In the current spec, (a) and (b) are done similarly but (c) is very >>> different. >>> >>> Pro 3: Adoption of the standard by clients is likely to be higher >>> because it's simpler for them. >>> >>> Pro 4: New (not incumbent) cloud providers will probably find this >>> easier to implement because they have no legacy. They will probably use >>> some form of NoSQL database and won't be constrained by the limitations= of >>> LDAP directories. >>> >>> Cons: >>> >>> Con 1: Incumbent cloud providers with existing data stores in a >>> directory format (where multi-valued attributes are stored as >>> comma-separated values under a single attribute node) will find it >>> difficult to migrate to this model and store each attribute value as a >>> sub-node with its own key. This will "hinder adoption of the spec", whi= ch >>> is what you fear. >>> >>> Have I summed up the Pros and Cons correctly? I'm biased of course, so = I >>> could have missed a Con or hyped a Pro :-). >>> >>> In other words, we're debating interface complexity (current spec) >>> versus implementation complexity (my suggestion). Both can hinder adopt= ion >>> of the spec by different parties. >>> >>> Here's what we need to discuss - Do the Pros make the suggestion worth >>> adopting in spite of the Cons, or are the Cons so great that it's best = to >>> leave the spec as it is? >>> >>> Keep in mind that a complex spec that only favours incumbent cloud >>> providers can cut both ways. It opens the door to a simpler interface >>> offered by a new generation of nimbler SPs that don't have the same leg= acy >>> issues, and there could be an exodus of clients to these new SPs. SCIM >>> could end up being obsoleted very soon, because the API interface is ve= ry >>> complex and clumsy, as any new reader can attest. I was taken aback by = the >>> complexity when I saw it, which is why I was prompted to suggest someth= ing >>> simpler. >>> >>> This is an issue where we need the opinions of many people, and they >>> need to state their affiliations. If most people weighing in belong to >>> incumbent SPs and they vote in favour of interface complexity to avoid >>> implementation complexity, then it means the spec is not doing a good j= ob >>> of balancing the interests of various groups. I think we should also po= ll >>> client organisations to see what they would want. >>> >>> (Gartner is trusted by enterprise clients to evaluate the capabilities >>> of vendors (SPs). I believe Gartner should take the lead in representin= g >>> client interests in this working group rather than those of incumbent >>> vendors, which is what it seems like to me. Correct me if I'm being unf= air.) >>> >>> Regards, >>> Ganesh >>> >>> >>> >>> On 11 August 2012 01:35, Diodati,Mark wrote: >>> >>>> Hi Ganesh, >>>> >>>> >>>> I am concerned about your second suggestion: >>>> >>>> =932. When dealing with multi-valued attributes of a resource (express= ed >>>> as arrays in JSON), they must be converted from an array into a dictio= nary >>>> with unique keys (UUIDs generated by the cloud provider when the attri= bute >>>> is created). Without unique keys for every attribute value of a resour= ce, >>>> manipulating it will be clumsy and inelegant.=94 >>>> >>>> >>>> One of the primary reasons that SPML failed was lack of adoption by >>>> service providers due to its complexity. Very few target applications >>>> implemented SPML. Most of the commercial provisioning systems had an S= PML >>>> interface (either v1 or v2), but not one of them was conformant to the= SPML >>>> standard because of complexity. If you are interested, I will forward = you >>>> the research documents that discuss these problems in detail. For SCIM= to >>>> be successful, it must be adopted by commercial target applications (i= .e., >>>> service providers). I am confident that a requirement for unique >>>> identifiers with multi-valued attributes will preclude its adoption, >>>> because it requires major changes to the service provider=92s existing >>>> identity storage mechanisms. >>>> >>>> Mark >>>> >>>> >>>> >>>> >>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>> >>>> *To:* Ganesh and Sashi Prasad >>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>> >>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>> >>>> >>>> >>>> Ganesh, >>>> >>>> >>>> I'll base my comments on your latest reply (below). >>>> >>>> >>>> The externalID is not part of the protocol. It is an *optional* >>>> attribute within the *schema* specification. As for #2, the protocol = spec >>>> works as you describe if "arbitrary URI parameters" equate to resource >>>> attributes (Allow generic search using 'GET /Users' and arbitrary URI >>>> parameters). Please clarify your suggestion. >>>> >>>> >>>> I'm not tracking your coupling concern. The client can search and >>>> hence retrieve resources on any attribute it chooses, externalId or >>>> otherwise. Nothing mandates use of externalId. >>>> >>>> >>>> >>>> What do you mean by "candidate key"? Given >>>> >>>> >>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>> g.c.prasad@gmail.com> wrote: >>>> >>>> > I think scim gets its current simplicity from its single owner hub >>>> spoke model implementing tight coupling. [...] IMHO loose coupling is = a >>>> much more complex solution. >>>> >>>> >>>> Phil, >>>> >>>> >>>> I'm a bit surprised that you're implying "tight coupling =3D=3D simple= " and >>>> "loose coupling =3D=3D complex". That's contrary to my experience. >>>> >>>> >>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>> Invariably, a reduction in dependencies leads to greater simplicity. >>>> >>>> >>>> Let's not confuse reduction of dependencies in the data model with a >>>> hub-and-spokes architecture. They're entirely orthogonal aspects of th= e >>>> solution. >>>> >>>> >>>> All that my suggestion involves is, >>>> >>>> >>>> 1. Take 'external ID' out of the protocol. >>>> >>>> 2. Allow generic search using 'GET /Users' and arbitrary URI parameter= s >>>> >>>> >>>> No planned functionality is lost by this. >>>> >>>> >>>> 1. The client enterprise can still send its internal ID as part of the >>>> resource body, inside some attribute defined by them (but not defined = by >>>> the protocol). Let's say they call it 'myID'. >>>> >>>> 2. The client enterprise can search for resource URIs using any >>>> attribute, including this internal ID >>>> >>>> 'GET /Users?myID=3Dbjensen' >>>> >>>> Since myID is a candidate key, the server will return exactly one URI, >>>> which is the canonical URI for the resource >>>> >>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>> >>>> 3. The client can use this URI to perform all other operations as usua= l. >>>> >>>> >>>> >>>> So taking 'externalID' out of the protocol spec only does this: >>>> >>>> 1. It avoids enshrining tight coupling in the protocol (If clients wan= t to tightly couple themselves to the cloud provider by sending their inter= nal IDs, they can do so. Suicide is OK, but the protocol should not be guil= ty of assisted suicide. ;-) >>>> >>>> 2. It encourages loose coupling by nudging clients towards maintaining= their own internal-to-external identifier mappings. >>>> >>>> >>>> >>>> That's what I'd like to see. I don't believe this complicates the prot= ocol. It simplifies it and it also lends itself to a loosely-coupled approa= ch. >>>> >>>> >>>> >>>> I'll address the multi-valued attribute suggestion separately. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Ganesh >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>> >>>> >>>> >>>> Phil >>>> >>>> >>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>>> wrote: >>>> >>>> > storing this information in a mapping table outside of the SCIM >>>> spec is a great way to enable this solution. Part of the key here is = that >>>> SCIM is just a piece of the architecture for this solution, and is onl= y >>>> responsible for the transport layer between domains. >>>> >>>> I wasn't suggesting that the mapping table be part of the SCIM spec. I >>>> provided that example to illustrate that splitting and merging identit= ies >>>> is a common requirement, and that decoupling local identifiers within = a >>>> domain from shared identifiers between domains was the best way to >>>> facilitate it. >>>> >>>> >>>> I'm suggesting that the spec do less, not more. >>>> >>>> >>>> What the SCIM spec needs to do there is just refrain from introducing >>>> tight coupling. I would like to see a single identifier exposed throug= h the >>>> API, with the implication (and perhaps the recommendation) that it be = the >>>> shared one. Allowing one domain to expose its internal identifier to t= he >>>> other creates tight coupling and ensures that both domains need >>>> simultaneously split or merge identities, which is not desirable. So I >>>> recommend _taking out_ the "external id" field from the API. The spec >>>> shouldn't encourage tight coupling. If clients want to pass in their >>>> internal ids as part of the resource body, no one can stop them, and t= hey >>>> can always do a search on that attribute to retrieve the URI exactly a= s you >>>> visualise they will with the "external id", but let's not elevate an >>>> anti-pattern to a recommendation by enshrining the "external id" as an >>>> acceptable attribute. >>>> >>>> >>>> Am I making sense? >>>> >>>> >>>> >>>> I see what you are saying. I think scim gets its current simplicity >>>> from its single owner hub spoke model implementing tight coupling. >>>> >>>> >>>> IMHO loose coupling is a much more complex solution. The reality is >>>> that each end-point has value to contribute and thus the single-owner = model >>>> will eventually need to become multi-owner or multi-hub. >>>> >>>> >>>> That said i think the current model provides a practical starting >>>> point. >>>> >>>> >>>> >>>> > Regarding unique identifiers for multi-valued attributes there is a >>>> trade-off involved. On one hand this makes PATCH semantics easier. O= n the >>>> other hand it puts extra burden on service providers. >>>> >>>> >>>> Precisely. The spec has to strike the right balance. It would be >>>> interesting to hear from the other members of the spec mailing list. Y= ou >>>> know where I stand on this. It would be good to hear the spectrum of >>>> opinions. >>>> >>>> >>>> Regards, >>>> >>>> Ganesh >>>> >>>> On 10 August 2012 00:28, Kelly Grizzle >>>> wrote: >>>> >>>> Thanks Emmanuel. I had started writing up a similar response. As you >>>> suggest, storing this information in a mapping table outside of the SC= IM >>>> spec is a great way to enable this solution. Part of the key here is = that >>>> SCIM is just a piece of the architecture for this solution, and is onl= y >>>> responsible for the transport layer between domains. >>>> >>>> >>>> You could also model these ID mappings in the SCIM user as an extensio= n >>>> but would probably not want to expose these externally. Here is an ex= ample >>>> of how to model the end state of the false positive scenario (splittin= g a >>>> user): >>>> >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>> true | >>>> >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>> true | >>>> >>>> >>>> This could be represented as two SCIM users that contain information >>>> about the entities on other domains. >>>> >>>> >>>> { >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"], >>>> >>>> "id": "9caf78aac3d6", >>>> >>>> "userName": "John Smith", >>>> >>>> "urn:scim:schemas:extension:federation:1.0": { >>>> >>>> "linkedUsers": [ >>>> >>>> { >>>> >>>> "domain": "D2", >>>> >>>> "externalEntityId": "ff487230b3a0" >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> { >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"], >>>> >>>> "id": "a99a5feba839", >>>> >>>> "userName": "John Smith", >>>> >>>> "urn:scim:schemas:extension:federation:1.0": { >>>> >>>> "linkedUsers": [ >>>> >>>> { >>>> >>>> "domain": "D2", >>>> >>>> "externalEntityId": "7a87f27c1dd8" >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> In the second user, the linkedUsers attribute would be empty until the >>>> split user was synced to domain 2. >>>> >>>> >>>> >>>> Similarly, the false negative use case (merging two users) looked like >>>> this at the end: >>>> >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>> true | >>>> >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>> false | >>>> >>>> >>>> This could be represented with the following SCIM user: >>>> >>>> >>>> { >>>> >>>> "schemas": ["urn:scim:schemas:core:1.0", >>>> "urn:scim:schemas:extension:federation:1.0"], >>>> >>>> "id": "9caf78aac3d6", >>>> >>>> "userName": "John Smith", >>>> >>>> "urn:scim:schemas:extension:federation:1.0": { >>>> >>>> "linkedUsers": [ >>>> >>>> { >>>> >>>> "domain": "D2", >>>> >>>> "externalEntityId": "ff487230b3a0" >>>> >>>> }, >>>> >>>> { >>>> >>>> "domain": "D2", >>>> >>>> "externalEntityId": "41206cc97c8b", >>>> >>>> "deletionRequired": true >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> Regarding unique identifiers for multi-valued attributes there is a >>>> trade-off involved. On one hand this makes PATCH semantics easier. O= n the >>>> other hand it puts extra burden on service providers. Since the incep= tion >>>> of SCIM, a key goal has been to foster adoption by service providers b= y >>>> making things fit easily onto existing systems. IMO the value gained = by >>>> unique identifiers for multi-valued attributes is not worth the demand= s put >>>> on a service provider. I also think that vendors that have a >>>> non-SCIM-compliant API will choose to keep things that way if the spec= is >>>> too hard for them to implement. In a green field environment we do ha= ve >>>> the luxury of mandating a model to make certain operations more elegan= t. >>>> However, we can=92t ignore legacy systems. >>>> >>>> >>>> --Kelly >>>> >>>> >>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>> Behalf Of *Emmanuel Dreux >>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>> *Cc:* scim@ietf.org >>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>> >>>> >>>> Hi Ganesh, >>>> >>>> >>>> Nothing prevents you in your SCIM implementation (client or server) to >>>> generate a unique identifier for each synchronized object and maintain= an >>>> internal mapping table ( you would have to map group membership as wel= l). >>>> >>>> >>>> This is what we are doing with Active Directory sources or targets: >>>> >>>> As we didn=92t find an immutable uniqueID in AD systems >>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can ch= ange >>>> if an AD domain is migrated), we decided to generate and maintain an >>>> internal table of ids. This fits your requirements as it hides interna= l ids. >>>> >>>> >>>> This was written in dotnet and we have started a project to rewrite ou= r >>>> SCIM stack in PHP and will give it to the Open Source community. This >>>> implementation will have a parameter : AllocateIds versus UseExistingI= Ds. >>>> >>>> This will give the choice of =93hiding=94 internalIDs or use them as u= nique >>>> ID. >>>> >>>> >>>> You can also implement such feature without violating the SCIM specs, >>>> or without asking to include it in the specs. >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Emmanuel Dreux >>>> >>>> http://www.cloudiway.com >>>> >>>> Tel: +33 4 26 78 17 58 >>>> >>>> Mobile: +33 6 47 81 26 70 >>>> >>>> skype: Emmanuel.Dreux >>>> >>>> >>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>> >>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>> *=C0 :* Kelly Grizzle >>>> *Cc :* scim@ietf.org >>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>> >>>> >>>> Hi Kelly, >>>> >>>> Thanks for your response. Let me first respond in brief to the two mai= n >>>> points you have made, and then elaborate on the first. >>>> >>>> 1. Why should domains not expose their internal identifiers to >>>> other domains? >>>> >>>> a. >>>> >>>> We are designing a protocol for a federated system of domains, where >>>> all domains are co-equal peers. (In physics too, N-body problems are m= uch >>>> harder than 2-body problems. :-) Therefore, assuming that there are on= ly >>>> two players in the interaction makes this tightly coupled in a number = of >>>> ways. We should rely on messaging and notification, with encapsulation= of >>>> domain-specific data. >>>> >>>> b. >>>> >>>> In any non-trivial data store, there will always be the ongoing need t= o >>>> merge and split identities as and when =93false negatives=94 and =93fa= lse >>>> positives=94 are discovered. A domain should be able to handle this in= ternal >>>> housekeeping freely, only notifying other domains when convenient. Map= ping >>>> of internal identifiers to external ones and maintaining this mapping >>>> internally allows this loosely-coupled housekeeping to take place. Sha= ring >>>> internal identifiers (or otherwise outsourcing the mapping of internal= to >>>> external identifiers) forces housekeeping activities to be done in >>>> lock-step across domains. >>>> >>>> c. >>>> >>>> Asynchronous interaction is not just a matter of a suitable wire >>>> protocol which can be designed later. The data model plays a crucial r= ole >>>> in enabling or constraining such interaction. A tightly-coupled data m= odel >>>> will force the use of synchronous interactions, and the exposure of >>>> internal identifiers is a key part of this tight coupling. >>>> >>>> 2. The difficulty of assigning unique identifiers to the individual >>>> values of multi-valued attributes: >>>> >>>> a. >>>> >>>> I'm not belittling the effort involved in migrating legacy data stores >>>> to such a model. However, in the larger historical context of cross-do= main >>>> identity management, we are really at the very early stages. If a >>>> relatively new discipline and a brand new spec are held captive to leg= acy >>>> considerations, we are losing an opportunity to provide a clean and el= egant >>>> model to subsequent users of the spec, and this will have repercussion= s >>>> over many years or even decades. >>>> >>>> b. >>>> >>>> If incumbent cloud providers find it hard to immediately adopt the >>>> dictionary model for existing multi-valued attributes, they can transi= tion >>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-co= mpliant=94 >>>> APIs to their customers and encouraging new customers to adopt the >>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradua= lly >>>> migrated to the SCIM-compliant API. The logistics are not insurmountab= le, >>>> and shouldn't prevent the adoption of a dictionary model for multi-val= ued >>>> attributes. >>>> >>>> Elaboration of Point 1: >>>> >>>> When we consider federated identity across more than one domain, we >>>> have to assume that domains are not necessarily master-slave in their >>>> interaction. The most generic interaction model is peer-to-peer, where >>>> entity lifecycle events within a domain are notified to other domains = (when >>>> necessary) in an asynchronous manner (i.e., through messaging) and the >>>> other domains are free to respond to these events in an appropriate ma= nner >>>> and at a time of their convenience. >>>> >>>> A key set of lifecycle events for an entity is the merging and >>>> splitting of identity that is often required. >>>> >>>> The question =93Is this one entity?=94 can be answered either yes >>>> (positive) or no (negative). But sometimes, we can discover false posi= tives >>>> and false negatives in our data stores. >>>> >>>> Consider a case where customers sign up online, and two customers who >>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and als= o use the >>>> same date of birth (say, 1 Jan 1970) or similar attributes. The front-= end >>>> application may make an intelligent (but incorrect) guess that these t= wo >>>> persons are the same, and re-assign the same identifier to the second >>>> person. This is a false positive. They appear to be the same entity, b= ut >>>> they're actually different. When the error is discovered, the identiti= es >>>> will need to be split, with a new identifier generated for one of them= . >>>> >>>> Consider the opposite case where a customer signs up through two >>>> different portals or in two different sessions, using the names =93JSm= ith=94 >>>> and =93JohnS=94. It is very likely that they will be treated as two di= fferent >>>> customers and assigned two unique identifiers. This is a false negativ= e. >>>> They appear to be two entities, but are actually the same. At a later >>>> stage, when the error is discovered, the identities will have to be me= rged, >>>> and one of the identifiers will have to be dropped. >>>> >>>> These are not theoretical use cases. They form a significant proportio= n >>>> of the user base in most large Web-facing applications. Let's see how = these >>>> can be managed in a federated way by mapping internal identifiers to >>>> external ones and only exposing external identifiers to other domains. >>>> >>>> a. False positives: >>>> >>>> Domain 1 has the following information about a customer in its data >>>> store: >>>> >>>> Internal ID: 9caf78aac3d6 >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> >>>> When requesting the provisioning of this entity in Domain 2, the >>>> following ID is returned by Domain 2: ff487230b3a0. >>>> >>>> Domain 1 then maintains the following in a mapping table and uses it >>>> for translation when talking to Domain 2, taking care never to expose = its >>>> internal identifier: >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> >>>> When the false positive is discovered and the entity is split, Domain = 1 >>>> creates a new internal identifier and now has the following entity >>>> information. >>>> >>>> Internal ID: 9caf78aac3d6 >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> >>>> Internal ID: a99a5feba839 >>>> >>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>> >>>> This second entity with its own internal identifier is invisible to >>>> Domain 2, and this is by design. Communication about the original enti= ty >>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0= =94 and >>>> vice-versa. At some convenient time (importantly, this doesn't have to= be >>>> at the time the split happens), Domain 2 can be requested to provision= a >>>> second entity, and when it responds with an identifier of =937a87f27c1= dd8=94, >>>> this can go into the mapping table as a new record associated with the >>>> second entity's internal identifier. >>>> >>>> The mapping table now contains the following entries: >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>> >>>> Domain 2 is not even aware that a split has happened, and the >>>> provisioning that it does is not in lockstep with the split in identit= y >>>> that occurred in Domain 1. >>>> >>>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>>> treatment of false negatives.) >>>> >>>> b. False negatives: >>>> >>>> Domain 1 has the following information about what it thinks are two >>>> distinct customers in its data store: >>>> >>>> Internal ID: 9caf78aac3d6 >>>> >>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>> >>>> Internal ID: 273d36e30d09 >>>> >>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>> >>>> When requesting the provisioning of these entities in Domain 2, the >>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>>> >>>> Domain 1 then maintains the following in a mapping table and uses it >>>> for translation when talking to Domain 2, taking care never to expose = its >>>> internal identifiers: >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> >>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>> >>>> When the false negative is discovered and the two entities are merged, >>>> Domain 1 drops one of the internal identifiers and rationalises the na= me of >>>> the customer (say, to =93John Smith=94). Let's say it retains the firs= t ID >>>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>> >>>> The mapping table now looks like this: >>>> >>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>> Primary flag | >>>> >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>> >>>> Now two external identifiers map to the same internal one, so inbound >>>> communication from Domain 2 can be unambi >>>> >>> _______________________________________________ >> >> 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 > > > --0015175cd13024fc4b04c6ff6c63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Phil,

The reason we cannot use the value itself to ident= ify an element is that this method will only work for simple elements, not = for nested structures. i.e., if we had an array of dictionaries (e.g., we h= ad to record an array of addresses for each customer, with each address ele= ment having sub-elements like street number, street name, suburb, etc.), th= en it would be clumsy to supply the entire value of the array element becau= se it's itself a dictionary. Creating a unique key for each element sca= les better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> wrote:
Ganesh,<= div>
Here's the sample that concerned me...
The two operations differ significantly, and= it's not very intuitive.=A0
With my suggestion, here's h= ow to delete a single member from a group:

PATCH= /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }


<= /div>
You gave other examples of an attribute with an identifier that m= atched that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don= 't see the point of the extra indexing to support this. Just use the va= lue as the item you wish to delete.

I agree, the delete value operation could be more = explicit and clear in general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:
>=A0 For the multi-value example you gave you used the value as the attribute na= me key.=A0

Now I'm confused :-). I don't believe= any of my examples ever used a value as the key.

Could you please show me which example you mean, and which parts of it you = believe to be the value?

Regards,
Ganesh= =A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wrote:

For the mu= lti-value example you gave you used the value as the attribute name key.=A0=

That means a lot more complex indexing structure. Bette= r to just say delete a specific value.=A0

The spec= already allows multiple values to have tags like home, work, etc.

Phil

On 2012-08-10, at= 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.=A0<= br>
I don't believe so.

I'm adopting a model = where every attribute of the resource is a key-value pair. The key is a nam= e or ID.

For non-repeating attributes (both simple and composite= ), the key is the attribute name itself.=A0

S= imple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite= attributes, the key employs dot notation to specify the fully-qualified at= tribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-num= ber"
Value: "10"

Key: &qu= ot;address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting = that there be new keys for each individual value, otherwise they are imposs= ible to distinguish, and a positional index is inadequate. So we convert th= e array into a dictionary and this then becomes a composite attribute using= dot notation for the key.

Multi-valued attribute:

Key: &= quot;emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: &qu= ot;john_smith@yah= oo.com"

So this allows us to apply uniform treatment to any arb= itrarily deep resource structure. We can refer to every leaf value with a k= ey that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and = specify only the value. The key is generated and returned. The fully-qualif= ied key is <collection-name>.<newly-generated-ID> and the value= is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the = key doesn't exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualifi= ed key. If there is already a key with that name, return a "409 Confli= ct".

FORCE the fully-qualified key to hold the given value, = regardless of whether it existed before or not. Only errors possible are &q= uot;400 Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualifie= d key. The implementation will determine whether the attribute will disappe= ar entirely or will exist holding a null value (the blank string "&quo= t; or the empty object {} ).

I'll explain in a separate post why we need operati= on verbs like these that are independent of the HTTP verbs.

<= /div>
Regards,
Ganesh

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

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.co= m>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sai= lpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Proto= col - 3 suggestions for improvement
G= anesh,

In your example you are conflating value wi= th an attribute id. I find that confusing.=A0

I agree though that operations in patch could be a lot = more explicit.=A0

Eg explicitly deleting a value b= y saying delete or retire.=A0

Phil

On 2012-08-1= 0, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I = am concerned about your second suggestion:=A0

Let= 's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipu= late resources becomes so much cleaner, consistent and intuitive when every= individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current s= pec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to th= e current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3=
f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very in= tuitive.=A0
With my suggestion, here's how to delete a single= member from a group:

PATCH /Groups/acbf3ae7-846= 3-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more c= onsistent and more intuitive to a reader.

Pro 2: W= e can apply this mechanism consistently to three areas:
(a) Manip= ulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk oper= ations, where we simply use HTTP verbs instead of the specialised (and sema= ntically less ambiguous) verbs I suggested for attributes, the "key&qu= ot; becomes the URI, and the "value" becomes the corresponding JS= ON object.

All of them return "207 Multi-Status" with th= e "results" array holding individual status codes.

=
In the current spec, (a) and (b) are done similarly but (c) is v= ery different.

Pro 3: Adoption of the standard by clients is likely to= be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to im= plement because they have no legacy. They will probably use some form of No= SQL database and won't be constrained by the limitations of LDAP direct= ories.

Cons:

Con 1: Incumbent cloud p= roviders with existing data stores in a directory format (where multi-value= d attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each attrib= ute value as a sub-node with its own key. This will "hinder adoption o= f the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm b= iased of course, so I could have missed a Con or hyped a Pro :-).

=
In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make t= he suggestion worth adopting in spite of the Cons, or are the Cons so great= that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, a= nd there could be an exodus of clients to these new SPs. SCIM could end up = being obsoleted very soon, because the API interface is very complex and cl= umsy, as any new reader can attest. I was taken aback by the complexity whe= n I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peo= ple, and they need to state their affiliations. If most people weighing in = belong to incumbent SPs and they vote in favour of interface complexity to = avoid implementation complexity, then it means the spec is not doing a good= job of balancing the interests of various groups. I think we should also p= oll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate t= he capabilities of vendors (SPs). I believe Gartner should take the lead in= representing client interests in this working group rather than those of i= ncumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.)

Regards,
Ganesh



<= div class=3D"gmail_quote">On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned abou= t your second suggestion:

=932. When dea= ling with multi-valued attributes of a resource (expressed as arrays in JSO= N), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary = reasons that SPML failed was lack of adoption by service providers due to i= ts complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Drake [mailto:trey.drake@unboundi= d.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ie= tf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

= Ganesh,

=A0

I'll base my comments on your latest reply = (below). =A0

=A0

The externalID is not part of the protocol. =A0= It is an *optional* attribute within the *schema* specification. =A0As for = #2, the protocol spec works as you describe if "arbitrary URI paramete= rs" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0= The client can search and hence retrieve resources on any attribute it choo= ses, externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0=

=A0
=A0

What do you mean by "candidate key"? = =A0Given=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sas= hi Prasad <g.c= .prasad@gmail.com> wrote:

>=A0 I think = scim gets its current simplicity from its single owner hub spoke model impl= ementing tight coupling. [...]=A0IMHO loose coupling is a much more complex= solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implyin= g "tight coupling =3D=3D simple" and "loose coupling =3D=3D = complex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean &= quot;no unnecessary dependencies". Invariably, a reduction in dependen= cies leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies= in the data model with a hub-and-spokes architecture. They're entirely= orthogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protoc= ol.

2. Allow generic search using 'GET /Users&#= 39; and arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its int= ernal ID as part of the resource body, inside some attribute defined by the= m (but not defined by the protocol). Let's say they call it 'myID&#= 39;.

2. The client enterprise can search for resourc= e URIs using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will = return exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0
=A0


On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com=
> wrote:








Phil








On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:






>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0











I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.


=A0




I'm suggesting that the spec do less, not m=
ore.


=A0


What the SCIM spec needs to do there is just re=
frain from introducing tight coupling. I would like to see a single identif=
ier exposed through the API, with the implication (and perhaps the recommen=
dation) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.




=A0




Am I making sense?








=A0




I see what you are saying. I think scim gets i=
ts current simplicity from its single owner hub spoke model implementing ti=
ght coupling.=A0


=A0




IMHO loose coupling is a much more complex solu=
tion. The reality is that each end-point has value to contribute and thus t=
he single-owner model will eventually need to become multi-owner or multi-h=
ub.=A0












=A0




That said i think the current model provides a =
practical starting point.=A0












=A0




>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0






Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.












=A0




Regards,




Ganesh


On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@=
sailpoint.com> wrote:




Thanks Emmanuel.=A0 =
I had started writing up a similar response.=A0 As you suggest, storing thi=
s information in a mapping table outside of the SCIM spec
 is a great way to enable this solution.=A0 Part of the key here is that SC=
IM is just a piece of the architecture for this solution, and is only respo=
nsible for the transport layer between domains.
=A0



You could also mode=
l these ID mappings in the SCIM user as an extension but would probably not=
 want to expose these externally.=A0 Here is an example
 of how to model the end state of the false positive scenario (splitting a =
user):


=A0
| Internal Entity ID | External Domain ID | External Entity ID =
| Primary flag |



| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |
|=
 a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |=




=A0


This could be repre=
sented as two SCIM users that contain information about the entities on oth=
er domains.



=A0
=
{



=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=




=A0 "id": "9caf78aac3d6",=

=A0 "userName": "Jo=
hn Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=
=A0=A0=A0=A0 }



=A0=A0=A0 ]
=
=A0 }



}
=A0
<=
p class=3D"MsoNormal">

{
=A0 "schemas": [=
"urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed=
eration:1.0"],



=A0 "id": "a99a5feba839",=

=A0 "userName": "Jo=
hn Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"
=A0=
=A0=A0=A0=A0 }



=A0=A0=A0 ]
=
=A0 }



}
=
=A0



In the second user,=
 the linkedUsers attribute would be empty until the split user was synced t=
o domain 2.



=A0
=A0



Similarly, the fals=
e negative use case (merging two users) looked like this at the end:=





=A0
| Internal Entity ID | External Domain ID | External Entity ID =
| Primary flag |



| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |
|=
 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0 | false=A0=A0=A0=A0=A0=A0=A0 |



=A0


This could be repre=
sented with the following SCIM user:
=A0



{
=A0 "schemas": ["urn:scim:schemas:core:1.0", "u=
rn:scim:schemas:extension:federation:1.0"],



=A0 "id": "9caf78aac3d6",=

=A0 "userName": "Jo=
hn Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=
=A0=A0=A0=A0 },



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",
=
=A0=A0=A0=A0=A0=A0=A0 "deletionRequired": true



=A0=A0=A0=A0=A0 }
=A0=A0=A0 ]



=A0 }
}



=A0
=A0



Regarding unique id=
entifiers for multi-valued attributes there is a trade-off involved.=A0 On =
one hand this makes PATCH semantics easier.=A0 On the other
 hand it puts extra burden on service providers.=A0 Since the inception of =
SCIM, a key goal has been to foster adoption by service providers by making=
 things fit easily onto existing systems.=A0 IMO the value gained by unique=
 identifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.

=A0
--Kelly



=A0




From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








=A0
Hi Ganesh,
=
=A0



Nothing prevents yo=
u in your SCIM implementation (client or server) to generate a unique ident=
ifier for each synchronized object and maintain an
 internal mapping table ( you would have to map group membership as well).<=
/span>
=A0


This is what we are doing with Active Directory =
sources or targets:
As we didn=92t find an immutable uniqueID in AD systems (DN,samAccount=
Name, UPN) are subject to change (even objectGuid can change if an AD domai=
n
 is migrated), we decided to generate and maintain an internal table of ids=
. This fits your requirements as it hides internal ids.
=A0



This was written in=
 dotnet and we have started a project to rewrite our SCIM stack in PHP and =
will give it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.
This will give the choice of =
=93hiding=94 internalIDs or use them as unique ID.



=A0
=
You can also implement such feature without viol=
ating the SCIM specs, or without asking to include it in the specs.<=
/p>


=A0
=
--



Regards,
Emmanue=
l Dreux



http://www.cloudiway.com



Tel:
+33 4 26 78=
 17 58
Mobile:
+33 6 47 81=
 26 70
skype: Emmanuel.Dreux



=A0


De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement


=A0
Hi Kelly,
Thanks for y=
our response. Let me first respond in brief to the two main points you have=
 made, and then elaborate on the first.




1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.

We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.
<=
p style=3D"margin-right:0in;margin-bottom:0in;margin-left:18.15pt;margin-bo=
ttom:.0001pt">


b. 

In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.

2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:

a. 

I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=





b. 

If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.
Elaboration of Point 1:


When we consider federated identity across more than one =
domain, we have to assume that domains are not necessarily master-slave in =
their interaction. The most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.
A key set of lifecycle events for an entity is=
 the merging and splitting of identity that is often required.


The question =93Is this one entity?=94 can be answered ei=
ther yes (positive) or no (negative). But sometimes, we can discover false =
positives and false negatives in our data stores.


Consider a case where customers sign up online, and two c=
ustomers who are privacy-conscious enter fake IDs such as =93John Smith=94,=
 and also use the same date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.
Consider the op=
posite case where a customer signs up through two different portals or in t=
wo different sessions, using the names =93JSmith=94 and =93JohnS=94. It is =
very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.
These are not theoretical use cases. They f=
orm a significant proportion of the user base in most large Web-facing appl=
ications. Let's see how these can be managed in a federated way by mapp=
ing
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.
a. False positives:


Domain 1 has the following information about a customer i=
n its data store:
Internal ID: 9caf78aac3d6


Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=
=94}
When requesting the provisioning of this entity in Domain 2, the=
 following ID is returned by Domain 2: ff487230b3a0.



Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | D2 | ff487230b3a0 | true |
When the false posit=
ive is discovered and the entity is split, Domain 1 creates a new internal =
identifier and now has the following entity information.



Inte=
rnal ID: 9caf78aac3d6
Attributes: {name: =93John Smith=94, dob: =9301=
-Jan-1970=94}



Inte=
rnal ID: a99a5feba839
Attributes: {name: =93John Smith=94, dob: =9301=
-Jan-1970=94}



This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.
The mapping table now contains the following ent=
ries:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | D2 | ff487230b3a0 | true |
| a99a5feba839 | D2 | 7a87f27c1dd=
8 | true |



Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.



(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. False negatives:
Domain 1 has the following info=
rmation about what it thinks are two distinct customers in its data store:<=
/span>



Inte=
rnal ID: 9caf78aac3d6
Attributes: {name: =93JSmith=94, dob: =9301-Jan=
-1970=94}



Inte=
rnal ID: 273d36e30d09
Attributes: {name: =93JohnS=94, dob: =9301-Jan-=
1970=94}



When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Domain 1 then maintains the following in a mapping table =
and uses it for translation when talking to Domain 2, taking care never to =
expose its internal identifiers:


| Internal Entity ID | External Domain ID | External Entity ID | Prima=
ry flag |
| 9caf78aac3d6 | D2 | ff487230b3a0 | true |



| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When the false negative is discovered and the two entitie=
s are merged, Domain 1 drops one of the internal identifiers and rationalis=
es the name of the customer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.
The mapping table now looks like this:


| Internal Entity ID | External Domain ID | External Entity ID | Prima=
ry flag |
| 9caf78aac3d6 | D2 | ff487230b3a0 | true |



| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now two external identifiers map to the same internal one=
, so inbound communication from Domain 2 can be unambi
_____________= __________________________________

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


--0015175cd13024fc4b04c6ff6c63-- From trey.drake@unboundid.com Sat Aug 11 08:59:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA33921F8619 for ; Sat, 11 Aug 2012 08:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cITXV+Bnxy6k for ; Sat, 11 Aug 2012 08:59:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0EA21F8617 for ; Sat, 11 Aug 2012 08:59:25 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so4664692obb.31 for ; Sat, 11 Aug 2012 08:59:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=NTzMMUcLlnRn3aF7RQW2xZS9tI3H1Pi15KRXRqrum1U=; b=gYx0dbaN2QqU5KqoLP9Hd290ELoPp1XBJign/WeXq4zQfHO4Dr/CJcyDQh7GcG2Zzh pCpXjYrEsRFjlphkmPJlXNYTaSCr1sR9fzGx5a+cJDwIVZOjtMJ+e4kBKjleY5ow2rkh HgX+SBiu7bnSB4elblhrYPtKP9iWItDI84ruIvRs6l5BzSenfJg0Gdy5NYVuNnAQbrkP zew9l3c3+5WKBHvjFJlVAx8oU7OoS4F+EkhmyPl2G5Nw+/B4nLkr6draVAkgePgFg67u EmRJySYNInYPCl05kNVgBc1IhHGfwv7ZU3nbnW8HthFrzwFtdfeurC7Fsa9z7NRi1AgT BCMA== Received: by 10.60.19.161 with SMTP id g1mr4181167oee.42.1344700764851; Sat, 11 Aug 2012 08:59:24 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id cp8sm1727198obc.23.2012.08.11.08.59.23 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Aug 2012 08:59:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A466ADB4-6404-4AEC-8254-67425D367603" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: Date: Sat, 11 Aug 2012 10:59:23 -0500 Message-Id: <5159F724-D64F-470C-900A-D7B17A7BC6A5@unboundid.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQnpJ2yTAZMEiO4Shku/8Ysrk6fVMNdXbc7xmkFI2q0x3HAhMB5RyJVwVQQg4upFpZk3p3W/ Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle , Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 15:59:30 -0000 --Apple-Mail=_A466ADB4-6404-4AEC-8254-67425D367603 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 10, 2012, at 5:38 PM, Ganesh and Sashi Prasad = wrote: > Trey, >=20 > > The externalID is not part of the protocol. It is an *optional* = attribute within the *schema* specification. >=20 > I didn't realise SCIM was also specifying a User schema. Does this = mean the User resource can only hold certain attributes as defined by = this schema? If so, that's going to be a severe constraint, because = client organisations are likely to require many specialised User = attributes depending on the nature of their business, and they will = expect to be able to store all of them, not just the subset defined by = the SCIM spec. I hope the SCIM User schema is not trying to be just a = representation of inetOrgPerson (the standard LDAP schema), because that = could be severely limiting. Most organisations with their own LDAP end = up extending inetOrgPerson, and they will expect that they can do the = same in the cloud. >=20 I recommend you read the relevant specifications. The working group has = accepted both a schema and protocol draft as input to the effort.=20 > > As for #2, the protocol spec works as you describe if "arbitrary URI = parameters" equate to resource attributes=20 >=20 > Yes, that's what I meant, but in implementation, it may work out to be = looser than that. The client should be able to specify any arbitrary = attribute in the search parameters, even those that aren't attributes of = the resource. If an attribute is not defined, or if the attribute exists = but the value doesn't match any stored record, the SP will return no = results. In the former case, it's a "400 Bad Request" and in the latter, = it's a "404 Not Found". And that's because? I don't see any value to the behavior (enabling = attribute searches on non-existent schema) you suggest.=20 >=20 > By "candidate key" (a data modelling term), I meant another attribute = that also uniquely identifies a single record, but is not the official = "primary key", i.e., the main ID. In this case, a client's internal = identifier also uniquely identifies a record, but is not the ID used in = the URI of RESTful operations. I know what a candidate key is. My question is why do you believe an SP = ought to care about "candidate keys"? Resources are uniquely = identified exactly 1 way by the SP and that is by the SP minted id. The = Consumer can retrieve a resource by any attribute though only the id is = guaranteed to be unique from the POV of the SP. The SCIM model is a = *mapping* between the consumer and SP hence it is not a prescription for = how the Resource data is actually stored on either side. =20 >=20 > Look, this may seem to be splitting hairs since a determined client = may be able to store and search by their own internal ID in either case = (the current SCIM spec or my suggestion). The difference is = philosophical. If the spec is showing how clients can store their = internal IDs in the cloud by explicitly providing for such an attribute, = that constitutes bad advice, IMO. If it turns a blind eye to what they = store and they store internal IDs anyway, they're constraining = themselves but the spec comes out smelling of roses because that's not = "recommended practice". >=20 If externalId were dropped it wouldn't bother me a bit. =20 > Ganesh >=20 > On 11 August 2012 00:50, Trey Drake wrote: > Ganesh, >=20 > I'll base my comments on your latest reply (below). =20 >=20 > The externalID is not part of the protocol. It is an *optional* = attribute within the *schema* specification. As for #2, the protocol = spec works as you describe if "arbitrary URI parameters" equate to = resource attributes (Allow generic search using 'GET /Users' and = arbitrary URI parameters). Please clarify your suggestion. >=20 > I'm not tracking your coupling concern. The client can search and = hence retrieve resources on any attribute it chooses, externalId or = otherwise. Nothing mandates use of externalId. =20 >=20 >=20 > What do you mean by "candidate key"? Given=20 >=20 > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad = wrote: > > I think scim gets its current simplicity from its single owner hub = spoke model implementing tight coupling. [...] IMHO loose coupling is a = much more complex solution. >=20 > Phil, >=20 > I'm a bit surprised that you're implying "tight coupling =3D=3D = simple" and "loose coupling =3D=3D complex". That's contrary to my = experience. >=20 > When I say "loose coupling", I mean "no unnecessary dependencies". = Invariably, a reduction in dependencies leads to greater simplicity. >=20 > Let's not confuse reduction of dependencies in the data model with a = hub-and-spokes architecture. They're entirely orthogonal aspects of the = solution. >=20 > All that my suggestion involves is, >=20 > 1. Take 'external ID' out of the protocol. > 2. Allow generic search using 'GET /Users' and arbitrary URI = parameters >=20 > No planned functionality is lost by this. >=20 > 1. The client enterprise can still send its internal ID as part of the = resource body, inside some attribute defined by them (but not defined by = the protocol). Let's say they call it 'myID'. > 2. The client enterprise can search for resource URIs using any = attribute, including this internal ID > 'GET /Users?myID=3Dbjensen' > Since myID is a candidate key, the server will return exactly one URI, = which is the canonical URI for the resource > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 > 3. The client can use this URI to perform all other operations as = usual. >=20 > So taking 'externalID' out of the protocol spec only does this: > 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not = be guilty of assisted suicide. ;-) > 2. It encourages loose coupling by nudging clients towards maintaining = their own internal-to-external identifier mappings. >=20 > That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled = approach. >=20 > I'll address the multi-valued attribute suggestion separately. >=20 > Regards, > Ganesh >=20 >=20 >=20 >=20 > On 10 August 2012 07:53, Phil Hunt wrote: >=20 >=20 > Phil >=20 > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >=20 >> > storing this information in a mapping table outside of the SCIM = spec is a great way to enable this solution. Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between domains.=20 >>=20 >> I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it. >>=20 >> I'm suggesting that the spec do less, not more. >>=20 >> What the SCIM spec needs to do there is just refrain from introducing = tight coupling. I would like to see a single identifier exposed through = the API, with the implication (and perhaps the recommendation) that it = be the shared one. Allowing one domain to expose its internal identifier = to the other creates tight coupling and ensures that both domains need = simultaneously split or merge identities, which is not desirable. So I = recommend _taking out_ the "external id" field from the API. The spec = shouldn't encourage tight coupling. If clients want to pass in their = internal ids as part of the resource body, no one can stop them, and = they can always do a search on that attribute to retrieve the URI = exactly as you visualise they will with the "external id", but let's not = elevate an anti-pattern to a recommendation by enshrining the "external = id" as an acceptable attribute. >>=20 >> Am I making sense? >=20 > I see what you are saying. I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling.=20 >=20 > IMHO loose coupling is a much more complex solution. The reality is = that each end-point has value to contribute and thus the single-owner = model will eventually need to become multi-owner or multi-hub.=20 >=20 > That said i think the current model provides a practical starting = point.=20 >>=20 >> > Regarding unique identifiers for multi-valued attributes there is = a trade-off involved. On one hand this makes PATCH semantics easier. = On the other hand it puts extra burden on service providers.=20 >>=20 >> Precisely. The spec has to strike the right balance. It would be = interesting to hear from the other members of the spec mailing list. You = know where I stand on this. It would be good to hear the spectrum of = opinions. >>=20 >> Regards, >> Ganesh >>=20 >> On 10 August 2012 00:28, Kelly Grizzle = wrote: >> Thanks Emmanuel. I had started writing up a similar response. As = you suggest, storing this information in a mapping table outside of the = SCIM spec is a great way to enable this solution. Part of the key here = is that SCIM is just a piece of the architecture for this solution, and = is only responsible for the transport layer between domains. >>=20 >> =20 >>=20 >> You could also model these ID mappings in the SCIM user as an = extension but would probably not want to expose these externally. Here = is an example of how to model the end state of the false positive = scenario (splitting a user): >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >>=20 >> =20 >>=20 >> This could be represented as two SCIM users that contain information = about the entities on other domains. >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "a99a5feba839", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "7a87f27c1dd8" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> In the second user, the linkedUsers attribute would be empty until = the split user was synced to domain 2. >>=20 >> =20 >>=20 >> =20 >>=20 >> Similarly, the false negative use case (merging two users) looked = like this at the end: >>=20 >> =20 >>=20 >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >>=20 >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>=20 >> | 9caf78aac3d6 | D2 | 41206cc97c8b | = false | >>=20 >> =20 >>=20 >> This could be represented with the following SCIM user: >>=20 >> =20 >>=20 >> { >>=20 >> "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"], >>=20 >> "id": "9caf78aac3d6", >>=20 >> "userName": "John Smith", >>=20 >> "urn:scim:schemas:extension:federation:1.0": { >>=20 >> "linkedUsers": [ >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "ff487230b3a0" >>=20 >> }, >>=20 >> { >>=20 >> "domain": "D2", >>=20 >> "externalEntityId": "41206cc97c8b", >>=20 >> "deletionRequired": true >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> =20 >>=20 >> Regarding unique identifiers for multi-valued attributes there is a = trade-off involved. On one hand this makes PATCH semantics easier. On = the other hand it puts extra burden on service providers. Since the = inception of SCIM, a key goal has been to foster adoption by service = providers by making things fit easily onto existing systems. IMO the = value gained by unique identifiers for multi-valued attributes is not = worth the demands put on a service provider. I also think that vendors = that have a non-SCIM-compliant API will choose to keep things that way = if the spec is too hard for them to implement. In a green field = environment we do have the luxury of mandating a model to make certain = operations more elegant. However, we can=92t ignore legacy systems. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Emmanuel Dreux >> Sent: Thursday, August 09, 2012 3:18 AM >> To: Ganesh and Sashi Prasad; Kelly Grizzle >> Cc: scim@ietf.org >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Ganesh, >>=20 >> =20 >>=20 >> Nothing prevents you in your SCIM implementation (client or server) = to generate a unique identifier for each synchronized object and = maintain an internal mapping table ( you would have to map group = membership as well). >>=20 >> =20 >>=20 >> This is what we are doing with Active Directory sources or targets: >>=20 >> As we didn=92t find an immutable uniqueID in AD systems = (DN,samAccountName, UPN) are subject to change (even objectGuid can = change if an AD domain is migrated), we decided to generate and maintain = an internal table of ids. This fits your requirements as it hides = internal ids. >>=20 >> =20 >>=20 >> This was written in dotnet and we have started a project to rewrite = our SCIM stack in PHP and will give it to the Open Source community. = This implementation will have a parameter : AllocateIds versus = UseExistingIDs. >>=20 >> This will give the choice of =93hiding=94 internalIDs or use them as = unique ID. >>=20 >> =20 >>=20 >> You can also implement such feature without violating the SCIM specs, = or without asking to include it in the specs. >>=20 >> =20 >>=20 >> -- >>=20 >> Regards, >>=20 >> Emmanuel Dreux >>=20 >> http://www.cloudiway.com >>=20 >> Tel: +33 4 26 78 17 58 >>=20 >> Mobile: +33 6 47 81 26 70 >>=20 >> skype: Emmanuel.Dreux >>=20 >> =20 >>=20 >> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 >> =C0 : Kelly Grizzle >> Cc : scim@ietf.org >> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> Hi Kelly, >> Thanks for your response. Let me first respond in brief to the two = main points you have made, and then elaborate on the first. >> 1. Why should domains not expose their internal identifiers to = other domains? >> a. >> We are designing a protocol for a federated system of domains, where = all domains are co-equal peers. (In physics too, N-body problems are = much harder than 2-body problems. :-) Therefore, assuming that there are = only two players in the interaction makes this tightly coupled in a = number of ways. We should rely on messaging and notification, with = encapsulation of domain-specific data. >> b. >> In any non-trivial data store, there will always be the ongoing need = to merge and split identities as and when =93false negatives=94 and = =93false positives=94 are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when = convenient. Mapping of internal identifiers to external ones and = maintaining this mapping internally allows this loosely-coupled = housekeeping to take place. Sharing internal identifiers (or otherwise = outsourcing the mapping of internal to external identifiers) forces = housekeeping activities to be done in lock-step across domains. >> c. >> Asynchronous interaction is not just a matter of a suitable wire = protocol which can be designed later. The data model plays a crucial = role in enabling or constraining such interaction. A tightly-coupled = data model will force the use of synchronous interactions, and the = exposure of internal identifiers is a key part of this tight coupling. >> 2. The difficulty of assigning unique identifiers to the individual = values of multi-valued attributes: >> a. >> I'm not belittling the effort involved in migrating legacy data = stores to such a model. However, in the larger historical context of = cross-domain identity management, we are really at the very early = stages. If a relatively new discipline and a brand new spec are held = captive to legacy considerations, we are losing an opportunity to = provide a clean and elegant model to subsequent users of the spec, and = this will have repercussions over many years or even decades. >> b. >> If incumbent cloud providers find it hard to immediately adopt the = dictionary model for existing multi-valued attributes, they can = transition to this model by offering both =93SCIM-compliant=94 and = =93non-SCIM-compliant=94 APIs to their customers and encouraging new = customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be = supported using a =93non-SCIM-compliant=94 API for an arbitrarily long = period and gradually migrated to the SCIM-compliant API. The logistics = are not insurmountable, and shouldn't prevent the adoption of a = dictionary model for multi-valued attributes. >> Elaboration of Point 1: >> When we consider federated identity across more than one domain, we = have to assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where = entity lifecycle events within a domain are notified to other domains = (when necessary) in an asynchronous manner (i.e., through messaging) and = the other domains are free to respond to these events in an appropriate = manner and at a time of their convenience. >> A key set of lifecycle events for an entity is the merging and = splitting of identity that is often required. >> The question =93Is this one entity?=94 can be answered either yes = (positive) or no (negative). But sometimes, we can discover false = positives and false negatives in our data stores. >> Consider a case where customers sign up online, and two customers who = are privacy-conscious enter fake IDs such as =93John Smith=94, and also = use the same date of birth (say, 1 Jan 1970) or similar attributes. The = front-end application may make an intelligent (but incorrect) guess that = these two persons are the same, and re-assign the same identifier to the = second person. This is a false positive. They appear to be the same = entity, but they're actually different. When the error is discovered, = the identities will need to be split, with a new identifier generated = for one of them. >> Consider the opposite case where a customer signs up through two = different portals or in two different sessions, using the names =93JSmith=94= and =93JohnS=94. It is very likely that they will be treated as two = different customers and assigned two unique identifiers. This is a false = negative. They appear to be two entities, but are actually the same. At = a later stage, when the error is discovered, the identities will have to = be merged, and one of the identifiers will have to be dropped. >> These are not theoretical use cases. They form a significant = proportion of the user base in most large Web-facing applications. Let's = see how these can be managed in a federated way by mapping internal = identifiers to external ones and only exposing external identifiers to = other domains. >> a. False positives: >> Domain 1 has the following information about a customer in its data = store: >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> When requesting the provisioning of this entity in Domain 2, the = following ID is returned by Domain 2: ff487230b3a0. >> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifier: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> When the false positive is discovered and the entity is split, Domain = 1 creates a new internal identifier and now has the following entity = information. >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> Internal ID: a99a5feba839 >> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >> This second entity with its own internal identifier is invisible to = Domain 2, and this is by design. Communication about the original entity = takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 = and vice-versa. At some convenient time (importantly, this doesn't have = to be at the time the split happens), Domain 2 can be requested to = provision a second entity, and when it responds with an identifier of = =937a87f27c1dd8=94, this can go into the mapping table as a new record = associated with the second entity's internal identifier. >> The mapping table now contains the following entries: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >> Domain 2 is not even aware that a split has happened, and the = provisioning that it does is not in lockstep with the split in identity = that occurred in Domain 1. >> (What is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.) >> b. False negatives: >> Domain 1 has the following information about what it thinks are two = distinct customers in its data store: >> Internal ID: 9caf78aac3d6 >> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >> Internal ID: 273d36e30d09 >> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >> When requesting the provisioning of these entities in Domain 2, the = following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >> Domain 1 then maintains the following in a mapping table and uses it = for translation when talking to Domain 2, taking care never to expose = its internal identifiers: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 273d36e30d09 | D2 | 41206cc97c8b | true | >> When the false negative is discovered and the two entities are = merged, Domain 1 drops one of the internal identifiers and rationalises = the name of the customer (say, to =93John Smith=94). Let's say it = retains the first ID =939caf78aac3d6=94 and drops the second = =93273d36e30d09=94. >> The mapping table now looks like this: >> | Internal Entity ID | External Domain ID | External Entity ID | = Primary flag | >> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >> Now two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to = look up the translation table to determine the =93primary=94 external ID = for this entity in Domain 2, which was decided to be =93ff487230b3a0=94. = That's where the =93Primary flag=94 comes in. The second external ID = =9341206cc97c8b=94 is never used thereafter in outbound communication. >> At some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be = removed once this is acknowledged. >> This scheme will scale up to multiple domains, because the =93External = Domain ID=94 column helps to keep track of which external ID is shared = with which Domain. (Why don't we use just one external ID for an entity = and share it with all external domains? Tight coupling again. Just as = OAuth allows an access token given to a third party to be invalidated = without affecting the access of other third parties, the use of separate = external identifiers for different domains allows fine-grained control = of identity federation.) >> The scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many = John Smiths there are who were born on 1 Jan 1970!) >> This is a fairly long-winded explanation, but this is why we need to = hide internal identifiers from other domains, and why mappings need to = be managed internally in each domain. Such a data model also allows us = to choose asynchronous protocols for propagation of identity events, = since there is no consistency requirement to update multiple domains = concurrently. >> Regards, >> Ganesh Prasad >> =20 >>=20 >> On 9 August 2012 04:55, Kelly Grizzle = wrote: >>=20 >> Thanks for the feedback, Ganesh. I read through this and your InfoQ = article (http://www.infoq.com/articles/scim-data-model-limitations) and = have some thoughts. >>=20 >> =20 >>=20 >> > The rest of the protocol does not meaningfully use the enterprise = client=92s identifier, the "external ID" >>=20 >> > at all, even though it was ostensibly introduced to make things = friendlier for the client. >>=20 >> =20 >>=20 >> The usage pattern for an external ID would be to search for a user by = externalId and use the ID of the returned user in any desired operation. = For example: >>=20 >> =20 >>=20 >> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did >>=20 >> =20 >>=20 >> { >>=20 >> =93totalResults=94: 1, >>=20 >> =93Resources=94: [ >>=20 >> { >>=20 >> =93id=94: =932819c223-7f76-453a-919d-413861904646=94 >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> =20 >>=20 >> Retrieve the ID from the response and use it. >>=20 >> =20 >>=20 >> DELETE /Users/2819c223-7f76-453a-919d-413861904646 >>=20 >> =20 >>=20 >> This does introduce an additional HTTP request if the client chooses = not to store the server=92s id. An issue was created to consider = allowing operations to use the externalId = (http://code.google.com/p/scim/issues/detail?id=3D35), but I believe the = general consensus has been to not include this in the spec. One main = point of contention is that much of the rest of the spec (eg =96 group = membership references, manager references, etc=85) require knowledge of = the server=92s identifier. Continuing this discussion on the IETF list = would be a good thing, though. >>=20 >> =20 >>=20 >> =20 >>=20 >> > the cloud provider's ID and the enterprise client's ID are both = "Internal IDs" with respect to their domains >>=20 >> =20 >>=20 >> I think this comes down to a nomenclature problem. The server=92s ID = does not necessarily have to be the unique identifier that the = underlying identity store uses, it just has to be stable and unique. In = many cases, the underlying identity store will provide identifiers with = these properties already (eg =96 a uuid) and it can be used by the SCIM = interface. The =93externalId=94 is referring to the fact that the id is = maintained external to the SCIM server. As long as the server=92s = identifiers are stable and unique (which is mandated by the spec), I = don=92t see a problem. >>=20 >> =20 >>=20 >> =20 >>=20 >> > The secret is that every value needs a key, and multi-valued = attributes lack that. So our solution is quite >>=20 >> > simple - turn every list or array (of values) into a dictionary (of = key-value pairs) by providing each value >>=20 >> > with a unique and meaning-free identifier. >>=20 >> =20 >>=20 >> I agree that this would be useful, especially in the PATCH operation. = One reason that this wasn=92t included in the spec originally is that = it can put undue burden on the service provider. Many service providers = are putting SCIM interfaces in front of their existing identity stores = (eg =96 directory servers, SaaS application databases, etc=85). Many of = these do not have a unique identifier for multi-valued attributes. By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute. I believe = this would be a roadblock for many implementers. >>=20 >> =20 >>=20 >> =20 >>=20 >> > When the SCIM protocol uses PATCH, there are areas where it seems a = bit clumsy. >>=20 >> =20 >>=20 >> I like the thoughts here. Your example reminds me of unified diffs = (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly = used with a patch program (pretty much the equivalent of the PATCH = verb). However, the three proposals seem to largely hinge on being able = to uniquely address each element within an object. Without these it is = not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85)= or provide a multi-status. >>=20 >>=20 >> The 207 response would be interesting to consider for the bulk = endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resources),= however. >>=20 >> =20 >>=20 >> =20 >>=20 >> > There are other, non-data aspects of SCIM which may require review, = such as its synchronous request-response >>=20 >> > interaction model, which is a form of tight coupling and could = prove to be a source of brittleness. >>=20 >> =20 >>=20 >> I agree that we should explore optional asynchronous requests in 2.0. >>=20 >> =20 >>=20 >> Thanks again for your thoughts. I hope you stay involved in the = discussion as work on SCIM 2.0 goes forward. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Ganesh and Sashi Prasad >> Sent: Wednesday, August 01, 2012 4:24 PM >> To: scim@ietf.org >> Subject: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> =20 >>=20 >> (I posted this on the SCIM Google Group, and I was advised to = subscribe to the mailing list and post it here instead, so here goes.) >>=20 >> =20 >>=20 >> Hi, >>=20 >> =20 >>=20 >> My name is Ganesh Prasad, and my experience in Identity and Access = Management is mainly through a 3-year project at an Australian insurance = company, an experience I have written about as a eBook on InfoQ = (http://www.infoq.com/minibooks/Identity-Management-Shoestring). >>=20 >> =20 >>=20 >> I have been following the SCIM spec off and on, and based on my = experience with a loosely-coupled architecture that I found to be = successful, I have the following 3 suggestions to make. >>=20 >> =20 >>=20 >> 1. The enterprise client and the cloud provider should maintain their = own internal IDs for a resource, which they should not reveal to each = other. Both of them should map their internal IDs to a shared External = ID, and this is the only ID that should be exposed through the API. The = current specification's provision of an id (which is the external ID and = the only one to be transferred through the API) and an "external ID" = (which is the client's internal ID and should be hidden) is = diametrically opposite to this. >>=20 >> =20 >>=20 >> 2. When dealing with multi-valued attributes of a resource (expressed = as arrays in JSON), they must be converted from an array into a = dictionary with unique keys (UUIDs generated by the cloud provider when = the attribute is created). Without unique keys for every attribute value = of a resource, manipulating it will be clumsy and inelegant. >>=20 >> =20 >>=20 >> 3. The PATCH command can be improved in 3 significant ways: >>=20 >> 3a. Leverage the fact (from 2 above) that every value has a key, to = greatly simplify the API >>=20 >> 3b. Use special verbs as nested operations of the PATCH command to = add, modify and delete attributes at any level >>=20 >> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 = OK" as the response to a PATCH (or BULK) command. >>=20 >> =20 >>=20 >> To elaborate, >>=20 >> =20 >>=20 >> 1. Revealing private IDs externally is a form of tight coupling. A = major requirement with Identity Management is to split (or merge) = identities when false positives (or false negatives) are detected, = i.e., when a resource is discovered to be more than one, or when = multiple resources are detected to be the same. If internal identifiers = are revealed to external domains, such clean-ups become difficult, hence = every domain that wants to expose references to a resource must map its = internal ID to and external one created for this explicit purpose, and = only reveal this. >>=20 >> =20 >>=20 >> In the SCIM case, when an enterprise client POSTs a resource creation = request, the cloud provider must generate its own internal UUID as well = as an external UUID, map them together, and only return the external = UUID in the "Location:" header. The enterprise client should map this = external UUID to a newly-generated internal ID of its own. In case the = resource already has an identifier within the enterprise client's = domain, then this is the internal ID that must be mapped to the external = UUID returned through the POST response. >>=20 >> =20 >>=20 >> 2. If a resource is to be created, and one of its attributes is = multi-valued, e.g., >>=20 >> =20 >>=20 >> "email-addrs" :=20 >>=20 >> [ >>=20 >> "john_smith@yahoo.com", >>=20 >> "john.smith@gmail.com", >>=20 >> "jsmith1970@hotmail.com" >>=20 >> < >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 --Apple-Mail=_A466ADB4-6404-4AEC-8254-67425D367603 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 g.c.prasad@gmail.com> = wrote:

Trey,

> The externalID is not part of the = protocol.  It is an *optional* attribute within the *schema* = specification.

I didn't realise SCIM was also specifying a User schema. = Does this mean the User resource can only hold certain attributes as = defined by this schema? If so, that's going to be a severe constraint, = because client organisations are likely to require many specialised User = attributes depending on the nature of their business, and they will = expect to be able to store all of them, not just the subset defined by = the SCIM spec. I hope the SCIM User schema is not trying to be just a = representation of inetOrgPerson (the standard LDAP schema), because that = could be severely limiting. Most organisations with their own LDAP end = up extending inetOrgPerson, and they will expect that they can do the = same in the cloud.

I = recommend you read the relevant specifications. The working group = has accepted both a schema and protocol draft as input to the = effort. 

> As for #2, the protocol spec = works as you describe if "arbitrary URI parameters" equate to resource = attributes 

Yes, that's what I meant, but in implementation, it = may work out to be looser than that. The client should be able to = specify any arbitrary attribute in the search parameters, even those = that aren't attributes of the resource. If an attribute is not defined, = or if the attribute exists but the value doesn't match any stored = record, the SP will return no results. In the former case, it's a "400 = Bad Request" and in the latter, it's a "404 Not = Found".
And that's because?  I don't = see any value to the behavior (enabling attribute searches on = non-existent schema) you suggest. 


By "candidate key" (a data modelling term), I meant = another attribute that also uniquely identifies a single record, but is = not the official "primary key", i.e., the main ID. In this case, a = client's internal identifier also uniquely identifies a record, but is = not the ID used in the URI of RESTful = operations.

I know what a = candidate key is.  My question is why do you believe an SP ought to = care about "candidate keys"?   Resources are uniquely identified = exactly 1 way by the SP and that is by the SP minted id.  The = Consumer can retrieve a resource by any attribute though only the id is = guaranteed to be unique from the POV of the SP.  The SCIM model is = a *mapping* between the consumer and SP hence it is not a prescription = for how the Resource data is actually stored on either = side.
  

Look, this may seem to be splitting hairs since a = determined client may be able to store and search by their own internal = ID in either case (the current SCIM spec or my suggestion). The = difference is philosophical. If the spec is showing how clients can = store their internal IDs in the cloud by explicitly providing for such = an attribute, that constitutes bad advice, IMO. If it turns a blind eye = to what they store and they store internal IDs anyway, they're = constraining themselves but the spec comes out smelling of roses because = that's not "recommended practice".


If externalId were = dropped it wouldn't bother me a bit.  

Ganesh

On 11 = August 2012 00:50, Trey Drake <trey.drake@unboundid.com> wrote:
Ganesh,

I'll base my comments = on your latest reply (below).  

The = externalID is not part of the protocol.  It is an *optional* = attribute within the *schema* specification.  As for #2, the = protocol spec works as you describe if "arbitrary URI parameters" equate = to resource attributes (Allow generic search using 'GET /Users' and = arbitrary URI parameters).  Please clarify your suggestion.

I'm not tracking your coupling concern.  The = client can search and hence retrieve resources on any attribute it = chooses, externalId or otherwise.  Nothing mandates use of = externalId.   


What do you mean by "candidate key"? =  Given 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi = Prasad <g.c.prasad@gmail.com> wrote:
>  I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. [...] IMHO loose coupling is a = much more complex = solution.

Phil,

I'm a bit = surprised that you're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my experience.

When I say "loose coupling", I mean "no unnecessary = dependencies". Invariably, a reduction in dependencies leads to greater = simplicity.

Let's not confuse reduction of = dependencies in the data model with a hub-and-spokes architecture. = They're entirely orthogonal aspects of the solution.

All that my suggestion involves = is,

1. Take 'external ID' out of the = protocol.
2. Allow generic search using 'GET /Users' and = arbitrary URI parameters

No planned functionality is lost by = this.

1. The client enterprise can still send = its internal ID as part of the resource body, inside some attribute = defined by them (but not defined by the protocol). Let's say they call = it 'myID'.
2. The client enterprise can search for resource URIs using any = attribute, including this internal ID
'GET = /Users?myID=3Dbjensen'
Since myID is a candidate key, the = server will return exactly one URI, which is the canonical URI for the = resource
https://example.com/v1/Users/2819c223-7f76-453a-919d-413=
861904646
3. The client can use this URI to perform all =
other operations as usual.

So taking 'externalID' out of the protocol spec =
only does this:
1. It avoids enshrining tight coupling in the =
protocol (If clients want to tightly couple themselves to the cloud =
provider by sending their internal IDs, they can do so. Suicide is OK, =
but the protocol should not be guilty of assisted suicide. =
;-)
2. It encourages loose coupling by nudging =
clients towards maintaining their own internal-to-external identifier =
mappings.

That's what I'd like to see. I don't believe this =
complicates the protocol. It simplifies it and it also lends itself to a =
loosely-coupled approach.

I'll address the multi-valued attribute =
suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil = Hunt <phil.hunt@oracle.com> wrote:


Phil

On 2012-08-09, = at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec = is a great way to enable this solution.  Part of the key here is = that SCIM is just a piece of the architecture for this solution, and is = only responsible for the transport layer between = domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. = I provided that example to illustrate that splitting and merging = identities is a common requirement, and that decoupling local = identifiers within a domain from shared identifiers between domains was = the best way to facilitate it.

I'm suggesting that the spec do less, not = more.

What the SCIM spec needs to do there is just refrain = from introducing tight coupling. I would like to see a single identifier = exposed through the API, with the implication (and perhaps the = recommendation) that it be the shared one. Allowing one domain to expose = its internal identifier to the other creates tight coupling and ensures = that both domains need simultaneously split or merge identities, which = is not desirable. So I recommend _taking out_ the "external id" field = from the API. The spec shouldn't encourage tight coupling. If clients = want to pass in their internal ids as part of the resource body, no one = can stop them, and they can always do a search on that attribute to = retrieve the URI exactly as you visualise they will with the "external = id", but let's not elevate an anti-pattern to a recommendation by = enshrining the "external id" as an acceptable attribute.

Am I making = sense?

I see what you are saying. = I think scim gets its current simplicity from its single owner hub spoke = model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The = reality is that each end-point has value to contribute and thus the = single-owner model will eventually need to become multi-owner or = multi-hub. 

That said i think the current model provides a = practical starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a = trade-off involved.  On one hand this makes PATCH semantics = easier.  On the other hand it puts extra burden on service = providers. 

Precisely. The spec has to strike the right balance. It would = be interesting to hear from the other members of the spec mailing list. = You know where I stand on this. It would be good to hear the spectrum of = opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

Thanks Emmanuel.  I had started writing up a = similar response.  As you suggest, storing this information in a = mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only = responsible for the transport layer between = domains.

 

You could also model these ID mappings in the SCIM = user as an extension but would probably not want to expose these = externally.  Here is an example of how to model the end state of the false positive scenario (splitting a = user):

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = a99a5feba839       | = D2            =      | = 7a87f27c1dd8       | = true         = |

 

This could be represented as two SCIM users that = contain information about the entities on other = domains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "a99a5feba839",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      = }

    ]

  }

}

 

In the second user, the linkedUsers attribute = would be empty until the split user was synced to domain = 2.

 

 

Similarly, the false negative use case (merging = two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |

| = 9caf78aac3d6       | = D2            =      | = ff487230b3a0       | = true         = |

| = 9caf78aac3d6       | = D2            =      | = 41206cc97c8b       | = false        = |

 

This could be represented with the following SCIM = user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0", = "urn:scim:schemas:extension:federation:1.0"],

  "id": = "9caf78aac3d6",

  "userName": "John = Smith",

  = "urn:scim:schemas:extension:federation:1.0": = {

    "linkedUsers": = [

      = {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      = },

      = {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      = }

    ]

  }

}

 

 

Regarding unique identifiers for multi-valued = attributes there is a trade-off involved.  On one hand this makes = PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of = SCIM, a key goal has been to foster adoption by service providers by = making things fit easily onto existing systems.  IMO the value = gained by unique identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think = that vendors that have a non-SCIM-compliant API will choose to keep = things that way if the spec is too hard for them to implement.  In = a green field environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we = can=92t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi Ganesh,

 

Nothing prevents you in your SCIM implementation = (client or server) to generate a unique identifier for each synchronized = object and maintain an internal mapping table ( you would have to map group membership as = well).

 

This is what we are doing with Active Directory = sources or targets:

As we didn=92t find an immutable uniqueID in AD = systems (DN,samAccountName, UPN) are subject to change (even objectGuid = can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits = your requirements as it hides internal ids.

 

This was written in dotnet and we have started a = project to rewrite our SCIM stack in PHP and will give it to the Open = Source community. This implementation will have a parameter : AllocateIds versus = UseExistingIDs.

This will give the choice of =93hiding=94 = internalIDs or use them as unique ID.

 

You can also implement such feature without = violating the SCIM specs, or without asking to include it in the = specs.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78 17 = 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ietf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for = improvement

 

Hi = Kelly,

Thanks= for your response. Let me first respond in brief to the two main points = you have made, and then elaborate on the = first.

1.      Why should domains not = expose their internal identifiers to other = domains?

a.

We are designing a protocol for a federated system of = domains, where all domains are co-equal peers. (In physics too, N-body = problems are much harder than 2-body problems. :-) Therefore, assuming = that there are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on = messaging and notification, with encapsulation of domain-specific = data.

b.

In any non-trivial data store, there will always be = the ongoing need to merge and split identities as and when =93false = negatives=94 and =93false positives=94 are discovered. A domain should = be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal = identifiers to external ones and maintaining this mapping internally = allows this loosely-coupled housekeeping to take place. Sharing internal = identifiers (or otherwise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be = done in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a = suitable wire protocol which can be designed later. The data model plays = a crucial role in enabling or constraining such interaction. A = tightly-coupled data model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of = this tight coupling.

2. The difficulty of assigning unique identifiers to = the individual values of multi-valued = attributes:

a.

I'm not belittling the effort involved in migrating = legacy data stores to such a model. However, in the larger historical = context of cross-domain identity management, we are really at the very = early stages. If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are = losing an opportunity to provide a clean and elegant model to subsequent = users of the spec, and this will have repercussions over many years or = even decades.

b.

If incumbent cloud providers find it hard to = immediately adopt the dictionary model for existing multi-valued = attributes, they can transition to this model by offering both = =93SCIM-compliant=94 and =93non-SCIM-compliant=94 APIs to their = customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy = customers can be supported using a =93non-SCIM-compliant=94 API for an = arbitrarily long period and gradually migrated to the SCIM-compliant = API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued = attributes.

Elaboration of Point 1:

When = we consider federated identity across more than one domain, we have to = assume that domains are not necessarily master-slave in their = interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain = are notified to other domains (when necessary) in an asynchronous manner = (i.e., through messaging) and the other domains are free to respond to = these events in an appropriate manner and at a time of their convenience.

A = key set of lifecycle events for an entity is the merging and splitting = of identity that is often required.

The = question =93Is this one entity?=94 can be answered either yes (positive) = or no (negative). But sometimes, we can discover false positives and = false negatives in our data stores.

Consider a case where customers sign up online, and two = customers who are privacy-conscious enter fake IDs such as =93John = Smith=94, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an = intelligent (but incorrect) guess that these two persons are the same, = and re-assign the same identifier to the second person. This is a false = positive. They appear to be the same entity, but they're actually different. When the error is discovered, the = identities will need to be split, with a new identifier generated for = one of them.

Consider the opposite case where a customer signs up through = two different portals or in two different sessions, using the names = =93JSmith=94 and =93JohnS=94. It is very likely that they will be treated as two different customers and assigned two unique = identifiers. This is a false negative. They appear to be two entities, = but are actually the same. At a later stage, when the error is = discovered, the identities will have to be merged, and one of the identifiers will have to be = dropped.

These = are not theoretical use cases. They form a significant proportion of the = user base in most large Web-facing applications. Let's see how these can = be managed in a federated way by mapping internal identifiers to external ones and only exposing = external identifiers to other domains.

a. = False positives:

Domain= 1 has the following information about a customer in its data = store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifier:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When = the false positive is discovered and the entity is split, Domain 1 = creates a new internal identifier and now has the following entity = information.

Internal ID: 9caf78aac3d6

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

Internal ID: a99a5feba839

Attributes: {name: =93John Smith=94, dob: = =9301-Jan-1970=94}

This = second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes = place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some = convenient time (importantly, this doesn't have to be at the time the = split happens), Domain 2 can be requested to provision a second entity, = and when it responds with an identifier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the = second entity's internal identifier.

The = mapping table now contains the following = entries:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = a99a5feba839 | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has = happened, and the provisioning that it does is not in lockstep with the = split in identity that occurred in Domain 1.

(What = is the =93Primary flag=94 used for? We'll see when we cover the = treatment of false negatives.)

b. = False negatives:

Domain= 1 has the following information about what it thinks are two distinct = customers in its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =93JSmith=94, dob: = =9301-Jan-1970=94}

Internal ID: 273d36e30d09

Attributes: {name: =93JohnS=94, dob: = =9301-Jan-1970=94}

When = requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and = 41206cc97c8b.

Domain= 1 then maintains the following in a mapping table and uses it for = translation when talking to Domain 2, taking care never to expose its = internal identifiers:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 273d36e30d09 | D2 | 41206cc97c8b | true |

When = the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the = customer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and = drops the second =93273d36e30d09=94.

The = mapping table now looks like this:

| Internal = Entity ID | External Domain ID | External Entity ID | Primary flag = |

| = 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| = 9caf78aac3d6 | D2 | 41206cc97c8b | false |

Now = two external identifiers map to the same internal one, so inbound = communication from Domain 2 can be unambiguously translated to the same = entity internally. However, when going outwards, Domain 1 will have to look up the translation table to = determine the =93primary=94 external ID for this entity in Domain 2, = which was decided to be =93ff487230b3a0=94. That's where the =93Primary = flag=94 comes in. The second external ID =9341206cc97c8b=94 is never used thereafter in outbound = communication.

At = some stage (importantly, not in lockstep with the identity merge), = Domain 2 can be requested to delete the customer record identified by = =9341206cc97c8b=94, and the second entry in the mapping table can be removed once this is = acknowledged.

This = scheme will scale up to multiple domains, because the =93External Domain = ID=94 column helps to keep track of which external ID is shared with = which Domain. (Why don't we use just one external ID for an entity and share it with all external = domains? Tight coupling again. Just as OAuth allows an access token = given to a third party to be invalidated without affecting the access of = other third parties, the use of separate external identifiers for different domains allows fine-grained control of = identity federation.)

The = scheme also allows the splitting of an entity into more than two = entities, and the merging of more than two entities into a single one. = (Any organisation with a web-facing application will tell you how many John Smiths there are who were born = on 1 Jan 1970!)

This = is a fairly long-winded explanation, but this is why we need to hide = internal identifiers from other domains, and why mappings need to be = managed internally in each domain. Such a data model also allows us to choose asynchronous protocols for = propagation of identity events, since there is no consistency = requirement to update multiple domains = concurrently.

Regards,

Ganesh= Prasad

 

On 9 August 2012 04:55, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Thanks for the feedback, Ganesh.  I read = through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitation= s) and have some thoughts.

 

> The rest of the protocol does not meaningfully = use the enterprise client=92s identifier, the "external = ID"

> at all, even though it was ostensibly = introduced to make things friendlier for the = client.

 

The usage pattern for an external ID would be to = search for a user by externalId and use the ID of the returned user in any desired operation.  For = example:

 

GET /Users?filter=3DexternalId eq = =93bjensen=94&attributes=3Did

 

{

  =93totalResults=94: = 1,

  =93Resources=94: = [

    {

      =93id=94: = =932819c223-7f76-453a-919d-413861904646=94

    }

  ]

}

 

Retrieve the ID from the response and use = it.

 

DELETE = /Users/2819c223-7f76-453a-919d-413861904646

 

This does introduce an additional HTTP request if = the client chooses not to store the server=92s id.  An issue was created to consider allowing operations to use the = externalId (http://code.google.com/p/scim/issues/detail?id=3D35<= span = style=3D"font-size:11.0pt;font-family:"Calibri","sans-serif= ";color:#1f497d">), but I believe the general consensus has been to not include this in the = spec.  One main point of contention is that much of the rest of the = spec (eg =96 group membership references, manager references, etc=85) = require knowledge of the server=92s identifier.  Continuing this discussion on the IETF list would be a good thing, = though.

 

 

> the cloud provider's ID and the enterprise = client's ID are both "Internal IDs" with respect to their = domains

 

I think this comes down to a nomenclature = problem.  The server=92s ID does not necessarily have to be the unique identifier that the underlying identity store uses, it = just has to be stable and unique.  In many cases, the underlying = identity store will provide identifiers with these properties already = (eg =96 a uuid) and it can be used by the SCIM interface.  The =93externalId=94 is referring to the fact that the id is maintained = external to the SCIM server.  As long as the server=92s identifiers = are stable and unique (which is mandated by the spec), I don=92t see a = problem.

 

 

> The secret is that every value needs a = key, and multi-valued attributes lack that. So our solution is = quite

> simple - turn every list or array (of = values) into a dictionary (of key-value pairs) by providing each value

> with a unique and meaning-free = identifier.

 

I agree that this would be useful, especially in = the PATCH operation.  One reason that this wasn=92t included in the spec originally is that it can put undue burden on the = service provider.  Many service providers are putting SCIM = interfaces in front of their existing identity stores (eg =96 directory = servers, SaaS application databases, etc=85).  Many of these do not have a unique identifier for multi-valued attributes.  By = requiring this, a majority of the server providers would have to start = maintaining a unique key for each multi-valued attribute.  I = believe this would be a roadblock for many = implementers.

 

 

> When the SCIM protocol uses PATCH, there are = areas where it seems a bit clumsy.

 

I like the thoughts here.  Your example = reminds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly used with a patch program (pretty much the = equivalent of the PATCH verb).  However, the three proposals seem = to largely hinge on being able to uniquely address each element within = an object.  Without these it is not so easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a = multi-status.


The 207 response would be interesting to consider for the bulk endpoint = (http://www.simplecloud.info/specs/draft-scim-api-00.html= #bulk-resources), however.

 

 

> There are other, non-data aspects of SCIM which = may require review, such as its synchronous = request-response

> interaction model, which is a form of tight = coupling and could prove to be a source of = brittleness.

 

I agree that we should explore optional = asynchronous requests in 2.0.

 

Thanks again for your thoughts.  I hope you = stay involved in the discussion as work on SCIM 2.0 goes forward.

 

--Kelly

 

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Wednesday, August 01, 2012 4:24 PM
To: scim@ietf.org
Subject: [scim] SCIM Protocol - 3 suggestions for = improvement

 

(I posted this on the SCIM Google Group, and = I was advised to subscribe to the mailing list and post it here instead, = so here goes.)

 

Hi,

 

My name is Ganesh Prasad, and my experience = in Identity and Access Management is mainly through a 3-year project at = an Australian insurance company, an experience I have written about as a eBook on InfoQ (http://www.infoq.com/minibooks/Identity-Management-Shoes= tring).

 

I have been following the SCIM spec off and = on, and based on my experience with a loosely-coupled architecture that = I found to be successful, I have the following 3 suggestions to make.

 

1. The enterprise client and the cloud = provider should maintain their own internal IDs for a resource, which = they should not reveal to each other. Both of them should map their internal IDs to a shared External ID, and this is the only ID that = should be exposed through the API. The current specification's provision = of an id (which is the external ID and the only one to be transferred = through the API) and an "external ID" (which is the client's internal ID and should be hidden) is diametrically = opposite to this.

 

2. When dealing with multi-valued attributes = of a resource (expressed as arrays in JSON), they must be converted from = an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created). Without unique = keys for every attribute value of a resource, manipulating it will be = clumsy and inelegant.

 

3. The PATCH command can be improved in 3 = significant ways:

3a. Leverage the fact (from 2 above) that = every value has a key, to greatly simplify the API

3b. Use special verbs as nested operations = of the PATCH command to add, modify and delete attributes at any = level

3c. Use the WebDAV status code of "207 = Multi-Status" instead of "200 OK" as the response to a PATCH (or BULK) = command.

 

To elaborate,

 

1. Revealing private IDs externally is a = form of tight coupling. A major requirement with Identity Management is = to split (or merge) identities when false positives (or false negatives) are detected, i.e., when a resource is discovered to be more than one, = or when multiple resources are detected to be the same. If internal = identifiers are revealed to external domains, such clean-ups become = difficult, hence every domain that wants to expose references to a resource must map its internal ID to and external one = created for this explicit purpose, and only reveal = this.

 

In the SCIM case, when an enterprise client = POSTs a resource creation request, the cloud provider must generate its = own internal UUID as well as an external UUID, map them together, and only return the external UUID in the "Location:" header. The = enterprise client should map this external UUID to a newly-generated = internal ID of its own. In case the resource already has an identifier = within the enterprise client's domain, then this is the internal ID that must be mapped to the external UUID returned = through the POST response.

 

2. If a resource is to be created, and one = of its attributes is multi-valued, e.g.,

 

    "email-addrs" = : 

    [

        "john_smith@yahoo.com",

        "john.smith@gmail.com",

        "jsmith1970@hotmail.com"

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


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




= --Apple-Mail=_A466ADB4-6404-4AEC-8254-67425D367603-- From phil.hunt@oracle.com Sat Aug 11 09:05:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7621F863F for ; Sat, 11 Aug 2012 09:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llKAWk-o0FjT for ; Sat, 11 Aug 2012 09:05:00 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9AA21F8629 for ; Sat, 11 Aug 2012 09:04:59 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7BG4vVB025172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 16:04:58 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7BG4uDH021365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 16:04:57 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7BG4uhS032646; Sat, 11 Aug 2012 11:04:56 -0500 Received: from [101.223.60.15] (/174.0.227.209) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Aug 2012 09:04:54 -0700 References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3F975445-8739-4EBA-A42C-CFB8B92E7E91 Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sat, 11 Aug 2012 10:04:51 -0600 To: Ganesh and Sashi Prasad X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:05:04 -0000 --Apple-Mail-3F975445-8739-4EBA-A42C-CFB8B92E7E91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That's a huge imposition on the client.=20 Not sure about your arg on server side. It depends on the store implemetatio= n i suppose.=20 Phil On 2012-08-11, at 9:50, Ganesh and Sashi Prasad wrote= : > Phil, >=20 > The reason we cannot use the value itself to identify an element is that t= his method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of a= ddresses for each customer, with each address element having sub-elements li= ke street number, street name, suburb, etc.), then it would be clumsy to sup= ply the entire value of the array element because it's itself a dictionary. C= reating a unique key for each element scales better. >=20 > Regards, > Ganesh >=20 > On 12 August 2012 01:12, Phil Hunt wrote: > Ganesh, >=20 > Here's the sample that concerned me... >> The two operations differ significantly, and it's not very intuitive.=20 >> With my suggestion, here's how to delete a single member from a group: >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >>=20 >> { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >> } >> } >> ] >> } >=20 >=20 > You gave other examples of an attribute with an identifier that matched th= at value or of identifiers that were additional unique keys. >=20 > Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to de= lete. >=20 > I agree, the delete value operation could be more explicit and clear in ge= neral. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >=20 >> > For the multi-value example you gave you used the value as the attribu= te name key.=20 >>=20 >> Now I'm confused :-). I don't believe any of my examples ever used a valu= e as the key. >>=20 >> Could you please show me which example you mean, and which parts of it yo= u believe to be the value? >>=20 >> Regards, >> Ganesh=20 >>=20 >> On 11 August 2012 13:59, Phil Hunt wrote: >>=20 >> For the multi-value example you gave you used the value as the attribute n= ame key.=20 >>=20 >> That means a lot more complex indexing structure. Better to just say dele= te a specific value.=20 >>=20 >> The spec already allows multiple values to have tags like home, work, etc= . >>=20 >> Phil >>=20 >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad w= rote: >>=20 >>> > In your example you are conflating value with an attribute id.=20 >>>=20 >>> I don't believe so. >>>=20 >>> I'm adopting a model where every attribute of the resource is a key-valu= e pair. The key is a name or ID. >>>=20 >>> For non-repeating attributes (both simple and composite), the key is the= attribute name itself.=20 >>>=20 >>> Simple attribute: >>>=20 >>> Key: "dob" >>> Value: "01 Jan 1970" >>>=20 >>> For composite attributes, the key employs dot notation to specify the fu= lly-qualified attribute name, e.g., "address.postcode". >>>=20 >>> Composite attribute: >>>=20 >>> Key: "address.street-number" >>> Value: "10" >>>=20 >>> Key: "address.suburb" >>> Value: "East Camden" >>>=20 >>> For repeating (multi-valued) attributes, I'm suggesting that there be ne= w keys for each individual value, otherwise they are impossible to distingui= sh, and a positional index is inadequate. So we convert the array into a dic= tionary and this then becomes a composite attribute using dot notation for t= he key. >>>=20 >>> Multi-valued attribute: >>>=20 >>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>> Value: "john_smith@yahoo.com" >>>=20 >>> So this allows us to apply uniform treatment to any arbitrarily deep res= ource structure. We can refer to every leaf value with a key that is the ful= ly-qualified name using dot notation. >>>=20 >>> The verbs are just unambiguous operations on these (now) explicitly addr= essable attributes. >>>=20 >>> INCLUDE to a collection and specify only the value. The key is generated= and returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. >>>=20 >>> REPLACE a fully-qualified key with a new value. If the key doesn't exist= , return a "404 Not Found". >>>=20 >>> PLACE a value at the logical location implied by the fully-qualified key= . If there is already a key with that name, return a "409 Conflict". >>>=20 >>> FORCE the fully-qualified key to hold the given value, regardless of whe= ther it existed before or not. Only errors possible are "400 Bad Request" an= d "500 Internal Error". >>>=20 >>> RETIRE an attribute or a collection given its fully-qualified key. The i= mplementation will determine whether the attribute will disappear entirely o= r will exist holding a null value (the blank string "" or the empty object {= } ). >>>=20 >>> I'll explain in a separate post why we need operation verbs like these t= hat are independent of the HTTP verbs. >>>=20 >>> Regards, >>> Ganesh >>>=20 >>> On 11 August 2012 10:38, wrote: >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>>=20 >>> https://www.ietf.org/mailman/listinfo/scim >>>=20 >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>>=20 >>>=20 >>>=20 >>> Send scim mailing list submissions to >>> scim@ietf.org >>>=20 >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/scim >>> or, via email, send a message with subject or body 'help' to >>> scim-request@ietf.org >>>=20 >>> You can reach the person managing the list at >>> scim-owner@ietf.org >>>=20 >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of scim digest..." >>>=20 >>> Today's Topics: >>>=20 >>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: Phil Hunt >>> To: Ganesh and Sashi Prasad >>> Cc: "Diodati, Mark" , Emmanuel Dreux , Trey Drake , Kelly Grizzle , "scim@ietf.org" >>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>> Ganesh, >>>=20 >>> In your example you are conflating value with an attribute id. I find th= at confusing.=20 >>>=20 >>> I agree though that operations in patch could be a lot more explicit.=20= >>>=20 >>> Eg explicitly deleting a value by saying delete or retire.=20 >>>=20 >>> Phil >>>=20 >>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad w= rote: >>>=20 >>>> > I am concerned about your second suggestion:=20 >>>>=20 >>>> Let's discuss that now. >>>>=20 >>>> The trade-offs are very clear here. >>>>=20 >>>> Pros: >>>>=20 >>>> Pro 1. The API to manipulate resources becomes so much cleaner, consist= ent and intuitive when every individual attribute value gets its own ID. >>>>=20 >>>> Here's how to delete a single member from a Group, as per the current s= pec: >>>>=20 >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>>=20 >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "members": [ >>>> { >>>> "display": "Babs Jensen", >>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>> "operation": "delete" >>>> } >>>> ] >>>> } >>>>=20 >>>> Here's how to delete ALL members from a group according to the current s= pec: >>>>=20 >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>>=20 >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "meta": { >>>> "attributes": [ >>>> "members" >>>> ] >>>> } >>>> } >>>>=20 >>>> The two operations differ significantly, and it's not very intuitive.=20= >>>> With my suggestion, here's how to delete a single member from a group: >>>>=20 >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>>=20 >>>> { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>> } >>>> } >>>> ] >>>> } >>>>=20 >>>> Here's how I suggest deleting ALL members from a group: >>>>=20 >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>>=20 >>>> { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members" >>>> } >>>> } >>>> ] >>>> } >>>>=20 >>>> I'm sure you'll agree that this is simpler, more consistent and more in= tuitive to a reader. >>>>=20 >>>> Pro 2: We can apply this mechanism consistently to three areas: >>>> (a) Manipulating multi-valued attributes of a resource >>>> (b) Manipulating members of a group >>>> (c) Performing bulk operations, where we simply use HTTP verbs instead o= f the specialised (and semantically less ambiguous) verbs I suggested for at= tributes, the "key" becomes the URI, and the "value" becomes the correspondi= ng JSON object. >>>>=20 >>>> All of them return "207 Multi-Status" with the "results" array holding i= ndividual status codes. >>>>=20 >>>> In the current spec, (a) and (b) are done similarly but (c) is very dif= ferent. >>>>=20 >>>> Pro 3: Adoption of the standard by clients is likely to be higher becau= se it's simpler for them. >>>>=20 >>>> Pro 4: New (not incumbent) cloud providers will probably find this easi= er to implement because they have no legacy. They will probably use some for= m of NoSQL database and won't be constrained by the limitations of LDAP dire= ctories. >>>>=20 >>>> Cons: >>>>=20 >>>> Con 1: Incumbent cloud providers with existing data stores in a directo= ry format (where multi-valued attributes are stored as comma-separated value= s under a single attribute node) will find it difficult to migrate to this m= odel and store each attribute value as a sub-node with its own key. This wil= l "hinder adoption of the spec", which is what you fear. >>>>=20 >>>> Have I summed up the Pros and Cons correctly? I'm biased of course, so I= could have missed a Con or hyped a Pro :-). >>>>=20 >>>> In other words, we're debating interface complexity (current spec) vers= us implementation complexity (my suggestion). Both can hinder adoption of th= e spec by different parties. >>>>=20 >>>> Here's what we need to discuss - Do the Pros make the suggestion worth a= dopting in spite of the Cons, or are the Cons so great that it's best to lea= ve the spec as it is? >>>>=20 >>>> Keep in mind that a complex spec that only favours incumbent cloud prov= iders can cut both ways. It opens the door to a simpler interface offered by= a new generation of nimbler SPs that don't have the same legacy issues, and= there could be an exodus of clients to these new SPs. SCIM could end up bei= ng obsoleted very soon, because the API interface is very complex and clumsy= , as any new reader can attest. I was taken aback by the complexity when I s= aw it, which is why I was prompted to suggest something simpler. >>>>=20 >>>> This is an issue where we need the opinions of many people, and they ne= ed to state their affiliations. If most people weighing in belong to incumbe= nt SPs and they vote in favour of interface complexity to avoid implementati= on complexity, then it means the spec is not doing a good job of balancing t= he interests of various groups. I think we should also poll client organisat= ions to see what they would want. >>>>=20 >>>> (Gartner is trusted by enterprise clients to evaluate the capabilities o= f vendors (SPs). I believe Gartner should take the lead in representing clie= nt interests in this working group rather than those of incumbent vendors, w= hich is what it seems like to me. Correct me if I'm being unfair.) >>>>=20 >>>> Regards, >>>> Ganesh >>>>=20 >>>>=20 >>>>=20 >>>> On 11 August 2012 01:35, Diodati,Mark wrote:= >>>> Hi Ganesh, >>>>=20 >>>> =20 >>>> I am concerned about your second suggestion: >>>>=20 >>>> =E2=80=9C2. When dealing with multi-valued attributes of a resource (ex= pressed as arrays in JSON), they must be converted from an array into a dict= ionary with unique keys (UUIDs generated by the cloud provider when the attr= ibute is created). Without unique keys for every attribute value of a resour= ce, manipulating it will be clumsy and inelegant.=E2=80=9D >>>>=20 >>>> =20 >>>> One of the primary reasons that SPML failed was lack of adoption by ser= vice providers due to its complexity. Very few target applications implement= ed SPML. Most of the commercial provisioning systems had an SPML interface (= either v1 or v2), but not one of them was conformant to the SPML standard be= cause of complexity. If you are interested, I will forward you the research d= ocuments that discuss these problems in detail. For SCIM to be successful, i= t must be adopted by commercial target applications (i.e., service providers= ). I am confident that a requirement for unique identifiers with multi-value= d attributes will preclude its adoption, because it requires major changes t= o the service provider=E2=80=99s existing identity storage mechanisms. >>>>=20 >>>> Mark >>>>=20 >>>> =20 >>>> =20 >>>> =20 >>>> From: Trey Drake [mailto:trey.drake@unboundid.com]=20 >>>> Sent: Friday, August 10, 2012 9:51 AM >>>>=20 >>>>=20 >>>> To: Ganesh and Sashi Prasad >>>> Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>=20 >>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>> Ganesh, >>>>=20 >>>> =20 >>>> I'll base my comments on your latest reply (below). =20 >>>>=20 >>>> =20 >>>> The externalID is not part of the protocol. It is an *optional* attrib= ute within the *schema* specification. As for #2, the protocol spec works a= s you describe if "arbitrary URI parameters" equate to resource attributes (= Allow generic search using 'GET /Users' and arbitrary URI parameters). Plea= se clarify your suggestion. >>>>=20 >>>> =20 >>>> I'm not tracking your coupling concern. The client can search and henc= e retrieve resources on any attribute it chooses, externalId or otherwise. N= othing mandates use of externalId. =20 >>>>=20 >>>> =20 >>>> =20 >>>> What do you mean by "candidate key"? Given=20 >>>>=20 >>>> =20 >>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad wrote: >>>>=20 >>>> > I think scim gets its current simplicity from its single owner hub s= poke model implementing tight coupling. [...] IMHO loose coupling is a much m= ore complex solution. >>>>=20 >>>> =20 >>>> Phil, >>>>=20 >>>> =20 >>>> I'm a bit surprised that you're implying "tight coupling =3D=3D simple"= and "loose coupling =3D=3D complex". That's contrary to my experience. >>>>=20 >>>> =20 >>>> When I say "loose coupling", I mean "no unnecessary dependencies". Inva= riably, a reduction in dependencies leads to greater simplicity. >>>>=20 >>>> =20 >>>> Let's not confuse reduction of dependencies in the data model with a hu= b-and-spokes architecture. They're entirely orthogonal aspects of the soluti= on. >>>>=20 >>>> =20 >>>> All that my suggestion involves is, >>>>=20 >>>> =20 >>>> 1. Take 'external ID' out of the protocol. >>>>=20 >>>> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters= >>>>=20 >>>> =20 >>>> No planned functionality is lost by this. >>>>=20 >>>> =20 >>>> 1. The client enterprise can still send its internal ID as part of the r= esource body, inside some attribute defined by them (but not defined by the p= rotocol). Let's say they call it 'myID'. >>>>=20 >>>> 2. The client enterprise can search for resource URIs using any attribu= te, including this internal ID >>>>=20 >>>> 'GET /Users?myID=3Dbjensen' >>>>=20 >>>> Since myID is a candidate key, the server will return exactly one URI, w= hich is the canonical URI for the resource >>>>=20 >>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>> 3. The client can use this URI to perform all other operations as usual= . >>>> =20 >>>> So taking 'externalID' out of the protocol spec only does this: >>>> 1. It avoids enshrining tight coupling in the protocol (If clients want= to tightly couple themselves to the cloud provider by sending their interna= l IDs, they can do so. Suicide is OK, but the protocol should not be guilty o= f assisted suicide. ;-) >>>> 2. It encourages loose coupling by nudging clients towards maintaining t= heir own internal-to-external identifier mappings. >>>> =20 >>>> That's what I'd like to see. I don't believe this complicates the proto= col. It simplifies it and it also lends itself to a loosely-coupled approach= . >>>> =20 >>>> I'll address the multi-valued attribute suggestion separately. >>>> =20 >>>> Regards, >>>> Ganesh >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Phil >>>>=20 >>>>=20 >>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad = wrote: >>>>=20 >>>> > storing this information in a mapping table outside of the SCIM spec= is a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsibl= e for the transport layer between domains.=20 >>>>=20 >>>> I wasn't suggesting that the mapping table be part of the SCIM spec. I p= rovided that example to illustrate that splitting and merging identities is a= common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. >>>>=20 >>>> =20 >>>> I'm suggesting that the spec do less, not more. >>>>=20 >>>> =20 >>>> What the SCIM spec needs to do there is just refrain from introducing t= ight coupling. I would like to see a single identifier exposed through the A= PI, with the implication (and perhaps the recommendation) that it be the sha= red one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spli= t or merge identities, which is not desirable. So I recommend _taking out_ t= he "external id" field from the API. The spec shouldn't encourage tight coup= ling. If clients want to pass in their internal ids as part of the resource b= ody, no one can stop them, and they can always do a search on that attribute= to retrieve the URI exactly as you visualise they will with the "external i= d", but let's not elevate an anti-pattern to a recommendation by enshrining t= he "external id" as an acceptable attribute. >>>>=20 >>>> =20 >>>> Am I making sense? >>>>=20 >>>> =20 >>>> I see what you are saying. I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling.=20 >>>>=20 >>>> =20 >>>> IMHO loose coupling is a much more complex solution. The reality is tha= t each end-point has value to contribute and thus the single-owner model wil= l eventually need to become multi-owner or multi-hub.=20 >>>>=20 >>>> =20 >>>> That said i think the current model provides a practical starting point= .=20 >>>>=20 >>>> =20 >>>> > Regarding unique identifiers for multi-valued attributes there is a t= rade-off involved. On one hand this makes PATCH semantics easier. On the o= ther hand it puts extra burden on service providers.=20 >>>>=20 >>>>=20 >>>> Precisely. The spec has to strike the right balance. It would be intere= sting to hear from the other members of the spec mailing list. You know wher= e I stand on this. It would be good to hear the spectrum of opinions. >>>>=20 >>>> =20 >>>> Regards, >>>>=20 >>>> Ganesh >>>>=20 >>>> On 10 August 2012 00:28, Kelly Grizzle wr= ote: >>>>=20 >>>> Thanks Emmanuel. I had started writing up a similar response. As you s= uggest, storing this information in a mapping table outside of the SCIM spec= is a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsibl= e for the transport layer between domains. >>>>=20 >>>> =20 >>>> You could also model these ID mappings in the SCIM user as an extension= but would probably not want to expose these externally. Here is an example= of how to model the end state of the false positive scenario (splitting a u= ser): >>>>=20 >>>> =20 >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>>=20 >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>>>=20 >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >>>>=20 >>>> =20 >>>> This could be represented as two SCIM users that contain information ab= out the entities on other domains. >>>>=20 >>>> =20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:= federation:1.0"], >>>>=20 >>>> "id": "9caf78aac3d6", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "ff487230b3a0" >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:= federation:1.0"], >>>>=20 >>>> "id": "a99a5feba839", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "7a87f27c1dd8" >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>> In the second user, the linkedUsers attribute would be empty until the s= plit user was synced to domain 2. >>>>=20 >>>> =20 >>>> =20 >>>> Similarly, the false negative use case (merging two users) looked like t= his at the end: >>>>=20 >>>> =20 >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>>=20 >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>>>=20 >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >>>>=20 >>>> =20 >>>> This could be represented with the following SCIM user: >>>>=20 >>>> =20 >>>> { >>>>=20 >>>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:= federation:1.0"], >>>>=20 >>>> "id": "9caf78aac3d6", >>>>=20 >>>> "userName": "John Smith", >>>>=20 >>>> "urn:scim:schemas:extension:federation:1.0": { >>>>=20 >>>> "linkedUsers": [ >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "ff487230b3a0" >>>>=20 >>>> }, >>>>=20 >>>> { >>>>=20 >>>> "domain": "D2", >>>>=20 >>>> "externalEntityId": "41206cc97c8b", >>>>=20 >>>> "deletionRequired": true >>>>=20 >>>> } >>>>=20 >>>> ] >>>>=20 >>>> } >>>>=20 >>>> } >>>>=20 >>>> =20 >>>> =20 >>>> Regarding unique identifiers for multi-valued attributes there is a tra= de-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Since the inception of S= CIM, a key goal has been to foster adoption by service providers by making t= hings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servic= e provider. I also think that vendors that have a non-SCIM-compliant API wi= ll choose to keep things that way if the spec is too hard for them to implem= ent. In a green field environment we do have the luxury of mandating a mode= l to make certain operations more elegant. However, we can=E2=80=99t ignore= legacy systems. >>>>=20 >>>> =20 >>>> --Kelly >>>>=20 >>>> =20 >>>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of= Emmanuel Dreux >>>> Sent: Thursday, August 09, 2012 3:18 AM >>>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>>> Cc: scim@ietf.org >>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>> Hi Ganesh, >>>>=20 >>>> =20 >>>> Nothing prevents you in your SCIM implementation (client or server) to g= enerate a unique identifier for each synchronized object and maintain an int= ernal mapping table ( you would have to map group membership as well). >>>>=20 >>>> =20 >>>> This is what we are doing with Active Directory sources or targets: >>>>=20 >>>> As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAc= countName, UPN) are subject to change (even objectGuid can change if an AD d= omain is migrated), we decided to generate and maintain an internal table of= ids. This fits your requirements as it hides internal ids. >>>>=20 >>>> =20 >>>> This was written in dotnet and we have started a project to rewrite our= SCIM stack in PHP and will give it to the Open Source community. This imple= mentation will have a parameter : AllocateIds versus UseExistingIDs. >>>>=20 >>>> This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or us= e them as unique ID. >>>>=20 >>>> =20 >>>> You can also implement such feature without violating the SCIM specs, o= r without asking to include it in the specs. >>>>=20 >>>> =20 >>>> -- >>>>=20 >>>> Regards, >>>>=20 >>>> Emmanuel Dreux >>>>=20 >>>> http://www.cloudiway.com >>>>=20 >>>> Tel: +33 4 26 78 17 58 >>>>=20 >>>> Mobile: +33 6 47 81 26 70 >>>>=20 >>>> skype: Emmanuel.Dreux >>>>=20 >>>> =20 >>>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>>> Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 >>>> =C3=80 : Kelly Grizzle >>>> Cc : scim@ietf.org >>>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>=20 >>>> =20 >>>> Hi Kelly, >>>> Thanks for your response. Let me first respond in brief to the two main= points you have made, and then elaborate on the first. >>>> 1. Why should domains not expose their internal identifiers to oth= er domains? >>>> a. >>>> We are designing a protocol for a federated system of domains, where al= l domains are co-equal peers. (In physics too, N-body problems are much hard= er than 2-body problems. :-) Therefore, assuming that there are only two pla= yers in the interaction makes this tightly coupled in a number of ways. We s= hould rely on messaging and notification, with encapsulation of domain-speci= fic data. >>>> b. >>>> In any non-trivial data store, there will always be the ongoing need to= merge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D an= d =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain should be able t= o handle this internal housekeeping freely, only notifying other domains whe= n convenient. Mapping of internal identifiers to external ones and maintaini= ng this mapping internally allows this loosely-coupled housekeeping to take p= lace. Sharing internal identifiers (or otherwise outsourcing the mapping of i= nternal to external identifiers) forces housekeeping activities to be done i= n lock-step across domains. >>>> c. >>>> Asynchronous interaction is not just a matter of a suitable wire protoc= ol which can be designed later. The data model plays a crucial role in enabl= ing or constraining such interaction. A tightly-coupled data model will forc= e the use of synchronous interactions, and the exposure of internal identifi= ers is a key part of this tight coupling. >>>> 2. The difficulty of assigning unique identifiers to the individual val= ues of multi-valued attributes: >>>> a. >>>> I'm not belittling the effort involved in migrating legacy data stores t= o such a model. However, in the larger historical context of cross-domain id= entity management, we are really at the very early stages. If a relatively n= ew discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subse= quent users of the spec, and this will have repercussions over many years or= even decades. >>>> b. >>>> If incumbent cloud providers find it hard to immediately adopt the dict= ionary model for existing multi-valued attributes, they can transition to th= is model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-= SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customer= s to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be= supported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrari= ly long period and gradually migrated to the SCIM-compliant API. The logisti= cs are not insurmountable, and shouldn't prevent the adoption of a dictionar= y model for multi-valued attributes. >>>> Elaboration of Point 1: >>>> When we consider federated identity across more than one domain, we hav= e to assume that domains are not necessarily master-slave in their interacti= on. The most generic interaction model is peer-to-peer, where entity lifecyc= le events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are fr= ee to respond to these events in an appropriate manner and at a time of thei= r convenience. >>>> A key set of lifecycle events for an entity is the merging and splittin= g of identity that is often required. >>>> The question =E2=80=9CIs this one entity?=E2=80=9D can be answered eith= er yes (positive) or no (negative). But sometimes, we can discover false pos= itives and false negatives in our data stores. >>>> Consider a case where customers sign up online, and two customers who a= re privacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, an= d also use the same date of birth (say, 1 Jan 1970) or similar attributes. T= he front-end application may make an intelligent (but incorrect) guess that t= hese two persons are the same, and re-assign the same identifier to the seco= nd person. This is a false positive. They appear to be the same entity, but t= hey're actually different. When the error is discovered, the identities will= need to be split, with a new identifier generated for one of them. >>>> Consider the opposite case where a customer signs up through two differ= ent portals or in two different sessions, using the names =E2=80=9CJSmith=E2= =80=9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be trea= ted as two different customers and assigned two unique identifiers. This is a= false negative. They appear to be two entities, but are actually the same. A= t a later stage, when the error is discovered, the identities will have to b= e merged, and one of the identifiers will have to be dropped. >>>> These are not theoretical use cases. They form a significant proportion= of the user base in most large Web-facing applications. Let's see how these= can be managed in a federated way by mapping internal identifiers to extern= al ones and only exposing external identifiers to other domains. >>>> a. False positives: >>>> Domain 1 has the following information about a customer in its data sto= re: >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1= 970=E2=80=9D} >>>> When requesting the provisioning of this entity in Domain 2, the follow= ing ID is returned by Domain 2: ff487230b3a0. >>>> Domain 1 then maintains the following in a mapping table and uses it fo= r translation when talking to Domain 2, taking care never to expose its inte= rnal identifier: >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> When the false positive is discovered and the entity is split, Domain 1= creates a new internal identifier and now has the following entity informat= ion. >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1= 970=E2=80=9D} >>>> Internal ID: a99a5feba839 >>>> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1= 970=E2=80=9D} >>>> This second entity with its own internal identifier is invisible to Dom= ain 2, and this is by design. Communication about the original entity takes p= lace as before by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff48723= 0b3a0=E2=80=9D and vice-versa. At some convenient time (importantly, this do= esn't have to be at the time the split happens), Domain 2 can be requested t= o provision a second entity, and when it responds with an identifier of =E2=80= =9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record= associated with the second entity's internal identifier. >>>> The mapping table now contains the following entries: >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>> Domain 2 is not even aware that a split has happened, and the provision= ing that it does is not in lockstep with the split in identity that occurred= in Domain 1. >>>> (What is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we= cover the treatment of false negatives.) >>>> b. False negatives: >>>> Domain 1 has the following information about what it thinks are two dis= tinct customers in its data store: >>>> Internal ID: 9caf78aac3d6 >>>> Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2= =80=9D} >>>> Internal ID: 273d36e30d09 >>>> Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2= =80=9D} >>>> When requesting the provisioning of these entities in Domain 2, the fol= lowing IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. >>>> Domain 1 then maintains the following in a mapping table and uses it fo= r translation when talking to Domain 2, taking care never to expose its inte= rnal identifiers: >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>> When the false negative is discovered and the two entities are merged, D= omain 1 drops one of the internal identifiers and rationalises the name of t= he customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the= first ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the second =E2=80=9C273d3= 6e30d09=E2=80=9D. >>>> The mapping table now looks like this: >>>> | Internal Entity ID | External Domain ID | External Entity ID | Primar= y flag | >>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>> Now two external identifiers map to the same internal one, so inbound c= ommunication from Domain 2 can be unambi >>>=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 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-3F975445-8739-4EBA-A42C-CFB8B92E7E91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
That's a huge imposition o= n the client. 

Not sure about your arg on serv= er side. It depends on the store implemetation i suppose. 

Phil<= /div>

On 2012-08-11, at 9:50, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

Phil,

The re= ason we cannot use the value itself to identify an element is that this meth= od will only work for simple elements, not for nested structures. i.e., if w= e had an array of dictionaries (e.g., we had to record an array of addresses= for each customer, with each address element having sub-elements like stree= t number, street name, suburb, etc.), then it would be clumsy to supply the e= ntire value of the array element because it's itself a dictionary. Creating a= unique key for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> wrote:
Ganesh,
Here's the sample that concerned me...
The two operations differ significantly, and i= t's not very intuitive. 
With my suggestion, here's how to de= lete a single member from a group:

PATCH /Groups/a= cbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.<= span style=3D"font-family:monospace;font-size:11px;white-space:pre-wrap">281= 9c223-7f76-453a-919d-413861904646"
}
}
] }


You gave other examples of an attribute with an identifier that mat= ched that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't s= ee the point of the extra indexing to support this. Just use the value as th= e item you wish to delete.

I agree, the delete value operation could be more exp= licit and clear in general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:
>  For the multi-value example you gave you used the value as the attribute nam= e key. 

Now I'm confused :-). I don't believe any of= my examples ever used a value as the key.

Could you please show me which example you mean, and which parts of it you b= elieve to be the value?

Regards,
Ganesh&n= bsp;

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wrote:

For the mult= i-value example you gave you used the value as the attribute name key. =

That means a lot more complex indexing structure. Better= to just say delete a specific value. 

The spe= c already allows multiple values to have tags like home, work, etc.

Phil

On 2012-08-10, at 2= 1:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value with an attribute id.&nb= sp;

I don't believe so.

I'm adopting a model where= every attribute of the resource is a key-value pair. The key is a name or I= D.

For non-repeating attributes (both simple and composite)= , the key is the attribute name itself. 

= Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes= , the key employs dot notation to specify the fully-qualified attribute name= , e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that t= here be new keys for each individual value, otherwise they are impossible to= distinguish, and a positional index is inadequate. So we convert the array i= nto a dictionary and this then becomes a composite attribute using dot notat= ion for the key.

Multi-valued attribute:

Key: "e= mails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbi= trarily deep resource structure. We can refer to every leaf value with a key= that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly add= ressable attributes.

INCLUDE to a collection and sp= ecify only the value. The key is generated and returned. The fully-qualified= key is <collection-name>.<newly-generated-ID> and the value is w= hat was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the k= ey doesn't exist, return a "404 Not Found".

PLACE a= value at the logical location implied by the fully-qualified key. If there i= s already a key with that name, return a "409 Conflict".

FORCE the fully-qualified key to hold the given value, r= egardless of whether it existed before or not. Only errors possible are "400= Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified= key. The implementation will determine whether the attribute will disappear= entirely or will exist holding a null value (the blank string "" or the emp= ty object {} ).

I'll explain in a separate post why we need operation ve= rbs like these that are independent of the HTTP verbs.

<= div>Regards,
Ganesh

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

htt= ps://www.ietf.org/mailman/listinfo/scim

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt= )


---------- Forwarded message ----------
From: Phil Hunt <= phil.hunt@oracle.c= om>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <edreux@cloudiway.com>= , Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com&= gt;, "scim@ietf.org" &= lt;scim@ietf.org><= br> Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM P= rotocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value w= ith an attribute id. I find that confusing. 

I agree though that operations in patch could be a lot m= ore explicit. 

Eg explicitly deleting a value b= y saying delete or retire. 

Phil

On 2012-08= -10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am concerned about your second suggestion: 

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipul= ate resources becomes so much cleaner, consistent and intuitive when every i= ndividual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current spec:<= /div> 

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the cur= rent spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuiti= ve. 
With my suggestion, here's how to delete a single member= from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4= fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.<= span style=3D"font-family:monospace;font-size:11px;white-space:pre-wrap">281= 9c223-7f76-453a-919d-413861904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent= and more intuitive to a reader.

Pro 2: We can appl= y this mechanism consistently to three areas:
(a) Manipulating mul= ti-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk opera= tions, where we simply use HTTP verbs instead of the specialised (and semant= ically less ambiguous) verbs I suggested for attributes, the "key" becomes t= he URI, and the "value" becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results"= array holding individual status codes.

In the curr= ent spec, (a) and (b) are done similarly but (c) is very different.

Pro 3: Adoption of the standard by clients is likely to b= e higher because it's simpler for them.

Pro 4: New (= not incumbent) cloud providers will probably find this easier to implement b= ecause they have no legacy. They will probably use some form of NoSQL databa= se and won't be constrained by the limitations of LDAP directories.

Cons:

Con 1: Incumbent cloud pr= oviders with existing data stores in a directory format (where multi-valued a= ttributes are stored as comma-separated values under a single attribute node= ) will find it difficult to migrate to this model and store each attribute v= alue as a sub-node with its own key. This will "hinder adoption of the spec"= , which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased= of course, so I could have missed a Con or hyped a Pro :-).

I= n other words, we're debating interface complexity (current spec) versus imp= lementation complexity (my suggestion). Both can hinder adoption of the spec= by different parties.

Here's what we need to discuss - Do the Pros make the su= ggestion worth adopting in spite of the Cons, or are the Cons so great that i= t's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud providers= can cut both ways. It opens the door to a simpler interface offered by a ne= w generation of nimbler SPs that don't have the same legacy issues, and ther= e could be an exodus of clients to these new SPs. SCIM could end up being ob= soleted very soon, because the API interface is very complex and clumsy, as a= ny new reader can attest. I was taken aback by the complexity when I saw it,= which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peop= le, and they need to state their affiliations. If most people weighing in be= long to incumbent SPs and they vote in favour of interface complexity to avo= id implementation complexity, then it means the spec is not doing a good job= of balancing the interests of various groups. I think we should also poll c= lient organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate th= e capabilities of vendors (SPs). I believe Gartner should take the lead in r= epresenting client interests in this working group rather than those of incu= mbent vendors, which is what it seems like to me. Correct me if I'm being un= fair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <Mark.= Diodati@gartner.com> wrote:

Hi Ganesh,

<= div> 

I am concerned about y= our second suggestion:

=E2=80=9C2. When= dealing with multi-valued attributes of a resource (expressed as arrays in J= SON), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating i= t will be clumsy and inelegant.=E2=80=9D

 

One of the primary re= asons that SPML failed was lack of adoption by service providers due to its c= omplexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either v= 1 or v2), but not one of them was conformant to the SPML standard because of= complexity. If you are interested, I will forward you the research document= s that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial targ= et applications (i.e., service providers). I am confident that a requirement= for unique identifiers with multi-valued attributes will preclude its adopt= ion, because it requires major changes to the service provider=E2=80=99s existing identity storage mechani= sms.

Mark=

 
 
 

From: Trey Drake [mailto:trey.drake@unboundid.com= ]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@iet= f.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (belo= w).  

 

The externalID is not part of the protocol. &nbs= p;It is an *optional* attribute within the *schema* specification.  As f= or #2, the protocol spec works as you describe if "arbitrary URI parameters"= equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clari= fy your suggestion.

 

I'm not tracking your coupling concern.  Th= e client can search and hence retrieve resources on any attribute it chooses= , externalId or otherwise.  Nothing mandates use of externalId.  &= nbsp;

 
 

What do you mean by "candidate key"?  Given=  

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sash= i Prasad <g.c.p= rasad@gmail.com> wrote:

>  I think s= cim gets its current simplicity from its single owner hub spoke model implem= enting tight coupling. [...] IMHO loose coupling is a much more complex= solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight c= oupling =3D=3D simple" and "loose coupling =3D=3D complex". That's contrary t= o my experience.

 

When I say "loose coupling", I mean "no unnecess= ary dependencies". Invariably, a reduction in dependencies leads to greater s= implicity.

 

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orthogona= l aspects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and a= rbitrary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its inte= rnal ID as part of the resource body, inside some attribute defined by them (= but not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource= URIs using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will r= eturn exactly one URI, which is the canonical URI for the resource

https://example.com/v1/Users/2819c223-7f76-453a-919d-413861=
904646
3.=
 The client can use this URI to perform all other operations as usual.
 
So=
 taking 'externalID' out of the protocol spec only does this:
1.=
 It avoids enshrining tight coupling in the protocol (If clients want to tig=
htly couple themselves to the cloud provider by sending their internal IDs, t=
hey can do so. Suicide is OK, but the protocol should not be guilty of assis=
ted suicide. ;-)
2.=
 It encourages loose coupling by nudging clients towards maintaining their o=
wn internal-to-external identifier mappings.
 
Th=
at's what I'd like to see. I don't believe this complicates the protocol. It=
 simplifies it and it also lends itself to a loosely-coupled approach.
 
I'=
ll address the multi-valued attribute suggestion separately.
 
Re=
gards,
Ga=
nesh
 
 
 
 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com>= wrote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a gr= eat way to enable this solution.  Part of the key here is that SCIM is j= ust a piece of the architecture for this solution, and is only responsible f= or the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I provi= ded that example to illustrate that splitting and merging identities is a co= mmon requirement, and that decoupling local identifiers within a domain from= shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.<= /p>

 

What the SCIM spec needs to do there is just ref= rain from introducing tight coupling. I would like to see a single identifie= r exposed through the API, with the implication (and perhaps the recommendat= ion) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight cou= pling and ensures that both domains need simultaneously split or merge ident= ities, which is not desirable. So I recommend _taking out_ the "external id"= field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their intern= al ids as part of the resource body, no one can stop them, and they can alwa= ys do a search on that attribute to retrieve the URI exactly as you visualis= e they will with the "external id", but let's not elevate an anti-pattern to a recommendation by enshrinin= g the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets it= s current simplicity from its single owner hub spoke model implementing tigh= t coupling. 

 

IMHO loose coupling is a much more complex solut= ion. The reality is that each end-point has value to contribute and thus the= single-owner model will eventually need to become multi-owner or multi-hub.=  

 

That said i think the current model provides a p= ractical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-of= f involved.  On one hand this makes PATCH semantics easier.  On th= e other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interesting= to hear from the other members of the spec mailing list. You know where I s= tand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sa= ilpoint.com> wrote:

Thanks Emmanuel. = I had started writing up a similar response.  As you suggest, storing t= his information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that S= CIM is just a piece of the architecture for this solution, and is only respo= nsible for the transport layer between domains.

 

You could also model t= hese ID mappings in the SCIM user as an extension but would probably not wan= t to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a u= ser):

 

| Internal Entity ID | External Domain ID | External Entity ID |= Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| a99a5feba839       |= D2            &= nbsp;    | 7a87f27c1dd8       |= true         |

 

This could be represe= nted as two SCIM users that contain information about the entities on other d= omains.

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUser= s": [

      {

        "domain":= "D2",

        "ext= ernalEntityId": "ff487230b3a0"

 &n= bsp;    }

    ]

  }

}

 
<= p class=3D"MsoNormal"> {

  "schemas": ["urn:scim:= schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUser= s": [

      {

        "domain":= "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

 &n= bsp;    }

    ]

  }

}

&nbs= p;

In the second user, t= he linkedUsers attribute would be empty until the split user was synced to d= omain 2.

 
 

Similarly, the false n= egative use case (merging two users) looked like this at the end:

=
 

| Internal Entity ID | External Domain ID | External Entity ID |= Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6       |= D2            &= nbsp;    | 41206cc97c8b       |= false        |

 

This could be represe= nted with the following SCIM user:

=  

{

&= nbsp; "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:f= ederation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

    "linkedUser= s": [

      {

        "domain":= "D2",

        "ext= ernalEntityId": "ff487230b3a0"

 &n= bsp;    },

      {

        "domain":= "D2",

        "ext= ernalEntityId": "41206cc97c8b",

 = ;       "deletionRequired": true

      }

    ]

  }

}

 
 

Regarding unique iden= tifiers for multi-valued attributes there is a trade-off involved.  On o= ne hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception o= f SCIM, a key goal has been to foster adoption by service providers by makin= g things fit easily onto existing systems.  IMO the value gained by uni= que identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that= vendors that have a non-SCIM-compliant API will choose to keep things that w= ay if the spec is too hard for them to implement.  In a green field env= ironment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 

--Kelly

 

From: scim-bounces@ietf= .org [mailto:= scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,

&= nbsp;

Nothing prevents you i= n your SCIM implementation (client or server) to generate a unique identifie= r for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doing with Active Directory so= urces or targets:

As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAccoun= tName, UPN) are subject to change (even objectGuid can change if an AD domai= n is migrated), we decided to generate and maintain an internal table of ids.= This fits your requirements as it hides internal ids.

 

This was written in d= otnet and we have started a project to rewrite our SCIM stack in PHP and wil= l give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choice of =E2=80= =9Chiding=E2=80=9D internalIDs or use them as unique ID.

 

You can also implement such feature without viola= ting the SCIM specs, or without asking to include it in the specs.

 

--

Regards,=

Emmanuel Dr= eux

http://www.cloudiway.com=

Tel: +33 4 26 78 1= 7 58

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi Kelly,

Thanks for your r= esponse. Let me first respond in brief to the two main points you have made,= and then elaborate on the first.

1. = ;     Why should domains not ex= pose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1:

When we consider federated identity across more than one d= omain, we have to assume that domains are not necessarily master-slave in th= eir interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified to= other domains (when necessary) in an asynchronous manner (i.e., through mes= saging) and the other domains are free to respond to these events in an appr= opriate manner and at a time of their convenience.

A key set of lifecycle events for an entity is t= he merging and splitting of identity that is often required.

The question =E2=80=9CIs this one entity?=E2=80=9D can be a= nswered either yes (positive) or no (negative). But sometimes, we can discov= er false positives and false negatives in our data stores.

Consider a case where customers sign up online, and two cu= stomers who are privacy-conscious enter fake IDs such as =E2=80=9CJohn Smith= =E2=80=9D, and also use the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrec= t) guess that these two persons are the same, and re-assign the same identif= ier to the second person. This is a false positive. They appear to be the sa= me entity, but they're actually different. When the error is discovered, the identities will need to be spl= it, with a new identifier generated for one of them.

Consider the oppos= ite case where a customer signs up through two different portals or in two d= ifferent sessions, using the names =E2=80=9CJSmith=E2=80=9D and =E2=80=9CJoh= nS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped.

These are not theoretical use cases. They for= m a significant proportion of the user base in most large Web-facing applica= tions. Let's see how these can be managed in a federated way by mapping internal identifiers to external ones and only exposing external identifier= s to other domains.

a. False positives:

Domain 1 has the following information about a customer in= its data store:

Internal ID: 9caf78aac3d6

Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80= =9C01-Jan-1970=E2=80=9D}

When requesting the provisioning of this entit= y in Domain 2, the following ID is returned by Domain 2: ff487230b3a0.

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

When the false positive= is discovered and the entity is split, Domain 1 creates a new internal iden= tifier and now has the following entity information.

Inter= nal ID: 9caf78aac3d6

Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, d= ob: =E2=80=9C01-Jan-1970=E2=80=9D}

Inter= nal ID: a99a5feba839

Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, d= ob: =E2=80=9C01-Jan-1970=E2=80=9D}

This s= econd entity with its own internal identifier is invisible to Domain 2, and t= his is by design. Communication about the original entity takes place as bef= ore by mapping =E2=80=9C9caf78aac3d6=E2=80=9D to =E2=80=9Cff487230b3a0=E2=80=9D and vice-versa. At some convenient time (= importantly, this doesn't have to be at the time the split happens), Domain 2= can be requested to provision a second entity, and when it responds with an= identifier of =E2=80=9C7a87f27c1dd8=E2=80=9D, this can go into the mapping table as a new record associated with the second entity's inter= nal identifier.

The mapping table now contains the following entries:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| a99a5feba839 | D2 | 7a87f27c1dd8 | t= rue |

Domain 2 is not even aware that a split has happened, a= nd the provisioning that it does is not in lockstep with the split in identi= ty that occurred in Domain 1.

(What= is the =E2=80=9CPrimary flag=E2=80=9D used for? We'll see when we cover the= treatment of false negatives.)

b. False negatives:

Domain 1 has the following inform= ation about what it thinks are two distinct customers in its data store:

Inter= nal ID: 9caf78aac3d6

Attributes: {name: =E2=80=9CJSmith=E2=80=9D, dob: =E2= =80=9C01-Jan-1970=E2=80=9D}

Inter= nal ID: 273d36e30d09

Attributes: {name: =E2=80=9CJohnS=E2=80=9D, dob: =E2= =80=9C01-Jan-1970=E2=80=9D}

When r= equesting the provisioning of these entities in Domain 2, the following IDs a= re returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintains the following in a mapping table a= nd uses it for translation when talking to Domain 2, taking care never to ex= pose its internal identifiers:

| Internal Entity ID | External Domain ID | External Entity ID | Primary= flag |

|= 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 273d36e30d09 | D2= | 41206cc97c8b | true |

When the false negative is discovered and the two entities= are merged, Domain 1 drops one of the internal identifiers and rationalises= the name of the customer (say, to =E2=80=9CJohn Smith=E2=80=9D). Let's say it retains the first ID =E2=80=9C9caf78aac3d6=E2=80=9D and drops the se= cond =E2=80=9C273d36e30d09=E2=80=9D.

The mapping table now looks like t= his:

| Internal Entity ID | External Domain ID | External Entity ID | Primary= flag |

|= 9caf78aac3d6 | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | D2= | 41206cc97c8b | false |

Now two external identifiers map to the same internal one,= so inbound communication from Domain 2 can be unambi

=
=
________________= _______________________________

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


=
____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-3F975445-8739-4EBA-A42C-CFB8B92E7E91-- From g.c.prasad@gmail.com Sat Aug 11 09:19:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAF421F861F for ; Sat, 11 Aug 2012 09:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWFEz+UceaU1 for ; Sat, 11 Aug 2012 09:19:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6319B21F8619 for ; Sat, 11 Aug 2012 09:19:09 -0700 (PDT) Received: by bkty7 with SMTP id y7so1064096bkt.31 for ; Sat, 11 Aug 2012 09:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=c7wqVPCu+OIm+8hMpdL/x7DrZrScRCP8sDM5aqicHdk=; b=s4m74VseQ63kEHRvGieedF3RzC8HcFOFpgONpdUNohw/EAF2c7+mEzf2xZjGoeCo/d DRIyliytrpxHk7yn/K3G//iQ4SvYVx2BfRuzjGEHUqrTn0DMFkSDoCgang7Ugo2yKLvR PIR5uD0RCmbQl+3Jqx6710imxFDz7SiDpIHxngSJA5TnQaVFMBzl8cfMhOuzQfq/Avak ZJ7OIVrvI2wW8iQYpI0ccP9BJcwU+zZg5Wh9d94KhRgNTsAwCg2NXVEHAHgdTEJIqtYp bImpiVoqmoLhTM75PMNZw3ag+hoWDXCPx78qMloqNg1OrRlUC+AygveASA4sKmxSrJPO rwaw== Received: by 10.205.127.131 with SMTP id ha3mr2397965bkc.123.1344701948321; Sat, 11 Aug 2012 09:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 09:18:46 -0700 (PDT) In-Reply-To: <5159F724-D64F-470C-900A-D7B17A7BC6A5@unboundid.com> References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <5159F724-D64F-470C-900A-D7B17A7BC6A5@unboundid.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 02:18:46 +1000 Message-ID: To: Trey Drake Content-Type: multipart/alternative; boundary=0015173fe4acf5606b04c6ffd1fe Cc: "scim@ietf.org" , Emmanuel Dreux , Kelly Grizzle , Phil Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:19:15 -0000 --0015173fe4acf5606b04c6ffd1fe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > And that's because? I don't see any value to the behavior (enabling attribute searches on non-existent schema) you suggest. I wasn't suggesting there was value in it. I was covering the possibility that the client could erroneously send URI parameters that are not valid attributes of the resource, and the only response to such requests is a "400 Bad Request". > My question is why do you believe an SP ought to care about "candidate keys"? Resources are uniquely identified exactly 1 way by the SP and that is by the SP minted id. The Consumer can retrieve a resource by any attribute though only the id is guaranteed to be unique from the POV of the SP. The SCIM model is a *mapping* between the consumer and SP hence it is not a prescription for how the Resource data is actually stored on either side. I think we may actually be in violent agreement here! Your description exactly matches my recommendation of a data model that is loosely-coupled between client and SP. The SP should not care about "candidate keys", of course. But if one of the attributes of the resource happens to be a client-internal key, then the _client_ knows that it is a candidate key, and that any search based on the candidate key will return at most one URI with the "SP minted ID". This is what I'd like to see in the SCIM spec. There is only one key exposed _as a key_ between client and SP, and that is the "SP minted ID". There is no _special_ attribute in the API called an "external ID". If the client wants to embed its internal identifier as an attribute within the resource, it is free to do so. The SP will treat it as just another attribute and will not even bother to impose a uniqueness constraint on it. > If externalId were dropped it wouldn't bother me a bit. Good. Does anyone have an actual _objection_ to dropping the "externalID" field? As I said above, it doesn't prevent a client from sending such an attribute as an ordinary attribute and doing searches on it. Keeping the SP ignorant of its status as a key within the client decouples the two parties to some extent, so dropping the specially-named "externalID" is desirable. Regards, Ganesh On 12 August 2012 01:59, Trey Drake wrote: > On Aug 10, 2012, at 5:38 PM, Ganesh and Sashi Prasad > wrote: > > Trey, > > > The externalID is not part of the protocol. It is an *optional* > attribute within the *schema* specification. > > I didn't realise SCIM was also specifying a User schema. Does this mean > the User resource can only hold certain attributes as defined by this > schema? If so, that's going to be a severe constraint, because client > organisations are likely to require many specialised User attributes > depending on the nature of their business, and they will expect to be abl= e > to store all of them, not just the subset defined by the SCIM spec. I hop= e > the SCIM User schema is not trying to be just a representation of > inetOrgPerson (the standard LDAP schema), because that could be severely > limiting. Most organisations with their own LDAP end up extending > inetOrgPerson, and they will expect that they can do the same in the clou= d. > > I recommend you read the relevant specifications. The working group has > accepted both a schema and protocol draft as input to the effort. > > > As for #2, the protocol spec works as you describe if "arbitrary URI > parameters" equate to resource attributes > > Yes, that's what I meant, but in implementation, it may work out to be > looser than that. The client should be able to specify any arbitrary > attribute in the search parameters, even those that aren't attributes of > the resource. If an attribute is not defined, or if the attribute exists > but the value doesn't match any stored record, the SP will return no > results. In the former case, it's a "400 Bad Request" and in the latter, > it's a "404 Not Found". > > And that's because? I don't see any value to the behavior (enabling > attribute searches on non-existent schema) you suggest. > > > By "candidate key" (a data modelling term), I meant another attribute tha= t > also uniquely identifies a single record, but is not the official "primar= y > key", i.e., the main ID. In this case, a client's internal identifier als= o > uniquely identifies a record, but is not the ID used in the URI of RESTfu= l > operations. > > > I know what a candidate key is. My question is why do you believe an SP > ought to care about "candidate keys"? Resources are uniquely identified > exactly 1 way by the SP and that is by the SP minted id. The Consumer ca= n > retrieve a resource by any attribute though only the id is guaranteed to = be > unique from the POV of the SP. The SCIM model is a *mapping* between the > consumer and SP hence it is not a prescription for how the Resource data = is > actually stored on either side. > > > > Look, this may seem to be splitting hairs since a determined client may b= e > able to store and search by their own internal ID in either case (the > current SCIM spec or my suggestion). The difference is philosophical. If > the spec is showing how clients can store their internal IDs in the cloud > by explicitly providing for such an attribute, that constitutes bad advic= e, > IMO. If it turns a blind eye to what they store and they store internal I= Ds > anyway, they're constraining themselves but the spec comes out smelling o= f > roses because that's not "recommended practice". > > > If externalId were dropped it wouldn't bother me a bit. > > Ganesh > > On 11 August 2012 00:50, Trey Drake wrote: > >> Ganesh, >> >> I'll base my comments on your latest reply (below). >> >> The externalID is not part of the protocol. It is an *optional* >> attribute within the *schema* specification. As for #2, the protocol sp= ec >> works as you describe if "arbitrary URI parameters" equate to resource >> attributes (Allow generic search using 'GET /Users' and arbitrary URI >> parameters). Please clarify your suggestion. >> >> I'm not tracking your coupling concern. The client can search and hence >> retrieve resources on any attribute it chooses, externalId or otherwise. >> Nothing mandates use of externalId. >> >> >> What do you mean by "candidate key"? Given >> >> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >> g.c.prasad@gmail.com> wrote: >> >>> > I think scim gets its current simplicity from its single owner hub >>> spoke model implementing tight coupling. [...] IMHO loose coupling is a >>> much more complex solution. >>> >>> Phil, >>> >>> I'm a bit surprised that you're implying "tight coupling =3D=3D simple"= and >>> "loose coupling =3D=3D complex". That's contrary to my experience. >>> >>> When I say "loose coupling", I mean "no unnecessary dependencies". >>> Invariably, a reduction in dependencies leads to greater simplicity. >>> >>> Let's not confuse reduction of dependencies in the data model with a >>> hub-and-spokes architecture. They're entirely orthogonal aspects of the >>> solution. >>> >>> All that my suggestion involves is, >>> >>> 1. Take 'external ID' out of the protocol. >>> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >>> >>> No planned functionality is lost by this. >>> >>> 1. The client enterprise can still send its internal ID as part of the >>> resource body, inside some attribute defined by them (but not defined b= y >>> the protocol). Let's say they call it 'myID'. >>> 2. The client enterprise can search for resource URIs using any >>> attribute, including this internal ID >>> 'GET /Users?myID=3Dbjensen' >>> Since myID is a candidate key, the server will return exactly one URI, >>> which is the canonical URI for the resource >>> >>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>> >>> 3. The client can use this URI to perform all other operations as usual= . >>> >>> >>> So taking 'externalID' out of the protocol spec only does this: >>> >>> 1. It avoids enshrining tight coupling in the protocol (If clients want= to tightly couple themselves to the cloud provider by sending their intern= al IDs, they can do so. Suicide is OK, but the protocol should not be guilt= y of assisted suicide. ;-) >>> >>> 2. It encourages loose coupling by nudging clients towards maintaining = their own internal-to-external identifier mappings. >>> >>> >>> That's what I'd like to see. I don't believe this complicates the proto= col. It simplifies it and it also lends itself to a loosely-coupled approac= h. >>> >>> >>> I'll address the multi-valued attribute suggestion separately. >>> >>> >>> Regards, >>> >>> Ganesh >>> >>> >>> >>> >>> On 10 August 2012 07:53, Phil Hunt wrote: >>> >>>> >>>> >>>> Phil >>>> >>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>>> wrote: >>>> >>>> > storing this information in a mapping table outside of the SCIM >>>> spec is a great way to enable this solution. Part of the key here is = that >>>> SCIM is just a piece of the architecture for this solution, and is onl= y >>>> responsible for the transport layer between domains. >>>> >>>> I wasn't suggesting that the mapping table be part of the SCIM spec. I >>>> provided that example to illustrate that splitting and merging identit= ies >>>> is a common requirement, and that decoupling local identifiers within = a >>>> domain from shared identifiers between domains was the best way to >>>> facilitate it. >>>> >>>> I'm suggesting that the spec do less, not more. >>>> >>>> What the SCIM spec needs to do there is just refrain from introducing >>>> tight coupling. I would like to see a single identifier exposed throug= h the >>>> API, with the implication (and perhaps the recommendation) that it be = the >>>> shared one. Allowing one domain to expose its internal identifier to t= he >>>> other creates tight coupling and ensures that both domains need >>>> simultaneously split or merge identities, which is not desirable. So I >>>> recommend _taking out_ the "external id" field from the API. The spec >>>> shouldn't encourage tight coupling. If clients want to pass in their >>>> internal ids as part of the resource body, no one can stop them, and t= hey >>>> can always do a search on that attribute to retrieve the URI exactly a= s you >>>> visualise they will with the "external id", but let's not elevate an >>>> anti-pattern to a recommendation by enshrining the "external id" as an >>>> acceptable attribute. >>>> >>>> Am I making sense? >>>> >>>> >>>> I see what you are saying. I think scim gets its current simplicity >>>> from its single owner hub spoke model implementing tight coupling. >>>> >>>> IMHO loose coupling is a much more complex solution. The reality is >>>> that each end-point has value to contribute and thus the single-owner = model >>>> will eventually need to become multi-owner or multi-hub. >>>> >>>> That said i think the current model provides a practical starting >>>> point. >>>> >>>> >>>> > Regarding unique identifiers for multi-valued attributes there is a >>>> trade-off involved. On one hand this makes PATCH semantics easier. O= n the >>>> other hand it puts extra burden on service providers. >>>> >>>> Precisely. The spec has to strike the right balance. It would be >>>> interesting to hear from the other members of the spec mailing list. Y= ou >>>> know where I stand on this. It would be good to hear the spectrum of >>>> opinions. >>>> >>>> Regards, >>>> Ganesh >>>> >>>> On 10 August 2012 00:28, Kelly Grizzle wr= ote: >>>> >>>>> Thanks Emmanuel. I had started writing up a similar response. As >>>>> you suggest, storing this information in a mapping table outside of t= he >>>>> SCIM spec is a great way to enable this solution. Part of the key he= re is >>>>> that SCIM is just a piece of the architecture for this solution, and = is >>>>> only responsible for the transport layer between domains.**** >>>>> >>>>> ** ** >>>>> >>>>> You could also model these ID mappings in the SCIM user as an >>>>> extension but would probably not want to expose these externally. He= re is >>>>> an example of how to model the end state of the false positive scenar= io >>>>> (splitting a user):**** >>>>> >>>>> ** ** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true |**** >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>> true |**** >>>>> >>>>> ** ** >>>>> >>>>> This could be represented as two SCIM users that contain information >>>>> about the entities on other domains.**** >>>>> >>>>> ** ** >>>>> >>>>> {**** >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>>> >>>>> "id": "9caf78aac3d6",**** >>>>> >>>>> "userName": "John Smith",**** >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>>> >>>>> "linkedUsers": [**** >>>>> >>>>> {**** >>>>> >>>>> "domain": "D2",**** >>>>> >>>>> "externalEntityId": "ff487230b3a0"**** >>>>> >>>>> }**** >>>>> >>>>> ]**** >>>>> >>>>> }**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> {**** >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>>> >>>>> "id": "a99a5feba839",**** >>>>> >>>>> "userName": "John Smith",**** >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>>> >>>>> "linkedUsers": [**** >>>>> >>>>> {**** >>>>> >>>>> "domain": "D2",**** >>>>> >>>>> "externalEntityId": "7a87f27c1dd8"**** >>>>> >>>>> }**** >>>>> >>>>> ]**** >>>>> >>>>> }**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> In the second user, the linkedUsers attribute would be empty until th= e >>>>> split user was synced to domain 2.**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> Similarly, the false negative use case (merging two users) looked lik= e >>>>> this at the end:**** >>>>> >>>>> ** ** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>> false |**** >>>>> >>>>> ** ** >>>>> >>>>> This could be represented with the following SCIM user:**** >>>>> >>>>> ** ** >>>>> >>>>> {**** >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"],**** >>>>> >>>>> "id": "9caf78aac3d6",**** >>>>> >>>>> "userName": "John Smith",**** >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": {**** >>>>> >>>>> "linkedUsers": [**** >>>>> >>>>> {**** >>>>> >>>>> "domain": "D2",**** >>>>> >>>>> "externalEntityId": "ff487230b3a0"**** >>>>> >>>>> },**** >>>>> >>>>> {**** >>>>> >>>>> "domain": "D2",**** >>>>> >>>>> "externalEntityId": "41206cc97c8b",**** >>>>> >>>>> "deletionRequired": true**** >>>>> >>>>> }**** >>>>> >>>>> ]**** >>>>> >>>>> }**** >>>>> >>>>> }**** >>>>> >>>>> ** ** >>>>> >>>>> ** ** >>>>> >>>>> Regarding unique identifiers for multi-valued attributes there is a >>>>> trade-off involved. On one hand this makes PATCH semantics easier. = On the >>>>> other hand it puts extra burden on service providers. Since the ince= ption >>>>> of SCIM, a key goal has been to foster adoption by service providers = by >>>>> making things fit easily onto existing systems. IMO the value gained= by >>>>> unique identifiers for multi-valued attributes is not worth the deman= ds put >>>>> on a service provider. I also think that vendors that have a >>>>> non-SCIM-compliant API will choose to keep things that way if the spe= c is >>>>> too hard for them to implement. In a green field environment we do h= ave >>>>> the luxury of mandating a model to make certain operations more elega= nt. >>>>> However, we can=92t ignore legacy systems. **** >>>>> >>>>> ** ** >>>>> >>>>> --Kelly**** >>>>> >>>>> ** ** >>>>> >>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>> Behalf Of *Emmanuel Dreux >>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>> *Cc:* scim@ietf.org >>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**= * >>>>> * >>>>> >>>>> ** ** >>>>> >>>>> Hi Ganesh,**** >>>>> >>>>> ** ** >>>>> >>>>> Nothing prevents you in your SCIM implementation (client or server) t= o >>>>> generate a unique identifier for each synchronized object and maintai= n an >>>>> internal mapping table ( you would have to map group membership as we= ll). >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> This is what we are doing with Active Directory sources or targets:**= * >>>>> * >>>>> >>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can c= hange >>>>> if an AD domain is migrated), we decided to generate and maintain an >>>>> internal table of ids. This fits your requirements as it hides intern= al ids. >>>>> **** >>>>> >>>>> ** ** >>>>> >>>>> This was written in dotnet and we have started a project to rewrite >>>>> our SCIM stack in PHP and will give it to the Open Source community. = This >>>>> implementation will have a parameter : AllocateIds versus UseExisting= IDs. >>>>> **** >>>>> >>>>> This will give the choice of =93hiding=94 internalIDs or use them as >>>>> unique ID.**** >>>>> >>>>> ** ** >>>>> >>>>> You can also implement such feature without violating the SCIM specs, >>>>> or without asking to include it in the specs.**** >>>>> >>>>> ** ** >>>>> >>>>> --**** >>>>> >>>>> Regards,**** >>>>> >>>>> Emmanuel Dreux**** >>>>> >>>>> http://www.cloudiway.com**** >>>>> >>>>> Tel: +33 4 26 78 17 58**** >>>>> >>>>> Mobile: +33 6 47 81 26 70**** >>>>> >>>>> skype: Emmanuel.Dreux**** >>>>> >>>>> ** ** >>>>> >>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>> >>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>> *=C0 :* Kelly Grizzle >>>>> *Cc :* scim@ietf.org >>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement***= * >>>>> >>>>> ** ** >>>>> >>>>> Hi Kelly,**** >>>>> >>>>> Thanks for your response. Let me first respond in brief to the two >>>>> main points you have made, and then elaborate on the first.**** >>>>> >>>>> **1. **Why should domains not expose their internal identifiers >>>>> to other domains?**** >>>>> >>>>> a.**** >>>>> >>>>> We are designing a protocol for a federated system of domains, where >>>>> all domains are co-equal peers. (In physics too, N-body problems are = much >>>>> harder than 2-body problems. :-) Therefore, assuming that there are o= nly >>>>> two players in the interaction makes this tightly coupled in a number= of >>>>> ways. We should rely on messaging and notification, with encapsulatio= n of >>>>> domain-specific data.**** >>>>> >>>>> b. **** >>>>> >>>>> In any non-trivial data store, there will always be the ongoing need >>>>> to merge and split identities as and when =93false negatives=94 and = =93false >>>>> positives=94 are discovered. A domain should be able to handle this i= nternal >>>>> housekeeping freely, only notifying other domains when convenient. Ma= pping >>>>> of internal identifiers to external ones and maintaining this mapping >>>>> internally allows this loosely-coupled housekeeping to take place. Sh= aring >>>>> internal identifiers (or otherwise outsourcing the mapping of interna= l to >>>>> external identifiers) forces housekeeping activities to be done in >>>>> lock-step across domains.**** >>>>> >>>>> c.**** >>>>> >>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>> protocol which can be designed later. The data model plays a crucial = role >>>>> in enabling or constraining such interaction. A tightly-coupled data = model >>>>> will force the use of synchronous interactions, and the exposure of >>>>> internal identifiers is a key part of this tight coupling.**** >>>>> >>>>> 2. The difficulty of assigning unique identifiers to the individual >>>>> values of multi-valued attributes:**** >>>>> >>>>> a. **** >>>>> >>>>> I'm not belittling the effort involved in migrating legacy data store= s >>>>> to such a model. However, in the larger historical context of cross-d= omain >>>>> identity management, we are really at the very early stages. If a >>>>> relatively new discipline and a brand new spec are held captive to le= gacy >>>>> considerations, we are losing an opportunity to provide a clean and e= legant >>>>> model to subsequent users of the spec, and this will have repercussio= ns >>>>> over many years or even decades.**** >>>>> >>>>> b. **** >>>>> >>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>> dictionary model for existing multi-valued attributes, they can trans= ition >>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-c= ompliant=94 >>>>> APIs to their customers and encouraging new customers to adopt the >>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradu= ally >>>>> migrated to the SCIM-compliant API. The logistics are not insurmounta= ble, >>>>> and shouldn't prevent the adoption of a dictionary model for multi-va= lued >>>>> attributes.**** >>>>> >>>>> Elaboration of Point 1:**** >>>>> >>>>> When we consider federated identity across more than one domain, we >>>>> have to assume that domains are not necessarily master-slave in their >>>>> interaction. The most generic interaction model is peer-to-peer, wher= e >>>>> entity lifecycle events within a domain are notified to other domains= (when >>>>> necessary) in an asynchronous manner (i.e., through messaging) and th= e >>>>> other domains are free to respond to these events in an appropriate m= anner >>>>> and at a time of their convenience.**** >>>>> >>>>> A key set of lifecycle events for an entity is the merging and >>>>> splitting of identity that is often required.**** >>>>> >>>>> The question =93Is this one entity?=94 can be answered either yes >>>>> (positive) or no (negative). But sometimes, we can discover false pos= itives >>>>> and false negatives in our data stores.**** >>>>> >>>>> Consider a case where customers sign up online, and two customers who >>>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and al= so use the >>>>> same date of birth (say, 1 Jan 1970) or similar attributes. The front= -end >>>>> application may make an intelligent (but incorrect) guess that these = two >>>>> persons are the same, and re-assign the same identifier to the second >>>>> person. This is a false positive. They appear to be the same entity, = but >>>>> they're actually different. When the error is discovered, the identit= ies >>>>> will need to be split, with a new identifier generated for one of the= m. >>>>> **** >>>>> >>>>> Consider the opposite case where a customer signs up through two >>>>> different portals or in two different sessions, using the names =93JS= mith=94 >>>>> and =93JohnS=94. It is very likely that they will be treated as two d= ifferent >>>>> customers and assigned two unique identifiers. This is a false negati= ve. >>>>> They appear to be two entities, but are actually the same. At a later >>>>> stage, when the error is discovered, the identities will have to be m= erged, >>>>> and one of the identifiers will have to be dropped.**** >>>>> >>>>> These are not theoretical use cases. They form a significant >>>>> proportion of the user base in most large Web-facing applications. Le= t's >>>>> see how these can be managed in a federated way by mapping internal >>>>> identifiers to external ones and only exposing external identifiers t= o >>>>> other domains.**** >>>>> >>>>> a. False positives:**** >>>>> >>>>> Domain 1 has the following information about a customer in its data >>>>> store:**** >>>>> >>>>> Internal ID: 9caf78aac3d6**** >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>>> >>>>> When requesting the provisioning of this entity in Domain 2, the >>>>> following ID is returned by Domain 2: ff487230b3a0.**** >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifier:**** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>>> >>>>> When the false positive is discovered and the entity is split, Domain >>>>> 1 creates a new internal identifier and now has the following entity >>>>> information.**** >>>>> >>>>> Internal ID: 9caf78aac3d6**** >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>>> >>>>> Internal ID: a99a5feba839**** >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** >>>>> >>>>> This second entity with its own internal identifier is invisible to >>>>> Domain 2, and this is by design. Communication about the original ent= ity >>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a= 0=94 and >>>>> vice-versa. At some convenient time (importantly, this doesn't have t= o be >>>>> at the time the split happens), Domain 2 can be requested to provisio= n a >>>>> second entity, and when it responds with an identifier of =937a87f27c= 1dd8=94, >>>>> this can go into the mapping table as a new record associated with th= e >>>>> second entity's internal identifier.**** >>>>> >>>>> The mapping table now contains the following entries:**** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** >>>>> >>>>> Domain 2 is not even aware that a split has happened, and the >>>>> provisioning that it does is not in lockstep with the split in identi= ty >>>>> that occurred in Domain 1.**** >>>>> >>>>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>>>> treatment of false negatives.)**** >>>>> >>>>> b. False negatives:**** >>>>> >>>>> Domain 1 has the following information about what it thinks are two >>>>> distinct customers in its data store:**** >>>>> >>>>> Internal ID: 9caf78aac3d6**** >>>>> >>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** >>>>> >>>>> Internal ID: 273d36e30d09**** >>>>> >>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** >>>>> >>>>> When requesting the provisioning of these entities in Domain 2, the >>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b= . >>>>> **** >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifiers:**** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>>> >>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true |**** >>>>> >>>>> When the false negative is discovered and the two entities are merged= , >>>>> Domain 1 drops one of the internal identifiers and rationalises the n= ame of >>>>> the customer (say, to =93John Smith=94). Let's say it retains the fir= st ID >>>>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** >>>>> >>>>> The mapping table now looks like this:**** >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** >>>>> >>>>> Now two external identifiers map to the same internal one, so inbound >>>>> communication from Domain 2 can be unambiguously translated to the sa= me >>>>> entity internally. However, when going outwards, Domain 1 will have t= o look >>>>> up the translation table to determine the =93primary=94 external ID f= or this >>>>> entity in Domain 2, which was decided to be =93ff487230b3a0=94. That'= s where >>>>> the =93Primary flag=94 comes in. The second external ID =9341206cc97c= 8b=94 is never >>>>> used thereafter in outbound communication.**** >>>>> >>>>> At some stage (importantly, not in lockstep with the identity merge), >>>>> Domain 2 can be requested to delete the customer record identified by >>>>> =9341206cc97c8b=94, and the second entry in the mapping table can be = removed >>>>> once this is acknowledged.**** >>>>> >>>>> This scheme will scale up to multiple domains, because the =93Externa= l >>>>> Domain ID=94 column helps to keep track of which external ID is share= d with >>>>> which Domain. (Why don't we use just one external ID for an entity an= d >>>>> share it with all external domains? Tight coupling again. Just as OAu= th >>>>> allows an access token given to a third party to be invalidated witho= ut >>>>> affecting the access of other third parties, the use of separate exte= rnal >>>>> identifiers for different domains allows fine-grained control of iden= tity >>>>> federation.)**** >>>>> >>>>> The scheme also allows the splitting of an entity into more than two >>>>> entities, and the merging of more than two entities into a single one= . (Any >>>>> organisation with a web-facing application will tell you how many Joh= n >>>>> Smiths there are who were born on 1 Jan 1970!)**** >>>>> >>>>> This is a fairly long-winded explanation, but this is why we need to >>>>> hide internal identifiers from other domains, and why mappings need t= o be >>>>> managed internally in each domain. Such a data model also allows us t= o >>>>> choose asynchronous protocols for propagation of identity events, sin= ce >>>>> there is no consistency requirement to update multiple domains concur= rently. >>>>> **** >>>>> >>>>> Regards, **** >>>>> >>>>> Ganesh Prasad**** >>>>> >>>>> ** ** >>>>> >>>>> On 9 August 2012 04:55, Kelly Grizzle >>>>> wrote:**** >>>>> >>>>> Thanks for the feedback, Ganesh. I read through this and your InfoQ >>>>> article (http://www.infoq.com/articles/scim-data-model-limitations) >>>>> and have some thoughts.**** >>>>> >>>>> **** >>>>> >>>>> > The rest of the protocol does not meaningfully use the enterprise >>>>> client=92s identifier, the "external ID"**** >>>>> >>>>> > at all, even though it was ostensibly introduced to make things >>>>> friendlier for the client.**** >>>>> >>>>> **** >>>>> >>>>> The usage pattern for an external ID would be to search for a user by >>>>> externalId and use the ID of the returned user in any desired operati= on. >>>>> For example:**** >>>>> >>>>> **** >>>>> >>>>> GET /Users?filter=3DexternalId eq =93bjensen=94&attributes=3Did**** >>>>> >>>>> **** >>>>> >>>>> {**** >>>>> >>>>> =93totalResults=94: 1,**** >>>>> >>>>> =93Resources=94: [**** >>>>> >>>>> {**** >>>>> >>>>> =93id=94: =932819c223-7f76-453a-919d-413861904646=94**** >>>>> >>>>> }**** >>>>> >>>>> ]**** >>>>> >>>>> }**** >>>>> >>>>> **** >>>>> >>>>> Retrieve the ID from the response and use it.**** >>>>> >>>>> **** >>>>> >>>>> DELETE /Users/2819c223-7f76-453a-919d-413861904646**** >>>>> >>>>> **** >>>>> >>>>> This does introduce an additional HTTP request if the client chooses >>>>> not to store the server=92s id. An issue was created to consider all= owing >>>>> operations to use the externalId ( >>>>> http://code.google.com/p/scim/issues/detail?id=3D35), but I believe t= he >>>>> general consensus has been to not include this in the spec. One main= point >>>>> of contention is that much of the rest of the spec (eg =96 group memb= ership >>>>> references, manager references, etc=85) require knowledge of the serv= er=92s >>>>> identifier. Continuing this discussion on the IETF list would be a g= ood >>>>> thing, though.**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> > the cloud provider's ID and the enterprise client's ID are both >>>>> "Internal IDs" with respect to their domains**** >>>>> >>>>> **** >>>>> >>>>> I think this comes down to a nomenclature problem. The server=92s ID >>>>> does not necessarily have to be the unique identifier that the underl= ying >>>>> identity store uses, it just has to be stable and unique. In many ca= ses, >>>>> the underlying identity store will provide identifiers with these >>>>> properties already (eg =96 a uuid) and it can be used by the SCIM int= erface. >>>>> The =93externalId=94 is referring to the fact that the id is maintain= ed >>>>> external to the SCIM server. As long as the server=92s identifiers a= re >>>>> stable and unique (which is mandated by the spec), I don=92t see a pr= oblem. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> > The secret is that *every value needs a key*, and multi-valued >>>>> attributes lack that. So our solution is quite**** >>>>> >>>>> > simple - turn every list or array (of values) into a dictionary (of >>>>> key-value pairs) by providing each value**** >>>>> >>>>> > with a unique and meaning-free identifier.**** >>>>> >>>>> **** >>>>> >>>>> I agree that this would be useful, especially in the PATCH operation. >>>>> One reason that this wasn=92t included in the spec originally is that= it can >>>>> put undue burden on the service provider. Many service providers are >>>>> putting SCIM interfaces in front of their existing identity stores (e= g =96 >>>>> directory servers, SaaS application databases, etc=85). Many of thes= e do not >>>>> have a unique identifier for multi-valued attributes. By requiring t= his, a >>>>> majority of the server providers would have to start maintaining a un= ique >>>>> key for each multi-valued attribute. I believe this would be a roadb= lock >>>>> for many implementers.**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> > When the SCIM protocol uses PATCH, there are areas where it seems a >>>>> bit clumsy.**** >>>>> >>>>> **** >>>>> >>>>> I like the thoughts here. Your example reminds me of unified diffs ( >>>>> http://en.wikipedia.org/wiki/Diff#Unified_format), which are commonly >>>>> used with a patch program (pretty much the equivalent of the PATCH ve= rb). >>>>> However, the three proposals seem to largely hinge on being able to >>>>> uniquely address each element within an object. Without these it is = not so >>>>> easy to address each patch sub-operation (REPLACE, INCLUDE, etc=85) o= r >>>>> provide a multi-status.**** >>>>> >>>>> >>>>> The 207 response would be interesting to consider for the bulk >>>>> endpoint ( >>>>> http://www.simplecloud.info/specs/draft-scim-api-00.html#bulk-resourc= es), >>>>> however.**** >>>>> >>>>> **** >>>>> >>>>> **** >>>>> >>>>> > There are other, non-data aspects of SCIM which may require review, >>>>> such as its synchronous request-response**** >>>>> >>>>> > interaction model, which is a form of tight coupling and could prov= e >>>>> to be a source of brittleness.**** >>>>> >>>>> **** >>>>> >>>>> I agree that we should explore optional asynchronous requests in 2.0.= * >>>>> *** >>>>> >>>>> **** >>>>> >>>>> Thanks again for your thoughts. I hope you stay involved in the >>>>> discussion as work on SCIM 2.0 goes forward.**** >>>>> >>>>> **** >>>>> >>>>> --Kelly**** >>>>> >>>>> **** >>>>> >>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>> Behalf Of *Ganesh and Sashi Prasad >>>>> *Sent:* Wednesday, August 01, 2012 4:24 PM >>>>> *To:* scim@ietf.org >>>>> *Subject:* [scim] SCIM Protocol - 3 suggestions for improvement**** >>>>> >>>>> **** >>>>> >>>>> (I posted this on the SCIM Google Group, and I was advised to >>>>> subscribe to the mailing list and post it here instead, so here goes.= ) >>>>> **** >>>>> >>>>> **** >>>>> >>>>> Hi,**** >>>>> >>>>> **** >>>>> >>>>> My name is Ganesh Prasad, and my experience in Identity and Access >>>>> Management is mainly through a 3-year project at an Australian insura= nce >>>>> company, an experience I have written about as a eBook on InfoQ ( >>>>> http://www.infoq.com/minibooks/Identity-Management-Shoestring).**** >>>>> >>>>> **** >>>>> >>>>> I have been following the SCIM spec off and on, and based on my >>>>> experience with a loosely-coupled architecture that I found to be >>>>> successful, I have the following 3 suggestions to make.**** >>>>> >>>>> **** >>>>> >>>>> 1. The enterprise client and the cloud provider should maintain their >>>>> own internal IDs for a resource, which they should not reveal to each >>>>> other. Both of them should map their internal IDs to a shared Externa= l ID, >>>>> and this is the only ID that should be exposed through the API. The c= urrent >>>>> specification's provision of an id (which is the external ID and the = only >>>>> one to be transferred through the API) and an "external ID" (which is= the >>>>> client's internal ID and should be hidden) is diametrically opposite = to >>>>> this.**** >>>>> >>>>> **** >>>>> >>>>> 2. When dealing with multi-valued attributes of a resource (expressed >>>>> as arrays in JSON), they must be converted from an array into a dicti= onary >>>>> with unique keys (UUIDs generated by the cloud provider when the attr= ibute >>>>> is created). Without unique keys for every attribute value of a resou= rce, >>>>> manipulating it will be clumsy and inelegant.**** >>>>> >>>>> **** >>>>> >>>>> 3. The PATCH command can be improved in 3 significant ways:**** >>>>> >>>>> 3a. Leverage the fact (from 2 above) that every value has a key, to >>>>> greatly simplify the API**** >>>>> >>>>> 3b. Use special verbs as nested operations of the PATCH command to >>>>> add, modify and delete attributes at any level**** >>>>> >>>>> 3c. Use the WebDAV status code of "207 Multi-Status" instead of "200 >>>>> OK" as the response to a PATCH (or BULK) command.**** >>>>> >>>>> **** >>>>> >>>>> To elaborate,**** >>>>> >>>>> **** >>>>> >>>>> 1. Revealing private IDs externally is a form of tight coupling. A >>>>> major requirement with Identity Management is to split (or merge) >>>>> identities when false positives (or false negatives) are detected, i.= e., >>>>> when a resource is discovered to be more than one, or when multiple >>>>> resources are detected to be the same. If internal identifiers are re= vealed >>>>> to external domains, such clean-ups become difficult, hence every dom= ain >>>>> that wants to expose references to a resource must map its internal I= D to >>>>> and external one created for this explicit purpose, and only reveal t= his. >>>>> **** >>>>> >>>>> **** >>>>> >>>>> In the SCIM case, when an enterprise client POSTs a resource creation >>>>> request, the cloud provider must generate its own internal UUID as we= ll as >>>>> an external UUID, map them together, and only return the external UUI= D in >>>>> the "Location:" header. The enterprise client should map this externa= l UUID >>>>> to a newly-generated internal ID of its own. In case the resource alr= eady >>>>> has an identifier within the enterprise client's domain, then this is= the >>>>> internal ID that must be mapped to the external UUID returned through= the >>>>> POST response.**** >>>>> >>>>> **** >>>>> >>>>> 2. If a resource is to be created, and one of its attributes is >>>>> multi-valued, e.g.,**** >>>>> >>>>> **** >>>>> >>>>> "email-addrs" : **** >>>>> >>>>> [**** >>>>> >>>>> "john_smith@yahoo.com",**** >>>>> >>>>> "john.smith@gmail.com",**** >>>>> >>>>> "jsmith1970@hotmail.com"**** >>>>> < >>>>> >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>>> >>> >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >> > > --0015173fe4acf5606b04c6ffd1fe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0And that's because? =A0I don't see any value to the behavior= (enabling attribute searches on non-existent schema) you suggest.=A0
I wasn't suggesting there was val= ue in it. I was covering the possibility that the client could erroneously = send URI parameters that are not valid attributes of the resource, and the = only response to such requests is a "400 Bad Request".

>=A0 My question is why do you believe an SP ought to care about "candidate= keys"? =A0 Resources are uniquely identified exactly 1 way by the SP = and that is by the SP minted id. =A0The Consumer can retrieve a resource by= any attribute though only the id is guaranteed to be unique from the POV o= f the SP. =A0The SCIM model is a *mapping* between the consumer and SP henc= e it is not a prescription for how the Resource data is actually stored on = either side.=A0

I think we may actually be in violent agreement here! Y= our description exactly matches my recommendation of a data model that is l= oosely-coupled between client and SP. The SP should not care about "ca= ndidate keys", of course. But if one of the attributes of the resource= happens to be a client-internal key, then the _client_ knows that it is a = candidate key, and that any search based on the candidate key will return a= t most one URI with the "SP minted ID".

This is what I'd like to see in the SCIM spec. Ther= e is only one key exposed _as a key_ between client and SP, and that is the= "SP minted ID". There is no _special_ attribute in the API calle= d an "external ID". If the client wants to embed its internal ide= ntifier as an attribute within the resource, it is free to do so. The SP wi= ll treat it as just another attribute and will not even bother to impose a = uniqueness constraint on it.

>=A0If externalId were dropped it wouldn't bothe= r me a bit. =A0

Good= . Does anyone have an actual _objection_ to dropping the "externalID&q= uot; field? As I said above, it doesn't prevent a client from sending s= uch an attribute as an ordinary attribute and doing searches on it. Keeping= the SP ignorant of its status as a key within the client decouples the two= parties to some extent, so dropping the specially-named "externalID&q= uot; is desirable.

Regards,
Ganesh

On 12 August 2012 01:59, Trey Drake <trey.drake@unboundid.co= m> wrote:
On Aug 10, 2012, at 5:38 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com= > wrote:

Trey,<= /span>

> The externalID is not part of the protocol. =A0= It is an *optional* attribute within the *schema* specification.

I didn't realise = SCIM was also specifying a User schema. Does this mean the User resource ca= n only hold certain attributes as defined by this schema? If so, that's= going to be a severe constraint, because client organisations are likely t= o require many specialised User attributes depending on the nature of their= business, and they will expect to be able to store all of them, not just t= he subset defined by the SCIM spec. I hope the SCIM User schema is not tryi= ng to be just a representation of inetOrgPerson (the standard LDAP schema),= because that could be severely limiting. Most organisations with their own= LDAP end up extending inetOrgPerson, and they will expect that they can do= the same in the cloud.

I recommend you re= ad the relevant specifications.=A0The working group has accepted both a sch= ema and protocol draft as input to the effort.=A0

> A= s for #2, the protocol spec works as you describe if "arbitrary URI pa= rameters" equate to resource attributes=A0

Yes, that's what I meant, but in implementation, it= may work out to be looser than that. The client should be able to specify = any arbitrary attribute in the search parameters, even those that aren'= t attributes of the resource. If an attribute is not defined, or if the att= ribute exists but the value doesn't match any stored record, the SP wil= l return no results. In the former case, it's a "400 Bad Request&q= uot; and in the latter, it's a "404 Not Found".
And that's because? =A0I don't see an= y value to the behavior (enabling attribute searches on non-existent schema= ) you suggest.=A0


By "candidate key" (a data modelling term), I= meant another attribute that also uniquely identifies a single record, but= is not the official "primary key", i.e., the main ID. In this ca= se, a client's internal identifier also uniquely identifies a record, b= ut is not the ID used in the URI of RESTful operations.

I know what a candidate key is. =A0= My question is why do you believe an SP ought to care about "candidate= keys"? =A0 Resources are uniquely identified exactly 1 way by the SP = and that is by the SP minted id. =A0The Consumer can retrieve a resource by= any attribute though only the id is guaranteed to be unique from the POV o= f the SP. =A0The SCIM model is a *mapping* between the consumer and SP henc= e it is not a prescription for how the Resource data is actually stored on = either side.
=A0=A0

Look, this may seem to be splitting hairs since a deter= mined client may be able to store and search by their own internal ID in ei= ther case (the current SCIM spec or my suggestion). The difference is philo= sophical. If the spec is showing how clients can store their internal IDs i= n the cloud by explicitly providing for such an attribute, that constitutes= bad advice, IMO. If it turns a blind eye to what they store and they store= internal IDs anyway, they're constraining themselves but the spec come= s out smelling of roses because that's not "recommended practice&q= uot;.


If externalId w= ere dropped it wouldn't bother me a bit. =A0

Ganesh

On 11 August 2012 00:50, Trey Drake <trey.drake@unboundid.com&g= t; wrote:
Ganesh,

I'll base my = comments on your latest reply (below). =A0

The ext= ernalID is not part of the protocol. =A0It is an *optional* attribute withi= n the *schema* specification. =A0As for #2, the protocol spec works as you = describe if "arbitrary URI parameters" equate to resource attribu= tes (Allow generic search using 'GET /Users' and arbitrary URI para= meters). =A0Please clarify your suggestion.

I'm not tracking your coupling concern. =A0The clie= nt can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0


What do you mean by "candidate key"? =A0= Given=A0

On Fri, Aug 10, 2012= at 5:49 AM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
>=A0 I think scim gets its current simplicity from its single owner hub spoke mo= del implementing tight coupling. [...]=A0IMHO loose coupling is a much more= complex solution.

Phil,

I'= m a bit surprised that you're implying "tight coupling =3D=3D simp= le" and "loose coupling =3D=3D complex". That's contrary= to my experience.

When I say "loose coupling", I mean "no = unnecessary dependencies". Invariably, a reduction in dependencies lea= ds to greater simplicity.

Let's not confuse re= duction of dependencies in the data model with a hub-and-spokes architectur= e. They're entirely orthogonal aspects of the solution.

All that my suggestion involves is,

1. Take 'external ID' out of the protocol.
2. Allow= generic search using 'GET /Users' and arbitrary URI parameters

No planned functionality is lost by this.
1. The client enterprise can still send its internal ID as part= of the resource body, inside some attribute defined by them (but not defin= ed by the protocol). Let's say they call it 'myID'.
2. The client enterprise can search for resource URIs using any attrib= ute, including this internal ID
'GET /Users?myID=3Dbjensen= 9;
Since myID is a candidate key, the server will return exactly = one URI, which is the canonical URI for the resource
https://example.com/v1/Users/281=
9c223-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other operat=
ions as usual.

So taking 'externalI=
D' out of the protocol spec only does this:
1. It avoids enshrining tight coupling in the protocol (If=
 clients want to tightly couple themselves to the cloud provider by sending=
 their internal IDs, they can do so. Suicide is OK, but the protocol should=
 not be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards=
 maintaining their own internal-to-external identifier mappings.








That's what I'd =
like to see. I don't believe this complicates the protocol. It simplifi=
es it and it also lends itself to a loosely-coupled approach.









I'll address the mul=
ti-valued attribute suggestion separately.







Regards,




Ganesh




On 10 August 2012 07:53, Phil Hunt=
 <phil.hunt@oracle.com> wrote:





Phil

On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com<=
/a>> wrote:








>=A0
storing this information in a mapping table outside of the SCIM spe=
c is a great way to enable this solution.=A0 Part of the key here is that S=
CIM is just a piece of the architecture for this solution, and is only resp=
onsible for the transport layer between domains.=A0










I wasn't suggesting that the mapping table be part of the SCIM spec=
. I provided that example to illustrate that splitting and merging identiti=
es is a common requirement, and that decoupling local identifiers within a =
domain from shared identifiers between domains was the best way to facilita=
te it.










I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do there is just refrain from introducing=
 tight coupling. I would like to see a single identifier exposed through th=
e API, with the implication (and perhaps the recommendation) that it be the=
 shared one. Allowing one domain to expose its internal identifier to the o=
ther creates tight coupling and ensures that both domains need simultaneous=
ly split or merge identities, which is not desirable. So I recommend _takin=
g out_ the "external id" field from the API. The spec shouldn'=
;t encourage tight coupling. If clients want to pass in their internal ids =
as part of the resource body, no one can stop them, and they can always do =
a search on that attribute to retrieve the URI exactly as you visualise the=
y will with the "external id", but let's not elevate an anti-=
pattern to a recommendation by enshrining the "external id" as an=
 acceptable attribute.











Am I making sense?

I see what you are saying. I think scim gets its current simplicity from=
 its single owner hub spoke model implementing tight coupling.=A0






IMHO loose coupling is a much more complex solution. The rea=
lity is that each end-point has value to contribute and thus the single-own=
er model will eventually need to become multi-owner or multi-hub.=A0









That said i think the current model provides a practica=
l starting point.=A0

=
>=A0
Regarding unique identifiers for multi-valued attributes there is a=
 trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O=
n the other hand it puts extra burden on service providers.=A0











Precisely. The spec has to strike the right balance. It would be i=
nteresting to hear from the other members of the spec mailing list. You kno=
w where I stand on this. It would be good to hear the spectrum of opinions.=












Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:



















Thanks Emmanuel.=A0 =
I had started writing up a similar response.=A0 As you suggest, storing thi=
s information in a mapping table outside of the SCIM spec is a great
 way to enable this solution.=A0 Part of the key here is that SCIM is just =
a piece of the architecture for this solution, and is only responsible for =
the transport layer between domains.


=A0
You could also model these ID mappings in the=
 SCIM user as an extension but would probably not want to expose these exte=
rnally.=A0 Here is an example of how to
 model the end state of the false positive scenario (splitting a user):<=
/u>
=A0



| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=
=A0=A0=A0 |
| a99a5fe=
ba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |



=A0


This could be repre=
sented as two SCIM users that contain information about the entities on oth=
er domains.



=A0<=
/p>
{



=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=




=A0 "id": "9caf78aac3d6",=

=A0 "userName&q=
uot;: "John Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=
=A0=A0 "linkedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "=
D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=A0=A0=A0=A0 }



=A0=A0=A0 ]
=A0 }



}
=A0



{
=A0 "schemas": ["urn:scim:schemas:core:1.0",=
 "urn:scim:schemas:extension:federation:1.0"],



=A0 "id": "a99a5feba839",=

=A0 "userName&q=
uot;: "John Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=
=A0=A0 "linkedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "=
D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"
=A0=A0=A0=A0=A0 }



=A0=A0=A0 ]
=A0 }



}
=A0



In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.



=A0<=
/p>
=A0



Similarly, the false nega=
tive use case (merging two users) looked like this at the end:










=A0
| Internal Entity ID | External Domai=
n ID | External Entity ID | Primary flag |



| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0 | false=A0=A0=A0=A0=A0=
=A0=A0 |
=A0




This could be repre=
sented with the following SCIM user:


=A0
{



=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=




=A0 "id": "9caf78aac3d6",=

=A0 "userName&q=
uot;: "John Smith",



=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=
=A0=A0 "linkedUsers": [



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "=
D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=A0=A0=A0=A0 },



=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "=
D2",



=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",
=A0=A0=A0=A0=A0=A0=A0 "deletionRequired": true=




=A0=A0=A0=A0=A0 }
=A0=A0=A0 ]



=A0 }
}



=A0<=
/p>
=A0



Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand it
 puts extra burden on service providers.=A0 Since the inception of SCIM, a =
key goal has been to foster adoption by service providers by making things =
fit easily onto existing systems.=A0 IMO the value gained by unique identif=
iers for multi-valued attributes is
 not worth the demands put on a service provider.=A0 I also think that vend=
ors that have a non-SCIM-compliant API will choose to keep things that way =
if the spec is too hard for them to implement.=A0 In a green field environm=
ent we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.

=
=A0
--Kelly



=A0<=
/p>



From: scim-bounces@i=
etf.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=





=A0
Hi Ganesh,


=A0
Nothing prevents you in your SCIM=
 implementation (client or server) to generate a unique identifier for each=
 synchronized object and maintain an internal mapping
 table ( you would have to map group membership as well).
=A0<=
/span>



This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an immutable uniqueID in AD =
systems (DN,samAccountName, UPN) are subject to change (even objectGuid can=
 change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.
=A0



This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.
This will give t=
he choice of =93hiding=94 internalIDs or use them as unique ID.



=A0<=
/p>
You can also implement=
 such feature without violating the SCIM specs, or without asking to includ=
e it in the specs.



=A0<=
/p>
--<=
u>



Regards,
Emmanuel Dreux



http://www.cloudiway.com<=
/u>



Tel: +33 4 26 78 17 58



Mobile: +33 6 47 81 26 70



skype: Emmanu=
el.Dreux
=A0




De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement


=A0
=

Hi K=
elly,


Thanks for your response. Let me first respond in brief t=
o the two main points you have made, and then elaborate on the first.



1.=A0=A0=A0=A0=A0
Why should domains not expose=
 their internal identifiers to other domains?



a.

We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 

In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.

2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 

I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=





b. 

If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.=

=
Elaboration of Point 1:


When we consider federated identity across more than one =
domain, we have to assume that domains are not necessarily master-slave in =
their interaction. The most generic interaction
 model is peer-to-peer, where entity lifecycle events within a domain are n=
otified to other domains (when necessary) in an asynchronous manner (i.e., =
through messaging) and the other domains are free to respond to these event=
s in an appropriate manner and at
 a time of their convenience.
A key set of lifecycle ev=
ents for an entity is the merging and splitting of identity that is often r=
equired.



The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.



Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan
 1970) or similar attributes. The front-end application may make an intelli=
gent (but incorrect) guess that these two persons are the same, and re-assi=
gn the same identifier to the second person. This is a false positive. They=
 appear to be the same entity, but
 they're actually different. When the error is discovered, the identiti=
es will need to be split, with a new identifier generated for one of them.<=
u>


Consider the opposite case where a customer signs up thro=
ugh two different portals or in two different sessions, using the names =93=
JSmith=94 and =93JohnS=94. It is very likely that
 they will be treated as two different customers and assigned two unique id=
entifiers. This is a false negative. They appear to be two entities, but ar=
e actually the same. At a later stage, when the error is discovered, the id=
entities will have to be merged,
 and one of the identifiers will have to be dropped.
Th=
ese are not theoretical use cases. They form a significant proportion of th=
e user base in most large Web-facing applications. Let's see how these =
can be managed in a federated
 way by mapping internal identifiers to external ones and only exposing ext=
ernal identifiers to other domains.
a. False positives:=




Doma=
in 1 has the following information about a customer in its data store:
Internal ID: 9caf78aac3d6



Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}
When requesting the provisioning of this entity in Domain 2, the followin=
g ID is returned by Domain 2: ff487230b3a0.



Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |



| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When the false positive is discovered and the entity is s=
plit, Domain 1 creates a new internal identifier and now has the following =
entity information.


Internal ID: 9caf78aac3d6
Attributes:=
 {name: =93John Smith=94, dob: =9301-Jan-1970=94}
<=
p style=3D"margin-bottom:0in;margin-bottom:.0001pt">

Internal ID: a99a5feba839
Attributes:=
 {name: =93John Smith=94, dob: =9301-Jan-1970=94}
<=
p style=3D"margin-bottom:0in;margin-bottom:.0001pt">

This second entity with its own internal identifier is in=
visible to Domain 2, and this is by design. Communication about the origina=
l entity takes place as before by mapping
 =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien=
t time (importantly, this doesn't have to be at the time the split happ=
ens), Domain 2 can be requested to provision a second entity, and when it r=
esponds with an identifier of =937a87f27c1dd8=94,
 this can go into the mapping table as a new record associated with the sec=
ond entity's internal identifier.
The mapping table=
 now contains the following entries:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |



| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | D2 | 7a87f27c1dd8 | true |
Domain 2 is not even aware th=
at a split has happened, and the provisioning that it does is not in lockst=
ep with the split in identity that occurred in
 Domain 1.
(What is the =93Pri=
mary flag=94 used for? We'll see when we cover the treatment of false n=
egatives.)



b. F=
alse negatives:
Domain 1 has the following information =
about what it thinks are two distinct customers in its data store:



Inte=
rnal ID: 9caf78aac3d6
Attributes: {name: =93JSmith=94, =
dob: =9301-Jan-1970=94}



Inte=
rnal ID: 273d36e30d09
Attributes: {name: =93JohnS=94, d=
ob: =9301-Jan-1970=94}



When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.



Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |



| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | D2 | 41206cc97c8b | true |
When the false negative is discovered and the two entiti=
es are merged, Domain 1 drops one of the internal identifiers and rationali=
ses the name of the customer (say, to =93John
 Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr=
ops the second =93273d36e30d09=94.
The mapping table no=
w looks like this:



| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |



| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | D2 | 41206cc97c8b | false |<=
u>
Now two external identifiers map to the same internal o=
ne, so inbound communication from Domain 2 can be unambiguously translated =
to the same entity internally. However, when
 going outwards, Domain 1 will have to look up the translation table to det=
ermine the =93primary=94 external ID for this entity in Domain 2, which was=
 decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 =
comes in. The second external ID =9341206cc97c8b=94
 is never used thereafter in outbound communication.
At=
 some stage (importantly, not in lockstep with the identity merge), Domain =
2 can be requested to delete the customer record identified by =9341206cc97=
c8b=94, and the second entry
 in the mapping table can be removed once this is acknowledged.
This scheme will scale up to multiple domains, because the =93Exte=
rnal Domain ID=94 column helps to keep track of which external ID is shared=
 with which Domain. (Why don't we use
 just one external ID for an entity and share it with all external domains?=
 Tight coupling again. Just as OAuth allows an access token given to a thir=
d party to be invalidated without affecting the access of other third parti=
es, the use of separate external
 identifiers for different domains allows fine-grained control of identity =
federation.)
The scheme also allows the splitting of an=
 entity into more than two entities, and the merging of more than two entit=
ies into a single one. (Any organisation with a web-facing
 application will tell you how many John Smiths there are who were born on =
1 Jan 1970!)
This is a fairly long-winded explanation, =
but this is why we need to hide internal identifiers from other domains, an=
d why mappings need to be managed internally in each domain.
 Such a data model also allows us to choose asynchronous protocols for prop=
agation of identity events, since there is no consistency requirement to up=
date multiple domains concurrently.


Regards,

Ganesh Prasad
=A0


On 9 August 2012 04:55, Kelly=
 Grizzle <kelly.grizzle@sailpoint.com> wrote:




Thanks for the feedb=
ack, Ganesh.=A0 I read through this and your InfoQ article (http://www.infoq.com/articles/scim-data-model-limitations)
 and have some thoughts.
=A0
=
>
The rest of the protocol does not meani=
ngfully use the enterprise client=92s identifier, the "external ID&quo=
t;



> at all, even thoug=
h it was ostensibly introduced to make things friendlier for the client.



=A0<=
/p>
The usage pattern for =
an external ID would be to search for a user by externalId and use the ID o=
f
 the returned user in any desired operation.=A0 For example:<=
u>
=A0



GET /Users?filter=3Dexter=
nalId eq =93bjensen=94&attributes=3Did


=A0
{



=A0 =93totalResults=94: 1,
=A0 =93Resources=94: [=




=A0=A0=A0 {
=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-453a-919d-=
413861904646=94



=A0=A0=A0 }
=A0 ]



}
=A0



Retrieve the ID from the =
response and use it.
=A0



DELETE /Users/2819c223-7f=
76-453a-919d-413861904646
=A0



This does introduce an ad=
ditional HTTP request if the client chooses not to store the server=92s id.=
=A0
 An issue was created to consider allowing operations to use the externalId=
 (http://code.google.com/p/scim/issues/detail?id=3D35),
 but I believe the general consensus has been to not include this in the sp=
ec.=A0 One main point of contention is that much of the rest of the spec (e=
g =96 group membership references, manager references, etc=85) require know=
ledge of the server=92s identifier.=A0 Continuing
 this discussion on the IETF list would be a good thing, though.<=
/u>
=A0<=
u>



=A0<=
/p>
>
the cloud provider's ID and the ent=
erprise client's ID are both "Internal IDs" with respect to t=
heir domains



=A0<=
/p>
I think this comes dow=
n to a nomenclature problem.=A0 The server=92s ID does not necessarily have=
 to
 be the unique identifier that the underlying identity store uses, it just =
has to be stable and unique.=A0 In many cases, the underlying identity stor=
e will provide identifiers with these properties already (eg =96 a uuid) an=
d it can be used by the SCIM interface.=A0
 The =93externalId=94 is referring to the fact that the id is maintained ex=
ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta=
ble and unique (which is mandated by the spec), I don=92t see a problem.



=A0<=
/p>
=A0



>
The secret is that=A0every value nee=
ds a key, and multi-valued attributes lack that. So our solution is qui=
te



> simple - turn ever=
y list or array (of values) into a dictionary (of key-value pairs) by provi=
ding
 each value
> with a unique and meaning-free identifier.<=
u>



=A0<=
/p>
I agree that this woul=
d be useful, especially in the PATCH operation.=A0 One reason that this was=
n=92t
 included in the spec originally is that it can put undue burden on the ser=
vice provider.=A0 Many service providers are putting SCIM interfaces in fro=
nt of their existing identity stores (eg =96 directory servers, SaaS applic=
ation databases, etc=85).=A0 Many of these
 do not have a unique identifier for multi-valued attributes.=A0 By requiri=
ng this, a majority of the server providers would have to start maintaining=
 a unique key for each multi-valued attribute.=A0 I believe this would be a=
 roadblock for many implementers.



=A0<=
/p>
=A0



>
When the SCIM protocol uses PATCH, ther=
e are areas where it seems a bit clumsy.


=A0
I like the thoughts here.=A0 Your example rem=
inds me of unified diffs (http://en.wikipedia.org/wiki/Diff#Unif=
ied_format),
 which are commonly used with a patch program (pretty much the equivalent o=
f the PATCH verb). =A0However, the three proposals seem to largely hinge on=
 being able to uniquely address each element within an object.=A0 Without t=
hese it is not so easy to address each
 patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<=
/span>
<=
br>


The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci=
m-api-00.html#bulk-resources),
 however.
=A0
=A0



>
There are other, non-data aspects of SC=
IM which may require review, such as its synchronous request-response



> interaction model,=
 which is a form of tight coupling and could prove to be a source of brittl=
eness.



=A0<=
/p>
I agree that we should=
 explore optional asynchronous requests in 2.0.



=A0<=
/p>
Thanks again for your =
thoughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0=
 goes
 forward.
=A0
--Kelly



=A0<=
/p>

From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Ganesh and Sashi Prasad

Sent: Wednesday, August 01, 2012 4:24 PM

To: scim@ietf.org=


Subject: [scim] SCIM Protocol - 3 suggestions for improvement=







=A0


(I posted this on the SCIM Google Group, and I =
was advised to subscribe to the mailing list and post it here instead, so h=
ere goes.)




=A0




Hi,




=A0




My name is Ganesh Prasad, and my experience in =
Identity and Access Management is mainly through a 3-year project at an Aus=
tralian insurance company, an experience I have written
 about as a eBook on InfoQ (http://www.infoq.com/minibooks=
/Identity-Management-Shoestring).




=A0




I have been following the SCIM spec off and on,=
 and based on my experience with a loosely-coupled architecture that I foun=
d to be successful, I have the following 3 suggestions
 to make.




=A0




1. The enterprise client and the cloud provider=
 should maintain their own internal IDs for a resource, which they should n=
ot reveal to each other. Both of them should map their
 internal IDs to a shared External ID, and this is the only ID that should =
be exposed through the API. The current specification's provision of an=
 id (which is the external ID and the only one to be transferred through th=
e API) and an "external ID" (which is
 the client's internal ID and should be hidden) is diametrically opposi=
te to this.




=A0




2. When dealing with multi-valued attributes of=
 a resource (expressed as arrays in JSON), they must be converted from an a=
rray into a dictionary with unique keys (UUIDs generated
 by the cloud provider when the attribute is created). Without unique keys =
for every attribute value of a resource, manipulating it will be clumsy and=
 inelegant.




=A0




3. The PATCH command can be improved in 3 signi=
ficant ways:




3a. Leverage the fact (from 2 above) that every=
 value has a key, to greatly simplify the API




3b. Use special verbs as nested operations of t=
he PATCH command to add, modify and delete attributes at any level




3c. Use the WebDAV status code of "207 Mul=
ti-Status" instead of "200 OK" as the response to a PATCH (o=
r BULK) command.




=A0




To elaborate,




=A0




1. Revealing private IDs externally is a form o=
f tight coupling. A major requirement with Identity Management is to split =
(or merge) identities when false positives (or false negatives)
 are detected, i.e., when a resource is discovered to be more than one, or =
when multiple resources are detected to be the same. If internal identifier=
s are revealed to external domains, such clean-ups become difficult, hence =
every domain that wants to expose
 references to a resource must map its internal ID to and external one crea=
ted for this explicit purpose, and only reveal this.




=A0




In the SCIM case, when an enterprise client POS=
Ts a resource creation request, the cloud provider must generate its own in=
ternal UUID as well as an external UUID, map them together,
 and only return the external UUID in the "Location:" header. The=
 enterprise client should map this external UUID to a newly-generated inter=
nal ID of its own. In case the resource already has an identifier within th=
e enterprise client's domain, then this is
 the internal ID that must be mapped to the external UUID returned through =
the POST response.




=A0




2. If a resource is to be created, and one of i=
ts attributes is multi-valued, e.g.,




=A0




=A0 =A0 "email-addrs" :=A0<=
/u>




=A0 =A0 [




=A0 =A0 =A0 =A0 "john_smith@yahoo.com",<=
/u>




=A0 =A0 =A0 =A0 "john.smith@gmail.com",<=
/u>




=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"<=
u>





<
_______________________________________________
scim mailing list
scim@ietf.org







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


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





--0015173fe4acf5606b04c6ffd1fe-- From g.c.prasad@gmail.com Sat Aug 11 09:28:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51AC21F84DA for ; Sat, 11 Aug 2012 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.206 X-Spam-Level: X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oAVIkzi+-3R for ; Sat, 11 Aug 2012 09:28:24 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 106F121F84D5 for ; Sat, 11 Aug 2012 09:28:22 -0700 (PDT) Received: by bkty7 with SMTP id y7so1066113bkt.31 for ; Sat, 11 Aug 2012 09:28:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fkCMwPSxnvH/GX3kCY08dUsUePjx520vUqziiZih/aI=; b=IpV+flCIOjITLWuspVFZL6t/DNHzaHQEBgCdTE19PqpMgP05mkQp8Lx/isw2PRIIFp jz9adgAA4p2bUVyqKjZPJxcPyc8JAKjIkODTi3MQmNXwEJ9aAbyO3S853homFIRh4juZ 5oTXVommrZBHMxXy8iX1/w/ZS0vpc1ppSQ7kRZEQIDB2+B2Seb48uZzvcb6iJOJT3ho+ mw1Uw2+DW4jwysNPLzMJYAvlbnKYoJicyV6h6dx5og4J2etVG9wBdQxYuUEW++9iClVc dV7LfIGq7qEP5yqVo6a8GaexbcWOK8aJw8YPArqAOnGop6pP6lBco8Q9mKBPo5Iq6rgM Ogxg== Received: by 10.204.154.211 with SMTP id p19mr2499954bkw.12.1344702502000; Sat, 11 Aug 2012 09:28:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 09:28:01 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 02:28:01 +1000 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175cd130f5d88604c6fff26b Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:28:28 -0000 --0015175cd130f5d88604c6fff26b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > That's a huge imposition on the client. Why? Any GET will return the resource representation with all keys, so the client can always discover the key to an attribute value at any time. The client doesn't have to store the keys if it doesn't want to. I'm not denying that there is some effort to be expended in return for the simplification in the API, but I wouldn't call it "huge". And if the interface is truly RESTful and follows the HatEoAS principle, it will return hyperlinks for every sub-resource that may be manipulated as the next step after the GET, so it could even be a set of readymade links to traverse to perform standard operations. I believe the XML equivalents look like these: , , etc. Regards, Ganesh On 12 August 2012 02:04, Phil Hunt wrote: > That's a huge imposition on the client. > > Not sure about your arg on server side. It depends on the store > implemetation i suppose. > > Phil > > On 2012-08-11, at 9:50, Ganesh and Sashi Prasad > wrote: > > Phil, > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > > Regards, > Ganesh > > On 12 August 2012 01:12, Phil Hunt wrote: > >> Ganesh, >> >> Here's the sample that concerned me... >> >> The two operations differ significantly, and it's not very intuitive. >> With my suggestion, here's how to delete a single member from a group: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >> } >> } >> ] } >> >> >> >> You gave other examples of an attribute with an identifier that matched >> that value or of identifiers that were additional unique keys. >> >> Given that multi-values must be each unique, I don't see the point of th= e >> extra indexing to support this. Just use the value as the item you wish = to >> delete. >> >> I agree, the delete value operation could be more explicit and clear in >> general. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >> >> > For the multi-value example you gave you used the value as the >> attribute name key. >> >> Now I'm confused :-). I don't believe any of my examples ever used a >> value as the key. >> >> Could you please show me which example you mean, and which parts of it >> you believe to be the value? >> >> Regards, >> Ganesh >> >> On 11 August 2012 13:59, Phil Hunt wrote: >> >>> >>> For the multi-value example you gave you used the value as the attribut= e >>> name key. >>> >>> That means a lot more complex indexing structure. Better to just say >>> delete a specific value. >>> >>> The spec already allows multiple values to have tags like home, work, >>> etc. >>> >>> Phil >>> >>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >>> wrote: >>> >>> > In your example you are conflating value with an attribute id. >>> >>> I don't believe so. >>> >>> I'm adopting a model where every attribute of the resource is a >>> key-value pair. The key is a name or ID. >>> >>> For non-repeating attributes (both simple and composite), the key is th= e >>> attribute name itself. >>> >>> Simple attribute: >>> >>> Key: "dob" >>> Value: "01 Jan 1970" >>> >>> For composite attributes, the key employs dot notation to specify the >>> fully-qualified attribute name, e.g., "address.postcode". >>> >>> Composite attribute: >>> >>> Key: "address.street-number" >>> Value: "10" >>> >>> Key: "address.suburb" >>> Value: "East Camden" >>> >>> For repeating (multi-valued) attributes, I'm suggesting that there be >>> new keys for each individual value, otherwise they are impossible to >>> distinguish, and a positional index is inadequate. So we convert the ar= ray >>> into a dictionary and this then becomes a composite attribute using dot >>> notation for the key. >>> >>> Multi-valued attribute: >>> >>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>> Value: "john_smith@yahoo.com" >>> >>> So this allows us to apply uniform treatment to any arbitrarily deep >>> resource structure. We can refer to every leaf value with a key that is= the >>> fully-qualified name using dot notation. >>> >>> The verbs are just unambiguous operations on these (now) explicitly >>> addressable attributes. >>> >>> INCLUDE to a collection and specify only the value. The key is generate= d >>> and returned. The fully-qualified key is >>> . and the value is what was specif= ied >>> in the INCLUDE. >>> >>> REPLACE a fully-qualified key with a new value. If the key doesn't >>> exist, return a "404 Not Found". >>> >>> PLACE a value at the logical location implied by the fully-qualified >>> key. If there is already a key with that name, return a "409 Conflict". >>> >>> FORCE the fully-qualified key to hold the given value, regardless of >>> whether it existed before or not. Only errors possible are "400 Bad >>> Request" and "500 Internal Error". >>> >>> RETIRE an attribute or a collection given its fully-qualified key. The >>> implementation will determine whether the attribute will disappear enti= rely >>> or will exist holding a null value (the blank string "" or the empty ob= ject >>> {} ). >>> >>> I'll explain in a separate post why we need operation verbs like these >>> that are independent of the HTTP verbs. >>> >>> Regards, >>> Ganesh >>> >>> On 11 August 2012 10:38, wrote: >>> >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your list >>>> subscription. To do so, go to >>>> >>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send scim mailing list submissions to >>>> scim@ietf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.ietf.org/mailman/listinfo/scim >>>> or, via email, send a message with subject or body 'help' to >>>> scim-request@ietf.org >>>> >>>> You can reach the person managing the list at >>>> scim-owner@ietf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of scim digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Phil Hunt >>>> To: Ganesh and Sashi Prasad >>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>> edreux@cloudiway.com>, Trey Drake , Kelly >>>> Grizzle , "scim@ietf.org" >>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>> Ganesh, >>>> >>>> In your example you are conflating value with an attribute id. I find >>>> that confusing. >>>> >>>> I agree though that operations in patch could be a lot more explicit. >>>> >>>> Eg explicitly deleting a value by saying delete or retire. >>>> >>>> Phil >>>> >>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >>>> wrote: >>>> >>>> > I am concerned about your second suggestion: >>>> >>>> Let's discuss that now. >>>> >>>> The trade-offs are very clear here. >>>> >>>> Pros: >>>> >>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>> consistent and intuitive when every individual attribute value gets it= s own >>>> ID. >>>> >>>> Here's how to delete a single member from a Group, as per the current >>>> spec: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>> >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "members": [ >>>> { >>>> "display": "Babs Jensen", >>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>> "operation": "delete" >>>> } >>>> ] >>>> } >>>> >>>> >>>> Here's how to delete ALL members from a group according to the current >>>> spec: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>> >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "meta": { >>>> "attributes": [ >>>> "members" >>>> ] >>>> } >>>> } >>>> >>>> >>>> The two operations differ significantly, and it's not very intuitive. >>>> With my suggestion, here's how to delete a single member from a group: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAc= cept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>> W/"a330bc54f0671c9" { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>> } >>>> } >>>> ] } >>>> Here's how I suggest deleting ALL members from a group: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAc= cept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>> W/"a330bc54f0671c9" { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members" >>>> } >>>> } >>>> ] } >>>> >>>> I'm sure you'll agree that this is simpler, more consistent and more >>>> intuitive to a reader. >>>> >>>> Pro 2: We can apply this mechanism consistently to three areas: >>>> (a) Manipulating multi-valued attributes of a resource >>>> (b) Manipulating members of a group >>>> (c) Performing bulk operations, where we simply use HTTP verbs instead >>>> of the specialised (and semantically less ambiguous) verbs I suggested= for >>>> attributes, the "key" becomes the URI, and the "value" becomes the >>>> corresponding JSON object. >>>> >>>> All of them return "207 Multi-Status" with the "results" array holding >>>> individual status codes. >>>> >>>> In the current spec, (a) and (b) are done similarly but (c) is very >>>> different. >>>> >>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>> because it's simpler for them. >>>> >>>> Pro 4: New (not incumbent) cloud providers will probably find this >>>> easier to implement because they have no legacy. They will probably us= e >>>> some form of NoSQL database and won't be constrained by the limitation= s of >>>> LDAP directories. >>>> >>>> Cons: >>>> >>>> Con 1: Incumbent cloud providers with existing data stores in a >>>> directory format (where multi-valued attributes are stored as >>>> comma-separated values under a single attribute node) will find it >>>> difficult to migrate to this model and store each attribute value as a >>>> sub-node with its own key. This will "hinder adoption of the spec", wh= ich >>>> is what you fear. >>>> >>>> Have I summed up the Pros and Cons correctly? I'm biased of course, so >>>> I could have missed a Con or hyped a Pro :-). >>>> >>>> In other words, we're debating interface complexity (current spec) >>>> versus implementation complexity (my suggestion). Both can hinder adop= tion >>>> of the spec by different parties. >>>> >>>> Here's what we need to discuss - Do the Pros make the suggestion worth >>>> adopting in spite of the Cons, or are the Cons so great that it's best= to >>>> leave the spec as it is? >>>> >>>> Keep in mind that a complex spec that only favours incumbent cloud >>>> providers can cut both ways. It opens the door to a simpler interface >>>> offered by a new generation of nimbler SPs that don't have the same le= gacy >>>> issues, and there could be an exodus of clients to these new SPs. SCIM >>>> could end up being obsoleted very soon, because the API interface is v= ery >>>> complex and clumsy, as any new reader can attest. I was taken aback by= the >>>> complexity when I saw it, which is why I was prompted to suggest somet= hing >>>> simpler. >>>> >>>> This is an issue where we need the opinions of many people, and they >>>> need to state their affiliations. If most people weighing in belong to >>>> incumbent SPs and they vote in favour of interface complexity to avoid >>>> implementation complexity, then it means the spec is not doing a good = job >>>> of balancing the interests of various groups. I think we should also p= oll >>>> client organisations to see what they would want. >>>> >>>> (Gartner is trusted by enterprise clients to evaluate the capabilities >>>> of vendors (SPs). I believe Gartner should take the lead in representi= ng >>>> client interests in this working group rather than those of incumbent >>>> vendors, which is what it seems like to me. Correct me if I'm being un= fair.) >>>> >>>> Regards, >>>> Ganesh >>>> >>>> >>>> >>>> On 11 August 2012 01:35, Diodati,Mark wrote= : >>>> >>>>> Hi Ganesh, >>>>> >>>>> >>>>> I am concerned about your second suggestion: >>>>> >>>>> =932. When dealing with multi-valued attributes of a resource (expres= sed >>>>> as arrays in JSON), they must be converted from an array into a dicti= onary >>>>> with unique keys (UUIDs generated by the cloud provider when the attr= ibute >>>>> is created). Without unique keys for every attribute value of a resou= rce, >>>>> manipulating it will be clumsy and inelegant.=94 >>>>> >>>>> >>>>> One of the primary reasons that SPML failed was lack of adoption by >>>>> service providers due to its complexity. Very few target applications >>>>> implemented SPML. Most of the commercial provisioning systems had an = SPML >>>>> interface (either v1 or v2), but not one of them was conformant to th= e SPML >>>>> standard because of complexity. If you are interested, I will forward= you >>>>> the research documents that discuss these problems in detail. For SCI= M to >>>>> be successful, it must be adopted by commercial target applications (= i.e., >>>>> service providers). I am confident that a requirement for unique >>>>> identifiers with multi-valued attributes will preclude its adoption, >>>>> because it requires major changes to the service provider=92s existin= g >>>>> identity storage mechanisms. >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>> >>>>> *To:* Ganesh and Sashi Prasad >>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>> >>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> >>>>> Ganesh, >>>>> >>>>> >>>>> I'll base my comments on your latest reply (below). >>>>> >>>>> >>>>> The externalID is not part of the protocol. It is an *optional* >>>>> attribute within the *schema* specification. As for #2, the protocol= spec >>>>> works as you describe if "arbitrary URI parameters" equate to resourc= e >>>>> attributes (Allow generic search using 'GET /Users' and arbitrary URI >>>>> parameters). Please clarify your suggestion. >>>>> >>>>> >>>>> I'm not tracking your coupling concern. The client can search and >>>>> hence retrieve resources on any attribute it chooses, externalId or >>>>> otherwise. Nothing mandates use of externalId. >>>>> >>>>> >>>>> >>>>> What do you mean by "candidate key"? Given >>>>> >>>>> >>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>> g.c.prasad@gmail.com> wrote: >>>>> >>>>> > I think scim gets its current simplicity from its single owner hub >>>>> spoke model implementing tight coupling. [...] IMHO loose coupling is= a >>>>> much more complex solution. >>>>> >>>>> >>>>> Phil, >>>>> >>>>> >>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D simpl= e" >>>>> and "loose coupling =3D=3D complex". That's contrary to my experience= . >>>>> >>>>> >>>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>>> Invariably, a reduction in dependencies leads to greater simplicity. >>>>> >>>>> >>>>> Let's not confuse reduction of dependencies in the data model with a >>>>> hub-and-spokes architecture. They're entirely orthogonal aspects of t= he >>>>> solution. >>>>> >>>>> >>>>> All that my suggestion involves is, >>>>> >>>>> >>>>> 1. Take 'external ID' out of the protocol. >>>>> >>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI paramete= rs >>>>> >>>>> >>>>> No planned functionality is lost by this. >>>>> >>>>> >>>>> 1. The client enterprise can still send its internal ID as part of th= e >>>>> resource body, inside some attribute defined by them (but not defined= by >>>>> the protocol). Let's say they call it 'myID'. >>>>> >>>>> 2. The client enterprise can search for resource URIs using any >>>>> attribute, including this internal ID >>>>> >>>>> 'GET /Users?myID=3Dbjensen' >>>>> >>>>> Since myID is a candidate key, the server will return exactly one URI= , >>>>> which is the canonical URI for the resource >>>>> >>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>> >>>>> 3. The client can use this URI to perform all other operations as usu= al. >>>>> >>>>> >>>>> >>>>> So taking 'externalID' out of the protocol spec only does this: >>>>> >>>>> 1. It avoids enshrining tight coupling in the protocol (If clients wa= nt to tightly couple themselves to the cloud provider by sending their inte= rnal IDs, they can do so. Suicide is OK, but the protocol should not be gui= lty of assisted suicide. ;-) >>>>> >>>>> 2. It encourages loose coupling by nudging clients towards maintainin= g their own internal-to-external identifier mappings. >>>>> >>>>> >>>>> >>>>> That's what I'd like to see. I don't believe this complicates the pro= tocol. It simplifies it and it also lends itself to a loosely-coupled appro= ach. >>>>> >>>>> >>>>> >>>>> I'll address the multi-valued attribute suggestion separately. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Ganesh >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>> >>>>> >>>>> >>>>> Phil >>>>> >>>>> >>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>>>> wrote: >>>>> >>>>> > storing this information in a mapping table outside of the SCIM >>>>> spec is a great way to enable this solution. Part of the key here is= that >>>>> SCIM is just a piece of the architecture for this solution, and is on= ly >>>>> responsible for the transport layer between domains. >>>>> >>>>> I wasn't suggesting that the mapping table be part of the SCIM spec. = I >>>>> provided that example to illustrate that splitting and merging identi= ties >>>>> is a common requirement, and that decoupling local identifiers within= a >>>>> domain from shared identifiers between domains was the best way to >>>>> facilitate it. >>>>> >>>>> >>>>> I'm suggesting that the spec do less, not more. >>>>> >>>>> >>>>> What the SCIM spec needs to do there is just refrain from introducing >>>>> tight coupling. I would like to see a single identifier exposed throu= gh the >>>>> API, with the implication (and perhaps the recommendation) that it be= the >>>>> shared one. Allowing one domain to expose its internal identifier to = the >>>>> other creates tight coupling and ensures that both domains need >>>>> simultaneously split or merge identities, which is not desirable. So = I >>>>> recommend _taking out_ the "external id" field from the API. The spec >>>>> shouldn't encourage tight coupling. If clients want to pass in their >>>>> internal ids as part of the resource body, no one can stop them, and = they >>>>> can always do a search on that attribute to retrieve the URI exactly = as you >>>>> visualise they will with the "external id", but let's not elevate an >>>>> anti-pattern to a recommendation by enshrining the "external id" as a= n >>>>> acceptable attribute. >>>>> >>>>> >>>>> Am I making sense? >>>>> >>>>> >>>>> >>>>> I see what you are saying. I think scim gets its current simplicity >>>>> from its single owner hub spoke model implementing tight coupling. >>>>> >>>>> >>>>> IMHO loose coupling is a much more complex solution. The reality is >>>>> that each end-point has value to contribute and thus the single-owner= model >>>>> will eventually need to become multi-owner or multi-hub. >>>>> >>>>> >>>>> That said i think the current model provides a practical starting >>>>> point. >>>>> >>>>> >>>>> >>>>> > Regarding unique identifiers for multi-valued attributes there is >>>>> a trade-off involved. On one hand this makes PATCH semantics easier.= On >>>>> the other hand it puts extra burden on service providers. >>>>> >>>>> >>>>> Precisely. The spec has to strike the right balance. It would be >>>>> interesting to hear from the other members of the spec mailing list. = You >>>>> know where I stand on this. It would be good to hear the spectrum of >>>>> opinions. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Ganesh >>>>> >>>>> On 10 August 2012 00:28, Kelly Grizzle >>>>> wrote: >>>>> >>>>> Thanks Emmanuel. I had started writing up a similar response. As yo= u >>>>> suggest, storing this information in a mapping table outside of the S= CIM >>>>> spec is a great way to enable this solution. Part of the key here is= that >>>>> SCIM is just a piece of the architecture for this solution, and is on= ly >>>>> responsible for the transport layer between domains. >>>>> >>>>> >>>>> You could also model these ID mappings in the SCIM user as an >>>>> extension but would probably not want to expose these externally. He= re is >>>>> an example of how to model the end state of the false positive scenar= io >>>>> (splitting a user): >>>>> >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true | >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>> true | >>>>> >>>>> >>>>> This could be represented as two SCIM users that contain information >>>>> about the entities on other domains. >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "9caf78aac3d6", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "ff487230b3a0" >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "a99a5feba839", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "7a87f27c1dd8" >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> In the second user, the linkedUsers attribute would be empty until th= e >>>>> split user was synced to domain 2. >>>>> >>>>> >>>>> >>>>> Similarly, the false negative use case (merging two users) looked lik= e >>>>> this at the end: >>>>> >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true | >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>> false | >>>>> >>>>> >>>>> This could be represented with the following SCIM user: >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "9caf78aac3d6", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "ff487230b3a0" >>>>> >>>>> }, >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "41206cc97c8b", >>>>> >>>>> "deletionRequired": true >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> Regarding unique identifiers for multi-valued attributes there is a >>>>> trade-off involved. On one hand this makes PATCH semantics easier. = On the >>>>> other hand it puts extra burden on service providers. Since the ince= ption >>>>> of SCIM, a key goal has been to foster adoption by service providers = by >>>>> making things fit easily onto existing systems. IMO the value gained= by >>>>> unique identifiers for multi-valued attributes is not worth the deman= ds put >>>>> on a service provider. I also think that vendors that have a >>>>> non-SCIM-compliant API will choose to keep things that way if the spe= c is >>>>> too hard for them to implement. In a green field environment we do h= ave >>>>> the luxury of mandating a model to make certain operations more elega= nt. >>>>> However, we can=92t ignore legacy systems. >>>>> >>>>> >>>>> --Kelly >>>>> >>>>> >>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>> Behalf Of *Emmanuel Dreux >>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>> *Cc:* scim@ietf.org >>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> Hi Ganesh, >>>>> >>>>> >>>>> Nothing prevents you in your SCIM implementation (client or server) t= o >>>>> generate a unique identifier for each synchronized object and maintai= n an >>>>> internal mapping table ( you would have to map group membership as we= ll). >>>>> >>>>> >>>>> This is what we are doing with Active Directory sources or targets: >>>>> >>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can c= hange >>>>> if an AD domain is migrated), we decided to generate and maintain an >>>>> internal table of ids. This fits your requirements as it hides intern= al ids. >>>>> >>>>> >>>>> This was written in dotnet and we have started a project to rewrite >>>>> our SCIM stack in PHP and will give it to the Open Source community. = This >>>>> implementation will have a parameter : AllocateIds versus UseExisting= IDs. >>>>> >>>>> This will give the choice of =93hiding=94 internalIDs or use them as >>>>> unique ID. >>>>> >>>>> >>>>> You can also implement such feature without violating the SCIM specs, >>>>> or without asking to include it in the specs. >>>>> >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> >>>>> Emmanuel Dreux >>>>> >>>>> http://www.cloudiway.com >>>>> >>>>> Tel: +33 4 26 78 17 58 >>>>> >>>>> Mobile: +33 6 47 81 26 70 >>>>> >>>>> skype: Emmanuel.Dreux >>>>> >>>>> >>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>> >>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>> *=C0 :* Kelly Grizzle >>>>> *Cc :* scim@ietf.org >>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> Hi Kelly, >>>>> >>>>> Thanks for your response. Let me first respond in brief to the two >>>>> main points you have made, and then elaborate on the first. >>>>> >>>>> 1. Why should domains not expose their internal identifiers to >>>>> other domains? >>>>> >>>>> a. >>>>> >>>>> We are designing a protocol for a federated system of domains, where >>>>> all domains are co-equal peers. (In physics too, N-body problems are = much >>>>> harder than 2-body problems. :-) Therefore, assuming that there are o= nly >>>>> two players in the interaction makes this tightly coupled in a number= of >>>>> ways. We should rely on messaging and notification, with encapsulatio= n of >>>>> domain-specific data. >>>>> >>>>> b. >>>>> >>>>> In any non-trivial data store, there will always be the ongoing need >>>>> to merge and split identities as and when =93false negatives=94 and = =93false >>>>> positives=94 are discovered. A domain should be able to handle this i= nternal >>>>> housekeeping freely, only notifying other domains when convenient. Ma= pping >>>>> of internal identifiers to external ones and maintaining this mapping >>>>> internally allows this loosely-coupled housekeeping to take place. Sh= aring >>>>> internal identifiers (or otherwise outsourcing the mapping of interna= l to >>>>> external identifiers) forces housekeeping activities to be done in >>>>> lock-step across domains. >>>>> >>>>> c. >>>>> >>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>> protocol which can be designed later. The data model plays a crucial = role >>>>> in enabling or constraining such interaction. A tightly-coupled data = model >>>>> will force the use of synchronous interactions, and the exposure of >>>>> internal identifiers is a key part of this tight coupling. >>>>> >>>>> 2. The difficulty of assigning unique identifiers to the individual >>>>> values of multi-valued attributes: >>>>> >>>>> a. >>>>> >>>>> I'm not belittling the effort involved in migrating legacy data store= s >>>>> to such a model. However, in the larger historical context of cross-d= omain >>>>> identity management, we are really at the very early stages. If a >>>>> relatively new discipline and a brand new spec are held captive to le= gacy >>>>> considerations, we are losing an opportunity to provide a clean and e= legant >>>>> model to subsequent users of the spec, and this will have repercussio= ns >>>>> over many years or even decades. >>>>> >>>>> b. >>>>> >>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>> dictionary model for existing multi-valued attributes, they can trans= ition >>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-c= ompliant=94 >>>>> APIs to their customers and encouraging new customers to adopt the >>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradu= ally >>>>> migrated to the SCIM-compliant API. The logistics are not insurmounta= ble, >>>>> and shouldn't prevent the adoption of a dictionary model for multi-va= lued >>>>> attributes. >>>>> >>>>> Elaboration of Point 1: >>>>> >>>>> When we consider federated identity across more than one domain, we >>>>> have to assume that domains are not necessarily master-slave in their >>>>> interaction. The most generic interaction model is peer-to-peer, wher= e >>>>> entity lifecycle events within a domain are notified to other domains= (when >>>>> necessary) in an asynchronous manner (i.e., through messaging) and th= e >>>>> other domains are free to respond to these events in an appropriate m= anner >>>>> and at a time of their convenience. >>>>> >>>>> A key set of lifecycle events for an entity is the merging and >>>>> splitting of identity that is often required. >>>>> >>>>> The question =93Is this one entity?=94 can be answered either yes >>>>> (positive) or no (negative). But sometimes, we can discover false pos= itives >>>>> and false negatives in our data stores. >>>>> >>>>> Consider a case where customers sign up online, and two customers who >>>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and al= so use the >>>>> same date of birth (say, 1 Jan 1970) or similar attributes. The front= -end >>>>> application may make an intelligent (but incorrect) guess that these = two >>>>> persons are the same, and re-assign the same identifier to the second >>>>> person. This is a false positive. They appear to be the same entity, = but >>>>> they're actually different. When the error is discovered, the identit= ies >>>>> will need to be split, with a new identifier generated for one of the= m. >>>>> >>>>> Consider the opposite case where a customer signs up through two >>>>> different portals or in two different sessions, using the names =93JS= mith=94 >>>>> and =93JohnS=94. It is very likely that they will be treated as two d= ifferent >>>>> customers and assigned two unique identifiers. This is a false negati= ve. >>>>> They appear to be two entities, but are actually the same. At a later >>>>> stage, when the error is discovered, the identities will have to be m= erged, >>>>> and one of the identifiers will have to be dropped. >>>>> >>>>> These are not theoretical use cases. They form a significant >>>>> proportion of the user base in most large Web-facing applications. Le= t's >>>>> see how these can be managed in a federated way by mapping internal >>>>> identifiers to external ones and only exposing external identifiers t= o >>>>> other domains. >>>>> >>>>> a. False positives: >>>>> >>>>> Domain 1 has the following information about a customer in its data >>>>> store: >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> When requesting the provisioning of this entity in Domain 2, the >>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifier: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> When the false positive is discovered and the entity is split, Domain >>>>> 1 creates a new internal identifier and now has the following entity >>>>> information. >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> Internal ID: a99a5feba839 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> This second entity with its own internal identifier is invisible to >>>>> Domain 2, and this is by design. Communication about the original ent= ity >>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a= 0=94 and >>>>> vice-versa. At some convenient time (importantly, this doesn't have t= o be >>>>> at the time the split happens), Domain 2 can be requested to provisio= n a >>>>> second entity, and when it responds with an identifier of =937a87f27c= 1dd8=94, >>>>> this can go into the mapping table as a new record associated with th= e >>>>> second entity's internal identifier. >>>>> >>>>> The mapping table now contains the following entries: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>> >>>>> Domain 2 is not even aware that a split has happened, and the >>>>> provisioning that it does is not in lockstep with the split in identi= ty >>>>> that occurred in Domain 1. >>>>> >>>>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>>>> treatment of false negatives.) >>>>> >>>>> b. False negatives: >>>>> >>>>> Domain 1 has the following information about what it thinks are two >>>>> distinct customers in its data store: >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> Internal ID: 273d36e30d09 >>>>> >>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>> >>>>> When requesting the provisioning of these entities in Domain 2, the >>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b= . >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifiers: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>> >>>>> When the false negative is discovered and the two entities are merged= , >>>>> Domain 1 drops one of the internal identifiers and rationalises the n= ame of >>>>> the customer (say, to =93John Smith=94). Let's say it retains the fir= st ID >>>>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>> >>>>> The mapping table now looks like this: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>> >>>>> Now two external identifiers map to the same internal one, so inbound >>>>> communication from Domain 2 can be unambi >>>>> >>>> _______________________________________________ >>> >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015175cd130f5d88604c6fff26b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 That's a huge imposition on the client.=A0

Why? Any = GET will return the resource representation with all keys, so the client ca= n always discover the key to an attribute value at any time. The client doe= sn't have to store the keys if it doesn't want to. I'm not deny= ing that there is some effort to be expended in return for the simplificati= on in the API, but I wouldn't call it "huge".

And if the interface is truly RESTful and follows the H= atEoAS principle, it will return hyperlinks for every sub-resource that may= be manipulated as the next step after the GET, so it could even be a set o= f readymade links to traverse to perform standard operations.

I believe the XML equivalents look like these: <link= rel=3D"REPLACE" href=3D"".../>, <link rel=3D&quo= t;RETIRE" href=3D"" .../>, etc.

= Regards,
Ganesh

On 12 August 2012 02:04, Phil= Hunt <phil.hunt@oracle.com> wrote:
That's a huge imposition on the client.= =A0

Not sure about your arg on server side. It dep= ends on the store implemetation i suppose.=A0

Phil

On 2012-08-11, = at 9:50, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

<= /div>
Phil,

The reason we canno= t use the value itself to identify an element is that this method will only= work for simple elements, not for nested structures. i.e., if we had an ar= ray of dictionaries (e.g., we had to record an array of addresses for each = customer, with each address element having sub-elements like street number,= street name, suburb, etc.), then it would be clumsy to supply the entire v= alue of the array element because it's itself a dictionary. Creating a = unique key for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> wrote:
Ganesh,<= div>
Here's the sample that concerned me...
The two operations differ significantly, and= it's not very intuitive.=A0
With my suggestion, here's h= ow to delete a single member from a group:

PATCH= /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }


<= /div>
You gave other examples of an attribute with an identifier that m= atched that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don= 't see the point of the extra indexing to support this. Just use the va= lue as the item you wish to delete.

I agree, the delete value operation could be more = explicit and clear in general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:
>=A0 For the multi-value example you gave you used the value as the attribute na= me key.=A0

Now I'm confused :-). I don't believe= any of my examples ever used a value as the key.

Could you please show me which example you mean, and which parts of it you = believe to be the value?

Regards,
Ganesh= =A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wrote:

For the mu= lti-value example you gave you used the value as the attribute name key.=A0=

That means a lot more complex indexing structure. Bette= r to just say delete a specific value.=A0

The spec= already allows multiple values to have tags like home, work, etc.

Phil

On 2012-08-10, at= 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.=A0<= br>
I don't believe so.

I'm adopting a model = where every attribute of the resource is a key-value pair. The key is a nam= e or ID.

For non-repeating attributes (both simple and composite= ), the key is the attribute name itself.=A0

S= imple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite= attributes, the key employs dot notation to specify the fully-qualified at= tribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-num= ber"
Value: "10"

Key: &qu= ot;address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting = that there be new keys for each individual value, otherwise they are imposs= ible to distinguish, and a positional index is inadequate. So we convert th= e array into a dictionary and this then becomes a composite attribute using= dot notation for the key.

Multi-valued attribute:

Key: &= quot;emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
Value: &qu= ot;john_smith@yah= oo.com"

So this allows us to apply uniform treatment to any arb= itrarily deep resource structure. We can refer to every leaf value with a k= ey that is the fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and = specify only the value. The key is generated and returned. The fully-qualif= ied key is <collection-name>.<newly-generated-ID> and the value= is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the = key doesn't exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualifi= ed key. If there is already a key with that name, return a "409 Confli= ct".

FORCE the fully-qualified key to hold the given value, = regardless of whether it existed before or not. Only errors possible are &q= uot;400 Bad Request" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualifie= d key. The implementation will determine whether the attribute will disappe= ar entirely or will exist holding a null value (the blank string "&quo= t; or the empty object {} ).

I'll explain in a separate post why we need operati= on verbs like these that are independent of the HTTP verbs.

<= /div>
Regards,
Ganesh

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

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.co= m>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sai= lpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Proto= col - 3 suggestions for improvement
G= anesh,

In your example you are conflating value wi= th an attribute id. I find that confusing.=A0

I agree though that operations in patch could be a lot = more explicit.=A0

Eg explicitly deleting a value b= y saying delete or retire.=A0

Phil

On 2012-08-1= 0, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I = am concerned about your second suggestion:=A0

Let= 's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipu= late resources becomes so much cleaner, consistent and intuitive when every= individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current s= pec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to th= e current spec:

   PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3=
f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very in= tuitive.=A0
With my suggestion, here's how to delete a single= member from a group:

PATCH /Groups/acbf3ae7-846= 3-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members.2819c223-7f76-453a-919d-413861904646"=
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {
"operations" : [
= {
"RETIRE" : {
"key&qu= ot; : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more c= onsistent and more intuitive to a reader.

Pro 2: W= e can apply this mechanism consistently to three areas:
(a) Manip= ulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk oper= ations, where we simply use HTTP verbs instead of the specialised (and sema= ntically less ambiguous) verbs I suggested for attributes, the "key&qu= ot; becomes the URI, and the "value" becomes the corresponding JS= ON object.

All of them return "207 Multi-Status" with th= e "results" array holding individual status codes.

=
In the current spec, (a) and (b) are done similarly but (c) is v= ery different.

Pro 3: Adoption of the standard by clients is likely to= be higher because it's simpler for them.

Pro = 4: New (not incumbent) cloud providers will probably find this easier to im= plement because they have no legacy. They will probably use some form of No= SQL database and won't be constrained by the limitations of LDAP direct= ories.

Cons:

Con 1: Incumbent cloud p= roviders with existing data stores in a directory format (where multi-value= d attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each attrib= ute value as a sub-node with its own key. This will "hinder adoption o= f the spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm b= iased of course, so I could have missed a Con or hyped a Pro :-).

=
In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make t= he suggestion worth adopting in spite of the Cons, or are the Cons so great= that it's best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, a= nd there could be an exodus of clients to these new SPs. SCIM could end up = being obsoleted very soon, because the API interface is very complex and cl= umsy, as any new reader can attest. I was taken aback by the complexity whe= n I saw it, which is why I was prompted to suggest something simpler.

This is an issue where we need the opinions of many peo= ple, and they need to state their affiliations. If most people weighing in = belong to incumbent SPs and they vote in favour of interface complexity to = avoid implementation complexity, then it means the spec is not doing a good= job of balancing the interests of various groups. I think we should also p= oll client organisations to see what they would want.

(Gartner is trusted by enterprise clients to evaluate t= he capabilities of vendors (SPs). I believe Gartner should take the lead in= representing client interests in this working group rather than those of i= ncumbent vendors, which is what it seems like to me. Correct me if I'm = being unfair.)

Regards,
Ganesh



<= div class=3D"gmail_quote">On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned abou= t your second suggestion:

=932. When dea= ling with multi-valued attributes of a resource (expressed as arrays in JSO= N), they must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary = reasons that SPML failed was lack of adoption by service providers due to i= ts complexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Drake [mailto:trey.drake@unboundi= d.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ie= tf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

= Ganesh,

=A0

I'll base my comments on your latest reply = (below). =A0

=A0

The externalID is not part of the protocol. =A0= It is an *optional* attribute within the *schema* specification. =A0As for = #2, the protocol spec works as you describe if "arbitrary URI paramete= rs" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0= The client can search and hence retrieve resources on any attribute it choo= ses, externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0=

=A0
=A0

What do you mean by "candidate key"? = =A0Given=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sas= hi Prasad <g.c= .prasad@gmail.com> wrote:

>=A0 I think = scim gets its current simplicity from its single owner hub spoke model impl= ementing tight coupling. [...]=A0IMHO loose coupling is a much more complex= solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implyin= g "tight coupling =3D=3D simple" and "loose coupling =3D=3D = complex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean &= quot;no unnecessary dependencies". Invariably, a reduction in dependen= cies leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies= in the data model with a hub-and-spokes architecture. They're entirely= orthogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protoc= ol.

2. Allow generic search using 'GET /Users&#= 39; and arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its int= ernal ID as part of the resource body, inside some attribute defined by the= m (but not defined by the protocol). Let's say they call it 'myID&#= 39;.

2. The client enterprise can search for resourc= e URIs using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will = return exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0
=A0


On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com=
> wrote:








Phil








On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:






>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0













I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.


=A0




I'm suggesting that the spec do less, not m=
ore.


=A0


What the SCIM spec needs to do there is just re=
frain from introducing tight coupling. I would like to see a single identif=
ier exposed through the API, with the implication (and perhaps the recommen=
dation) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.




=A0




Am I making sense?








=A0




I see what you are saying. I think scim gets i=
ts current simplicity from its single owner hub spoke model implementing ti=
ght coupling.=A0


=A0




IMHO loose coupling is a much more complex solu=
tion. The reality is that each end-point has value to contribute and thus t=
he single-owner model will eventually need to become multi-owner or multi-h=
ub.=A0














=A0




That said i think the current model provides a =
practical starting point.=A0












=A0




>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0






Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.














=A0




Regards,




Ganesh


On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@=
sailpoint.com> wrote:




Thanks Emmanuel.=A0 =
I had started writing up a similar response.=A0 As you suggest, storing thi=
s information in a mapping table outside of the SCIM spec
 is a great way to enable this solution.=A0 Part of the key here is that SC=
IM is just a piece of the architecture for this solution, and is only respo=
nsible for the transport layer between domains.
=A0





You could also mode=
l these ID mappings in the SCIM user as an extension but would probably not=
 want to expose these externally.=A0 Here is an example
 of how to model the end state of the false positive scenario (splitting a =
user):


=A0
| Internal Entity ID | External Domain ID | External Entity ID =
| Primary flag |





| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |
|=
 a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |=






=A0


This could be repre=
sented as two SCIM users that contain information about the entities on oth=
er domains.





=A0
=
{





=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=






=A0 "id": "9caf78aac3d6",=

=A0 "userName": "Jo=
hn Smith",





=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [





=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",





=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=
=A0=A0=A0=A0 }





=A0=A0=A0 ]
=
=A0 }





}
=A0
<=
p class=3D"MsoNormal">



{
=A0 "schemas": [=
"urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fed=
eration:1.0"],





=A0 "id": "a99a5feba839",=

=A0 "userName": "Jo=
hn Smith",





=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [





=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",





=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"
=A0=
=A0=A0=A0=A0 }





=A0=A0=A0 ]
=
=A0 }





}
=
=A0





In the second user,=
 the linkedUsers attribute would be empty until the split user was synced t=
o domain 2.





=A0
=A0





Similarly, the fals=
e negative use case (merging two users) looked like this at the end:=







=A0
| Internal Entity ID | External Domain ID | External Entity ID =
| Primary flag |





| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |
|=
 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0 | false=A0=A0=A0=A0=A0=A0=A0 |





=A0


This could be repre=
sented with the following SCIM user:
=A0





{
=A0 "schemas": ["urn:scim:schemas:core:1.0", "u=
rn:scim:schemas:extension:federation:1.0"],





=A0 "id": "9caf78aac3d6",=

=A0 "userName": "Jo=
hn Smith",





=A0 "urn:scim:schemas:extension:federati=
on:1.0": {
=A0=A0=A0 "lin=
kedUsers": [





=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",





=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"
=A0=
=A0=A0=A0=A0 },





=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0 "domain": "D2",





=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",
=
=A0=A0=A0=A0=A0=A0=A0 "deletionRequired": true





=A0=A0=A0=A0=A0 }
=A0=A0=A0 ]





=A0 }
}





=A0
=A0





Regarding unique id=
entifiers for multi-valued attributes there is a trade-off involved.=A0 On =
one hand this makes PATCH semantics easier.=A0 On the other
 hand it puts extra burden on service providers.=A0 Since the inception of =
SCIM, a key goal has been to foster adoption by service providers by making=
 things fit easily onto existing systems.=A0 IMO the value gained by unique=
 identifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.

=A0
--Kelly





=A0




From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








=A0
Hi Ganesh,
=
=A0





Nothing prevents yo=
u in your SCIM implementation (client or server) to generate a unique ident=
ifier for each synchronized object and maintain an
 internal mapping table ( you would have to map group membership as well).<=
/span>
=A0




This is what we are doing with Active Directory =
sources or targets:
As we didn=92t find an immutable uniqueID in AD systems (DN,samAccount=
Name, UPN) are subject to change (even objectGuid can change if an AD domai=
n
 is migrated), we decided to generate and maintain an internal table of ids=
. This fits your requirements as it hides internal ids.
=A0





This was written in=
 dotnet and we have started a project to rewrite our SCIM stack in PHP and =
will give it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.
This will give the choice of =
=93hiding=94 internalIDs or use them as unique ID.





=A0
=
You can also implement such feature without viol=
ating the SCIM specs, or without asking to include it in the specs.<=
/p>




=A0
=
--





Regards,
Emmanue=
l Dreux





http://www.cloudiway.com





Tel:
+33 4 26 78=
 17 58
Mobile:
+33 6 47 81=
 26 70
skype: Emmanuel.Dreux





=A0


De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement


=A0
Hi Kelly,
Thanks for y=
our response. Let me first respond in brief to the two main points you have=
 made, and then elaborate on the first.






1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?





a.

We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.
<=
p style=3D"margin-right:0in;margin-bottom:0in;margin-left:18.15pt;margin-bo=
ttom:.0001pt">




b. 

In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.

2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:

a. 

I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=







b. 

If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.
Elaboration of Point 1:




When we consider federated identity across more than one =
domain, we have to assume that domains are not necessarily master-slave in =
their interaction. The most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.
A key set of lifecycle events for an entity is=
 the merging and splitting of identity that is often required.




The question =93Is this one entity?=94 can be answered ei=
ther yes (positive) or no (negative). But sometimes, we can discover false =
positives and false negatives in our data stores.




Consider a case where customers sign up online, and two c=
ustomers who are privacy-conscious enter fake IDs such as =93John Smith=94,=
 and also use the same date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.
Consider the op=
posite case where a customer signs up through two different portals or in t=
wo different sessions, using the names =93JSmith=94 and =93JohnS=94. It is =
very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.
These are not theoretical use cases. They f=
orm a significant proportion of the user base in most large Web-facing appl=
ications. Let's see how these can be managed in a federated way by mapp=
ing
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.
a. False positives:




Domain 1 has the following information about a customer i=
n its data store:
Internal ID: 9caf78aac3d6




Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=
=94}
When requesting the provisioning of this entity in Domain 2, the=
 following ID is returned by Domain 2: ff487230b3a0.





Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:





| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff487230b3a0 | true |
When the false posit=
ive is discovered and the entity is split, Domain 1 creates a new internal =
identifier and now has the following entity information.





Inte=
rnal ID: 9caf78aac3d6
Attributes: {name: =93John Smith=94, dob: =9301=
-Jan-1970=94}





Inte=
rnal ID: a99a5feba839
Attributes: {name: =93John Smith=94, dob: =9301=
-Jan-1970=94}





This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.
The mapping table now contains the following ent=
ries:





| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff487230b3a0 | true |
| a99a5feba839 | D2 | 7a87f27c1dd=
8 | true |





Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.





(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)




b. False negatives:
Domain 1 has the following info=
rmation about what it thinks are two distinct customers in its data store:<=
/span>





Inte=
rnal ID: 9caf78aac3d6
Attributes: {name: =93JSmith=94, dob: =9301-Jan=
-1970=94}





Inte=
rnal ID: 273d36e30d09
Attributes: {name: =93JohnS=94, dob: =9301-Jan-=
1970=94}





When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.




Domain 1 then maintains the following in a mapping table =
and uses it for translation when talking to Domain 2, taking care never to =
expose its internal identifiers:




| Internal Entity ID | External Domain ID | External Entity ID | Prima=
ry flag |
| 9caf78aac3d6 | D2 | ff487230b3a0 | true |





| 273d36e30d09 | =
D2 | 41206cc97c8b | true |




When the false negative is discovered and the two entitie=
s are merged, Domain 1 drops one of the internal identifiers and rationalis=
es the name of the customer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.
The mapping table now looks like this:




| Internal Entity ID | External Domain ID | External Entity ID | Prima=
ry flag |
| 9caf78aac3d6 | D2 | ff487230b3a0 | true |





| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |




Now two external identifiers map to the same internal one=
, so inbound communication from Domain 2 can be unambi
_____________= __________________________________

_______________________________________________
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

--0015175cd130f5d88604c6fff26b-- From g.c.prasad@gmail.com Sat Aug 11 09:52:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900DB21F859B for ; Sat, 11 Aug 2012 09:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG6r806NCtFk for ; Sat, 11 Aug 2012 09:52:36 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0FC21F8578 for ; Sat, 11 Aug 2012 09:52:36 -0700 (PDT) Received: by bkty7 with SMTP id y7so1071054bkt.31 for ; Sat, 11 Aug 2012 09:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=S/JtcwsrK+HVUmQMt2LGSCRHrVpuTd6SCxCtwy8mN4U=; b=XG/4YQ7Ylgdp8esT/3ntqSESrdcGzDuSQvDpVw/jLnpgqZGo1b7ClZ1x4U2fM71lEy NNgYb9b+rvcrIRtRAr/TR2VyEFfWq7sSeitKakpTjn3l/rqT1qwz9Hstsi8vEwnXMmS0 PnLzd84WtNCO9bWWSHkWzF8k8t4i5SrdgySJVfNjpUIu395nokJsKaicj89OhdCTTrjL liBY1JOYdNj5aF3K57+QUi2DglalS4OXXeL87EWcHcYdFc7Np5lqubaBtlMzYelKwOK9 ZKSL01QqE5ci8b8+OfC4+SGmWVotkNykaJbo8ozJSEIRd2JkTqdhF5fjJhFNUOmzZ7n6 fyXA== Received: by 10.205.137.8 with SMTP id im8mr2318765bkc.135.1344703955324; Sat, 11 Aug 2012 09:52:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 09:52:15 -0700 (PDT) In-Reply-To: References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <5159F724-D64F-470C-900A-D7B17A7BC6A5@unboundid.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 02:52:15 +1000 Message-ID: To: "scim@ietf.org" Content-Type: multipart/alternative; boundary=0015175dd5c895d13c04c70049c9 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 16:52:37 -0000 --0015175dd5c895d13c04c70049c9 Content-Type: text/plain; charset=ISO-8859-1 There's another aspect to this discussion that I've been meaning to bring up for a while, but I've been getting side-tracked by the (necessary) discussions on the external ID and multi-valued attribute treatment. This is about asynchronous behaviour. I think someone mentioned early on in the thread that we would like to get a synchronous spec out the door first and then think about doing an async version. IMO, this "synchronous first, asynchronous later" approach could entail a lot of rework at a later stage, which may then not be undertaken because it breaks backwards-compatibility. We should plan ahead for asynchronous support. Adding synchronous protocol support to an asynchronous protocol is trivial. We just need to define what happens when the initiator blocks on a response instead of going off to do other things and relying on notification. However, the reverse is not true. When we design synchronous protocols, we may often slip aspects of tight coupling (at the data layer) into the protocol, and this will not be visible because the protocol is synchronous (tightly coupled) anyway. When we then attempt to make this protocol asynchronous, the data layer tight coupling will emerge as a major constraint preventing this. An example is an attribute that has to be kept in sync across two data stores. This implies some form of two-phase commit protocol which doesn't lend itself well to asynchronous interactions. The external ID is a prime example of this kind of data coupling. If one domain has to do housekeeping internally to clean up its data, and this involves splitting or merging identities, then having these identifiers stored within another domain (e.g., externalID) means those domains also have to be changed at the same time. I had earlier shown how to do it asynchronously with mapping tables. This is another reason why I suggest using non-HTTP verbs inside a PATCH. When we change from synchronous to asynchronous interaction, we _may_ use a wire protocol other than HTTP (e.g., WebSockets) and then the outer HTTP verbs will have to be replaced with something else. If we use the suggested reserved words INCLUDE, PLACE, REPLACE, FORCE and RETIRE, the inner verbs will not have to change at all. We should also think about idempotence and models like "eventual consistency". INCLUDE is not idempotent, and this is where the client may have to be aware of dictionary keys for array elements and generate its own suggested UUIDs. Using a PLACE instead of an INCLUDE will make the request idempotent. (This is not tight coupling because the UUID is the only shared identifier between client and SP.) Regards, Ganesh --0015175dd5c895d13c04c70049c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There's another aspect to this discussion that I've been meaning to= bring up for a while, but I've been getting side-tracked by the (neces= sary) discussions on the external ID and multi-valued attribute treatment.<= div>
This is about asynchronous behaviour.

I think someone mentioned early on in the thread that we would like to g= et a synchronous spec out the door first and then think about doing an asyn= c version.

IMO, this "synchronous first, asynchronous later&q= uot; approach could entail a lot of rework at a later stage, which may then= not be undertaken because it breaks backwards-compatibility. We should pla= n ahead for asynchronous support.

Adding synchronous protocol support to an asynchronous = protocol is trivial. We just need to define what happens when the initiator= blocks on a response instead of going off to do other things and relying o= n notification.

However, the reverse is not true. When we design synchr= onous protocols, we may often slip aspects of tight coupling (at the data l= ayer) into the protocol, and this will not be visible because the protocol = is synchronous (tightly coupled) anyway. When we then attempt to make this = protocol asynchronous, the data layer tight coupling will emerge as a major= constraint preventing this.

An example is an attribute that has to be kept in sync = across two data stores. This implies some form of two-phase commit protocol= which doesn't lend itself well to asynchronous interactions. The exter= nal ID is a prime example of this kind of data coupling. If one domain has = to do housekeeping internally to clean up its data, and this involves split= ting or merging identities, then having these identifiers stored within ano= ther domain (e.g., externalID) means those domains also have to be changed = at the same time. I had earlier shown how to do it asynchronously with mapp= ing tables.

This is another reason why I suggest using non-HTTP ver= bs inside a PATCH. When we change from synchronous to asynchronous interact= ion, we _may_ use a wire protocol other than HTTP (e.g., WebSockets) and th= en the outer HTTP verbs will have to be replaced with something else. If we= use the suggested reserved words INCLUDE, PLACE, REPLACE, FORCE and RETIRE= , the inner verbs will not have to change at all.

We should also think about idempotence and models like = "eventual consistency". INCLUDE is not idempotent, and this is wh= ere the client may have to be aware of dictionary keys for array elements a= nd generate its own suggested UUIDs. Using a PLACE instead of an INCLUDE wi= ll make the request idempotent.=A0(This is not tight coupling because the U= UID is the only shared identifier between client and SP.)

Regards,
Ganesh
--0015175dd5c895d13c04c70049c9-- From phil.hunt@oracle.com Sat Aug 11 10:06:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC99821F8578 for ; Sat, 11 Aug 2012 10:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv0X3doQBsrG for ; Sat, 11 Aug 2012 10:06:53 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE8221F84F6 for ; Sat, 11 Aug 2012 10:06:52 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7BH6ld3015971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Aug 2012 17:06:48 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7BH6lix029297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 17:06:47 GMT Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7BH6kd2021545; Sat, 11 Aug 2012 12:06:46 -0500 Received: from [25.73.50.96] (/74.198.150.224) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 11 Aug 2012 10:06:45 -0700 References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <5159F724-D64F-470C-900A-D7B17A7BC6A5@unboundid.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-C7C4D6EF-93CE-43F1-9570-3016D2935F07 Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sat, 11 Aug 2012 11:06:38 -0600 To: Ganesh and Sashi Prasad X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" , Kelly Grizzle , Trey Drake , Emmanuel Dreux Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:06:57 -0000 --Apple-Mail-C7C4D6EF-93CE-43F1-9570-3016D2935F07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. I object. ExternalId is optional. There is no need for this major break= ing change. IMHO.=20 Phil On 2012-08-11, at 10:18, Ganesh and Sashi Prasad wrot= e: > > And that's because? I don't see any value to the behavior (enabling att= ribute searches on non-existent schema) you suggest.=20 >=20 > I wasn't suggesting there was value in it. I was covering the possibility t= hat the client could erroneously send URI parameters that are not valid attr= ibutes of the resource, and the only response to such requests is a "400 Bad= Request". >=20 > > My question is why do you believe an SP ought to care about "candidate k= eys"? Resources are uniquely identified exactly 1 way by the SP and that i= s by the SP minted id. The Consumer can retrieve a resource by any attribut= e though only the id is guaranteed to be unique from the POV of the SP. The= SCIM model is a *mapping* between the consumer and SP hence it is not a pre= scription for how the Resource data is actually stored on either side.=20 >=20 > I think we may actually be in violent agreement here! Your description exa= ctly matches my recommendation of a data model that is loosely-coupled betwe= en client and SP. The SP should not care about "candidate keys", of course. B= ut if one of the attributes of the resource happens to be a client-internal k= ey, then the _client_ knows that it is a candidate key, and that any search b= ased on the candidate key will return at most one URI with the "SP minted ID= ". >=20 > This is what I'd like to see in the SCIM spec. There is only one key expos= ed _as a key_ between client and SP, and that is the "SP minted ID". There i= s no _special_ attribute in the API called an "external ID". If the client w= ants to embed its internal identifier as an attribute within the resource, i= t is free to do so. The SP will treat it as just another attribute and will n= ot even bother to impose a uniqueness constraint on it. >=20 > > If externalId were dropped it wouldn't bother me a bit. =20 >=20 > Good. Does anyone have an actual _objection_ to dropping the "externalID" f= ield? As I said above, it doesn't prevent a client from sending such an attr= ibute as an ordinary attribute and doing searches on it. Keeping the SP igno= rant of its status as a key within the client decouples the two parties to s= ome extent, so dropping the specially-named "externalID" is desirable. >=20 > Regards, > Ganesh >=20 > On 12 August 2012 01:59, Trey Drake wrote: > On Aug 10, 2012, at 5:38 PM, Ganesh and Sashi Prasad wrote: >=20 >> Trey, >>=20 >> > The externalID is not part of the protocol. It is an *optional* attrib= ute within the *schema* specification. >>=20 >> I didn't realise SCIM was also specifying a User schema. Does this mean t= he User resource can only hold certain attributes as defined by this schema?= If so, that's going to be a severe constraint, because client organisations= are likely to require many specialised User attributes depending on the nat= ure of their business, and they will expect to be able to store all of them,= not just the subset defined by the SCIM spec. I hope the SCIM User schema i= s not trying to be just a representation of inetOrgPerson (the standard LDAP= schema), because that could be severely limiting. Most organisations with t= heir own LDAP end up extending inetOrgPerson, and they will expect that they= can do the same in the cloud. >>=20 > I recommend you read the relevant specifications. The working group has ac= cepted both a schema and protocol draft as input to the effort.=20 >=20 >> > As for #2, the protocol spec works as you describe if "arbitrary URI pa= rameters" equate to resource attributes=20 >>=20 >> Yes, that's what I meant, but in implementation, it may work out to be lo= oser than that. The client should be able to specify any arbitrary attribute= in the search parameters, even those that aren't attributes of the resource= . If an attribute is not defined, or if the attribute exists but the value d= oesn't match any stored record, the SP will return no results. In the former= case, it's a "400 Bad Request" and in the latter, it's a "404 Not Found". >=20 > And that's because? I don't see any value to the behavior (enabling attri= bute searches on non-existent schema) you suggest.=20 >=20 >>=20 >> By "candidate key" (a data modelling term), I meant another attribute tha= t also uniquely identifies a single record, but is not the official "primary= key", i.e., the main ID. In this case, a client's internal identifier also u= niquely identifies a record, but is not the ID used in the URI of RESTful op= erations. >=20 > I know what a candidate key is. My question is why do you believe an SP o= ught to care about "candidate keys"? Resources are uniquely identified exa= ctly 1 way by the SP and that is by the SP minted id. The Consumer can retr= ieve a resource by any attribute though only the id is guaranteed to be uniq= ue from the POV of the SP. The SCIM model is a *mapping* between the consum= er and SP hence it is not a prescription for how the Resource data is actual= ly stored on either side. > =20 >>=20 >> Look, this may seem to be splitting hairs since a determined client may b= e able to store and search by their own internal ID in either case (the curr= ent SCIM spec or my suggestion). The difference is philosophical. If the spe= c is showing how clients can store their internal IDs in the cloud by explic= itly providing for such an attribute, that constitutes bad advice, IMO. If i= t turns a blind eye to what they store and they store internal IDs anyway, t= hey're constraining themselves but the spec comes out smelling of roses beca= use that's not "recommended practice". >>=20 >=20 > If externalId were dropped it wouldn't bother me a bit. =20 >=20 >> Ganesh >>=20 >> On 11 August 2012 00:50, Trey Drake wrote: >> Ganesh, >>=20 >> I'll base my comments on your latest reply (below). =20 >>=20 >> The externalID is not part of the protocol. It is an *optional* attribut= e within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters). Please c= larify your suggestion. >>=20 >> I'm not tracking your coupling concern. The client can search and hence r= etrieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. =20 >>=20 >>=20 >> What do you mean by "candidate key"? Given=20 >>=20 >> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad wrote: >> > I think scim gets its current simplicity from its single owner hub spo= ke model implementing tight coupling. [...] IMHO loose coupling is a much mo= re complex solution. >>=20 >> Phil, >>=20 >> I'm a bit surprised that you're implying "tight coupling =3D=3D simple" a= nd "loose coupling =3D=3D complex". That's contrary to my experience. >>=20 >> When I say "loose coupling", I mean "no unnecessary dependencies". Invari= ably, a reduction in dependencies leads to greater simplicity. >>=20 >> Let's not confuse reduction of dependencies in the data model with a hub-= and-spokes architecture. They're entirely orthogonal aspects of the solution= . >>=20 >> All that my suggestion involves is, >>=20 >> 1. Take 'external ID' out of the protocol. >> 2. Allow generic search using 'GET /Users' and arbitrary URI parameters >>=20 >> No planned functionality is lost by this. >>=20 >> 1. The client enterprise can still send its internal ID as part of the re= source body, inside some attribute defined by them (but not defined by the p= rotocol). Let's say they call it 'myID'. >> 2. The client enterprise can search for resource URIs using any attribute= , including this internal ID >> 'GET /Users?myID=3Dbjensen' >> Since myID is a candidate key, the server will return exactly one URI, wh= ich is the canonical URI for the resource >> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >> 3. The client can use this URI to perform all other operations as usual. >>=20 >> So taking 'externalID' out of the protocol spec only does this: >> 1. It avoids enshrining tight coupling in the protocol (If clients want t= o tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of a= ssisted suicide. ;-) >> 2. It encourages loose coupling by nudging clients towards maintaining th= eir own internal-to-external identifier mappings. >>=20 >> That's what I'd like to see. I don't believe this complicates the protoco= l. It simplifies it and it also lends itself to a loosely-coupled approach. >>=20 >> I'll address the multi-valued attribute suggestion separately. >>=20 >> Regards, >> Ganesh >>=20 >>=20 >>=20 >>=20 >> On 10 August 2012 07:53, Phil Hunt wrote: >>=20 >>=20 >> Phil >>=20 >> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad w= rote: >>=20 >>> > storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM is= just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains.=20 >>>=20 >>> I wasn't suggesting that the mapping table be part of the SCIM spec. I p= rovided that example to illustrate that splitting and merging identities is a= common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. >>>=20 >>> I'm suggesting that the spec do less, not more. >>>=20 >>> What the SCIM spec needs to do there is just refrain from introducing ti= ght coupling. I would like to see a single identifier exposed through the AP= I, with the implication (and perhaps the recommendation) that it be the shar= ed one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spli= t or merge identities, which is not desirable. So I recommend _taking out_ t= he "external id" field from the API. The spec shouldn't encourage tight coup= ling. If clients want to pass in their internal ids as part of the resource b= ody, no one can stop them, and they can always do a search on that attribute= to retrieve the URI exactly as you visualise they will with the "external i= d", but let's not elevate an anti-pattern to a recommendation by enshrining t= he "external id" as an acceptable attribute. >>>=20 >>> Am I making sense? >>=20 >> I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling.=20 >>=20 >> IMHO loose coupling is a much more complex solution. The reality is that e= ach end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub.=20 >>=20 >> That said i think the current model provides a practical starting point.=20= >>>=20 >>> > Regarding unique identifiers for multi-valued attributes there is a t= rade-off involved. On one hand this makes PATCH semantics easier. On the o= ther hand it puts extra burden on service providers.=20 >>>=20 >>> Precisely. The spec has to strike the right balance. It would be interes= ting to hear from the other members of the spec mailing list. You know where= I stand on this. It would be good to hear the spectrum of opinions. >>>=20 >>> Regards, >>> Ganesh >>>=20 >>> On 10 August 2012 00:28, Kelly Grizzle wro= te: >>> Thanks Emmanuel. I had started writing up a similar response. As you s= uggest, storing this information in a mapping table outside of the SCIM spec= is a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsibl= e for the transport layer between domains. >>>=20 >>> =20 >>>=20 >>> You could also model these ID mappings in the SCIM user as an extension b= ut would probably not want to expose these externally. Here is an example o= f how to model the end state of the false positive scenario (splitting a use= r): >>>=20 >>> =20 >>>=20 >>> | Internal Entity ID | External Domain ID | External Entity ID | Primary= flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>>=20 >>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | >>>=20 >>> =20 >>>=20 >>> This could be represented as two SCIM users that contain information abo= ut the entities on other domains. >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:f= ederation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:f= ederation:1.0"], >>>=20 >>> "id": "a99a5feba839", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "7a87f27c1dd8" >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> In the second user, the linkedUsers attribute would be empty until the s= plit user was synced to domain 2. >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Similarly, the false negative use case (merging two users) looked like t= his at the end: >>>=20 >>> =20 >>>=20 >>> | Internal Entity ID | External Domain ID | External Entity ID | Primary= flag | >>>=20 >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | >>>=20 >>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | >>>=20 >>> =20 >>>=20 >>> This could be represented with the following SCIM user: >>>=20 >>> =20 >>>=20 >>> { >>>=20 >>> "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:f= ederation:1.0"], >>>=20 >>> "id": "9caf78aac3d6", >>>=20 >>> "userName": "John Smith", >>>=20 >>> "urn:scim:schemas:extension:federation:1.0": { >>>=20 >>> "linkedUsers": [ >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "ff487230b3a0" >>>=20 >>> }, >>>=20 >>> { >>>=20 >>> "domain": "D2", >>>=20 >>> "externalEntityId": "41206cc97c8b", >>>=20 >>> "deletionRequired": true >>>=20 >>> } >>>=20 >>> ] >>>=20 >>> } >>>=20 >>> } >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the othe= r hand it puts extra burden on service providers. Since the inception of SC= IM, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique ident= ifiers for multi-valued attributes is not worth the demands put on a service= provider. I also think that vendors that have a non-SCIM-compliant API wil= l choose to keep things that way if the spec is too hard for them to impleme= nt. In a green field environment we do have the luxury of mandating a model= to make certain operations more elegant. However, we can=E2=80=99t ignore l= egacy systems. >>>=20 >>> =20 >>>=20 >>> --Kelly >>>=20 >>> =20 >>>=20 >>> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of E= mmanuel Dreux >>> Sent: Thursday, August 09, 2012 3:18 AM >>> To: Ganesh and Sashi Prasad; Kelly Grizzle >>> Cc: scim@ietf.org >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>>=20 >>> Hi Ganesh, >>>=20 >>> =20 >>>=20 >>> Nothing prevents you in your SCIM implementation (client or server) to g= enerate a unique identifier for each synchronized object and maintain an int= ernal mapping table ( you would have to map group membership as well). >>>=20 >>> =20 >>>=20 >>> This is what we are doing with Active Directory sources or targets: >>>=20 >>> As we didn=E2=80=99t find an immutable uniqueID in AD systems (DN,samAcc= ountName, UPN) are subject to change (even objectGuid can change if an AD do= main is migrated), we decided to generate and maintain an internal table of i= ds. This fits your requirements as it hides internal ids. >>>=20 >>> =20 >>>=20 >>> This was written in dotnet and we have started a project to rewrite our S= CIM stack in PHP and will give it to the Open Source community. This impleme= ntation will have a parameter : AllocateIds versus UseExistingIDs. >>>=20 >>> This will give the choice of =E2=80=9Chiding=E2=80=9D internalIDs or use= them as unique ID. >>>=20 >>> =20 >>>=20 >>> You can also implement such feature without violating the SCIM specs, or= without asking to include it in the specs. >>>=20 >>> =20 >>>=20 >>> -- >>>=20 >>> Regards, >>>=20 >>> Emmanuel Dreux >>>=20 >>> http://www.cloudiway.com >>>=20 >>> Tel: +33 4 26 78 17 58 >>>=20 >>> Mobile: +33 6 47 81 26 70 >>>=20 >>> skype: Emmanuel.Dreux >>>=20 >>> =20 >>>=20 >>> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >>> Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35 >>> =C3=80 : Kelly Grizzle >>> Cc : scim@ietf.org >>> Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>=20 >>> =20 >>>=20 >>> Hi Kelly, >>> Thanks for your response. Let me first respond in brief to the two main p= oints you have made, and then elaborate on the first. >>> 1. Why should domains not expose their internal identifiers to othe= r domains? >>> a. >>> We are designing a protocol for a federated system of domains, where all= domains are co-equal peers. (In physics too, N-body problems are much harde= r than 2-body problems. :-) Therefore, assuming that there are only two play= ers in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-specif= ic data. >>> b. >>> In any non-trivial data store, there will always be the ongoing need to m= erge and split identities as and when =E2=80=9Cfalse negatives=E2=80=9D and =E2= =80=9Cfalse positives=E2=80=9D are discovered. A domain should be able to ha= ndle this internal housekeeping freely, only notifying other domains when co= nvenient. Mapping of internal identifiers to external ones and maintaining t= his mapping internally allows this loosely-coupled housekeeping to take plac= e. Sharing internal identifiers (or otherwise outsourcing the mapping of int= ernal to external identifiers) forces housekeeping activities to be done in l= ock-step across domains. >>> c. >>> Asynchronous interaction is not just a matter of a suitable wire protoco= l which can be designed later. The data model plays a crucial role in enabli= ng or constraining such interaction. A tightly-coupled data model will force= the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. >>> 2. The difficulty of assigning unique identifiers to the individual valu= es of multi-valued attributes: >>> a. >>> I'm not belittling the effort involved in migrating legacy data stores t= o such a model. However, in the larger historical context of cross-domain id= entity management, we are really at the very early stages. If a relatively n= ew discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subse= quent users of the spec, and this will have repercussions over many years or= even decades. >>> b. >>> If incumbent cloud providers find it hard to immediately adopt the dicti= onary model for existing multi-valued attributes, they can transition to thi= s model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2=80=9Cnon-S= CIM-compliant=E2=80=9D APIs to their customers and encouraging new customers= to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API. Legacy customers can be s= upported using a =E2=80=9Cnon-SCIM-compliant=E2=80=9D API for an arbitrarily= long period and gradually migrated to the SCIM-compliant API. The logistics= are not insurmountable, and shouldn't prevent the adoption of a dictionary m= odel for multi-valued attributes. >>> Elaboration of Point 1: >>> When we consider federated identity across more than one domain, we have= to assume that domains are not necessarily master-slave in their interactio= n. The most generic interaction model is peer-to-peer, where entity lifecycl= e events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are fr= ee to respond to these events in an appropriate manner and at a time of thei= r convenience. >>> A key set of lifecycle events for an entity is the merging and splitting= of identity that is often required. >>> The question =E2=80=9CIs this one entity?=E2=80=9D can be answered eithe= r yes (positive) or no (negative). But sometimes, we can discover false posi= tives and false negatives in our data stores. >>> Consider a case where customers sign up online, and two customers who ar= e privacy-conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and= also use the same date of birth (say, 1 Jan 1970) or similar attributes. Th= e front-end application may make an intelligent (but incorrect) guess that t= hese two persons are the same, and re-assign the same identifier to the seco= nd person. This is a false positive. They appear to be the same entity, but t= hey're actually different. When the error is discovered, the identities will= need to be split, with a new identifier generated for one of them. >>> Consider the opposite case where a customer signs up through two differe= nt portals or in two different sessions, using the names =E2=80=9CJSmith=E2=80= =9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated= as two different customers and assigned two unique identifiers. This is a f= alse negative. They appear to be two entities, but are actually the same. At= a later stage, when the error is discovered, the identities will have to be= merged, and one of the identifiers will have to be dropped. >>> These are not theoretical use cases. They form a significant proportion o= f the user base in most large Web-facing applications. Let's see how these c= an be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. >>> a. False positives: >>> Domain 1 has the following information about a customer in its data stor= e: >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-19= 70=E2=80=9D} >>> When requesting the provisioning of this entity in Domain 2, the followi= ng ID is returned by Domain 2: ff487230b3a0. >>> Domain 1 then maintains the following in a mapping table and uses it for= translation when talking to Domain 2, taking care never to expose its inter= nal identifier: >>> | Internal Entity ID | External Domain ID | External Entity ID | Primary= flag | >>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>> When the false positive is discovered and the entity is split, Domain 1 c= reates a new internal identifier and now has the following entity informatio= n. >>> Internal ID: 9caf78aac3d6 >>> Attributes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-19= 70=E2=80=9D} >>> Internal ID: a99a5feba839 --Apple-Mail-C7C4D6EF-93CE-43F1-9570-3016D2935F07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <= /div>= --Apple-Mail-C7C4D6EF-93CE-43F1-9570-3016D2935F07-- From kelly.grizzle@sailpoint.com Sat Aug 11 18:54:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D711E8091 for ; Sat, 11 Aug 2012 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0m1IH71D5fX for ; Sat, 11 Aug 2012 18:54:03 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3421F84F2 for ; Sat, 11 Aug 2012 18:54:01 -0700 (PDT) Received: from mail126-db3-R.bigfish.com (10.3.81.226) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Sun, 12 Aug 2012 01:54:00 +0000 Received: from mail126-db3 (localhost [127.0.0.1]) by mail126-db3-R.bigfish.com (Postfix) with ESMTP id A8A8F160094; Sun, 12 Aug 2012 01:54:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -95 X-BigFish: PS-95(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85ehc430I1418Iac5W9d9Rzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail126-db3: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail126-db3 (localhost.localdomain [127.0.0.1]) by mail126-db3 (MessageSwitch) id 1344736435636567_23292; Sun, 12 Aug 2012 01:53:55 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.244]) by mail126-db3.bigfish.com (Postfix) with ESMTP id 859073C0044; Sun, 12 Aug 2012 01:53:55 +0000 (UTC) Received: from BY2PRD0410HT004.namprd04.prod.outlook.com (157.56.236.85) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 12 Aug 2012 01:53:54 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT004.namprd04.prod.outlook.com ([10.255.83.39]) with mapi id 14.16.0175.005; Sun, 12 Aug 2012 01:53:52 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad , Phil Hunt Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PrysoINrXz30exI2CcM9WIa5dT/IGAgABLt4CAAHBZgIAACouAgACi+YU= Date: Sun, 12 Aug 2012 01:53:51 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330257D6BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 01:54:08 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330257D6BY2PRD0410MB354_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh and= Sashi Prasad [g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestion worth adop= ting in spite of the Cons, or are the Cons so great that it's best to leave= the spec as it is? Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, and t= here could be an exodus of clients to these new SPs. SCIM could end up bein= g obsoleted very soon, because the API interface is very complex and clumsy= , as any new reader can attest. I was taken aback by the complexity when I = saw it, which is why I was prompted to suggest something simpler. This is an issue where we need the opinions of many people, and they need t= o state their affiliations. If most people weighing in belong to incumbent = SPs and they vote in favour of interface complexity to avoid implementation= complexity, then it means the spec is not doing a good job of balancing th= e interests of various groups. I think we should also poll client organisat= ions to see what they would want. (Gartner is trusted by enterprise clients to evaluate the capabilities of v= endors (SPs). I believe Gartner should take the lead in representing client= interests in this working group rather than those of incumbent vendors, wh= ich is what it seems like to me. Correct me if I'm being unfair.) Regards, Ganesh On 11 August 2012 01:35, Diodati,Mark > wrote: Hi Ganesh, I am concerned about your second suggestion: =932. When dealing with multi-valued attributes of a resource (expressed as= arrays in JSON), they must be converted from an array into a dictionary wi= th unique keys (UUIDs generated by the cloud provider when the attribute is= created). Without unique keys for every attribute value of a resource, man= ipulating it will be clumsy and inelegant.=94 One of the primary reasons that SPML failed was lack of adoption by service= providers due to its complexity. Very few target applications implemented = SPML. Most of the commercial provisioning systems had an SPML interface (ei= ther v1 or v2), but not one of them was conformant to the SPML standard bec= ause of complexity. If you are interested, I will forward you the research = documents that discuss these problems in detail. For SCIM to be successful,= it must be adopted by commercial target applications (i.e., service provid= ers). I am confident that a requirement for unique identifiers with multi-v= alued attributes will preclude its adoption, because it requires major chan= ges to the service provider=92s existing identity storage mechanisms. Mark From: Trey Drake [mailto:trey.drake@unboundid.com] Sent: Friday, August 10, 2012 9:51 AM To: Ganesh and Sashi Prasad Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phi= l Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute = within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (Al= low generic search using 'GET /Users' and arbitrary URI parameters). Pleas= e clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence re= trieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > wrote: > I think scim gets its current simplicity from its single owner hub spoke= model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and= "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariab= ly, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-an= d-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the reso= urce body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, = including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, whic= h is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to = tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of= assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining thei= r own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol.= It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt > wrote: Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? I see what you are saying. I think scim gets its current simplicity from it= s single owner hub spoke model implementing tight coupling. IMHO loose coupling is a much more complex solution. The reality is that ea= ch end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub. That said i think the current model provides a practical starting point. > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can=92t ignore = legacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountName,= UPN) are subject to change (even objectGuid can change if an AD domain is = migrated), we decided to generate and maintain an internal table of ids. Th= is fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of =93hiding=94 internalIDs or use them as unique= ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when =93false negatives=94 and =93false posi= tives=94 are discovered. A domain should be able to handle this internal ho= usekeeping freely, only notifying other domains when convenient. Mapping of= internal identifiers to external ones and maintaining this mapping interna= lly allows this loosely-coupled housekeeping to take place. Sharing interna= l identifiers (or otherwise outsourcing the mapping of internal to external= identifiers) forces housekeeping activities to be done in lock-step across= domains. c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both =93SCIM-compliant=94 and =93non-SCIM-compliant=94 AP= Is to their customers and encouraging new customers to adopt the =93SCIM-co= mpliant=94 API. Legacy customers can be supported using a =93non-SCIM-compl= iant=94 API for an arbitrarily long period and gradually migrated to the SC= IM-compliant API. The logistics are not insurmountable, and shouldn't preve= nt the adoption of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question =93Is this one entity?=94 can be answered either yes (positive= ) or no (negative). But sometimes, we can discover false positives and fals= e negatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as =93John Smith=94, and also use the = same date of birth (say, 1 Jan 1970) or similar attributes. The front-end a= pplication may make an intelligent (but incorrect) guess that these two per= sons are the same, and re-assign the same identifier to the second person. = This is a false positive. They appear to be the same entity, but they're ac= tually different. When the error is discovered, the identities will need to= be split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names =93JSmith=94 and =93J= ohnS=94. It is very likely that they will be treated as two different custo= mers and assigned two unique identifiers. This is a false negative. They ap= pear to be two entities, but are actually the same. At a later stage, when = the error is discovered, the identities will have to be merged, and one of = the identifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} Internal ID: a99a5feba839 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-v= ersa. At some convenient time (importantly, this doesn't have to be at the = time the split happens), Domain 2 can be requested to provision a second en= tity, and when it responds with an identifier of =937a87f27c1dd8=94, this c= an go into the mapping table as a new record associated with the second ent= ity's internal identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} Internal ID: 273d36e30d09 Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to =93John Smith=94). Let's say it retains the first ID =93= 9caf78aac3d6=94 and drops the second =93273d36e30d09=94. The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambi _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_56C3C758F9D6534CA3778EAA1E0C3437330257D6BY2PRD0410MB354_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ganesh,

This is exactly how PATCH works in SCIM 1.0.  Mu= lti-valued attributes that have a value sub-attribute can be removed by spe= cifying only the value since it is unique.  Multi-valued attributes th= at don't have a value sub-attribute (eg - address) have to specified completely for uniqueness.  As I have said before, = I am very opposed to adding a unique identifier to each element in a multi-= valued collection due to the burden it will put on SPs.  Is it elegant= ?  No.  Is it functional?  Yes.  Will this non-elegance affect adoption?  My opinion is that adding unique keys = to each element will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more i= ntuitive without adding uids to each element.  The verbs that you prop= ose make sense.  There is also a JSON Patch informational draft in the= IETF that is interesting - http://tools.ietf.org/html/draft-ietf-appsawg= -json-patch-02.  It relies on a JSON Pointer draft which uses index-based addressing = for multi-valued attributes.  I think that this is something that shou= ld be looked at within the WG and I would be willing to lead this effort.

I'm curious if anyone else in the WG is in favor of u= nique identifiers for every multi-valued element.

--Kelly
From: scim-bounces@ietf= .org [scim-bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.pras= ad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique key fo= r each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuitive.&= nbsp;
With my suggestion, here's how to delete a single member from a group:=

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-41386= 1904646"
}
}
] }


You gave other examples of an attribute with an identifier that match= ed that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point of= the extra indexing to support this. Just use the value as the item you wis= h to delete.

I agree, the delete value operation could be more explicit and clear = in general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>  For the multi-value example you gave y= ou used the value as the attribute name key. 

Now I'm confused :-). I don't believe any of my examples ever used a v= alue as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh 

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key. 

That means a lot more complex indexing structure. Better to just say d= elete a specific value. 

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value with an attribute i= d. 

I don't believe so.

I'm adopting a model where every attribute of the resource is a key-va= lue pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself. 

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to distin= guish, and a positional index is inadequate. So we convert the array into a= dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't exi= st, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like these= that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun= t)


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudi= way.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing. 

I agree though that operations in patch could be a lot more explicit.&= nbsp;

Eg explicitly deleting a value by saying delete or retire. 

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am concerned about your second sugge= stion: 

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current = spec:

   PATCH /G=
roups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce=0A=
   Host: example.com=
=0A=
   Accept: application/json=0A=
   Authorization: Bearer h480djs93hd8=0A=
   ETag: W/"a330bc54f0671c9"=0A=
=0A=
   {=0A=
     "schemas": ["urn:scim:schemas:core:1.0"],=0A=
     "members": [=0A=
       {=0A=
         "display": "Babs Jensen",=0A=
         "value": "2819c223-7f76-453a-919d-413861904646"=
;=0A=
         "operation": "delete"=0A=
       }=0A=
     ]=0A=
   }=0A=

Here's how to delete ALL members from a group according to the current spec= :

   PATCH /G=
roups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce=0A=
   Host: example.com=
=0A=
   Accept: application/json=0A=
   Authorization: Bearer h480djs93hd8=0A=
   ETag: W/"a330bc54f0671c9"=0A=
=0A=
   {=0A=
     "schemas": ["urn:scim:schemas:core:1.0"],=0A=
     "meta": {=0A=
       "attributes": [=0A=
         "members"=0A=
       ]=0A=
     }=0A=
   }=0A=

The two operations differ significantly, and it's not very intuitive. =
With my suggestion, here's how to delete a single member from a group:=

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-41386= 1904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LDAP d= irectories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course, so= I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec) ver= sus implementation complexity (my suggestion). Both can hinder adoption of = the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion worth= adopting in spite of the Cons, or are the Cons so great that it's best to = leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issues, = and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

 

I am concerned about yo= ur second suggestion:

=932. When dealing with= multi-valued attributes of a resource (expressed as arrays in JSON), they = must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

 

One of the primary reas= ons that SPML failed was lack of adoption by service providers due to its c= omplexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

 
 
 

From: Trey D= rake [mailto:= trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). =  

 

The externalID is not part of the protocol.  It= is an *optional* attribute within the *schema* specification.  As for= #2, the protocol spec works as you describe if "arbitrary URI paramet= ers" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clar= ify your suggestion.

 

I'm not tracking your coupling concern.  The cl= ient can search and hence retrieve resources on any attribute it chooses, e= xternalId or otherwise.  Nothing mandates use of externalId.  &nb= sp;

 
 

What do you mean by "candidate key"?  = ;Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>  I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling. [...]&nb= sp;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight= coupling =3D=3D simple" and "loose coupling =3D=3D complex"= . That's contrary to my experience.

 

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the d= ata model with a hub-and-spokes architecture. They're entirely orthogonal a= spects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbit= rary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
 
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
 
T=
hat's what I'd like to see. I don't believe this complicates the protocol. =
It simplifies it and it also lends itself to a loosely-coupled approach.
 
I=
'll address the multi-valued attribute suggestion separately.
 
R=
egards,
G=
anesh
 
 
 
 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w= rote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a g= reat way to enable this solution.  Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain= from introducing tight coupling. I would like to see a single identifier e= xposed through the API, with the implication (and perhaps the recommendatio= n) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight co= upling and ensures that both domains need simultaneously split or merge ide= ntities, which is not desirable. So I recommend _taking out_ the "exte= rnal id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their inter= nal ids as part of the resource body, no one can stop them, and they can al= ways do a search on that attribute to retrieve the URI exactly as you visua= lise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its cur= rent simplicity from its single owner hub spoke model implementing tight co= upling. 

 

IMHO loose coupling is a much more complex solution.= The reality is that each end-point has value to contribute and thus the si= ngle-owner model will eventually need to become multi-owner or multi-hub.&n= bsp;

 

That said i think the current model provides a pract= ical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved.  On one hand this makes PATCH semantics easier.  On = the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emmanuel.  = I had started writing up a similar response.  As you suggest, storing = this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM= is just a piece of the architecture for this solution, and is only respons= ible for the transport layer between domains.

 

You could also model th= ese ID mappings in the SCIM user as an extension but would probably not wan= t to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /span>

 

| Internal Entity ID | External Domain ID |= External Entity ID | Primary flag |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | ff487230b3a0    &nb= sp;  | true         |

| a99a5feba839     = ;  | D2          &nb= sp;      | 7a87f27c1dd8    &nb= sp;  | true         |

 

This could be represent= ed as two SCIM users that contain information about the entities on other d= omains.

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "9caf78aac3d6&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "a99a5feba839&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the= linkedUsers attribute would be empty until the split user was synced to do= main 2.

 
 

Similarly, the false ne= gative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID |= External Entity ID | Primary flag |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | ff487230b3a0    &nb= sp;  | true         |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | 41206cc97c8b    &nb= sp;  | false        |

 

This could be represent= ed with the following SCIM user:

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "9caf78aac3d6&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      },

      {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      }

    ]

  }

}

 
 

Regarding unique identi= fiers for multi-valued attributes there is a trade-off involved.  On o= ne hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SC= IM, a key goal has been to foster adoption by service providers by making t= hings fit easily onto existing systems.  IMO the value gained by uniqu= e identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think tha= t vendors that have a non-SCIM-compliant API will choose to keep things tha= t way if the spec is too hard for them to implement.  In a green field= environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=92t= ignore legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,<= /span>

 

Nothing prevents you in= your SCIM implementation (client or server) to generate a unique identifie= r for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doi= ng with Active Directory sources or targets:

As we didn=92t find an = immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to ch= ange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

 

This was written in dot= net and we have started a project to rewrite our SCIM stack in PHP and will= give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choi= ce of =93hiding=94 internalIDs or use them as unique ID.

 

You can also implement = such feature without violating the SCIM specs, or without asking to include= it in the specs.

 

--

Regards,

Emmanuel Dr= eux

http://www.cloudiway.com

Tel: +33 4 2= 6 78 17 58

Mobile: +33 6 4= 7 81 26 70

skype: Emma= nuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi = Kelly,

Tha= nks for your response. Let me first respond in brief to the two main points= you have made, and then elaborate on the first.

1.&nbs= p;     Why should domains not = expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Ela= boration of Point 1:

Whe= n we consider federated identity across more than one domain, we have to as= sume that domains are not necessarily master-slave in their interaction. Th= e most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified t= o other domains (when necessary) in an asynchronous manner (i.e., through m= essaging) and the other domains are free to respond to these events in an a= ppropriate manner and at a time of their convenience.

A k= ey set of lifecycle events for an entity is the merging and splitting of id= entity that is often required.

The= question =93Is this one entity?=94 can be answered either yes (positive) o= r no (negative). But sometimes, we can discover false positives and false n= egatives in our data stores.

Con= sider a case where customers sign up online, and two customers who are priv= acy-conscious enter fake IDs such as =93John Smith=94, and also use the sam= e date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Con= sider the opposite case where a customer signs up through two different por= tals or in two different sessions, using the names =93JSmith=94 and =93John= S=94. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

The= se are not theoretical use cases. They form a significant proportion of the= user base in most large Web-facing applications. Let's see how these can b= e managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. = False positives:

Dom= ain 1 has the following information about a customer in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Whe= n requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifier:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

Whe= n the false positive is discovered and the entity is split, Domain 1 create= s a new internal identifier and now has the following entity information.

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Int= ernal ID: a99a5feba839

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Thi= s second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes place = as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly= , this doesn't have to be at the time the split happens), Domain 2 can be r= equested to provision a second entity, and when it responds with an identif= ier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The= mapping table now contains the following entries:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| a99a5feba839 = | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happene= d, and the provisioning that it does is not in lockstep with the split in i= dentity that occurred in Domain 1.

(Wh= at is the =93Primary flag=94 used for? We'll see when we cover the treatmen= t of false negatives.)

b. = False negatives:

Dom= ain 1 has the following information about what it thinks are two distinct c= ustomers in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Int= ernal ID: 273d36e30d09

Att= ributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

Whe= n requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifiers:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 273d36e30d09 = | D2 | 41206cc97c8b | true |

Whe= n the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the cu= stomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and drops the second =93273= d36e30d09=94.

The= mapping table now looks like this:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 = | D2 | 41206cc97c8b | false |

Now= two external identifiers map to the same internal one, so inbound communic= ation from Domain 2 can be unambi

_______________________________________________

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


--_000_56C3C758F9D6534CA3778EAA1E0C3437330257D6BY2PRD0410MB354_-- From g.c.prasad@gmail.com Sat Aug 11 19:53:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A9321F84EC for ; Sat, 11 Aug 2012 19:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOUqdT2U3C46 for ; Sat, 11 Aug 2012 19:53:31 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8C921F84E2 for ; Sat, 11 Aug 2012 19:53:30 -0700 (PDT) Received: by bkty7 with SMTP id y7so1168836bkt.31 for ; Sat, 11 Aug 2012 19:53: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:from:date:message-id:subject:to :cc:content-type; bh=Gion6tpi4aG2bqytZaHO9rBA4acjWpmeYozinKL6w+c=; b=hYyifx66WThWXE4bqJRfuEvmi3kQdAPxBOixG06rVoECKSq/CYck548F6xxAipcF7l EnvEYUpDuB48RjBe6F0gq2cDd1d4bv7MWxCJQA7ouGotm7aDHDrCMXGbPJj/4Wxaadyb 9gHMZ2Ozk3XAmfeufxyRbMHCJ3zOkJuGbgQoyEAbuABVWjceDPZ9o5SMLuWjhruS08rJ nE3lX+3pTfo5vBldHS3d2WYvPuvYhxiBa6Ztz+G4GwQnnYhOK1+BGQN6JmOb055iPX2q fAO3cRNSoZtiAGMhwQZ8OAbe/4lN+fj/ljxFJux8qSatUKQYL4TqlaDSfXfy66uUqgMi 0uPg== Received: by 10.205.137.8 with SMTP id im8mr2635507bkc.135.1344740009338; Sat, 11 Aug 2012 19:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 19:53:08 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 12:53:08 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015175dd5c892672e04c708ae63 Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 02:53:36 -0000 --0015175dd5c892672e04c708ae63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Multi-valued attributes that don't have a value sub-attribute (eg - address) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be updated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mechanism for simple attributes, I would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, and having two mechanisms (depending on whether the attribute is simple or composite) will complicate every script that has to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is overblown. Is there any SP representative in this WG who can tell us what this proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle wrote: > Ganesh, > > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes > that have a value sub-attribute can be removed by specifying only the val= ue > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption. > > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort. > > I'm curious if anyone else in the WG is in favor of unique identifiers > for every multi-valued element. > > --Kelly > > ------------------------------ > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 > > Phil, > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > > Regards, > Ganesh > > On 12 August 2012 01:12, Phil Hunt wrote: > >> Ganesh, >> >> Here's the sample that concerned me... >> >> The two operations differ significantly, and it's not very intuitive. >> With my suggestion, here's how to delete a single member from a group: >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" { >> "operations" : [ >> { >> "RETIRE" : { >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >> } >> } >> ] } >> >> >> >> You gave other examples of an attribute with an identifier that matched >> that value or of identifiers that were additional unique keys. >> >> Given that multi-values must be each unique, I don't see the point of >> the extra indexing to support this. Just use the value as the item you w= ish >> to delete. >> >> I agree, the delete value operation could be more explicit and clear in >> general. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >> >> > For the multi-value example you gave you used the value as the >> attribute name key. >> >> Now I'm confused :-). I don't believe any of my examples ever used a >> value as the key. >> >> Could you please show me which example you mean, and which parts of it >> you believe to be the value? >> >> Regards, >> Ganesh >> >> On 11 August 2012 13:59, Phil Hunt wrote: >> >>> >>> For the multi-value example you gave you used the value as the attribut= e >>> name key. >>> >>> That means a lot more complex indexing structure. Better to just say >>> delete a specific value. >>> >>> The spec already allows multiple values to have tags like home, work, >>> etc. >>> >>> Phil >>> >>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >>> wrote: >>> >>> > In your example you are conflating value with an attribute id. >>> >>> I don't believe so. >>> >>> I'm adopting a model where every attribute of the resource is a >>> key-value pair. The key is a name or ID. >>> >>> For non-repeating attributes (both simple and composite), the key is >>> the attribute name itself. >>> >>> Simple attribute: >>> >>> Key: "dob" >>> Value: "01 Jan 1970" >>> >>> For composite attributes, the key employs dot notation to specify the >>> fully-qualified attribute name, e.g., "address.postcode". >>> >>> Composite attribute: >>> >>> Key: "address.street-number" >>> Value: "10" >>> >>> Key: "address.suburb" >>> Value: "East Camden" >>> >>> For repeating (multi-valued) attributes, I'm suggesting that there be >>> new keys for each individual value, otherwise they are impossible to >>> distinguish, and a positional index is inadequate. So we convert the ar= ray >>> into a dictionary and this then becomes a composite attribute using dot >>> notation for the key. >>> >>> Multi-valued attribute: >>> >>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>> Value: "john_smith@yahoo.com" >>> >>> So this allows us to apply uniform treatment to any arbitrarily deep >>> resource structure. We can refer to every leaf value with a key that is= the >>> fully-qualified name using dot notation. >>> >>> The verbs are just unambiguous operations on these (now) explicitly >>> addressable attributes. >>> >>> INCLUDE to a collection and specify only the value. The key is >>> generated and returned. The fully-qualified key is >>> . and the value is what was specif= ied >>> in the INCLUDE. >>> >>> REPLACE a fully-qualified key with a new value. If the key doesn't >>> exist, return a "404 Not Found". >>> >>> PLACE a value at the logical location implied by the fully-qualified >>> key. If there is already a key with that name, return a "409 Conflict". >>> >>> FORCE the fully-qualified key to hold the given value, regardless of >>> whether it existed before or not. Only errors possible are "400 Bad >>> Request" and "500 Internal Error". >>> >>> RETIRE an attribute or a collection given its fully-qualified key. The >>> implementation will determine whether the attribute will disappear enti= rely >>> or will exist holding a null value (the blank string "" or the empty ob= ject >>> {} ). >>> >>> I'll explain in a separate post why we need operation verbs like these >>> that are independent of the HTTP verbs. >>> >>> Regards, >>> Ganesh >>> >>> On 11 August 2012 10:38, wrote: >>> >>>> If you have received this digest without all the individual message >>>> attachments you will need to update your digest options in your list >>>> subscription. To do so, go to >>>> >>>> https://www.ietf.org/mailman/listinfo/scim >>>> >>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>> globally for all the list digests you receive at this point. >>>> >>>> >>>> >>>> Send scim mailing list submissions to >>>> scim@ietf.org >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://www.ietf.org/mailman/listinfo/scim >>>> or, via email, send a message with subject or body 'help' to >>>> scim-request@ietf.org >>>> >>>> You can reach the person managing the list at >>>> scim-owner@ietf.org >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of scim digest..." >>>> >>>> Today's Topics: >>>> >>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Phil Hunt >>>> To: Ganesh and Sashi Prasad >>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>> edreux@cloudiway.com>, Trey Drake , Kelly >>>> Grizzle , "scim@ietf.org" >>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>> Ganesh, >>>> >>>> In your example you are conflating value with an attribute id. I find >>>> that confusing. >>>> >>>> I agree though that operations in patch could be a lot more explicit. >>>> >>>> Eg explicitly deleting a value by saying delete or retire. >>>> >>>> Phil >>>> >>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >>>> wrote: >>>> >>>> > I am concerned about your second suggestion: >>>> >>>> Let's discuss that now. >>>> >>>> The trade-offs are very clear here. >>>> >>>> Pros: >>>> >>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>> consistent and intuitive when every individual attribute value gets it= s own >>>> ID. >>>> >>>> Here's how to delete a single member from a Group, as per the current >>>> spec: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>> >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "members": [ >>>> { >>>> "display": "Babs Jensen", >>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>> "operation": "delete" >>>> } >>>> ] >>>> } >>>> >>>> >>>> Here's how to delete ALL members from a group according to the current >>>> spec: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>> Host: example.com >>>> Accept: application/json >>>> Authorization: Bearer h480djs93hd8 >>>> ETag: W/"a330bc54f0671c9" >>>> >>>> { >>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>> "meta": { >>>> "attributes": [ >>>> "members" >>>> ] >>>> } >>>> } >>>> >>>> >>>> The two operations differ significantly, and it's not very intuitive. >>>> With my suggestion, here's how to delete a single member from a group: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comA= ccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>> W/"a330bc54f0671c9" { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>> } >>>> } >>>> ] } >>>> Here's how I suggest deleting ALL members from a group: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comA= ccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>> W/"a330bc54f0671c9" { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members" >>>> } >>>> } >>>> ] } >>>> >>>> I'm sure you'll agree that this is simpler, more consistent and more >>>> intuitive to a reader. >>>> >>>> Pro 2: We can apply this mechanism consistently to three areas: >>>> (a) Manipulating multi-valued attributes of a resource >>>> (b) Manipulating members of a group >>>> (c) Performing bulk operations, where we simply use HTTP verbs instead >>>> of the specialised (and semantically less ambiguous) verbs I suggested= for >>>> attributes, the "key" becomes the URI, and the "value" becomes the >>>> corresponding JSON object. >>>> >>>> All of them return "207 Multi-Status" with the "results" array >>>> holding individual status codes. >>>> >>>> In the current spec, (a) and (b) are done similarly but (c) is very >>>> different. >>>> >>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>> because it's simpler for them. >>>> >>>> Pro 4: New (not incumbent) cloud providers will probably find this >>>> easier to implement because they have no legacy. They will probably us= e >>>> some form of NoSQL database and won't be constrained by the limitation= s of >>>> LDAP directories. >>>> >>>> Cons: >>>> >>>> Con 1: Incumbent cloud providers with existing data stores in a >>>> directory format (where multi-valued attributes are stored as >>>> comma-separated values under a single attribute node) will find it >>>> difficult to migrate to this model and store each attribute value as a >>>> sub-node with its own key. This will "hinder adoption of the spec", wh= ich >>>> is what you fear. >>>> >>>> Have I summed up the Pros and Cons correctly? I'm biased of course, >>>> so I could have missed a Con or hyped a Pro :-). >>>> >>>> In other words, we're debating interface complexity (current spec) >>>> versus implementation complexity (my suggestion). Both can hinder adop= tion >>>> of the spec by different parties. >>>> >>>> Here's what we need to discuss - Do the Pros make the suggestion >>>> worth adopting in spite of the Cons, or are the Cons so great that it'= s >>>> best to leave the spec as it is? >>>> >>>> Keep in mind that a complex spec that only favours incumbent cloud >>>> providers can cut both ways. It opens the door to a simpler interface >>>> offered by a new generation of nimbler SPs that don't have the same le= gacy >>>> issues, and there could be an exodus of clients to these new SPs. SCIM >>>> could end up being obsoleted very soon, because the API interface is v= ery >>>> complex and clumsy, as any new reader can attest. I was taken aback by= the >>>> complexity when I saw it, which is why I was prompted to suggest somet= hing >>>> simpler. >>>> >>>> This is an issue where we need the opinions of many people, and they >>>> need to state their affiliations. If most people weighing in belong to >>>> incumbent SPs and they vote in favour of interface complexity to avoid >>>> implementation complexity, then it means the spec is not doing a good = job >>>> of balancing the interests of various groups. I think we should also p= oll >>>> client organisations to see what they would want. >>>> >>>> (Gartner is trusted by enterprise clients to evaluate the >>>> capabilities of vendors (SPs). I believe Gartner should take the lead = in >>>> representing client interests in this working group rather than those = of >>>> incumbent vendors, which is what it seems like to me. Correct me if I'= m >>>> being unfair.) >>>> >>>> Regards, >>>> Ganesh >>>> >>>> >>>> >>>> On 11 August 2012 01:35, Diodati,Mark wrote= : >>>> >>>>> Hi Ganesh, >>>>> >>>>> >>>>> I am concerned about your second suggestion: >>>>> >>>>> =932. When dealing with multi-valued attributes of a resource (expres= sed >>>>> as arrays in JSON), they must be converted from an array into a dicti= onary >>>>> with unique keys (UUIDs generated by the cloud provider when the attr= ibute >>>>> is created). Without unique keys for every attribute value of a resou= rce, >>>>> manipulating it will be clumsy and inelegant.=94 >>>>> >>>>> >>>>> One of the primary reasons that SPML failed was lack of adoption by >>>>> service providers due to its complexity. Very few target applications >>>>> implemented SPML. Most of the commercial provisioning systems had an = SPML >>>>> interface (either v1 or v2), but not one of them was conformant to th= e SPML >>>>> standard because of complexity. If you are interested, I will forward= you >>>>> the research documents that discuss these problems in detail. For SCI= M to >>>>> be successful, it must be adopted by commercial target applications (= i.e., >>>>> service providers). I am confident that a requirement for unique >>>>> identifiers with multi-valued attributes will preclude its adoption, >>>>> because it requires major changes to the service provider=92s existin= g >>>>> identity storage mechanisms. >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> >>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>> >>>>> *To:* Ganesh and Sashi Prasad >>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>> >>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> >>>>> Ganesh, >>>>> >>>>> >>>>> I'll base my comments on your latest reply (below). >>>>> >>>>> >>>>> The externalID is not part of the protocol. It is an *optional* >>>>> attribute within the *schema* specification. As for #2, the protocol= spec >>>>> works as you describe if "arbitrary URI parameters" equate to resourc= e >>>>> attributes (Allow generic search using 'GET /Users' and arbitrary URI >>>>> parameters). Please clarify your suggestion. >>>>> >>>>> >>>>> I'm not tracking your coupling concern. The client can search and >>>>> hence retrieve resources on any attribute it chooses, externalId or >>>>> otherwise. Nothing mandates use of externalId. >>>>> >>>>> >>>>> >>>>> What do you mean by "candidate key"? Given >>>>> >>>>> >>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>> g.c.prasad@gmail.com> wrote: >>>>> >>>>> > I think scim gets its current simplicity from its single owner hub >>>>> spoke model implementing tight coupling. [...] IMHO loose coupling is= a >>>>> much more complex solution. >>>>> >>>>> >>>>> Phil, >>>>> >>>>> >>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D simpl= e" >>>>> and "loose coupling =3D=3D complex". That's contrary to my experience= . >>>>> >>>>> >>>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>>> Invariably, a reduction in dependencies leads to greater simplicity. >>>>> >>>>> >>>>> Let's not confuse reduction of dependencies in the data model with a >>>>> hub-and-spokes architecture. They're entirely orthogonal aspects of t= he >>>>> solution. >>>>> >>>>> >>>>> All that my suggestion involves is, >>>>> >>>>> >>>>> 1. Take 'external ID' out of the protocol. >>>>> >>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI paramete= rs >>>>> >>>>> >>>>> No planned functionality is lost by this. >>>>> >>>>> >>>>> 1. The client enterprise can still send its internal ID as part of th= e >>>>> resource body, inside some attribute defined by them (but not defined= by >>>>> the protocol). Let's say they call it 'myID'. >>>>> >>>>> 2. The client enterprise can search for resource URIs using any >>>>> attribute, including this internal ID >>>>> >>>>> 'GET /Users?myID=3Dbjensen' >>>>> >>>>> Since myID is a candidate key, the server will return exactly one URI= , >>>>> which is the canonical URI for the resource >>>>> >>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>> >>>>> 3. The client can use this URI to perform all other operations as usu= al. >>>>> >>>>> >>>>> >>>>> So taking 'externalID' out of the protocol spec only does this: >>>>> >>>>> 1. It avoids enshrining tight coupling in the protocol (If clients wa= nt to tightly couple themselves to the cloud provider by sending their inte= rnal IDs, they can do so. Suicide is OK, but the protocol should not be gui= lty of assisted suicide. ;-) >>>>> >>>>> 2. It encourages loose coupling by nudging clients towards maintainin= g their own internal-to-external identifier mappings. >>>>> >>>>> >>>>> >>>>> That's what I'd like to see. I don't believe this complicates the pro= tocol. It simplifies it and it also lends itself to a loosely-coupled appro= ach. >>>>> >>>>> >>>>> >>>>> I'll address the multi-valued attribute suggestion separately. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Ganesh >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>> >>>>> >>>>> >>>>> Phil >>>>> >>>>> >>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad >>>>> wrote: >>>>> >>>>> > storing this information in a mapping table outside of the SCIM >>>>> spec is a great way to enable this solution. Part of the key here is= that >>>>> SCIM is just a piece of the architecture for this solution, and is on= ly >>>>> responsible for the transport layer between domains. >>>>> >>>>> I wasn't suggesting that the mapping table be part of the SCIM spec. = I >>>>> provided that example to illustrate that splitting and merging identi= ties >>>>> is a common requirement, and that decoupling local identifiers within= a >>>>> domain from shared identifiers between domains was the best way to >>>>> facilitate it. >>>>> >>>>> >>>>> I'm suggesting that the spec do less, not more. >>>>> >>>>> >>>>> What the SCIM spec needs to do there is just refrain from introducing >>>>> tight coupling. I would like to see a single identifier exposed throu= gh the >>>>> API, with the implication (and perhaps the recommendation) that it be= the >>>>> shared one. Allowing one domain to expose its internal identifier to = the >>>>> other creates tight coupling and ensures that both domains need >>>>> simultaneously split or merge identities, which is not desirable. So = I >>>>> recommend _taking out_ the "external id" field from the API. The spec >>>>> shouldn't encourage tight coupling. If clients want to pass in their >>>>> internal ids as part of the resource body, no one can stop them, and = they >>>>> can always do a search on that attribute to retrieve the URI exactly = as you >>>>> visualise they will with the "external id", but let's not elevate an >>>>> anti-pattern to a recommendation by enshrining the "external id" as a= n >>>>> acceptable attribute. >>>>> >>>>> >>>>> Am I making sense? >>>>> >>>>> >>>>> >>>>> I see what you are saying. I think scim gets its current simplicity >>>>> from its single owner hub spoke model implementing tight coupling. >>>>> >>>>> >>>>> IMHO loose coupling is a much more complex solution. The reality is >>>>> that each end-point has value to contribute and thus the single-owner= model >>>>> will eventually need to become multi-owner or multi-hub. >>>>> >>>>> >>>>> That said i think the current model provides a practical starting >>>>> point. >>>>> >>>>> >>>>> >>>>> > Regarding unique identifiers for multi-valued attributes there is >>>>> a trade-off involved. On one hand this makes PATCH semantics easier.= On >>>>> the other hand it puts extra burden on service providers. >>>>> >>>>> >>>>> Precisely. The spec has to strike the right balance. It would be >>>>> interesting to hear from the other members of the spec mailing list. = You >>>>> know where I stand on this. It would be good to hear the spectrum of >>>>> opinions. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Ganesh >>>>> >>>>> On 10 August 2012 00:28, Kelly Grizzle >>>>> wrote: >>>>> >>>>> Thanks Emmanuel. I had started writing up a similar response. As yo= u >>>>> suggest, storing this information in a mapping table outside of the S= CIM >>>>> spec is a great way to enable this solution. Part of the key here is= that >>>>> SCIM is just a piece of the architecture for this solution, and is on= ly >>>>> responsible for the transport layer between domains. >>>>> >>>>> >>>>> You could also model these ID mappings in the SCIM user as an >>>>> extension but would probably not want to expose these externally. He= re is >>>>> an example of how to model the end state of the false positive scenar= io >>>>> (splitting a user): >>>>> >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true | >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>> true | >>>>> >>>>> >>>>> This could be represented as two SCIM users that contain information >>>>> about the entities on other domains. >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "9caf78aac3d6", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "ff487230b3a0" >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "a99a5feba839", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "7a87f27c1dd8" >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> In the second user, the linkedUsers attribute would be empty until th= e >>>>> split user was synced to domain 2. >>>>> >>>>> >>>>> >>>>> Similarly, the false negative use case (merging two users) looked lik= e >>>>> this at the end: >>>>> >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>> true | >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>> false | >>>>> >>>>> >>>>> This could be represented with the following SCIM user: >>>>> >>>>> >>>>> { >>>>> >>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>> >>>>> "id": "9caf78aac3d6", >>>>> >>>>> "userName": "John Smith", >>>>> >>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>> >>>>> "linkedUsers": [ >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "ff487230b3a0" >>>>> >>>>> }, >>>>> >>>>> { >>>>> >>>>> "domain": "D2", >>>>> >>>>> "externalEntityId": "41206cc97c8b", >>>>> >>>>> "deletionRequired": true >>>>> >>>>> } >>>>> >>>>> ] >>>>> >>>>> } >>>>> >>>>> } >>>>> >>>>> >>>>> >>>>> Regarding unique identifiers for multi-valued attributes there is a >>>>> trade-off involved. On one hand this makes PATCH semantics easier. = On the >>>>> other hand it puts extra burden on service providers. Since the ince= ption >>>>> of SCIM, a key goal has been to foster adoption by service providers = by >>>>> making things fit easily onto existing systems. IMO the value gained= by >>>>> unique identifiers for multi-valued attributes is not worth the deman= ds put >>>>> on a service provider. I also think that vendors that have a >>>>> non-SCIM-compliant API will choose to keep things that way if the spe= c is >>>>> too hard for them to implement. In a green field environment we do h= ave >>>>> the luxury of mandating a model to make certain operations more elega= nt. >>>>> However, we can=92t ignore legacy systems. >>>>> >>>>> >>>>> --Kelly >>>>> >>>>> >>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>> Behalf Of *Emmanuel Dreux >>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>> *Cc:* scim@ietf.org >>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> Hi Ganesh, >>>>> >>>>> >>>>> Nothing prevents you in your SCIM implementation (client or server) t= o >>>>> generate a unique identifier for each synchronized object and maintai= n an >>>>> internal mapping table ( you would have to map group membership as we= ll). >>>>> >>>>> >>>>> This is what we are doing with Active Directory sources or targets: >>>>> >>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can c= hange >>>>> if an AD domain is migrated), we decided to generate and maintain an >>>>> internal table of ids. This fits your requirements as it hides intern= al ids. >>>>> >>>>> >>>>> This was written in dotnet and we have started a project to rewrite >>>>> our SCIM stack in PHP and will give it to the Open Source community. = This >>>>> implementation will have a parameter : AllocateIds versus UseExisting= IDs. >>>>> >>>>> This will give the choice of =93hiding=94 internalIDs or use them as >>>>> unique ID. >>>>> >>>>> >>>>> You can also implement such feature without violating the SCIM specs, >>>>> or without asking to include it in the specs. >>>>> >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> >>>>> Emmanuel Dreux >>>>> >>>>> http://www.cloudiway.com >>>>> >>>>> Tel: +33 4 26 78 17 58 >>>>> >>>>> Mobile: +33 6 47 81 26 70 >>>>> >>>>> skype: Emmanuel.Dreux >>>>> >>>>> >>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>> >>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>> *=C0 :* Kelly Grizzle >>>>> *Cc :* scim@ietf.org >>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> >>>>> >>>>> Hi Kelly, >>>>> >>>>> Thanks for your response. Let me first respond in brief to the two >>>>> main points you have made, and then elaborate on the first. >>>>> >>>>> 1. Why should domains not expose their internal identifiers to >>>>> other domains? >>>>> >>>>> a. >>>>> >>>>> We are designing a protocol for a federated system of domains, where >>>>> all domains are co-equal peers. (In physics too, N-body problems are = much >>>>> harder than 2-body problems. :-) Therefore, assuming that there are o= nly >>>>> two players in the interaction makes this tightly coupled in a number= of >>>>> ways. We should rely on messaging and notification, with encapsulatio= n of >>>>> domain-specific data. >>>>> >>>>> b. >>>>> >>>>> In any non-trivial data store, there will always be the ongoing need >>>>> to merge and split identities as and when =93false negatives=94 and = =93false >>>>> positives=94 are discovered. A domain should be able to handle this i= nternal >>>>> housekeeping freely, only notifying other domains when convenient. Ma= pping >>>>> of internal identifiers to external ones and maintaining this mapping >>>>> internally allows this loosely-coupled housekeeping to take place. Sh= aring >>>>> internal identifiers (or otherwise outsourcing the mapping of interna= l to >>>>> external identifiers) forces housekeeping activities to be done in >>>>> lock-step across domains. >>>>> >>>>> c. >>>>> >>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>> protocol which can be designed later. The data model plays a crucial = role >>>>> in enabling or constraining such interaction. A tightly-coupled data = model >>>>> will force the use of synchronous interactions, and the exposure of >>>>> internal identifiers is a key part of this tight coupling. >>>>> >>>>> 2. The difficulty of assigning unique identifiers to the individual >>>>> values of multi-valued attributes: >>>>> >>>>> a. >>>>> >>>>> I'm not belittling the effort involved in migrating legacy data store= s >>>>> to such a model. However, in the larger historical context of cross-d= omain >>>>> identity management, we are really at the very early stages. If a >>>>> relatively new discipline and a brand new spec are held captive to le= gacy >>>>> considerations, we are losing an opportunity to provide a clean and e= legant >>>>> model to subsequent users of the spec, and this will have repercussio= ns >>>>> over many years or even decades. >>>>> >>>>> b. >>>>> >>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>> dictionary model for existing multi-valued attributes, they can trans= ition >>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-c= ompliant=94 >>>>> APIs to their customers and encouraging new customers to adopt the >>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gradu= ally >>>>> migrated to the SCIM-compliant API. The logistics are not insurmounta= ble, >>>>> and shouldn't prevent the adoption of a dictionary model for multi-va= lued >>>>> attributes. >>>>> >>>>> Elaboration of Point 1: >>>>> >>>>> When we consider federated identity across more than one domain, we >>>>> have to assume that domains are not necessarily master-slave in their >>>>> interaction. The most generic interaction model is peer-to-peer, wher= e >>>>> entity lifecycle events within a domain are notified to other domains= (when >>>>> necessary) in an asynchronous manner (i.e., through messaging) and th= e >>>>> other domains are free to respond to these events in an appropriate m= anner >>>>> and at a time of their convenience. >>>>> >>>>> A key set of lifecycle events for an entity is the merging and >>>>> splitting of identity that is often required. >>>>> >>>>> The question =93Is this one entity?=94 can be answered either yes >>>>> (positive) or no (negative). But sometimes, we can discover false pos= itives >>>>> and false negatives in our data stores. >>>>> >>>>> Consider a case where customers sign up online, and two customers who >>>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and al= so use the >>>>> same date of birth (say, 1 Jan 1970) or similar attributes. The front= -end >>>>> application may make an intelligent (but incorrect) guess that these = two >>>>> persons are the same, and re-assign the same identifier to the second >>>>> person. This is a false positive. They appear to be the same entity, = but >>>>> they're actually different. When the error is discovered, the identit= ies >>>>> will need to be split, with a new identifier generated for one of the= m. >>>>> >>>>> Consider the opposite case where a customer signs up through two >>>>> different portals or in two different sessions, using the names =93JS= mith=94 >>>>> and =93JohnS=94. It is very likely that they will be treated as two d= ifferent >>>>> customers and assigned two unique identifiers. This is a false negati= ve. >>>>> They appear to be two entities, but are actually the same. At a later >>>>> stage, when the error is discovered, the identities will have to be m= erged, >>>>> and one of the identifiers will have to be dropped. >>>>> >>>>> These are not theoretical use cases. They form a significant >>>>> proportion of the user base in most large Web-facing applications. Le= t's >>>>> see how these can be managed in a federated way by mapping internal >>>>> identifiers to external ones and only exposing external identifiers t= o >>>>> other domains. >>>>> >>>>> a. False positives: >>>>> >>>>> Domain 1 has the following information about a customer in its data >>>>> store: >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> When requesting the provisioning of this entity in Domain 2, the >>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifier: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> When the false positive is discovered and the entity is split, Domain >>>>> 1 creates a new internal identifier and now has the following entity >>>>> information. >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> Internal ID: a99a5feba839 >>>>> >>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> This second entity with its own internal identifier is invisible to >>>>> Domain 2, and this is by design. Communication about the original ent= ity >>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a= 0=94 and >>>>> vice-versa. At some convenient time (importantly, this doesn't have t= o be >>>>> at the time the split happens), Domain 2 can be requested to provisio= n a >>>>> second entity, and when it responds with an identifier of =937a87f27c= 1dd8=94, >>>>> this can go into the mapping table as a new record associated with th= e >>>>> second entity's internal identifier. >>>>> >>>>> The mapping table now contains the following entries: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>> >>>>> Domain 2 is not even aware that a split has happened, and the >>>>> provisioning that it does is not in lockstep with the split in identi= ty >>>>> that occurred in Domain 1. >>>>> >>>>> (What is the =93Primary flag=94 used for? We'll see when we cover the >>>>> treatment of false negatives.) >>>>> >>>>> b. False negatives: >>>>> >>>>> Domain 1 has the following information about what it thinks are two >>>>> distinct customers in its data store: >>>>> >>>>> Internal ID: 9caf78aac3d6 >>>>> >>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>> >>>>> Internal ID: 273d36e30d09 >>>>> >>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>> >>>>> When requesting the provisioning of these entities in Domain 2, the >>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b= . >>>>> >>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>> for translation when talking to Domain 2, taking care never to expose= its >>>>> internal identifiers: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>> >>>>> When the false negative is discovered and the two entities are merged= , >>>>> Domain 1 drops one of the internal identifiers and rationalises the n= ame of >>>>> the customer (say, to =93John Smith=94). Let's say it retains the fir= st ID >>>>> =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>> >>>>> The mapping table now looks like this: >>>>> >>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>> Primary flag | >>>>> >>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>> >>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>> >>>>> Now two external identifiers map to the same internal one, so inbound >>>>> communication from Domain 2 can be unambi >>>>> >>>> _______________________________________________ >>> >>> 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 >> >> >> > --0015175dd5c892672e04c708ae63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 Multi-valued attributes that don't have a value sub-attri= bute (eg - address) have to specified completely for uniqueness.=A0= =A0

That's exactly the point. How do we "specify comple= tely for uniqueness"?

In the example below, h= ow are you proposing that the following element be updated if we can't = use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
=A0= ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 &= quot;type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 = =A0 =A0 "street-name" : "High Road",
=A0 =A0 = =A0 "suburb" : "East Camden",
=A0 =A0 =A0 &qu= ot;postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 = "country" : "Australia"
=A0 =A0 },
= =A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0= =A0 "postcode" : "5000",
=A0 =A0 =A0 "s= tate" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 = =A0 }
=A0 ]
}

It's impract= ical to use the value because it's the whole dictionary element:
<= div>
{
=A0 "type" : "office",
=A0 "street-number" : "213",
=A0 "= street-name" : "Main Street",
=A0 "suburb&quo= t; : "Adelaide",
=A0 "postcode" : "5000",
=A0 "state= " : "SA",
=A0 "country" : "Australi= a"
}

With my proposal, the &q= uot;addresses" array gets converted to a dictionary, and then we have = a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243= "

{
=
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f= 5" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
= =A0 =A0 =A0 "street-name" : "High Road",
=A0 = =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0= =A0 "state" : "SA",
=A0 =A0 =A0 "countr= y" : "Australia"
=A0 =A0 },
=A0 =A0 &quo= t;3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",=
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0= =A0 "state" : "SA",
=A0 =A0 =A0 "countr= y" : "Australia"
=A0 =A0 }
=A0 }
}

If you're proposing one mechanism for composite attributes and ano= ther mechanism for simple attributes, I would suggest that's actually m= ore complex than adopting a single mechanism that works the same way for _a= ll_ attributes. Remember that a lot of the administration is probably going= to be scripted rather than done by hand, and having two mechanisms (depend= ing on whether the attribute is simple or composite) will complicate every = script that has to be written.

There's a lot of talk about the "burden&= quot; on the SPs, but I believe this is overblown. Is there any SP represen= tative in this WG who can tell us what this proposal will actually entail f= or them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued att= ributes that have a value sub-attribute can be removed by specifying only t= he value since it is unique. =A0Multi-valued attributes that don't have= a value sub-attribute (eg - address) have to specified completely for uniqueness. =A0As I have said before, I a= m very opposed to adding a unique identifier to each element in a multi-val= ued collection due to the burden it will put on SPs. =A0Is it elegant? =A0N= o. =A0Is it functional? =A0Yes. =A0Will this non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element. =A0The verbs that you propose make sense= . =A0There is also a JSON Patch informational draft in the IETF that is int= eresting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-j= son-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= /div>

I'm curious if anyone else in the WG is in favor of unique i= dentifiers for every multi-valued element.

--Kelly
From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh and Sashi P= rasad [g.c.prasad= @gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique ke= y for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuiti= ve.=A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }


You gave other examples of an attribute with an identifier that matched= that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point = of the extra indexing to support this. Just use the value as the item you w= ish to delete.

I agree, the delete value operation could be more explicit and clear in= general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>=A0 For the multi-value example you gave you = used the value as the attribute name key.=A0

Now I'm confused :-). I don't believe any of my examples ever = used a value as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key.=A0

That means a lot more complex indexing structure. Better to just say d= elete a specific value.=A0

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.= =A0

I don't believe so.

I'm adopting a model where every attribute of the resource is a ke= y-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself.=A0

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there= be new keys for each individual value, otherwise they are impossible to di= stinguish, and a positional index is inadequate. So we convert the array in= to a dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't= exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like t= hese that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing.=A0

I agree though that operations in patch could be a lot more explicit.= =A0

Eg explicitly deleting a value by saying delete or retire.=A0

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the curr= ent spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current = spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive.= =A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LD= AP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course= , so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion w= orth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issu= es, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0
=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0






On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0





I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0








I'm suggesting that the spec do less, not more.<=
/p>



=A0






What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0








Am I making sense?










=A0








I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0








IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0








=A0








That said i think the current model provides a pract=
ical starting point.=A0














=A0








>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.








=A0








Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a
 great way to enable this solution.=A0 Part of the key here is that SCIM is=
 just a piece of the architecture for this solution, and is only responsibl=
e for the transport layer between domains.


=A0




You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how
 to model the end state of the false positive scenario (splitting a user):<=
/span>




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.




=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.




=A0




=A0




Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 with the following SCIM user:


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




=A0




Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand
 it puts extra burden on service providers.=A0 Since the inception of SCIM,=
 a key goal has been to foster adoption by service providers by making thin=
gs fit easily onto existing systems.=A0 IMO the value gained by unique iden=
tifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0




--Kelly


=A0








From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0




Hi Ganesh,


=A0




Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal
 mapping table ( you would have to map group membership as well).

=A0




This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0




This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0




You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.




=A0




--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com




Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0






De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0




Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=






b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.




Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.




Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.




(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_______________________________________________

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



--0015175dd5c892672e04c708ae63-- From kelly.grizzle@sailpoint.com Sat Aug 11 20:25:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5AA21F849A for ; Sat, 11 Aug 2012 20:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX3SHo+2o6FU for ; Sat, 11 Aug 2012 20:25:39 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 09A4A21F847B for ; Sat, 11 Aug 2012 20:25:37 -0700 (PDT) Received: from mail110-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Sun, 12 Aug 2012 03:25:37 +0000 Received: from mail110-db3 (localhost [127.0.0.1]) by mail110-db3-R.bigfish.com (Postfix) with ESMTP id 2450E4603B8; Sun, 12 Aug 2012 03:25:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -95 X-BigFish: PS-95(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85ehc430I1418Iac5W9d9Rzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail110-db3: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail110-db3 (localhost.localdomain [127.0.0.1]) by mail110-db3 (MessageSwitch) id 1344741931841785_20639; Sun, 12 Aug 2012 03:25:31 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.254]) by mail110-db3.bigfish.com (Postfix) with ESMTP id CA3C3100066; Sun, 12 Aug 2012 03:25:31 +0000 (UTC) Received: from BY2PRD0410HT002.namprd04.prod.outlook.com (157.56.236.85) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 12 Aug 2012 03:25:29 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT002.namprd04.prod.outlook.com ([10.255.83.37]) with mapi id 14.16.0175.005; Sun, 12 Aug 2012 03:25:27 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PrysoINrXz30exI2CcM9WIa5dT/IGAgABLt4CAAHBZgIAACouAgACi+YWAABY3AIAAAzFr Date: Sun, 12 Aug 2012 03:25:27 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373302585CBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 03:25:44 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373302585CBY2PRD0410MB354_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > how are you proposing that the following element be updated if we can't u= se positional indexes? My proposal is what is currently in the spec - http://tools.ietf.org/html/d= raft-scim-api-00#section-3.3.2. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub-Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. Another way to say this is "the whole dictionary element", which I don't be= lieve is impractical. I understand your proposal and the implications of u= sing uid for each element vs. not. It just comes down to a difference of o= pinion. --Kelly ________________________________ From: Ganesh and Sashi Prasad [g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 9:53 PM To: Kelly Grizzle Cc: Phil Hunt; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestion worth adop= ting in spite of the Cons, or are the Cons so great that it's best to leave= the spec as it is? Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, and t= here could be an exodus of clients to these new SPs. SCIM could end up bein= g obsoleted very soon, because the API interface is very complex and clumsy= , as any new reader can attest. I was taken aback by the complexity when I = saw it, which is why I was prompted to suggest something simpler. This is an issue where we need the opinions of many people, and they need t= o state their affiliations. If most people weighing in belong to incumbent = SPs and they vote in favour of interface complexity to avoid implementation= complexity, then it means the spec is not doing a good job of balancing th= e interests of various groups. I think we should also poll client organisat= ions to see what they would want. (Gartner is trusted by enterprise clients to evaluate the capabilities of v= endors (SPs). I believe Gartner should take the lead in representing client= interests in this working group rather than those of incumbent vendors, wh= ich is what it seems like to me. Correct me if I'm being unfair.) Regards, Ganesh On 11 August 2012 01:35, Diodati,Mark > wrote: Hi Ganesh, I am concerned about your second suggestion: =932. When dealing with multi-valued attributes of a resource (expressed as= arrays in JSON), they must be converted from an array into a dictionary wi= th unique keys (UUIDs generated by the cloud provider when the attribute is= created). Without unique keys for every attribute value of a resource, man= ipulating it will be clumsy and inelegant.=94 One of the primary reasons that SPML failed was lack of adoption by service= providers due to its complexity. Very few target applications implemented = SPML. Most of the commercial provisioning systems had an SPML interface (ei= ther v1 or v2), but not one of them was conformant to the SPML standard bec= ause of complexity. If you are interested, I will forward you the research = documents that discuss these problems in detail. For SCIM to be successful,= it must be adopted by commercial target applications (i.e., service provid= ers). I am confident that a requirement for unique identifiers with multi-v= alued attributes will preclude its adoption, because it requires major chan= ges to the service provider=92s existing identity storage mechanisms. Mark From: Trey Drake [mailto:trey.drake@unboundid.com] Sent: Friday, August 10, 2012 9:51 AM To: Ganesh and Sashi Prasad Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phi= l Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute = within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (Al= low generic search using 'GET /Users' and arbitrary URI parameters). Pleas= e clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence re= trieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > wrote: > I think scim gets its current simplicity from its single owner hub spoke= model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and= "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariab= ly, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-an= d-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the reso= urce body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, = including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, whic= h is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to = tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of= assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining thei= r own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol.= It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt > wrote: Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? I see what you are saying. I think scim gets its current simplicity from it= s single owner hub spoke model implementing tight coupling. IMHO loose coupling is a much more complex solution. The reality is that ea= ch end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub. That said i think the current model provides a practical starting point. > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can=92t ignore = legacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountName,= UPN) are subject to change (even objectGuid can change if an AD domain is = migrated), we decided to generate and maintain an internal table of ids. Th= is fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of =93hiding=94 internalIDs or use them as unique= ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when =93false negatives=94 and =93false posi= tives=94 are discovered. A domain should be able to handle this internal ho= usekeeping freely, only notifying other domains when convenient. Mapping of= internal identifiers to external ones and maintaining this mapping interna= lly allows this loosely-coupled housekeeping to take place. Sharing interna= l identifiers (or otherwise outsourcing the mapping of internal to external= identifiers) forces housekeeping activities to be done in lock-step across= domains. c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both =93SCIM-compliant=94 and =93non-SCIM-compliant=94 AP= Is to their customers and encouraging new customers to adopt the =93SCIM-co= mpliant=94 API. Legacy customers can be supported using a =93non-SCIM-compl= iant=94 API for an arbitrarily long period and gradually migrated to the SC= IM-compliant API. The logistics are not insurmountable, and shouldn't preve= nt the adoption of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question =93Is this one entity?=94 can be answered either yes (positive= ) or no (negative). But sometimes, we can discover false positives and fals= e negatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as =93John Smith=94, and also use the = same date of birth (say, 1 Jan 1970) or similar attributes. The front-end a= pplication may make an intelligent (but incorrect) guess that these two per= sons are the same, and re-assign the same identifier to the second person. = This is a false positive. They appear to be the same entity, but they're ac= tually different. When the error is discovered, the identities will need to= be split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names =93JSmith=94 and =93J= ohnS=94. It is very likely that they will be treated as two different custo= mers and assigned two unique identifiers. This is a false negative. They ap= pear to be two entities, but are actually the same. At a later stage, when = the error is discovered, the identities will have to be merged, and one of = the identifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} Internal ID: a99a5feba839 Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-v= ersa. At some convenient time (importantly, this doesn't have to be at the = time the split happens), Domain 2 can be requested to provision a second en= tity, and when it responds with an identifier of =937a87f27c1dd8=94, this c= an go into the mapping table as a new record associated with the second ent= ity's internal identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the =93Primary flag=94 used for? We'll see when we cover the treat= ment of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} Internal ID: 273d36e30d09 Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to =93John Smith=94). Let's say it retains the first ID =93= 9caf78aac3d6=94 and drops the second =93273d36e30d09=94. The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambi _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_56C3C758F9D6534CA3778EAA1E0C34373302585CBY2PRD0410MB354_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
> how are you proposing that the following elem= ent be updated if we can't use positional indexes?

My proposal is what is curre= ntly in the spec - http://tools.ietf.org/html/draft-scim-api-00#section-3.= 3.2.

      Attributes that do not have a=
 value Sub-Attribute or that have a
      non-unique value Sub-Attribut=
e are matched by comparing all
      Sub-Attribute values from the=
 PATCH request body to the Sub-Attribute
      values of the Resource.

Another way to say this is &= quot;the whole dictionary element", which I don't believe is impractic= al.  I understand your proposal and the implications of using uid for = each element vs. not.  It just comes down to a difference of opinion.

--Kelly

From: Ganesh and Sashi Prasad [g.c.prasa= d@gmail.com]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>  Multi-valued attributes that don't have a value sub-attribute (eg - address= ) have to specified completely for uniqueness.  

That's exactly the point. How do we "specify completely for uniqu= eness"?

In the example below, how are you proposing that the following element= be updated if we can't use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
  ...
  addresses: [
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",<= /div>
      "suburb" : "East Camden",
      "postcode" : "5346",
      "state" : "SA",
      "country" : "Australia"
    },
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street"= ,
      "suburb" : "Adelaide",
      "postcode" : "5000",
      "state" : "SA",
      "country" : "Australia"
    }
  ]
}

It's impractical to use the value because it's the whole dictionary el= ement:

{
  "type" : "office",
  "street-number" : "213",
  "street-name" : "Main Street",
  "suburb" : "Adelaide",
  "postcode" : "5000",
  "state" : "SA",
  "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243"

{
  ...
  addresses: {
    "d6ea365462f5" :
    {
      "type" : "home",
      "street-number" : "35",
      "street-name" : "High Road",<= /div>
      "suburb" : "East Camden",
      "postcode" : "5346",
      "state" : "SA",
      "country" : "Australia"
    },
    "3cbaaff8e84e" :
    {
      "type" : "office",
      "street-number" : "213",
      "street-name" : "Main Street"= ,
      "suburb" : "Adelaide",
      "postcode" : "5000",
      "state" : "SA",
      "country" : "Australia"
    }
  }
}

If you're proposing one mechanism for composite attributes and another= mechanism for simple attributes, I would suggest that's actually more comp= lex than adopting a single mechanism that works the same way for _all_ attr= ibutes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, = and having two mechanisms (depending on whether the attribute is simple or = composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but I b= elieve this is overblown. Is there any SP representative in this WG who can= tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0.  Multi-valued = attributes that have a value sub-attribute can be removed by specifying onl= y the value since it is unique.  Multi-valued attributes that don't ha= ve a value sub-attribute (eg - address) have to specified completely for uniqueness.  As I have said before, I am = very opposed to adding a unique identifier to each element in a multi-value= d collection due to the burden it will put on SPs.  Is it elegant? &nb= sp;No.  Is it functional?  Yes.  Will this non-elegance affect adoption?  My opinion is that adding unique keys to each eleme= nt will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element.  The verbs that you propose make se= nse.  There is also a JSON Patch informational draft in the IETF that = is interesting - http://tools.ietf.org/html/draft-ietf-= appsawg-json-patch-02.  It relies on a JSON Pointer draft which uses index-based addressing = for multi-valued attributes.  I think that this is something that shou= ld be looked at within the WG and I would be willing to lead this effort.

I'm curious if anyone else in the WG is in favor of unique ident= ifiers for every multi-valued element.

--Kelly
From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique key fo= r each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuitive.&= nbsp;
With my suggestion, here's how to delete a single member from a group:=

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-41386= 1904646"
}
}
] }


You gave other examples of an attribute with an identifier that match= ed that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point of= the extra indexing to support this. Just use the value as the item you wis= h to delete.

I agree, the delete value operation could be more explicit and clear = in general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>  For the multi-value example you gave y= ou used the value as the attribute name key. 

Now I'm confused :-). I don't believe any of my examples ever used a v= alue as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh 

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key. 

That means a lot more complex indexing structure. Better to just say d= elete a specific value. 

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value with an attribute i= d. 

I don't believe so.

I'm adopting a model where every attribute of the resource is a key-va= lue pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself. 

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to distin= guish, and a positional index is inadequate. So we convert the array into a= dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't exi= st, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like these= that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun= t)


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudi= way.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing. 

I agree though that operations in patch could be a lot more explicit.&= nbsp;

Eg explicitly deleting a value by saying delete or retire. 

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am concerned about your second sugge= stion: 

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the current = spec:

   PATCH /G=
roups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce=0A=
   Host: example.com=
=0A=
   Accept: application/json=0A=
   Authorization: Bearer h480djs93hd8=0A=
   ETag: W/"a330bc54f0671c9"=0A=
=0A=
   {=0A=
     "schemas": ["urn:scim:schemas:core:1.0"],=0A=
     "members": [=0A=
       {=0A=
         "display": "Babs Jensen",=0A=
         "value": "2819c223-7f76-453a-919d-413861904646"=
;=0A=
         "operation": "delete"=0A=
       }=0A=
     ]=0A=
   }=0A=

Here's how to delete ALL members from a group according to the current spec= :

   PATCH /G=
roups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce=0A=
   Host: example.com=
=0A=
   Accept: application/json=0A=
   Authorization: Bearer h480djs93hd8=0A=
   ETag: W/"a330bc54f0671c9"=0A=
=0A=
   {=0A=
     "schemas": ["urn:scim:schemas:core:1.0"],=0A=
     "meta": {=0A=
       "attributes": [=0A=
         "members"=0A=
       ]=0A=
     }=0A=
   }=0A=

The two operations differ significantly, and it's not very intuitive. =
With my suggestion, here's how to delete a single member from a group:=

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-41386= 1904646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LDAP d= irectories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course, so= I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec) ver= sus implementation complexity (my suggestion). Both can hinder adoption of = the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion worth= adopting in spite of the Cons, or are the Cons so great that it's best to = leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issues, = and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

 

I am concerned about yo= ur second suggestion:

=932. When dealing with= multi-valued attributes of a resource (expressed as arrays in JSON), they = must be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

 

One of the primary reas= ons that SPML failed was lack of adoption by service providers due to its c= omplexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

 
 
 

From: Trey D= rake [mailto:= trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Ganesh,

 

I'll base my comments on your latest reply (below). =  

 

The externalID is not part of the protocol.  It= is an *optional* attribute within the *schema* specification.  As for= #2, the protocol spec works as you describe if "arbitrary URI paramet= ers" equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters).  Please clar= ify your suggestion.

 

I'm not tracking your coupling concern.  The cl= ient can search and hence retrieve resources on any attribute it chooses, e= xternalId or otherwise.  Nothing mandates use of externalId.  &nb= sp;

 
 

What do you mean by "candidate key"?  = ;Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>  I think scim gets its current simplicity = from its single owner hub spoke model implementing tight coupling. [...]&nb= sp;IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying "tight= coupling =3D=3D simple" and "loose coupling =3D=3D complex"= . That's contrary to my experience.

 

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

 

Let's not confuse reduction of dependencies in the d= ata model with a hub-and-spokes architecture. They're entirely orthogonal a= spects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' and arbit= rary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
 
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
 
T=
hat's what I'd like to see. I don't believe this complicates the protocol. =
It simplifies it and it also lends itself to a loosely-coupled approach.
 
I=
'll address the multi-valued attribute suggestion separately.
 
R=
egards,
G=
anesh
 
 
 
 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w= rote:



Phil


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>  storing this information in a mapping table outside of the SCIM spec is a g= reat way to enable this solution.  Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not more.

 

What the SCIM spec needs to do there is just refrain= from introducing tight coupling. I would like to see a single identifier e= xposed through the API, with the implication (and perhaps the recommendatio= n) that it be the shared one. Allowing one domain to expose its internal identifier to the other creates tight co= upling and ensures that both domains need simultaneously split or merge ide= ntities, which is not desirable. So I recommend _taking out_ the "exte= rnal id" field from the API. The spec shouldn't encourage tight coupling. If clients want to pass in their inter= nal ids as part of the resource body, no one can stop them, and they can al= ways do a search on that attribute to retrieve the URI exactly as you visua= lise they will with the "external id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets its cur= rent simplicity from its single owner hub spoke model implementing tight co= upling. 

 

IMHO loose coupling is a much more complex solution.= The reality is that each end-point has value to contribute and thus the si= ngle-owner model will eventually need to become multi-owner or multi-hub.&n= bsp;

 

That said i think the current model provides a pract= ical starting point. 

 

>  Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved.  On one hand this makes PATCH semantics easier.  On = the other hand it puts extra burden on service providers. 


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Thanks Emmanuel.  = I had started writing up a similar response.  As you suggest, storing = this information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM= is just a piece of the architecture for this solution, and is only respons= ible for the transport layer between domains.

 

You could also model th= ese ID mappings in the SCIM user as an extension but would probably not wan= t to expose these externally.  Here is an example of how to model the end state of the false positive scenario (splitting a user):<= /span>

 

| Internal Entity ID | External Domain ID |= External Entity ID | Primary flag |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | ff487230b3a0    &nb= sp;  | true         |

| a99a5feba839     = ;  | D2          &nb= sp;      | 7a87f27c1dd8    &nb= sp;  | true         |

 

This could be represent= ed as two SCIM users that contain information about the entities on other d= omains.

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "9caf78aac3d6&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "a99a5feba839&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the= linkedUsers attribute would be empty until the split user was synced to do= main 2.

 
 

Similarly, the false ne= gative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID |= External Entity ID | Primary flag |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | ff487230b3a0    &nb= sp;  | true         |

| 9caf78aac3d6     = ;  | D2          &nb= sp;      | 41206cc97c8b    &nb= sp;  | false        |

 

This could be represent= ed with the following SCIM user:

 

{

  "schemas": ["urn:scim= :schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&qu= ot;],

  "id": "9caf78aac3d6&q= uot;,

  "userName": "John Smi= th",

  "urn:scim:schemas:extension:fed= eration:1.0": {

    "linkedUsers":= [

      {

        = "domain": "D2",

        = "externalEntityId": "ff487230b3a0"

      },

      {

        = "domain": "D2",

        = "externalEntityId": "41206cc97c8b",

        = "deletionRequired": true

      }

    ]

  }

}

 
 

Regarding unique identi= fiers for multi-valued attributes there is a trade-off involved.  On o= ne hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SC= IM, a key goal has been to foster adoption by service providers by making t= hings fit easily onto existing systems.  IMO the value gained by uniqu= e identifiers for multi-valued attributes is not worth the demands put on a service provider.  I also think tha= t vendors that have a non-SCIM-compliant API will choose to keep things tha= t way if the spec is too hard for them to implement.  In a green field= environment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=92t= ignore legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,<= /span>

 

Nothing prevents you in= your SCIM implementation (client or server) to generate a unique identifie= r for each synchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 

This is what we are doi= ng with Active Directory sources or targets:

As we didn=92t find an = immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to ch= ange (even objectGuid can change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits yo= ur requirements as it hides internal ids.

 

This was written in dot= net and we have started a project to rewrite our SCIM stack in PHP and will= give it to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the choi= ce of =93hiding=94 internalIDs or use them as unique ID.

 

You can also implement = such feature without violating the SCIM specs, or without asking to include= it in the specs.

 

--

Regards,

Emmanuel Dr= eux

http://www.cloudiway.com

Tel: +33 4 2= 6 78 17 58

Mobile: +33 6 4= 7 81 26 70

skype: Emma= nuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi = Kelly,

Tha= nks for your response. Let me first respond in brief to the two main points= you have made, and then elaborate on the first.

1.&nbs= p;     Why should domains not = expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of dom= ains, where all domains are co-equal peers. (In physics too, N-body problem= s are much harder than 2-body problems. :-) Therefore, assuming that there = are only two players in the interaction makes this tightly coupled in a number of ways. We should rely on messagin= g and notification, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the o= ngoing need to merge and split identities as and when =93false negatives=94= and =93false positives=94 are discovered. A domain should be able to handl= e this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers t= o external ones and maintaining this mapping internally allows this loosely= -coupled housekeeping to take place. Sharing internal identifiers (or other= wise outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be don= e in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitab= le wire protocol which can be designed later. The data model plays a crucia= l role in enabling or constraining such interaction. A tightly-coupled data= model will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of th= is tight coupling.

2. The difficulty of assigning unique identifiers to the = individual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legac= y data stores to such a model. However, in the larger historical context of= cross-domain identity management, we are really at the very early stages. = If a relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing = an opportunity to provide a clean and elegant model to subsequent users of = the spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately = adopt the dictionary model for existing multi-valued attributes, they can t= ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 APIs to their customers and encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu= stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Ela= boration of Point 1:

Whe= n we consider federated identity across more than one domain, we have to as= sume that domains are not necessarily master-slave in their interaction. Th= e most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are notified t= o other domains (when necessary) in an asynchronous manner (i.e., through m= essaging) and the other domains are free to respond to these events in an a= ppropriate manner and at a time of their convenience.

A k= ey set of lifecycle events for an entity is the merging and splitting of id= entity that is often required.

The= question =93Is this one entity?=94 can be answered either yes (positive) o= r no (negative). But sometimes, we can discover false positives and false n= egatives in our data stores.

Con= sider a case where customers sign up online, and two customers who are priv= acy-conscious enter fake IDs such as =93John Smith=94, and also use the sam= e date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorre= ct) guess that these two persons are the same, and re-assign the same ident= ifier to the second person. This is a false positive. They appear to be the= same entity, but they're actually different. When the error is discovered, the identities will need to be sp= lit, with a new identifier generated for one of them.

Con= sider the opposite case where a customer signs up through two different por= tals or in two different sessions, using the names =93JSmith=94 and =93John= S=94. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a = false negative. They appear to be two entities, but are actually the same. = At a later stage, when the error is discovered, the identities will have to= be merged, and one of the identifiers will have to be dropped.

The= se are not theoretical use cases. They form a significant proportion of the= user base in most large Web-facing applications. Let's see how these can b= e managed in a federated way by mapping internal identifiers to external ones and only exposing external identifie= rs to other domains.

a. = False positives:

Dom= ain 1 has the following information about a customer in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Whe= n requesting the provisioning of this entity in Domain 2, the following ID = is returned by Domain 2: ff487230b3a0.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifier:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

Whe= n the false positive is discovered and the entity is split, Domain 1 create= s a new internal identifier and now has the following entity information.

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Int= ernal ID: a99a5feba839

Att= ributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}

Thi= s second entity with its own internal identifier is invisible to Domain 2, = and this is by design. Communication about the original entity takes place = as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly= , this doesn't have to be at the time the split happens), Domain 2 can be r= equested to provision a second entity, and when it responds with an identif= ier of =937a87f27c1dd8=94, this can go into the mapping table as a new record associated with the second entity's inte= rnal identifier.

The= mapping table now contains the following entries:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| a99a5feba839 = | D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happene= d, and the provisioning that it does is not in lockstep with the split in i= dentity that occurred in Domain 1.

(Wh= at is the =93Primary flag=94 used for? We'll see when we cover the treatmen= t of false negatives.)

b. = False negatives:

Dom= ain 1 has the following information about what it thinks are two distinct c= ustomers in its data store:

Int= ernal ID: 9caf78aac3d6

Att= ributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Int= ernal ID: 273d36e30d09

Att= ributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

Whe= n requesting the provisioning of these entities in Domain 2, the following = IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.

Dom= ain 1 then maintains the following in a mapping table and uses it for trans= lation when talking to Domain 2, taking care never to expose its internal i= dentifiers:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 273d36e30d09 = | D2 | 41206cc97c8b | true |

Whe= n the false negative is discovered and the two entities are merged, Domain = 1 drops one of the internal identifiers and rationalises the name of the cu= stomer (say, to =93John Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and drops the second =93273= d36e30d09=94.

The= mapping table now looks like this:

| Internal Enti= ty ID | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 = | D2 | ff487230b3a0 | true |

| 9caf78aac3d6 = | D2 | 41206cc97c8b | false |

Now= two external identifiers map to the same internal one, so inbound communic= ation from Domain 2 can be unambi

_______________________________________________

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



--_000_56C3C758F9D6534CA3778EAA1E0C34373302585CBY2PRD0410MB354_-- From g.c.prasad@gmail.com Sat Aug 11 21:29:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E1211E80AD for ; Sat, 11 Aug 2012 21:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuxpOtYjYKS3 for ; Sat, 11 Aug 2012 21:29:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A25D11E809B for ; Sat, 11 Aug 2012 21:29:01 -0700 (PDT) Received: by bkty7 with SMTP id y7so1181371bkt.31 for ; Sat, 11 Aug 2012 21:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VfgOUN5usGyOYCweL3uZQlnbSaLZjhJAU2XyrEHJlWQ=; b=eW2LqcvH2MzXw3mTGDc4iVhOMgwYACUJtRuFu4xZAgBznVxh8FPPlW3mU2+tzVjzio shZCYmDjliojCizRQribqWyyjgAqcHggGnMiu/bErev870T26Oq99GSfJ1T528ElAi8R lKjBZsRY15YX/Xp0QbBJKKf58GSNaIPyjBF25X1UyL2kPZgzFiCaKY5u6vOTSYb3sKT9 Cn6hPGhtlQt+C5F+S9z9Owgr42v86LyjSU5cTnmUqKfNCYKQoeAZoza/84ShXMGmHf7s QSwegNW7HhfT3K++xryU0Jx1AmdixhZ3WuJtZXcP/c+neouFf0t4rDhKl4u87hzoQj/v 8Y1g== Received: by 10.204.133.194 with SMTP id g2mr2763097bkt.13.1344745740250; Sat, 11 Aug 2012 21:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 21:28:39 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 14:28:39 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=00151759308429300b04c70a042f Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 04:29:07 -0000 --00151759308429300b04c70a042f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > It just comes down to a difference of opinion. Yes, but do consider that the unique key approach allows uniformity of treatment regardless of level in the hierarchy for _all_ operations - add, modify and delete, with "modify" having three sub-elements of its own (add attribute, modify attribute, delete attribute). INCLUDE and RETIRE (add a new dictionary element to this collection, or remove the entire collection): key =3D "addresses" REPLACE, FORCE and RETIRE (update or remove one complete dictionary element in the collection): key =3D "addresses.3cbaaff8e84e" PLACE and FORCE (introduce a new dictionary element with a pre-assigned unique key - not the client's internal key, of course): key =3D "addresses.7956063c59a1" REPLACE, FORCE and RETIRE (update of the dictionary element, updating or removing an _existing_ sub-element): key =3D "addresses.3cbaaff8e84e.street-number" key =3D "addresses.3cbaaff8e84e.street-name" ... key =3D "addresses.3cbaaff8e84e.country" PLACE and FORCE (update of the dictionary element, introducing a _new_ sub-element): key =3D "addresses.3cbaaff8e84e.city" INCLUDE (update of the dictionary element, introducing one or more _new_ values for a multi-valued sub-element): key =3D "addresses.3cbaaff8e84e.available-services" value =3D ["cable", "ADSL"] (This in turn returns keys for the two new dictionary elements that it creates.) There's just one standard syntax for all of these operations. There's a bit of an initial conceptual hurdle for a reader of the spec to grok this approach and also a one-time implementation hurdle for the SPs, but thereafter it's simple and elegant. Once again I'd like to ask, is there any SP representative on this working group who can tell us exactly what it would entail for them to implement a unique-key-per-value scheme? I want to understand how much of a burden this really is, because I reckon this would knock a few pages off the spec document (which is another index of simplicity). Regards, Ganesh On 12 August 2012 13:25, Kelly Grizzle wrote: > > how are you proposing that the following element be updated if we > can't use positional indexes? > > My proposal is what is currently in the spec - > http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2. > > Attributes that do not have a value Sub-Attribute or that have a > > non-unique value Sub-Attribute are matched by comparing all > > Sub-Attribute values from the PATCH request body to the Sub-Attribu= te > > values of the Resource. > > > Another way to say this is "the whole dictionary element", which I don't > believe is impractical. I understand your proposal and the implications = of > using uid for each element vs. not. It just comes down to a difference o= f > opinion. > > --Kelly > > ------------------------------ > *From:* Ganesh and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 9:53 PM > *To:* Kelly Grizzle > *Cc:* Phil Hunt; scim@ietf.org > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 > > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. > > That's exactly the point. How do we "specify completely for uniqueness"? > > In the example below, how are you proposing that the following element > be updated if we can't use positional indexes? > > addresses[1].street-number =3D "243" > > User object: > > { > ... > addresses: [ > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > ] > } > > It's impractical to use the value because it's the whole dictionary > element: > > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element: > > addresses.3cbaaff8e84e.street-number =3D "243" > > { > ... > addresses: { > "d6ea365462f5" : > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > "3cbaaff8e84e" : > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > } > } > > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written. > > There's a lot of talk about the "burden" on the SPs, but I believe this > is overblown. Is there any SP representative in this WG who can tell us > what this proposal will actually entail for them? > > Regards, > Ganesh > > On 12 August 2012 11:53, Kelly Grizzle wrote= : > >> Ganesh, >> >> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >> that have a value sub-attribute can be removed by specifying only the va= lue >> since it is unique. Multi-valued attributes that don't have a value >> sub-attribute (eg - address) have to specified completely for uniqueness= . >> As I have said before, I am very opposed to adding a unique identifier = to >> each element in a multi-valued collection due to the burden it will put = on >> SPs. Is it elegant? No. Is it functional? Yes. Will this non-elegan= ce >> affect adoption? My opinion is that adding unique keys to each element >> will have a much more detrimental effect on adoption. >> >> I do believe that in general PATCH can be made more intuitive without >> adding uids to each element. The verbs that you propose make sense. Th= ere >> is also a JSON Patch informational draft in the IETF that is interesting= - >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >> on a JSON Pointer draft which uses index-based addressing for multi-valu= ed >> attributes. I think that this is something that should be looked at wit= hin >> the WG and I would be willing to lead this effort. >> >> I'm curious if anyone else in the WG is in favor of unique identifiers >> for every multi-valued element. >> >> --Kelly >> >> ------------------------------ >> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >> *Sent:* Saturday, August 11, 2012 10:50 AM >> *To:* Phil Hunt >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >> >> Phil, >> >> The reason we cannot use the value itself to identify an element is >> that this method will only work for simple elements, not for nested >> structures. i.e., if we had an array of dictionaries (e.g., we had to >> record an array of addresses for each customer, with each address elemen= t >> having sub-elements like street number, street name, suburb, etc.), then= it >> would be clumsy to supply the entire value of the array element because >> it's itself a dictionary. Creating a unique key for each element scales >> better. >> >> Regards, >> Ganesh >> >> On 12 August 2012 01:12, Phil Hunt wrote: >> >>> Ganesh, >>> >>> Here's the sample that concerned me... >>> >>> The two operations differ significantly, and it's not very intuitive. >>> With my suggestion, here's how to delete a single member from a group: >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAc= cept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" { >>> "operations" : [ >>> { >>> "RETIRE" : { >>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>> } >>> } >>> ] } >>> >>> >>> >>> You gave other examples of an attribute with an identifier that >>> matched that value or of identifiers that were additional unique keys. >>> >>> Given that multi-values must be each unique, I don't see the point of >>> the extra indexing to support this. Just use the value as the item you = wish >>> to delete. >>> >>> I agree, the delete value operation could be more explicit and clear >>> in general. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >>> >>> > For the multi-value example you gave you used the value as the >>> attribute name key. >>> >>> Now I'm confused :-). I don't believe any of my examples ever used a >>> value as the key. >>> >>> Could you please show me which example you mean, and which parts of it >>> you believe to be the value? >>> >>> Regards, >>> Ganesh >>> >>> On 11 August 2012 13:59, Phil Hunt wrote: >>> >>>> >>>> For the multi-value example you gave you used the value as the >>>> attribute name key. >>>> >>>> That means a lot more complex indexing structure. Better to just say >>>> delete a specific value. >>>> >>>> The spec already allows multiple values to have tags like home, work, >>>> etc. >>>> >>>> Phil >>>> >>>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >>>> wrote: >>>> >>>> > In your example you are conflating value with an attribute id. >>>> >>>> I don't believe so. >>>> >>>> I'm adopting a model where every attribute of the resource is a >>>> key-value pair. The key is a name or ID. >>>> >>>> For non-repeating attributes (both simple and composite), the key is >>>> the attribute name itself. >>>> >>>> Simple attribute: >>>> >>>> Key: "dob" >>>> Value: "01 Jan 1970" >>>> >>>> For composite attributes, the key employs dot notation to specify the >>>> fully-qualified attribute name, e.g., "address.postcode". >>>> >>>> Composite attribute: >>>> >>>> Key: "address.street-number" >>>> Value: "10" >>>> >>>> Key: "address.suburb" >>>> Value: "East Camden" >>>> >>>> For repeating (multi-valued) attributes, I'm suggesting that there be >>>> new keys for each individual value, otherwise they are impossible to >>>> distinguish, and a positional index is inadequate. So we convert the a= rray >>>> into a dictionary and this then becomes a composite attribute using do= t >>>> notation for the key. >>>> >>>> Multi-valued attribute: >>>> >>>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>>> Value: "john_smith@yahoo.com" >>>> >>>> So this allows us to apply uniform treatment to any arbitrarily deep >>>> resource structure. We can refer to every leaf value with a key that i= s the >>>> fully-qualified name using dot notation. >>>> >>>> The verbs are just unambiguous operations on these (now) explicitly >>>> addressable attributes. >>>> >>>> INCLUDE to a collection and specify only the value. The key is >>>> generated and returned. The fully-qualified key is >>>> . and the value is what was speci= fied >>>> in the INCLUDE. >>>> >>>> REPLACE a fully-qualified key with a new value. If the key doesn't >>>> exist, return a "404 Not Found". >>>> >>>> PLACE a value at the logical location implied by the fully-qualified >>>> key. If there is already a key with that name, return a "409 Conflict"= . >>>> >>>> FORCE the fully-qualified key to hold the given value, regardless of >>>> whether it existed before or not. Only errors possible are "400 Bad >>>> Request" and "500 Internal Error". >>>> >>>> RETIRE an attribute or a collection given its fully-qualified key. >>>> The implementation will determine whether the attribute will disappear >>>> entirely or will exist holding a null value (the blank string "" or th= e >>>> empty object {} ). >>>> >>>> I'll explain in a separate post why we need operation verbs like >>>> these that are independent of the HTTP verbs. >>>> >>>> Regards, >>>> Ganesh >>>> >>>> On 11 August 2012 10:38, wrote: >>>> >>>>> If you have received this digest without all the individual message >>>>> attachments you will need to update your digest options in your list >>>>> subscription. To do so, go to >>>>> >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>> >>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>> globally for all the list digests you receive at this point. >>>>> >>>>> >>>>> >>>>> Send scim mailing list submissions to >>>>> scim@ietf.org >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://www.ietf.org/mailman/listinfo/scim >>>>> or, via email, send a message with subject or body 'help' to >>>>> scim-request@ietf.org >>>>> >>>>> You can reach the person managing the list at >>>>> scim-owner@ietf.org >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of scim digest..." >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Phil Hunt >>>>> To: Ganesh and Sashi Prasad >>>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>>> edreux@cloudiway.com>, Trey Drake , Kelly >>>>> Grizzle , "scim@ietf.org" >>>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>> Ganesh, >>>>> >>>>> In your example you are conflating value with an attribute id. I >>>>> find that confusing. >>>>> >>>>> I agree though that operations in patch could be a lot more >>>>> explicit. >>>>> >>>>> Eg explicitly deleting a value by saying delete or retire. >>>>> >>>>> Phil >>>>> >>>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >>>>> wrote: >>>>> >>>>> > I am concerned about your second suggestion: >>>>> >>>>> Let's discuss that now. >>>>> >>>>> The trade-offs are very clear here. >>>>> >>>>> Pros: >>>>> >>>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>>> consistent and intuitive when every individual attribute value gets i= ts own >>>>> ID. >>>>> >>>>> Here's how to delete a single member from a Group, as per the >>>>> current spec: >>>>> >>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>> Host: example.com >>>>> Accept: application/json >>>>> Authorization: Bearer h480djs93hd8 >>>>> ETag: W/"a330bc54f0671c9" >>>>> >>>>> { >>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>> "members": [ >>>>> { >>>>> "display": "Babs Jensen", >>>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>>> "operation": "delete" >>>>> } >>>>> ] >>>>> } >>>>> >>>>> >>>>> Here's how to delete ALL members from a group according to the curren= t >>>>> spec: >>>>> >>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>> Host: example.com >>>>> Accept: application/json >>>>> Authorization: Bearer h480djs93hd8 >>>>> ETag: W/"a330bc54f0671c9" >>>>> >>>>> { >>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>> "meta": { >>>>> "attributes": [ >>>>> "members" >>>>> ] >>>>> } >>>>> } >>>>> >>>>> >>>>> The two operations differ significantly, and it's not very intuitive. >>>>> With my suggestion, here's how to delete a single member from a group= : >>>>> >>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>> W/"a330bc54f0671c9" { >>>>> "operations" : [ >>>>> { >>>>> "RETIRE" : { >>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>> } >>>>> } >>>>> ] } >>>>> Here's how I suggest deleting ALL members from a group: >>>>> >>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>> W/"a330bc54f0671c9" { >>>>> "operations" : [ >>>>> { >>>>> "RETIRE" : { >>>>> "key" : "members" >>>>> } >>>>> } >>>>> ] } >>>>> >>>>> I'm sure you'll agree that this is simpler, more consistent and more >>>>> intuitive to a reader. >>>>> >>>>> Pro 2: We can apply this mechanism consistently to three areas: >>>>> (a) Manipulating multi-valued attributes of a resource >>>>> (b) Manipulating members of a group >>>>> (c) Performing bulk operations, where we simply use HTTP verbs instea= d >>>>> of the specialised (and semantically less ambiguous) verbs I suggeste= d for >>>>> attributes, the "key" becomes the URI, and the "value" becomes the >>>>> corresponding JSON object. >>>>> >>>>> All of them return "207 Multi-Status" with the "results" array >>>>> holding individual status codes. >>>>> >>>>> In the current spec, (a) and (b) are done similarly but (c) is very >>>>> different. >>>>> >>>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>>> because it's simpler for them. >>>>> >>>>> Pro 4: New (not incumbent) cloud providers will probably find this >>>>> easier to implement because they have no legacy. They will probably u= se >>>>> some form of NoSQL database and won't be constrained by the limitatio= ns of >>>>> LDAP directories. >>>>> >>>>> Cons: >>>>> >>>>> Con 1: Incumbent cloud providers with existing data stores in a >>>>> directory format (where multi-valued attributes are stored as >>>>> comma-separated values under a single attribute node) will find it >>>>> difficult to migrate to this model and store each attribute value as = a >>>>> sub-node with its own key. This will "hinder adoption of the spec", w= hich >>>>> is what you fear. >>>>> >>>>> Have I summed up the Pros and Cons correctly? I'm biased of course, >>>>> so I could have missed a Con or hyped a Pro :-). >>>>> >>>>> In other words, we're debating interface complexity (current spec) >>>>> versus implementation complexity (my suggestion). Both can hinder ado= ption >>>>> of the spec by different parties. >>>>> >>>>> Here's what we need to discuss - Do the Pros make the suggestion >>>>> worth adopting in spite of the Cons, or are the Cons so great that it= 's >>>>> best to leave the spec as it is? >>>>> >>>>> Keep in mind that a complex spec that only favours incumbent cloud >>>>> providers can cut both ways. It opens the door to a simpler interface >>>>> offered by a new generation of nimbler SPs that don't have the same l= egacy >>>>> issues, and there could be an exodus of clients to these new SPs. SCI= M >>>>> could end up being obsoleted very soon, because the API interface is = very >>>>> complex and clumsy, as any new reader can attest. I was taken aback b= y the >>>>> complexity when I saw it, which is why I was prompted to suggest some= thing >>>>> simpler. >>>>> >>>>> This is an issue where we need the opinions of many people, and they >>>>> need to state their affiliations. If most people weighing in belong t= o >>>>> incumbent SPs and they vote in favour of interface complexity to avoi= d >>>>> implementation complexity, then it means the spec is not doing a good= job >>>>> of balancing the interests of various groups. I think we should also = poll >>>>> client organisations to see what they would want. >>>>> >>>>> (Gartner is trusted by enterprise clients to evaluate the >>>>> capabilities of vendors (SPs). I believe Gartner should take the lead= in >>>>> representing client interests in this working group rather than those= of >>>>> incumbent vendors, which is what it seems like to me. Correct me if I= 'm >>>>> being unfair.) >>>>> >>>>> Regards, >>>>> Ganesh >>>>> >>>>> >>>>> >>>>> On 11 August 2012 01:35, Diodati,Mark wrote= : >>>>> >>>>>> Hi Ganesh, >>>>>> >>>>>> >>>>>> I am concerned about your second suggestion: >>>>>> >>>>>> =932. When dealing with multi-valued attributes of a resource >>>>>> (expressed as arrays in JSON), they must be converted from an array = into a >>>>>> dictionary with unique keys (UUIDs generated by the cloud provider w= hen the >>>>>> attribute is created). Without unique keys for every attribute value= of a >>>>>> resource, manipulating it will be clumsy and inelegant.=94 >>>>>> >>>>>> >>>>>> One of the primary reasons that SPML failed was lack of adoption by >>>>>> service providers due to its complexity. Very few target application= s >>>>>> implemented SPML. Most of the commercial provisioning systems had an= SPML >>>>>> interface (either v1 or v2), but not one of them was conformant to t= he SPML >>>>>> standard because of complexity. If you are interested, I will forwar= d you >>>>>> the research documents that discuss these problems in detail. For SC= IM to >>>>>> be successful, it must be adopted by commercial target applications = (i.e., >>>>>> service providers). I am confident that a requirement for unique >>>>>> identifiers with multi-valued attributes will preclude its adoption, >>>>>> because it requires major changes to the service provider=92s existi= ng >>>>>> identity storage mechanisms. >>>>>> >>>>>> Mark >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>>> >>>>>> *To:* Ganesh and Sashi Prasad >>>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>>> >>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>> >>>>>> >>>>>> >>>>>> Ganesh, >>>>>> >>>>>> >>>>>> I'll base my comments on your latest reply (below). >>>>>> >>>>>> >>>>>> The externalID is not part of the protocol. It is an *optional* >>>>>> attribute within the *schema* specification. As for #2, the protoco= l spec >>>>>> works as you describe if "arbitrary URI parameters" equate to resour= ce >>>>>> attributes (Allow generic search using 'GET /Users' and arbitrary UR= I >>>>>> parameters). Please clarify your suggestion. >>>>>> >>>>>> >>>>>> I'm not tracking your coupling concern. The client can search and >>>>>> hence retrieve resources on any attribute it chooses, externalId or >>>>>> otherwise. Nothing mandates use of externalId. >>>>>> >>>>>> >>>>>> >>>>>> What do you mean by "candidate key"? Given >>>>>> >>>>>> >>>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>>> g.c.prasad@gmail.com> wrote: >>>>>> >>>>>> > I think scim gets its current simplicity from its single owner hu= b >>>>>> spoke model implementing tight coupling. [...] IMHO loose coupling i= s a >>>>>> much more complex solution. >>>>>> >>>>>> >>>>>> Phil, >>>>>> >>>>>> >>>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D simp= le" >>>>>> and "loose coupling =3D=3D complex". That's contrary to my experienc= e. >>>>>> >>>>>> >>>>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>>>> Invariably, a reduction in dependencies leads to greater simplicity. >>>>>> >>>>>> >>>>>> Let's not confuse reduction of dependencies in the data model with a >>>>>> hub-and-spokes architecture. They're entirely orthogonal aspects of = the >>>>>> solution. >>>>>> >>>>>> >>>>>> All that my suggestion involves is, >>>>>> >>>>>> >>>>>> 1. Take 'external ID' out of the protocol. >>>>>> >>>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI >>>>>> parameters >>>>>> >>>>>> >>>>>> No planned functionality is lost by this. >>>>>> >>>>>> >>>>>> 1. The client enterprise can still send its internal ID as part of >>>>>> the resource body, inside some attribute defined by them (but not de= fined >>>>>> by the protocol). Let's say they call it 'myID'. >>>>>> >>>>>> 2. The client enterprise can search for resource URIs using any >>>>>> attribute, including this internal ID >>>>>> >>>>>> 'GET /Users?myID=3Dbjensen' >>>>>> >>>>>> Since myID is a candidate key, the server will return exactly one >>>>>> URI, which is the canonical URI for the resource >>>>>> >>>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>>> >>>>>> 3. The client can use this URI to perform all other operations as us= ual. >>>>>> >>>>>> >>>>>> >>>>>> So taking 'externalID' out of the protocol spec only does this: >>>>>> >>>>>> 1. It avoids enshrining tight coupling in the protocol (If clients w= ant to tightly couple themselves to the cloud provider by sending their int= ernal IDs, they can do so. Suicide is OK, but the protocol should not be gu= ilty of assisted suicide. ;-) >>>>>> >>>>>> 2. It encourages loose coupling by nudging clients towards maintaini= ng their own internal-to-external identifier mappings. >>>>>> >>>>>> >>>>>> >>>>>> That's what I'd like to see. I don't believe this complicates the pr= otocol. It simplifies it and it also lends itself to a loosely-coupled appr= oach. >>>>>> >>>>>> >>>>>> >>>>>> I'll address the multi-valued attribute suggestion separately. >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ganesh >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>>> >>>>>> >>>>>> >>>>>> Phil >>>>>> >>>>>> >>>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad < >>>>>> g.c.prasad@gmail.com> wrote: >>>>>> >>>>>> > storing this information in a mapping table outside of the SCIM >>>>>> spec is a great way to enable this solution. Part of the key here i= s that >>>>>> SCIM is just a piece of the architecture for this solution, and is o= nly >>>>>> responsible for the transport layer between domains. >>>>>> >>>>>> I wasn't suggesting that the mapping table be part of the SCIM spec. >>>>>> I provided that example to illustrate that splitting and merging ide= ntities >>>>>> is a common requirement, and that decoupling local identifiers withi= n a >>>>>> domain from shared identifiers between domains was the best way to >>>>>> facilitate it. >>>>>> >>>>>> >>>>>> I'm suggesting that the spec do less, not more. >>>>>> >>>>>> >>>>>> What the SCIM spec needs to do there is just refrain from introducin= g >>>>>> tight coupling. I would like to see a single identifier exposed thro= ugh the >>>>>> API, with the implication (and perhaps the recommendation) that it b= e the >>>>>> shared one. Allowing one domain to expose its internal identifier to= the >>>>>> other creates tight coupling and ensures that both domains need >>>>>> simultaneously split or merge identities, which is not desirable. So= I >>>>>> recommend _taking out_ the "external id" field from the API. The spe= c >>>>>> shouldn't encourage tight coupling. If clients want to pass in their >>>>>> internal ids as part of the resource body, no one can stop them, and= they >>>>>> can always do a search on that attribute to retrieve the URI exactly= as you >>>>>> visualise they will with the "external id", but let's not elevate an >>>>>> anti-pattern to a recommendation by enshrining the "external id" as = an >>>>>> acceptable attribute. >>>>>> >>>>>> >>>>>> Am I making sense? >>>>>> >>>>>> >>>>>> >>>>>> I see what you are saying. I think scim gets its current simplicity >>>>>> from its single owner hub spoke model implementing tight coupling. >>>>>> >>>>>> >>>>>> IMHO loose coupling is a much more complex solution. The reality is >>>>>> that each end-point has value to contribute and thus the single-owne= r model >>>>>> will eventually need to become multi-owner or multi-hub. >>>>>> >>>>>> >>>>>> That said i think the current model provides a practical starting >>>>>> point. >>>>>> >>>>>> >>>>>> >>>>>> > Regarding unique identifiers for multi-valued attributes there is >>>>>> a trade-off involved. On one hand this makes PATCH semantics easier= . On >>>>>> the other hand it puts extra burden on service providers. >>>>>> >>>>>> >>>>>> Precisely. The spec has to strike the right balance. It would be >>>>>> interesting to hear from the other members of the spec mailing list.= You >>>>>> know where I stand on this. It would be good to hear the spectrum of >>>>>> opinions. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Ganesh >>>>>> >>>>>> On 10 August 2012 00:28, Kelly Grizzle >>>>>> wrote: >>>>>> >>>>>> Thanks Emmanuel. I had started writing up a similar response. As >>>>>> you suggest, storing this information in a mapping table outside of = the >>>>>> SCIM spec is a great way to enable this solution. Part of the key h= ere is >>>>>> that SCIM is just a piece of the architecture for this solution, and= is >>>>>> only responsible for the transport layer between domains. >>>>>> >>>>>> >>>>>> You could also model these ID mappings in the SCIM user as an >>>>>> extension but would probably not want to expose these externally. H= ere is >>>>>> an example of how to model the end state of the false positive scena= rio >>>>>> (splitting a user): >>>>>> >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>> true | >>>>>> >>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>>> true | >>>>>> >>>>>> >>>>>> This could be represented as two SCIM users that contain information >>>>>> about the entities on other domains. >>>>>> >>>>>> >>>>>> { >>>>>> >>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>> >>>>>> "id": "9caf78aac3d6", >>>>>> >>>>>> "userName": "John Smith", >>>>>> >>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>> >>>>>> "linkedUsers": [ >>>>>> >>>>>> { >>>>>> >>>>>> "domain": "D2", >>>>>> >>>>>> "externalEntityId": "ff487230b3a0" >>>>>> >>>>>> } >>>>>> >>>>>> ] >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> { >>>>>> >>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>> >>>>>> "id": "a99a5feba839", >>>>>> >>>>>> "userName": "John Smith", >>>>>> >>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>> >>>>>> "linkedUsers": [ >>>>>> >>>>>> { >>>>>> >>>>>> "domain": "D2", >>>>>> >>>>>> "externalEntityId": "7a87f27c1dd8" >>>>>> >>>>>> } >>>>>> >>>>>> ] >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> In the second user, the linkedUsers attribute would be empty until >>>>>> the split user was synced to domain 2. >>>>>> >>>>>> >>>>>> >>>>>> Similarly, the false negative use case (merging two users) looked >>>>>> like this at the end: >>>>>> >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>> true | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>>> false | >>>>>> >>>>>> >>>>>> This could be represented with the following SCIM user: >>>>>> >>>>>> >>>>>> { >>>>>> >>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>> >>>>>> "id": "9caf78aac3d6", >>>>>> >>>>>> "userName": "John Smith", >>>>>> >>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>> >>>>>> "linkedUsers": [ >>>>>> >>>>>> { >>>>>> >>>>>> "domain": "D2", >>>>>> >>>>>> "externalEntityId": "ff487230b3a0" >>>>>> >>>>>> }, >>>>>> >>>>>> { >>>>>> >>>>>> "domain": "D2", >>>>>> >>>>>> "externalEntityId": "41206cc97c8b", >>>>>> >>>>>> "deletionRequired": true >>>>>> >>>>>> } >>>>>> >>>>>> ] >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> Regarding unique identifiers for multi-valued attributes there is a >>>>>> trade-off involved. On one hand this makes PATCH semantics easier. = On the >>>>>> other hand it puts extra burden on service providers. Since the inc= eption >>>>>> of SCIM, a key goal has been to foster adoption by service providers= by >>>>>> making things fit easily onto existing systems. IMO the value gaine= d by >>>>>> unique identifiers for multi-valued attributes is not worth the dema= nds put >>>>>> on a service provider. I also think that vendors that have a >>>>>> non-SCIM-compliant API will choose to keep things that way if the sp= ec is >>>>>> too hard for them to implement. In a green field environment we do = have >>>>>> the luxury of mandating a model to make certain operations more eleg= ant. >>>>>> However, we can=92t ignore legacy systems. >>>>>> >>>>>> >>>>>> --Kelly >>>>>> >>>>>> >>>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>>> Behalf Of *Emmanuel Dreux >>>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>>> *Cc:* scim@ietf.org >>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>> >>>>>> >>>>>> Hi Ganesh, >>>>>> >>>>>> >>>>>> Nothing prevents you in your SCIM implementation (client or server) >>>>>> to generate a unique identifier for each synchronized object and mai= ntain >>>>>> an internal mapping table ( you would have to map group membership a= s well). >>>>>> >>>>>> >>>>>> This is what we are doing with Active Directory sources or targets: >>>>>> >>>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can = change >>>>>> if an AD domain is migrated), we decided to generate and maintain an >>>>>> internal table of ids. This fits your requirements as it hides inter= nal ids. >>>>>> >>>>>> >>>>>> This was written in dotnet and we have started a project to rewrite >>>>>> our SCIM stack in PHP and will give it to the Open Source community.= This >>>>>> implementation will have a parameter : AllocateIds versus UseExistin= gIDs. >>>>>> >>>>>> This will give the choice of =93hiding=94 internalIDs or use them as >>>>>> unique ID. >>>>>> >>>>>> >>>>>> You can also implement such feature without violating the SCIM specs= , >>>>>> or without asking to include it in the specs. >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Regards, >>>>>> >>>>>> Emmanuel Dreux >>>>>> >>>>>> http://www.cloudiway.com >>>>>> >>>>>> Tel: +33 4 26 78 17 58 >>>>>> >>>>>> Mobile: +33 6 47 81 26 70 >>>>>> >>>>>> skype: Emmanuel.Dreux >>>>>> >>>>>> >>>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>>> >>>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>>> *=C0 :* Kelly Grizzle >>>>>> *Cc :* scim@ietf.org >>>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>> >>>>>> >>>>>> Hi Kelly, >>>>>> >>>>>> Thanks for your response. Let me first respond in brief to the two >>>>>> main points you have made, and then elaborate on the first. >>>>>> >>>>>> 1. Why should domains not expose their internal identifiers to >>>>>> other domains? >>>>>> >>>>>> a. >>>>>> >>>>>> We are designing a protocol for a federated system of domains, where >>>>>> all domains are co-equal peers. (In physics too, N-body problems are= much >>>>>> harder than 2-body problems. :-) Therefore, assuming that there are = only >>>>>> two players in the interaction makes this tightly coupled in a numbe= r of >>>>>> ways. We should rely on messaging and notification, with encapsulati= on of >>>>>> domain-specific data. >>>>>> >>>>>> b. >>>>>> >>>>>> In any non-trivial data store, there will always be the ongoing need >>>>>> to merge and split identities as and when =93false negatives=94 and = =93false >>>>>> positives=94 are discovered. A domain should be able to handle this = internal >>>>>> housekeeping freely, only notifying other domains when convenient. M= apping >>>>>> of internal identifiers to external ones and maintaining this mappin= g >>>>>> internally allows this loosely-coupled housekeeping to take place. S= haring >>>>>> internal identifiers (or otherwise outsourcing the mapping of intern= al to >>>>>> external identifiers) forces housekeeping activities to be done in >>>>>> lock-step across domains. >>>>>> >>>>>> c. >>>>>> >>>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>>> protocol which can be designed later. The data model plays a crucial= role >>>>>> in enabling or constraining such interaction. A tightly-coupled data= model >>>>>> will force the use of synchronous interactions, and the exposure of >>>>>> internal identifiers is a key part of this tight coupling. >>>>>> >>>>>> 2. The difficulty of assigning unique identifiers to the individual >>>>>> values of multi-valued attributes: >>>>>> >>>>>> a. >>>>>> >>>>>> I'm not belittling the effort involved in migrating legacy data >>>>>> stores to such a model. However, in the larger historical context of >>>>>> cross-domain identity management, we are really at the very early st= ages. >>>>>> If a relatively new discipline and a brand new spec are held captive= to >>>>>> legacy considerations, we are losing an opportunity to provide a cle= an and >>>>>> elegant model to subsequent users of the spec, and this will have >>>>>> repercussions over many years or even decades. >>>>>> >>>>>> b. >>>>>> >>>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>>> dictionary model for existing multi-valued attributes, they can tran= sition >>>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-= compliant=94 >>>>>> APIs to their customers and encouraging new customers to adopt the >>>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and grad= ually >>>>>> migrated to the SCIM-compliant API. The logistics are not insurmount= able, >>>>>> and shouldn't prevent the adoption of a dictionary model for multi-v= alued >>>>>> attributes. >>>>>> >>>>>> Elaboration of Point 1: >>>>>> >>>>>> When we consider federated identity across more than one domain, we >>>>>> have to assume that domains are not necessarily master-slave in thei= r >>>>>> interaction. The most generic interaction model is peer-to-peer, whe= re >>>>>> entity lifecycle events within a domain are notified to other domain= s (when >>>>>> necessary) in an asynchronous manner (i.e., through messaging) and t= he >>>>>> other domains are free to respond to these events in an appropriate = manner >>>>>> and at a time of their convenience. >>>>>> >>>>>> A key set of lifecycle events for an entity is the merging and >>>>>> splitting of identity that is often required. >>>>>> >>>>>> The question =93Is this one entity?=94 can be answered either yes >>>>>> (positive) or no (negative). But sometimes, we can discover false po= sitives >>>>>> and false negatives in our data stores. >>>>>> >>>>>> Consider a case where customers sign up online, and two customers wh= o >>>>>> are privacy-conscious enter fake IDs such as =93John Smith=94, and a= lso use the >>>>>> same date of birth (say, 1 Jan 1970) or similar attributes. The fron= t-end >>>>>> application may make an intelligent (but incorrect) guess that these= two >>>>>> persons are the same, and re-assign the same identifier to the secon= d >>>>>> person. This is a false positive. They appear to be the same entity,= but >>>>>> they're actually different. When the error is discovered, the identi= ties >>>>>> will need to be split, with a new identifier generated for one of th= em. >>>>>> >>>>>> Consider the opposite case where a customer signs up through two >>>>>> different portals or in two different sessions, using the names =93J= Smith=94 >>>>>> and =93JohnS=94. It is very likely that they will be treated as two = different >>>>>> customers and assigned two unique identifiers. This is a false negat= ive. >>>>>> They appear to be two entities, but are actually the same. At a late= r >>>>>> stage, when the error is discovered, the identities will have to be = merged, >>>>>> and one of the identifiers will have to be dropped. >>>>>> >>>>>> These are not theoretical use cases. They form a significant >>>>>> proportion of the user base in most large Web-facing applications. L= et's >>>>>> see how these can be managed in a federated way by mapping internal >>>>>> identifiers to external ones and only exposing external identifiers = to >>>>>> other domains. >>>>>> >>>>>> a. False positives: >>>>>> >>>>>> Domain 1 has the following information about a customer in its data >>>>>> store: >>>>>> >>>>>> Internal ID: 9caf78aac3d6 >>>>>> >>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>> >>>>>> When requesting the provisioning of this entity in Domain 2, the >>>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>>> >>>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>>> for translation when talking to Domain 2, taking care never to expos= e its >>>>>> internal identifier: >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>> >>>>>> When the false positive is discovered and the entity is split, Domai= n >>>>>> 1 creates a new internal identifier and now has the following entity >>>>>> information. >>>>>> >>>>>> Internal ID: 9caf78aac3d6 >>>>>> >>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>> >>>>>> Internal ID: a99a5feba839 >>>>>> >>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>> >>>>>> This second entity with its own internal identifier is invisible to >>>>>> Domain 2, and this is by design. Communication about the original en= tity >>>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b3= a0=94 and >>>>>> vice-versa. At some convenient time (importantly, this doesn't have = to be >>>>>> at the time the split happens), Domain 2 can be requested to provisi= on a >>>>>> second entity, and when it responds with an identifier of =937a87f27= c1dd8=94, >>>>>> this can go into the mapping table as a new record associated with t= he >>>>>> second entity's internal identifier. >>>>>> >>>>>> The mapping table now contains the following entries: >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>> >>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>>> >>>>>> Domain 2 is not even aware that a split has happened, and the >>>>>> provisioning that it does is not in lockstep with the split in ident= ity >>>>>> that occurred in Domain 1. >>>>>> >>>>>> (What is the =93Primary flag=94 used for? We'll see when we cover th= e >>>>>> treatment of false negatives.) >>>>>> >>>>>> b. False negatives: >>>>>> >>>>>> Domain 1 has the following information about what it thinks are two >>>>>> distinct customers in its data store: >>>>>> >>>>>> Internal ID: 9caf78aac3d6 >>>>>> >>>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>>> >>>>>> Internal ID: 273d36e30d09 >>>>>> >>>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>>> >>>>>> When requesting the provisioning of these entities in Domain 2, the >>>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8= b. >>>>>> >>>>>> Domain 1 then maintains the following in a mapping table and uses it >>>>>> for translation when talking to Domain 2, taking care never to expos= e its >>>>>> internal identifiers: >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>> >>>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>>> >>>>>> When the false negative is discovered and the two entities are >>>>>> merged, Domain 1 drops one of the internal identifiers and rationali= ses the >>>>>> name of the customer (say, to =93John Smith=94). Let's say it retain= s the first >>>>>> ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>>> >>>>>> The mapping table now looks like this: >>>>>> >>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>> Primary flag | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>> >>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>>> >>>>>> Now two external identifiers map to the same internal one, so inboun= d >>>>>> communication from Domain 2 can be unambi >>>>>> >>>>> _______________________________________________ >>>> >>>> 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 >>> >>> >>> >> > --00151759308429300b04c70a042f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 It j= ust comes down to a difference of opinion.=A0

Yes= , but do consider that the unique key approach allows uniformity of treatme= nt regardless of level in the hierarchy for _all_ operations - add, modify = and delete, with "modify" having three sub-elements of its own (a= dd attribute, modify attribute, delete attribute).=A0

INCLUDE and RETIRE (add a new dictionary element to thi= s collection, or remove the entire collection):
key =3D "add= resses"

REPLACE, FORCE and RETIRE (update or = remove one complete dictionary element in the collection):
key =3D "addresses.3cbaaff= 8e84e"

PLACE and FORCE (= introduce a new dictionary element with a pre-assigned unique key - not the= client's internal key, of course):
key =3D "addresses.7956063c59a1"

REPLACE, FORCE and RETIRE (update of the dictiona= ry element, updating or removing an _existing_ sub-element):
key =3D "addresses.3c= baaff8e84e.street-number"
key =3D "addresses.3cbaaff8e84e.street-name"
=
...
key =3D "addresses.3cbaaff8e84e.country"

=
PLAC= E and FORCE (update of the dictionary element, introducing a _new_ sub-elem= ent):
key =3D "addresses.3cbaaff8e84e.city"

=
INCLUDE (update of the dictionary element, introducing one or more= _new_ values for a multi-valued sub-element):
key = =3D=A0"addresses.3c= baaff8e84e.available-services"
= value =3D ["cable", &= quot;ADSL"]
(Thi= s in turn returns keys for the two new dictionary elements that it creates.= )

There's just one standard = syntax for all of these operations.=A0There's a bit of an initial conce= ptual hurdle for a reader of the spec to grok this approach and also a one-= time implementation hurdle for the SPs, but thereafter it's simple and = elegant.

Once again = I'd like to ask, is there any SP representative on this working group w= ho can tell us exactly what it would entail for them to implement a unique-= key-per-value scheme? I want to understand how much of a burden this really= is, because I reckon this would knock a few pages off the spec document (w= hich is another index of simplicity).

Regards,
Ganesh

O= n 12 August 2012 13:25, Kelly Grizzle <kelly.grizzle@sailpoint.c= om> wrote:
>=A0how are you proposing that the following element be upda= ted if we can't use positional indexes?
<= br>
My proposal is what is= currently in the spec -=A0http://tools.ietf.org/html/draft-s= cim-api-00#section-3.3.2.

      Attr=
ibutes that do not have a value Sub-Attribute or that have a
      non-=
unique value Sub-Attribute are matched by comparing all
      Sub-=
Attribute values from the PATCH request body to the Sub-Attribute

      valu=
es of the Resource.

Another way to say this is &= quot;the whole dictionary element", which I don't believe is impra= ctical. =A0I understand your proposal and the implications of using uid for= each element vs. not. =A0It just comes down to a difference of opinion.

--Kelly

Fro= m: Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; sc= im@ietf.org

Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

That's exactly the point. How do we "specify completely for u= niqueness"?

In the example below, how are you proposing that the following element= be updated if we can't use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 ]
}

It's impractical to use the value because it's the whole dicti= onary element:

{
=A0 "type" : "office",
=A0 "street-number" : "213",
=A0 "street-name" : "Main Street",
=A0 "suburb" : "Adelaide",
=A0 "postcode" : "5000",
=A0 "state" : "SA",
=A0 "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243"

{
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 "3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 }
}

If you're proposing one mechanism for composite attributes and ano= ther mechanism for simple attributes, I would suggest that's actually m= ore complex than adopting a single mechanism that works the same way for _a= ll_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, = and having two mechanisms (depending on whether the attribute is simple or = composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but= I believe this is overblown. Is there any SP representative in this WG who= can tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued att= ributes that have a value sub-attribute can be removed by specifying only t= he value since it is unique. =A0Multi-valued attributes that don't have= a value sub-attribute (eg - address) have to specified completely for uniqueness. =A0As I have said before, I am ver= y opposed to adding a unique identifier to each element in a multi-valued c= ollection due to the burden it will put on SPs. =A0Is it elegant? =A0No. = =A0Is it functional? =A0Yes. =A0Will this non-elegance affect adoption? =A0My opinion is that adding unique keys to each element = will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element. =A0The verbs that you propose make sense= . =A0There is also a JSON Patch informational draft in the IETF that is int= eresting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-j= son-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= /div>

I'm curious if anyone else in the WG is in favor of unique i= dentifiers for every multi-valued element.

--Kelly
From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique ke= y for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuiti= ve.=A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }


You gave other examples of an attribute with an identifier that matched= that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point = of the extra indexing to support this. Just use the value as the item you w= ish to delete.

I agree, the delete value operation could be more explicit and clear in= general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>=A0 For the multi-value example you gave you = used the value as the attribute name key.=A0

Now I'm confused :-). I don't believe any of my examples ever = used a value as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key.=A0

That means a lot more complex indexing structure. Better to just say d= elete a specific value.=A0

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.= =A0

I don't believe so.

I'm adopting a model where every attribute of the resource is a ke= y-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself.=A0

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there= be new keys for each individual value, otherwise they are impossible to di= stinguish, and a positional index is inadequate. So we convert the array in= to a dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't= exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like t= hese that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing.=A0

I agree though that operations in patch could be a lot more explicit.= =A0

Eg explicitly deleting a value by saying delete or retire.=A0

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the curr= ent spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current = spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive.= =A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LD= AP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course= , so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion w= orth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issu= es, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0
=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0






On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0





I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0








I'm suggesting that the spec do less, not more.<=
/p>



=A0






What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0








Am I making sense?










=A0








I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0








IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0








=A0








That said i think the current model provides a pract=
ical starting point.=A0














=A0








>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.








=A0








Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a
 great way to enable this solution.=A0 Part of the key here is that SCIM is=
 just a piece of the architecture for this solution, and is only responsibl=
e for the transport layer between domains.


=A0




You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how
 to model the end state of the false positive scenario (splitting a user):<=
/span>




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.




=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.




=A0




=A0




Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 with the following SCIM user:


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=





=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




=A0




Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand
 it puts extra burden on service providers.=A0 Since the inception of SCIM,=
 a key goal has been to foster adoption by service providers by making thin=
gs fit easily onto existing systems.=A0 IMO the value gained by unique iden=
tifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0




--Kelly


=A0








From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0




Hi Ganesh,


=A0




Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal
 mapping table ( you would have to map group membership as well).

=A0




This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0




This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0




You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.




=A0




--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com




Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0






De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0




Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=






b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.




Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.




Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.




(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:




| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_______________________________________________

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




--00151759308429300b04c70a042f-- From g.c.prasad@gmail.com Sat Aug 11 22:01:41 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748B521F85ED for ; Sat, 11 Aug 2012 22:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnLcN7P2p9jc for ; Sat, 11 Aug 2012 22:01:35 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2621F85E4 for ; Sat, 11 Aug 2012 22:01:30 -0700 (PDT) Received: by bkty7 with SMTP id y7so1185793bkt.31 for ; Sat, 11 Aug 2012 22:01: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:from:date:message-id:subject:to :cc:content-type; bh=l7bQhClAHScN5/hbKQmCy3F26ON19kbj6QzW8sv+so4=; b=IEBNgUrvqSiOvd9jVSOQDq8/uRJOZUEkSLYIp3383c1+IKZh2Rb80udUuRFtC5+piR Qd4QE+dTbAS6z/dc+jrjPdExFDAQ382QBfLTzCykRwQCUOXLinXCNKYYadsKyzOkJg9P QzvBJ4gFoHV2QBOTZISt2ZLScoJq+eMGQdtzVIRvvVFCOTsgR9qcAQAVf1pQF+LYu4uC tuxGGSCOCq2LzKhyFRLlZMHsqi5HurlZEuOQjlYgcxKJESaqXoM7ZQijtmfVaYevCwiP wLEAZUiBnNqRDSUZbSluuRHAWVFIf0hF1TcBwmGfkO1yffZI/7KKFFuO1XHVvdcvNqM8 rPnA== Received: by 10.205.127.131 with SMTP id ha3mr2801298bkc.123.1344747689468; Sat, 11 Aug 2012 22:01:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 22:01:09 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 15:01:09 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015173fe4ac57e4ca04c70a78cc Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 05:01:41 -0000 --0015173fe4ac57e4ca04c70a78cc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable (I'm aware that I'm pushing very hard on this, and apologies if this is putting anyone off. I think it's in the best interests of the spec to have a robust (but respectful) discussion.) Nested arrays are a great example of where the simplistic approach breaks down. How can we specify that the first address now also has "Wi-fi" and doesn't have the "cable" service anymore? With the current spec, we'd struggle. These are not esoteric examples. I work for a telco and this is stock-standard information that we need to maintain about our customers. { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", ... "country" : "Australia", "available_services" : ["cable", "ADSL"] }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", ... "country" : "Australia", "available_services: ["ADSL2+", "Wi-fi"] } ] } Here's how I believe it should be done: PATCH /Users { "operations" : [ { "INCLUDE" : { "key" : "addresses.d6ea365462f5.available_services", "value" : "Wi-fi" }, "RETIRE" : { "key" : "addresses.d6ea365462f5.available_services.9be6378dc303" } } ] } because the resource structure would be like this: { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", ... "country" : "Australia", "available_services" : { "9be6378dc303" : "cable", "6aa1429eba34" : "ADSL" } }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", ... "country" : "Australia", "available_services: { "2beca1fdf3e5" : "ADSL2+", "8c3dcc204a33" : "Wi-fi" } } } } I think nested arrays are the clincher in favour of the unique-key-per-value approach. The difference of opinion is then just whether you think nested arrays are a common occurrence or not. I've just provided an example from my current industry where it is. Regards, Ganesh On 12 August 2012 14:28, Ganesh and Sashi Prasad wrot= e: > > It just comes down to a difference of opinion. > > Yes, but do consider that the unique key approach allows uniformity of > treatment regardless of level in the hierarchy for _all_ operations - add= , > modify and delete, with "modify" having three sub-elements of its own (ad= d > attribute, modify attribute, delete attribute). > > INCLUDE and RETIRE (add a new dictionary element to this collection, or > remove the entire collection): > key =3D "addresses" > > REPLACE, FORCE and RETIRE (update or remove one complete dictionary > element in the collection): > key =3D "addresses.3cbaaff8e84e" > > PLACE and FORCE (introduce a new dictionary element with a pre-assigned > unique key - not the client's internal key, of course): > key =3D "addresses.7956063c59a1" > > REPLACE, FORCE and RETIRE (update of the dictionary element, updating or > removing an _existing_ sub-element): > key =3D "addresses.3cbaaff8e84e.street-number" > key =3D "addresses.3cbaaff8e84e.street-name" > ... > key =3D "addresses.3cbaaff8e84e.country" > > PLACE and FORCE (update of the dictionary element, introducing a _new_ > sub-element): > key =3D "addresses.3cbaaff8e84e.city" > > INCLUDE (update of the dictionary element, introducing one or more _new_ > values for a multi-valued sub-element): > key =3D "addresses.3cbaaff8e84e.available-services" > value =3D ["cable", "ADSL"] > (This in turn returns keys for the two new dictionary elements that it > creates.) > > There's just one standard syntax for all of these operations. There's a > bit of an initial conceptual hurdle for a reader of the spec to grok this > approach and also a one-time implementation hurdle for the SPs, but > thereafter it's simple and elegant. > > Once again I'd like to ask, is there any SP representative on this workin= g > group who can tell us exactly what it would entail for them to implement = a > unique-key-per-value scheme? I want to understand how much of a burden th= is > really is, because I reckon this would knock a few pages off the spec > document (which is another index of simplicity). > > Regards, > Ganesh > > On 12 August 2012 13:25, Kelly Grizzle wrote= : > >> > how are you proposing that the following element be updated if we >> can't use positional indexes? >> >> My proposal is what is currently in the spec - >> http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2. >> >> Attributes that do not have a value Sub-Attribute or that have a >> >> non-unique value Sub-Attribute are matched by comparing all >> >> Sub-Attribute values from the PATCH request body to the Sub-Attrib= ute >> >> values of the Resource. >> >> >> Another way to say this is "the whole dictionary element", which I >> don't believe is impractical. I understand your proposal and the >> implications of using uid for each element vs. not. It just comes down = to >> a difference of opinion. >> >> --Kelly >> >> ------------------------------ >> *From:* Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >> *Sent:* Saturday, August 11, 2012 9:53 PM >> *To:* Kelly Grizzle >> *Cc:* Phil Hunt; scim@ietf.org >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >> >> > Multi-valued attributes that don't have a value sub-attribute (eg - >> address) have to specified completely for uniqueness. >> >> That's exactly the point. How do we "specify completely for uniqueness"= ? >> >> In the example below, how are you proposing that the following element >> be updated if we can't use positional indexes? >> >> addresses[1].street-number =3D "243" >> >> User object: >> >> { >> ... >> addresses: [ >> { >> "type" : "home", >> "street-number" : "35", >> "street-name" : "High Road", >> "suburb" : "East Camden", >> "postcode" : "5346", >> "state" : "SA", >> "country" : "Australia" >> }, >> { >> "type" : "office", >> "street-number" : "213", >> "street-name" : "Main Street", >> "suburb" : "Adelaide", >> "postcode" : "5000", >> "state" : "SA", >> "country" : "Australia" >> } >> ] >> } >> >> It's impractical to use the value because it's the whole dictionary >> element: >> >> { >> "type" : "office", >> "street-number" : "213", >> "street-name" : "Main Street", >> "suburb" : "Adelaide", >> "postcode" : "5000", >> "state" : "SA", >> "country" : "Australia" >> } >> >> With my proposal, the "addresses" array gets converted to a dictionary, >> and then we have a stable way of referencing this element: >> >> addresses.3cbaaff8e84e.street-number =3D "243" >> >> { >> ... >> addresses: { >> "d6ea365462f5" : >> { >> "type" : "home", >> "street-number" : "35", >> "street-name" : "High Road", >> "suburb" : "East Camden", >> "postcode" : "5346", >> "state" : "SA", >> "country" : "Australia" >> }, >> "3cbaaff8e84e" : >> { >> "type" : "office", >> "street-number" : "213", >> "street-name" : "Main Street", >> "suburb" : "Adelaide", >> "postcode" : "5000", >> "state" : "SA", >> "country" : "Australia" >> } >> } >> } >> >> If you're proposing one mechanism for composite attributes and another >> mechanism for simple attributes, I would suggest that's actually more >> complex than adopting a single mechanism that works the same way for _al= l_ >> attributes. Remember that a lot of the administration is probably going = to >> be scripted rather than done by hand, and having two mechanisms (dependi= ng >> on whether the attribute is simple or composite) will complicate every >> script that has to be written. >> >> There's a lot of talk about the "burden" on the SPs, but I believe this >> is overblown. Is there any SP representative in this WG who can tell us >> what this proposal will actually entail for them? >> >> Regards, >> Ganesh >> >> On 12 August 2012 11:53, Kelly Grizzle wrot= e: >> >>> Ganesh, >>> >>> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >>> that have a value sub-attribute can be removed by specifying only the v= alue >>> since it is unique. Multi-valued attributes that don't have a value >>> sub-attribute (eg - address) have to specified completely for uniquenes= s. >>> As I have said before, I am very opposed to adding a unique identifier= to >>> each element in a multi-valued collection due to the burden it will put= on >>> SPs. Is it elegant? No. Is it functional? Yes. Will this non-elega= nce >>> affect adoption? My opinion is that adding unique keys to each element >>> will have a much more detrimental effect on adoption. >>> >>> I do believe that in general PATCH can be made more intuitive without >>> adding uids to each element. The verbs that you propose make sense. T= here >>> is also a JSON Patch informational draft in the IETF that is interestin= g - >>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >>> on a JSON Pointer draft which uses index-based addressing for multi-val= ued >>> attributes. I think that this is something that should be looked at wi= thin >>> the WG and I would be willing to lead this effort. >>> >>> I'm curious if anyone else in the WG is in favor of unique identifiers >>> for every multi-valued element. >>> >>> --Kelly >>> >>> ------------------------------ >>> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >>> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>> *Sent:* Saturday, August 11, 2012 10:50 AM >>> *To:* Phil Hunt >>> *Cc:* scim@ietf.org >>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >>> >>> Phil, >>> >>> The reason we cannot use the value itself to identify an element is >>> that this method will only work for simple elements, not for nested >>> structures. i.e., if we had an array of dictionaries (e.g., we had to >>> record an array of addresses for each customer, with each address eleme= nt >>> having sub-elements like street number, street name, suburb, etc.), the= n it >>> would be clumsy to supply the entire value of the array element because >>> it's itself a dictionary. Creating a unique key for each element scales >>> better. >>> >>> Regards, >>> Ganesh >>> >>> On 12 August 2012 01:12, Phil Hunt wrote: >>> >>>> Ganesh, >>>> >>>> Here's the sample that concerned me... >>>> >>>> The two operations differ significantly, and it's not very intuitive. >>>> With my suggestion, here's how to delete a single member from a group: >>>> >>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comA= ccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>> W/"a330bc54f0671c9" { >>>> "operations" : [ >>>> { >>>> "RETIRE" : { >>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>> } >>>> } >>>> ] } >>>> >>>> >>>> >>>> You gave other examples of an attribute with an identifier that >>>> matched that value or of identifiers that were additional unique keys. >>>> >>>> Given that multi-values must be each unique, I don't see the point of >>>> the extra indexing to support this. Just use the value as the item you= wish >>>> to delete. >>>> >>>> I agree, the delete value operation could be more explicit and clear >>>> in general. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >>>> >>>> > For the multi-value example you gave you used the value as the >>>> attribute name key. >>>> >>>> Now I'm confused :-). I don't believe any of my examples ever used a >>>> value as the key. >>>> >>>> Could you please show me which example you mean, and which parts of >>>> it you believe to be the value? >>>> >>>> Regards, >>>> Ganesh >>>> >>>> On 11 August 2012 13:59, Phil Hunt wrote: >>>> >>>>> >>>>> For the multi-value example you gave you used the value as the >>>>> attribute name key. >>>>> >>>>> That means a lot more complex indexing structure. Better to just say >>>>> delete a specific value. >>>>> >>>>> The spec already allows multiple values to have tags like home, >>>>> work, etc. >>>>> >>>>> Phil >>>>> >>>>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >>>>> wrote: >>>>> >>>>> > In your example you are conflating value with an attribute id. >>>>> >>>>> I don't believe so. >>>>> >>>>> I'm adopting a model where every attribute of the resource is a >>>>> key-value pair. The key is a name or ID. >>>>> >>>>> For non-repeating attributes (both simple and composite), the key is >>>>> the attribute name itself. >>>>> >>>>> Simple attribute: >>>>> >>>>> Key: "dob" >>>>> Value: "01 Jan 1970" >>>>> >>>>> For composite attributes, the key employs dot notation to specify >>>>> the fully-qualified attribute name, e.g., "address.postcode". >>>>> >>>>> Composite attribute: >>>>> >>>>> Key: "address.street-number" >>>>> Value: "10" >>>>> >>>>> Key: "address.suburb" >>>>> Value: "East Camden" >>>>> >>>>> For repeating (multi-valued) attributes, I'm suggesting that there >>>>> be new keys for each individual value, otherwise they are impossible = to >>>>> distinguish, and a positional index is inadequate. So we convert the = array >>>>> into a dictionary and this then becomes a composite attribute using d= ot >>>>> notation for the key. >>>>> >>>>> Multi-valued attribute: >>>>> >>>>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>>>> Value: "john_smith@yahoo.com" >>>>> >>>>> So this allows us to apply uniform treatment to any arbitrarily deep >>>>> resource structure. We can refer to every leaf value with a key that = is the >>>>> fully-qualified name using dot notation. >>>>> >>>>> The verbs are just unambiguous operations on these (now) explicitly >>>>> addressable attributes. >>>>> >>>>> INCLUDE to a collection and specify only the value. The key is >>>>> generated and returned. The fully-qualified key is >>>>> . and the value is what was spec= ified >>>>> in the INCLUDE. >>>>> >>>>> REPLACE a fully-qualified key with a new value. If the key doesn't >>>>> exist, return a "404 Not Found". >>>>> >>>>> PLACE a value at the logical location implied by the fully-qualified >>>>> key. If there is already a key with that name, return a "409 Conflict= ". >>>>> >>>>> FORCE the fully-qualified key to hold the given value, regardless of >>>>> whether it existed before or not. Only errors possible are "400 Bad >>>>> Request" and "500 Internal Error". >>>>> >>>>> RETIRE an attribute or a collection given its fully-qualified key. >>>>> The implementation will determine whether the attribute will disappea= r >>>>> entirely or will exist holding a null value (the blank string "" or t= he >>>>> empty object {} ). >>>>> >>>>> I'll explain in a separate post why we need operation verbs like >>>>> these that are independent of the HTTP verbs. >>>>> >>>>> Regards, >>>>> Ganesh >>>>> >>>>> On 11 August 2012 10:38, wrote: >>>>> >>>>>> If you have received this digest without all the individual message >>>>>> attachments you will need to update your digest options in your list >>>>>> subscription. To do so, go to >>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>> >>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>> globally for all the list digests you receive at this point. >>>>>> >>>>>> >>>>>> >>>>>> Send scim mailing list submissions to >>>>>> scim@ietf.org >>>>>> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>> or, via email, send a message with subject or body 'help' to >>>>>> scim-request@ietf.org >>>>>> >>>>>> You can reach the person managing the list at >>>>>> scim-owner@ietf.org >>>>>> >>>>>> When replying, please edit your Subject line so it is more specific >>>>>> than "Re: Contents of scim digest..." >>>>>> >>>>>> Today's Topics: >>>>>> >>>>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Phil Hunt >>>>>> To: Ganesh and Sashi Prasad >>>>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>>>> edreux@cloudiway.com>, Trey Drake , Kelly >>>>>> Grizzle , "scim@ietf.org" >>>>> > >>>>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>> Ganesh, >>>>>> >>>>>> In your example you are conflating value with an attribute id. I >>>>>> find that confusing. >>>>>> >>>>>> I agree though that operations in patch could be a lot more >>>>>> explicit. >>>>>> >>>>>> Eg explicitly deleting a value by saying delete or retire. >>>>>> >>>>>> Phil >>>>>> >>>>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad < >>>>>> g.c.prasad@gmail.com> wrote: >>>>>> >>>>>> > I am concerned about your second suggestion: >>>>>> >>>>>> Let's discuss that now. >>>>>> >>>>>> The trade-offs are very clear here. >>>>>> >>>>>> Pros: >>>>>> >>>>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>>>> consistent and intuitive when every individual attribute value gets = its own >>>>>> ID. >>>>>> >>>>>> Here's how to delete a single member from a Group, as per the >>>>>> current spec: >>>>>> >>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>> Host: example.com >>>>>> Accept: application/json >>>>>> Authorization: Bearer h480djs93hd8 >>>>>> ETag: W/"a330bc54f0671c9" >>>>>> >>>>>> { >>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>> "members": [ >>>>>> { >>>>>> "display": "Babs Jensen", >>>>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>>>> "operation": "delete" >>>>>> } >>>>>> ] >>>>>> } >>>>>> >>>>>> >>>>>> Here's how to delete ALL members from a group according to the >>>>>> current spec: >>>>>> >>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>> Host: example.com >>>>>> Accept: application/json >>>>>> Authorization: Bearer h480djs93hd8 >>>>>> ETag: W/"a330bc54f0671c9" >>>>>> >>>>>> { >>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>> "meta": { >>>>>> "attributes": [ >>>>>> "members" >>>>>> ] >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> The two operations differ significantly, and it's not very intuitive= . >>>>>> With my suggestion, here's how to delete a single member from a grou= p: >>>>>> >>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.co= mAccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>>> W/"a330bc54f0671c9" { >>>>>> "operations" : [ >>>>>> { >>>>>> "RETIRE" : { >>>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>>> } >>>>>> } >>>>>> ] } >>>>>> Here's how I suggest deleting ALL members from a group: >>>>>> >>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.co= mAccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>>> W/"a330bc54f0671c9" { >>>>>> "operations" : [ >>>>>> { >>>>>> "RETIRE" : { >>>>>> "key" : "members" >>>>>> } >>>>>> } >>>>>> ] } >>>>>> >>>>>> I'm sure you'll agree that this is simpler, more consistent and more >>>>>> intuitive to a reader. >>>>>> >>>>>> Pro 2: We can apply this mechanism consistently to three areas: >>>>>> (a) Manipulating multi-valued attributes of a resource >>>>>> (b) Manipulating members of a group >>>>>> (c) Performing bulk operations, where we simply use HTTP verbs >>>>>> instead of the specialised (and semantically less ambiguous) verbs I >>>>>> suggested for attributes, the "key" becomes the URI, and the "value" >>>>>> becomes the corresponding JSON object. >>>>>> >>>>>> All of them return "207 Multi-Status" with the "results" array >>>>>> holding individual status codes. >>>>>> >>>>>> In the current spec, (a) and (b) are done similarly but (c) is very >>>>>> different. >>>>>> >>>>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>>>> because it's simpler for them. >>>>>> >>>>>> Pro 4: New (not incumbent) cloud providers will probably find this >>>>>> easier to implement because they have no legacy. They will probably = use >>>>>> some form of NoSQL database and won't be constrained by the limitati= ons of >>>>>> LDAP directories. >>>>>> >>>>>> Cons: >>>>>> >>>>>> Con 1: Incumbent cloud providers with existing data stores in a >>>>>> directory format (where multi-valued attributes are stored as >>>>>> comma-separated values under a single attribute node) will find it >>>>>> difficult to migrate to this model and store each attribute value as= a >>>>>> sub-node with its own key. This will "hinder adoption of the spec", = which >>>>>> is what you fear. >>>>>> >>>>>> Have I summed up the Pros and Cons correctly? I'm biased of course, >>>>>> so I could have missed a Con or hyped a Pro :-). >>>>>> >>>>>> In other words, we're debating interface complexity (current spec) >>>>>> versus implementation complexity (my suggestion). Both can hinder ad= option >>>>>> of the spec by different parties. >>>>>> >>>>>> Here's what we need to discuss - Do the Pros make the suggestion >>>>>> worth adopting in spite of the Cons, or are the Cons so great that i= t's >>>>>> best to leave the spec as it is? >>>>>> >>>>>> Keep in mind that a complex spec that only favours incumbent cloud >>>>>> providers can cut both ways. It opens the door to a simpler interfac= e >>>>>> offered by a new generation of nimbler SPs that don't have the same = legacy >>>>>> issues, and there could be an exodus of clients to these new SPs. SC= IM >>>>>> could end up being obsoleted very soon, because the API interface is= very >>>>>> complex and clumsy, as any new reader can attest. I was taken aback = by the >>>>>> complexity when I saw it, which is why I was prompted to suggest som= ething >>>>>> simpler. >>>>>> >>>>>> This is an issue where we need the opinions of many people, and >>>>>> they need to state their affiliations. If most people weighing in be= long to >>>>>> incumbent SPs and they vote in favour of interface complexity to avo= id >>>>>> implementation complexity, then it means the spec is not doing a goo= d job >>>>>> of balancing the interests of various groups. I think we should also= poll >>>>>> client organisations to see what they would want. >>>>>> >>>>>> (Gartner is trusted by enterprise clients to evaluate the >>>>>> capabilities of vendors (SPs). I believe Gartner should take the lea= d in >>>>>> representing client interests in this working group rather than thos= e of >>>>>> incumbent vendors, which is what it seems like to me. Correct me if = I'm >>>>>> being unfair.) >>>>>> >>>>>> Regards, >>>>>> Ganesh >>>>>> >>>>>> >>>>>> >>>>>> On 11 August 2012 01:35, Diodati,Mark wrot= e: >>>>>> >>>>>>> Hi Ganesh, >>>>>>> >>>>>>> >>>>>>> I am concerned about your second suggestion: >>>>>>> >>>>>>> =932. When dealing with multi-valued attributes of a resource >>>>>>> (expressed as arrays in JSON), they must be converted from an array= into a >>>>>>> dictionary with unique keys (UUIDs generated by the cloud provider = when the >>>>>>> attribute is created). Without unique keys for every attribute valu= e of a >>>>>>> resource, manipulating it will be clumsy and inelegant.=94 >>>>>>> >>>>>>> >>>>>>> One of the primary reasons that SPML failed was lack of adoption by >>>>>>> service providers due to its complexity. Very few target applicatio= ns >>>>>>> implemented SPML. Most of the commercial provisioning systems had a= n SPML >>>>>>> interface (either v1 or v2), but not one of them was conformant to = the SPML >>>>>>> standard because of complexity. If you are interested, I will forwa= rd you >>>>>>> the research documents that discuss these problems in detail. For S= CIM to >>>>>>> be successful, it must be adopted by commercial target applications= (i.e., >>>>>>> service providers). I am confident that a requirement for unique >>>>>>> identifiers with multi-valued attributes will preclude its adoption= , >>>>>>> because it requires major changes to the service provider=92s exist= ing >>>>>>> identity storage mechanisms. >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>>>> >>>>>>> *To:* Ganesh and Sashi Prasad >>>>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>>>> >>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ganesh, >>>>>>> >>>>>>> >>>>>>> I'll base my comments on your latest reply (below). >>>>>>> >>>>>>> >>>>>>> The externalID is not part of the protocol. It is an *optional* >>>>>>> attribute within the *schema* specification. As for #2, the protoc= ol spec >>>>>>> works as you describe if "arbitrary URI parameters" equate to resou= rce >>>>>>> attributes (Allow generic search using 'GET /Users' and arbitrary U= RI >>>>>>> parameters). Please clarify your suggestion. >>>>>>> >>>>>>> >>>>>>> I'm not tracking your coupling concern. The client can search and >>>>>>> hence retrieve resources on any attribute it chooses, externalId or >>>>>>> otherwise. Nothing mandates use of externalId. >>>>>>> >>>>>>> >>>>>>> >>>>>>> What do you mean by "candidate key"? Given >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>> >>>>>>> > I think scim gets its current simplicity from its single owner >>>>>>> hub spoke model implementing tight coupling. [...] IMHO loose coupl= ing is a >>>>>>> much more complex solution. >>>>>>> >>>>>>> >>>>>>> Phil, >>>>>>> >>>>>>> >>>>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D sim= ple" >>>>>>> and "loose coupling =3D=3D complex". That's contrary to my experien= ce. >>>>>>> >>>>>>> >>>>>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>>>>> Invariably, a reduction in dependencies leads to greater simplicity= . >>>>>>> >>>>>>> >>>>>>> Let's not confuse reduction of dependencies in the data model with = a >>>>>>> hub-and-spokes architecture. They're entirely orthogonal aspects of= the >>>>>>> solution. >>>>>>> >>>>>>> >>>>>>> All that my suggestion involves is, >>>>>>> >>>>>>> >>>>>>> 1. Take 'external ID' out of the protocol. >>>>>>> >>>>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI >>>>>>> parameters >>>>>>> >>>>>>> >>>>>>> No planned functionality is lost by this. >>>>>>> >>>>>>> >>>>>>> 1. The client enterprise can still send its internal ID as part of >>>>>>> the resource body, inside some attribute defined by them (but not d= efined >>>>>>> by the protocol). Let's say they call it 'myID'. >>>>>>> >>>>>>> 2. The client enterprise can search for resource URIs using any >>>>>>> attribute, including this internal ID >>>>>>> >>>>>>> 'GET /Users?myID=3Dbjensen' >>>>>>> >>>>>>> Since myID is a candidate key, the server will return exactly one >>>>>>> URI, which is the canonical URI for the resource >>>>>>> >>>>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>>>> >>>>>>> 3. The client can use this URI to perform all other operations as u= sual. >>>>>>> >>>>>>> >>>>>>> >>>>>>> So taking 'externalID' out of the protocol spec only does this: >>>>>>> >>>>>>> 1. It avoids enshrining tight coupling in the protocol (If clients = want to tightly couple themselves to the cloud provider by sending their in= ternal IDs, they can do so. Suicide is OK, but the protocol should not be g= uilty of assisted suicide. ;-) >>>>>>> >>>>>>> 2. It encourages loose coupling by nudging clients towards maintain= ing their own internal-to-external identifier mappings. >>>>>>> >>>>>>> >>>>>>> >>>>>>> That's what I'd like to see. I don't believe this complicates the p= rotocol. It simplifies it and it also lends itself to a loosely-coupled app= roach. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'll address the multi-valued attribute suggestion separately. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ganesh >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> >>>>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad < >>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>> >>>>>>> > storing this information in a mapping table outside of the SCIM >>>>>>> spec is a great way to enable this solution. Part of the key here = is that >>>>>>> SCIM is just a piece of the architecture for this solution, and is = only >>>>>>> responsible for the transport layer between domains. >>>>>>> >>>>>>> I wasn't suggesting that the mapping table be part of the SCIM spec= . >>>>>>> I provided that example to illustrate that splitting and merging id= entities >>>>>>> is a common requirement, and that decoupling local identifiers with= in a >>>>>>> domain from shared identifiers between domains was the best way to >>>>>>> facilitate it. >>>>>>> >>>>>>> >>>>>>> I'm suggesting that the spec do less, not more. >>>>>>> >>>>>>> >>>>>>> What the SCIM spec needs to do there is just refrain from >>>>>>> introducing tight coupling. I would like to see a single identifier= exposed >>>>>>> through the API, with the implication (and perhaps the recommendati= on) that >>>>>>> it be the shared one. Allowing one domain to expose its internal id= entifier >>>>>>> to the other creates tight coupling and ensures that both domains n= eed >>>>>>> simultaneously split or merge identities, which is not desirable. S= o I >>>>>>> recommend _taking out_ the "external id" field from the API. The sp= ec >>>>>>> shouldn't encourage tight coupling. If clients want to pass in thei= r >>>>>>> internal ids as part of the resource body, no one can stop them, an= d they >>>>>>> can always do a search on that attribute to retrieve the URI exactl= y as you >>>>>>> visualise they will with the "external id", but let's not elevate a= n >>>>>>> anti-pattern to a recommendation by enshrining the "external id" as= an >>>>>>> acceptable attribute. >>>>>>> >>>>>>> >>>>>>> Am I making sense? >>>>>>> >>>>>>> >>>>>>> >>>>>>> I see what you are saying. I think scim gets its current simplicity >>>>>>> from its single owner hub spoke model implementing tight coupling. >>>>>>> >>>>>>> >>>>>>> IMHO loose coupling is a much more complex solution. The reality is >>>>>>> that each end-point has value to contribute and thus the single-own= er model >>>>>>> will eventually need to become multi-owner or multi-hub. >>>>>>> >>>>>>> >>>>>>> That said i think the current model provides a practical starting >>>>>>> point. >>>>>>> >>>>>>> >>>>>>> >>>>>>> > Regarding unique identifiers for multi-valued attributes there >>>>>>> is a trade-off involved. On one hand this makes PATCH semantics ea= sier. >>>>>>> On the other hand it puts extra burden on service providers. >>>>>>> >>>>>>> >>>>>>> Precisely. The spec has to strike the right balance. It would be >>>>>>> interesting to hear from the other members of the spec mailing list= . You >>>>>>> know where I stand on this. It would be good to hear the spectrum o= f >>>>>>> opinions. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Ganesh >>>>>>> >>>>>>> On 10 August 2012 00:28, Kelly Grizzle >>>>>>> wrote: >>>>>>> >>>>>>> Thanks Emmanuel. I had started writing up a similar response. As >>>>>>> you suggest, storing this information in a mapping table outside of= the >>>>>>> SCIM spec is a great way to enable this solution. Part of the key = here is >>>>>>> that SCIM is just a piece of the architecture for this solution, an= d is >>>>>>> only responsible for the transport layer between domains. >>>>>>> >>>>>>> >>>>>>> You could also model these ID mappings in the SCIM user as an >>>>>>> extension but would probably not want to expose these externally. = Here is >>>>>>> an example of how to model the end state of the false positive scen= ario >>>>>>> (splitting a user): >>>>>>> >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>> true | >>>>>>> >>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>>>> true | >>>>>>> >>>>>>> >>>>>>> This could be represented as two SCIM users that contain informatio= n >>>>>>> about the entities on other domains. >>>>>>> >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>> >>>>>>> "id": "9caf78aac3d6", >>>>>>> >>>>>>> "userName": "John Smith", >>>>>>> >>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>> >>>>>>> "linkedUsers": [ >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "domain": "D2", >>>>>>> >>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>> >>>>>>> } >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>> >>>>>>> "id": "a99a5feba839", >>>>>>> >>>>>>> "userName": "John Smith", >>>>>>> >>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>> >>>>>>> "linkedUsers": [ >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "domain": "D2", >>>>>>> >>>>>>> "externalEntityId": "7a87f27c1dd8" >>>>>>> >>>>>>> } >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> In the second user, the linkedUsers attribute would be empty until >>>>>>> the split user was synced to domain 2. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Similarly, the false negative use case (merging two users) looked >>>>>>> like this at the end: >>>>>>> >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>> true | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>>>> false | >>>>>>> >>>>>>> >>>>>>> This could be represented with the following SCIM user: >>>>>>> >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>> >>>>>>> "id": "9caf78aac3d6", >>>>>>> >>>>>>> "userName": "John Smith", >>>>>>> >>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>> >>>>>>> "linkedUsers": [ >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "domain": "D2", >>>>>>> >>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>> >>>>>>> }, >>>>>>> >>>>>>> { >>>>>>> >>>>>>> "domain": "D2", >>>>>>> >>>>>>> "externalEntityId": "41206cc97c8b", >>>>>>> >>>>>>> "deletionRequired": true >>>>>>> >>>>>>> } >>>>>>> >>>>>>> ] >>>>>>> >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regarding unique identifiers for multi-valued attributes there is a >>>>>>> trade-off involved. On one hand this makes PATCH semantics easier.= On the >>>>>>> other hand it puts extra burden on service providers. Since the in= ception >>>>>>> of SCIM, a key goal has been to foster adoption by service provider= s by >>>>>>> making things fit easily onto existing systems. IMO the value gain= ed by >>>>>>> unique identifiers for multi-valued attributes is not worth the dem= ands put >>>>>>> on a service provider. I also think that vendors that have a >>>>>>> non-SCIM-compliant API will choose to keep things that way if the s= pec is >>>>>>> too hard for them to implement. In a green field environment we do= have >>>>>>> the luxury of mandating a model to make certain operations more ele= gant. >>>>>>> However, we can=92t ignore legacy systems. >>>>>>> >>>>>>> >>>>>>> --Kelly >>>>>>> >>>>>>> >>>>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>>>> Behalf Of *Emmanuel Dreux >>>>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>>>> *Cc:* scim@ietf.org >>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>> >>>>>>> >>>>>>> Hi Ganesh, >>>>>>> >>>>>>> >>>>>>> Nothing prevents you in your SCIM implementation (client or server) >>>>>>> to generate a unique identifier for each synchronized object and ma= intain >>>>>>> an internal mapping table ( you would have to map group membership = as well). >>>>>>> >>>>>>> >>>>>>> This is what we are doing with Active Directory sources or targets: >>>>>>> >>>>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid can= change >>>>>>> if an AD domain is migrated), we decided to generate and maintain a= n >>>>>>> internal table of ids. This fits your requirements as it hides inte= rnal ids. >>>>>>> >>>>>>> >>>>>>> This was written in dotnet and we have started a project to rewrite >>>>>>> our SCIM stack in PHP and will give it to the Open Source community= . This >>>>>>> implementation will have a parameter : AllocateIds versus UseExisti= ngIDs. >>>>>>> >>>>>>> This will give the choice of =93hiding=94 internalIDs or use them a= s >>>>>>> unique ID. >>>>>>> >>>>>>> >>>>>>> You can also implement such feature without violating the SCIM >>>>>>> specs, or without asking to include it in the specs. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Emmanuel Dreux >>>>>>> >>>>>>> http://www.cloudiway.com >>>>>>> >>>>>>> Tel: +33 4 26 78 17 58 >>>>>>> >>>>>>> Mobile: +33 6 47 81 26 70 >>>>>>> >>>>>>> skype: Emmanuel.Dreux >>>>>>> >>>>>>> >>>>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>>>> >>>>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>>>> *=C0 :* Kelly Grizzle >>>>>>> *Cc :* scim@ietf.org >>>>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>> >>>>>>> >>>>>>> Hi Kelly, >>>>>>> >>>>>>> Thanks for your response. Let me first respond in brief to the two >>>>>>> main points you have made, and then elaborate on the first. >>>>>>> >>>>>>> 1. Why should domains not expose their internal identifiers to >>>>>>> other domains? >>>>>>> >>>>>>> a. >>>>>>> >>>>>>> We are designing a protocol for a federated system of domains, wher= e >>>>>>> all domains are co-equal peers. (In physics too, N-body problems ar= e much >>>>>>> harder than 2-body problems. :-) Therefore, assuming that there are= only >>>>>>> two players in the interaction makes this tightly coupled in a numb= er of >>>>>>> ways. We should rely on messaging and notification, with encapsulat= ion of >>>>>>> domain-specific data. >>>>>>> >>>>>>> b. >>>>>>> >>>>>>> In any non-trivial data store, there will always be the ongoing nee= d >>>>>>> to merge and split identities as and when =93false negatives=94 and= =93false >>>>>>> positives=94 are discovered. A domain should be able to handle this= internal >>>>>>> housekeeping freely, only notifying other domains when convenient. = Mapping >>>>>>> of internal identifiers to external ones and maintaining this mappi= ng >>>>>>> internally allows this loosely-coupled housekeeping to take place. = Sharing >>>>>>> internal identifiers (or otherwise outsourcing the mapping of inter= nal to >>>>>>> external identifiers) forces housekeeping activities to be done in >>>>>>> lock-step across domains. >>>>>>> >>>>>>> c. >>>>>>> >>>>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>>>> protocol which can be designed later. The data model plays a crucia= l role >>>>>>> in enabling or constraining such interaction. A tightly-coupled dat= a model >>>>>>> will force the use of synchronous interactions, and the exposure of >>>>>>> internal identifiers is a key part of this tight coupling. >>>>>>> >>>>>>> 2. The difficulty of assigning unique identifiers to the individual >>>>>>> values of multi-valued attributes: >>>>>>> >>>>>>> a. >>>>>>> >>>>>>> I'm not belittling the effort involved in migrating legacy data >>>>>>> stores to such a model. However, in the larger historical context o= f >>>>>>> cross-domain identity management, we are really at the very early s= tages. >>>>>>> If a relatively new discipline and a brand new spec are held captiv= e to >>>>>>> legacy considerations, we are losing an opportunity to provide a cl= ean and >>>>>>> elegant model to subsequent users of the spec, and this will have >>>>>>> repercussions over many years or even decades. >>>>>>> >>>>>>> b. >>>>>>> >>>>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>>>> dictionary model for existing multi-valued attributes, they can tra= nsition >>>>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCIM= -compliant=94 >>>>>>> APIs to their customers and encouraging new customers to adopt the >>>>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using a >>>>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gra= dually >>>>>>> migrated to the SCIM-compliant API. The logistics are not insurmoun= table, >>>>>>> and shouldn't prevent the adoption of a dictionary model for multi-= valued >>>>>>> attributes. >>>>>>> >>>>>>> Elaboration of Point 1: >>>>>>> >>>>>>> When we consider federated identity across more than one domain, we >>>>>>> have to assume that domains are not necessarily master-slave in the= ir >>>>>>> interaction. The most generic interaction model is peer-to-peer, wh= ere >>>>>>> entity lifecycle events within a domain are notified to other domai= ns (when >>>>>>> necessary) in an asynchronous manner (i.e., through messaging) and = the >>>>>>> other domains are free to respond to these events in an appropriate= manner >>>>>>> and at a time of their convenience. >>>>>>> >>>>>>> A key set of lifecycle events for an entity is the merging and >>>>>>> splitting of identity that is often required. >>>>>>> >>>>>>> The question =93Is this one entity?=94 can be answered either yes >>>>>>> (positive) or no (negative). But sometimes, we can discover false p= ositives >>>>>>> and false negatives in our data stores. >>>>>>> >>>>>>> Consider a case where customers sign up online, and two customers >>>>>>> who are privacy-conscious enter fake IDs such as =93John Smith=94, = and also use >>>>>>> the same date of birth (say, 1 Jan 1970) or similar attributes. The >>>>>>> front-end application may make an intelligent (but incorrect) guess= that >>>>>>> these two persons are the same, and re-assign the same identifier t= o the >>>>>>> second person. This is a false positive. They appear to be the same= entity, >>>>>>> but they're actually different. When the error is discovered, the >>>>>>> identities will need to be split, with a new identifier generated f= or one >>>>>>> of them. >>>>>>> >>>>>>> Consider the opposite case where a customer signs up through two >>>>>>> different portals or in two different sessions, using the names =93= JSmith=94 >>>>>>> and =93JohnS=94. It is very likely that they will be treated as two= different >>>>>>> customers and assigned two unique identifiers. This is a false nega= tive. >>>>>>> They appear to be two entities, but are actually the same. At a lat= er >>>>>>> stage, when the error is discovered, the identities will have to be= merged, >>>>>>> and one of the identifiers will have to be dropped. >>>>>>> >>>>>>> These are not theoretical use cases. They form a significant >>>>>>> proportion of the user base in most large Web-facing applications. = Let's >>>>>>> see how these can be managed in a federated way by mapping internal >>>>>>> identifiers to external ones and only exposing external identifiers= to >>>>>>> other domains. >>>>>>> >>>>>>> a. False positives: >>>>>>> >>>>>>> Domain 1 has the following information about a customer in its data >>>>>>> store: >>>>>>> >>>>>>> Internal ID: 9caf78aac3d6 >>>>>>> >>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>> >>>>>>> When requesting the provisioning of this entity in Domain 2, the >>>>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>>>> >>>>>>> Domain 1 then maintains the following in a mapping table and uses i= t >>>>>>> for translation when talking to Domain 2, taking care never to expo= se its >>>>>>> internal identifier: >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>> >>>>>>> When the false positive is discovered and the entity is split, >>>>>>> Domain 1 creates a new internal identifier and now has the followin= g entity >>>>>>> information. >>>>>>> >>>>>>> Internal ID: 9caf78aac3d6 >>>>>>> >>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>> >>>>>>> Internal ID: a99a5feba839 >>>>>>> >>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>> >>>>>>> This second entity with its own internal identifier is invisible to >>>>>>> Domain 2, and this is by design. Communication about the original e= ntity >>>>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230b= 3a0=94 and >>>>>>> vice-versa. At some convenient time (importantly, this doesn't have= to be >>>>>>> at the time the split happens), Domain 2 can be requested to provis= ion a >>>>>>> second entity, and when it responds with an identifier of =937a87f2= 7c1dd8=94, >>>>>>> this can go into the mapping table as a new record associated with = the >>>>>>> second entity's internal identifier. >>>>>>> >>>>>>> The mapping table now contains the following entries: >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>> >>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>>>> >>>>>>> Domain 2 is not even aware that a split has happened, and the >>>>>>> provisioning that it does is not in lockstep with the split in iden= tity >>>>>>> that occurred in Domain 1. >>>>>>> >>>>>>> (What is the =93Primary flag=94 used for? We'll see when we cover t= he >>>>>>> treatment of false negatives.) >>>>>>> >>>>>>> b. False negatives: >>>>>>> >>>>>>> Domain 1 has the following information about what it thinks are two >>>>>>> distinct customers in its data store: >>>>>>> >>>>>>> Internal ID: 9caf78aac3d6 >>>>>>> >>>>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>>>> >>>>>>> Internal ID: 273d36e30d09 >>>>>>> >>>>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>>>> >>>>>>> When requesting the provisioning of these entities in Domain 2, the >>>>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c= 8b. >>>>>>> >>>>>>> Domain 1 then maintains the following in a mapping table and uses i= t >>>>>>> for translation when talking to Domain 2, taking care never to expo= se its >>>>>>> internal identifiers: >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>> >>>>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>>>> >>>>>>> When the false negative is discovered and the two entities are >>>>>>> merged, Domain 1 drops one of the internal identifiers and rational= ises the >>>>>>> name of the customer (say, to =93John Smith=94). Let's say it retai= ns the first >>>>>>> ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>>>> >>>>>>> The mapping table now looks like this: >>>>>>> >>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>> Primary flag | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>> >>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>>>> >>>>>>> Now two external identifiers map to the same internal one, so >>>>>>> inbound communication from Domain 2 can be unambi >>>>>>> >>>>>> _______________________________________________ >>>>> >>>>> 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 >>>> >>>> >>>> >>> >> > --0015173fe4ac57e4ca04c70a78cc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
(I'm aware that I'm pushing very hard on this, and apologies i= f this is putting anyone off. I think it's in the best interests of the= spec to have a robust (but respectful) discussion.)

Nested arrays are a great example of where the simplistic approach breaks d= own. How can we specify that the first address now also has "Wi-fi&quo= t; and doesn't have the "cable" service anymore? With the cur= rent spec, we'd struggle.

These are not esoteric examples. I work for a telco and this= is stock-standard information that we need to maintain about our customers= .

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
= =A0 =A0 =A0 "street-name" : "High Road",
=A0 = =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia&quo= t;,
=A0 =A0 =A0 "available_services" : ["cable", "= ;ADSL"]
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0= "type" : "office",
=A0 =A0 =A0 "street-= number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Austra= lia",
=A0 =A0 =A0 "available_services: ["ADSL2+&qu= ot;, "Wi-fi"]
=A0 =A0 }
=A0 ]
}

Here= 9;s how I believe it should be done:

PATCH /U= sers

{
=A0 "operations" : [
=A0 =A0 {
=A0 =A0 =A0 "INCLUDE" : {
=A0 =A0 = =A0 =A0 "key" : "addresses.d6ea365462f5.available_services&q= uot;,
=A0 =A0 =A0 =A0 "value" : "Wi-fi"
=
=A0 =A0 =A0 },
=A0 =A0 =A0 "RETIRE" : {
=A0 =A0 =A0 =A0 "key"= ; : "addresses.d6ea365462f5.available_services.9be6378dc303"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 ]
}

because the resource structure would be like this:

{
=A0 ...
=A0 addresses: {
=A0 =A0 &quo= t;d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "type= " : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 = =A0 =A0 "street-name" : "High Road",
=A0 =A0 = =A0 ...
=A0 =A0 =A0 "country" : "Australia",<= /div>
=A0 =A0 =A0 "available_services" : {
=A0 =A0 =A0 =A0 "9be6378dc303" : "cable",=A0
=
=A0 =A0 =A0 =A0 "6aa1429eba34" : "ADSL"
= =A0 =A0 =A0 }
=A0 =A0 },
=A0 =A0 "3cbaaff8e84e&quo= t; :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 &q= uot;street-number" : "213",
=A0 =A0 =A0 "stre= et-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia",
=A0 =A0 =A0 "available_services: {
=A0 =A0 =A0 =A0 &quo= t;2beca1fdf3e5" : "ADSL2+",=A0
=A0 =A0 =A0 =A0 &qu= ot;8c3dcc204a33" : "Wi-fi"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 }
}

I think nested arrays are the clinche= r in favour of the unique-key-per-value approach. The difference of opinion= is then just whether you think nested arrays are a common occurrence or no= t. I've just provided an example from my current industry where it is.<= /div>

Regards,
Ganesh

On 12 August 2012 14:28, Ganesh and Sashi Prasad &= lt;g.c.prasad@gma= il.com> wrote:
>=A0 It j= ust comes down to a difference of opinion.=A0

Yes, but do consider that the unique key approach allows uniformity of t= reatment regardless of level in the hierarchy for _all_ operations - add, m= odify and delete, with "modify" having three sub-elements of its = own (add attribute, modify attribute, delete attribute).=A0

INCLUDE and RETIRE (add a new dictionary element to thi= s collection, or remove the entire collection):
key =3D "add= resses"

REPLACE, FORCE and RETIRE (update or = remove one complete dictionary element in the collection):
key =3D "addresses.3cbaaff= 8e84e"

PLACE and FORCE (= introduce a new dictionary element with a pre-assigned unique key - not the= client's internal key, of course):
key =3D "addresses.7956063c59a1"

REPLACE, FORCE and RETIRE (update of the dictiona= ry element, updating or removing an _existing_ sub-element):
key =3D "addresses.3c= baaff8e84e.street-number"
key =3D "addresses.3cbaaff8e84e.street-name"
=
...
key =3D "addresses.3cbaaff8e84e.country"

=
PLAC= E and FORCE (update of the dictionary element, introducing a _new_ sub-elem= ent):
key =3D "addresses.3cbaaff8e84e.city"

=
INCLUDE (update of the dictionary element, introducing one or more= _new_ values for a multi-valued sub-element):
key = =3D=A0"addresses.3c= baaff8e84e.available-services"
= value =3D ["cable", &= quot;ADSL"]
(Thi= s in turn returns keys for the two new dictionary elements that it creates.= )

There's just one standard = syntax for all of these operations.=A0There's a bit of an initial conce= ptual hurdle for a reader of the spec to grok this approach and also a one-= time implementation hurdle for the SPs, but thereafter it's simple and = elegant.

Once again = I'd like to ask, is there any SP representative on this working group w= ho can tell us exactly what it would entail for them to implement a unique-= key-per-value scheme? I want to understand how much of a burden this really= is, because I reckon this would knock a few pages off the spec document (w= hich is another index of simplicity).

Regards,
Ganesh

On 12 August 2012 13:25, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
>=A0how are you proposing that the following element be upda= ted if we can't use positional indexes?
<= br>
My proposal is what is= currently in the spec -=A0http://tools.ietf.org/html/draft-s= cim-api-00#section-3.3.2.

      Attr=
ibutes that do not have a value Sub-Attribute or that have a
      non-=
unique value Sub-Attribute are matched by comparing all
      Sub-=
Attribute values from the PATCH request body to the Sub-Attribute

      valu=
es of the Resource.

Another way to say this is &= quot;the whole dictionary element", which I don't believe is impra= ctical. =A0I understand your proposal and the implications of using uid for= each element vs. not. =A0It just comes down to a difference of opinion.

--Kelly

Fro= m: Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; sc= im@ietf.org

Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

That's exactly the point. How do we "specify completely for u= niqueness"?

In the example below, how are you proposing that the following element= be updated if we can't use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 ]
}

It's impractical to use the value because it's the whole dicti= onary element:

{
=A0 "type" : "office",
=A0 "street-number" : "213",
=A0 "street-name" : "Main Street",
=A0 "suburb" : "Adelaide",
=A0 "postcode" : "5000",
=A0 "state" : "SA",
=A0 "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243"

{
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 "3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 }
}

If you're proposing one mechanism for composite attributes and ano= ther mechanism for simple attributes, I would suggest that's actually m= ore complex than adopting a single mechanism that works the same way for _a= ll_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, = and having two mechanisms (depending on whether the attribute is simple or = composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but= I believe this is overblown. Is there any SP representative in this WG who= can tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued att= ributes that have a value sub-attribute can be removed by specifying only t= he value since it is unique. =A0Multi-valued attributes that don't have= a value sub-attribute (eg - address) have to specified completely for uniqueness. =A0As I have said before, I am ver= y opposed to adding a unique identifier to each element in a multi-valued c= ollection due to the burden it will put on SPs. =A0Is it elegant? =A0No. = =A0Is it functional? =A0Yes. =A0Will this non-elegance affect adoption? =A0My opinion is that adding unique keys to each element = will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element. =A0The verbs that you propose make sense= . =A0There is also a JSON Patch informational draft in the IETF that is int= eresting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-j= son-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= /div>

I'm curious if anyone else in the WG is in favor of unique i= dentifiers for every multi-valued element.

--Kelly
From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique ke= y for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuiti= ve.=A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }


You gave other examples of an attribute with an identifier that matched= that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point = of the extra indexing to support this. Just use the value as the item you w= ish to delete.

I agree, the delete value operation could be more explicit and clear in= general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>=A0 For the multi-value example you gave you = used the value as the attribute name key.=A0

Now I'm confused :-). I don't believe any of my examples ever = used a value as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key.=A0

That means a lot more complex indexing structure. Better to just say d= elete a specific value.=A0

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.= =A0

I don't believe so.

I'm adopting a model where every attribute of the resource is a ke= y-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself.=A0

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there= be new keys for each individual value, otherwise they are impossible to di= stinguish, and a positional index is inadequate. So we convert the array in= to a dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't= exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like t= hese that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing.=A0

I agree though that operations in patch could be a lot more explicit.= =A0

Eg explicitly deleting a value by saying delete or retire.=A0

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the curr= ent spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current = spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive.= =A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LD= AP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course= , so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion w= orth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issu= es, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0
=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0






On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0






I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0








I'm suggesting that the spec do less, not more.<=
/p>



=A0






What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0








Am I making sense?










=A0








I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0








IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0









=A0








That said i think the current model provides a pract=
ical starting point.=A0














=A0








>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.









=A0








Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a
 great way to enable this solution.=A0 Part of the key here is that SCIM is=
 just a piece of the architecture for this solution, and is only responsibl=
e for the transport layer between domains.


=A0




You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how
 to model the end state of the false positive scenario (splitting a user):<=
/span>




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.





=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=






=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=






=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.





=A0




=A0




Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 with the following SCIM user:


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=






=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




=A0




Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand
 it puts extra burden on service providers.=A0 Since the inception of SCIM,=
 a key goal has been to foster adoption by service providers by making thin=
gs fit easily onto existing systems.=A0 IMO the value gained by unique iden=
tifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0




--Kelly


=A0








From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0




Hi Ganesh,


=A0




Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal
 mapping table ( you would have to map group membership as well).

=A0




This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0




This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0




You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.





=A0




--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com





Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0






De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0




Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=







b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.





Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:





| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.





Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.





(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:





| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_______________________________________________

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





--0015173fe4ac57e4ca04c70a78cc-- From g.c.prasad@gmail.com Sat Aug 11 22:43:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CC511E809B for ; Sat, 11 Aug 2012 22:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U8+hC0Wrsn4 for ; Sat, 11 Aug 2012 22:43:50 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 271AE11E8091 for ; Sat, 11 Aug 2012 22:43:48 -0700 (PDT) Received: by bkty7 with SMTP id y7so1191593bkt.31 for ; Sat, 11 Aug 2012 22:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VopSdN8joclSi5Iek6hvmACMu4+xTEzqcqtp1tidaf0=; b=0w8y4UMu2THVAozTgULAIWs8VdEDoqPjXazi7CYUaC0LRezJxuH69ADIN9agOhP7lu XzJxNPejxjsOzW2qnlxPU1gObrXMyiy/0X/lRY+sj5cL4a7Cz5rHTmEZf/rt8pVkrcT5 nZk9vHNenp88odh+lzBZtf3IvK7B5yF12DRmZJaPPfSaXhL6SLOVN4xQD67jY0JujiCl Skvj97ZCMvjO0v1cktpebGso78JqvCbqBsS7x5/UWmPCNI2/Q578QhqB9vNCj7z3YRyH QttZ/ORaogmwagPVXKu11oHnLIxNestBkCbGHI+6+HTiIAKU7G9aYidf7pgn77GQXNCG yZ8w== Received: by 10.204.156.87 with SMTP id v23mr2919852bkw.0.1344750228034; Sat, 11 Aug 2012 22:43:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 22:43:27 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 15:43:27 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015175cba22a756df04c70b0fb6 Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 05:43:56 -0000 --0015175cba22a756df04c70b0fb6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. I don't know how I let this one pass! A JSON array is a List, not a Set. There is _no uniqueness constraint_ on its values, so your assumption is not justified. If I wanted to model the medal winners of the men's 100 metre race at the London Olympics (won by Usain Bolt and his compatriots), I might want to say: "medallists" : [ "Jamaica", "Jamaica", "Jamaica" ] Are you saying this will not be allowed by SCIM because the values are not unique? Why not? When JSON allows it, why should SCIM object? Until now, I assumed that the spec was only _clumsy_. If it's based on the assumption that array values are unique, then it is _wrong_. Regards, Ganesh On 12 August 2012 15:01, Ganesh and Sashi Prasad wrot= e: > (I'm aware that I'm pushing very hard on this, and apologies if this is > putting anyone off. I think it's in the best interests of the spec to hav= e > a robust (but respectful) discussion.) > > Nested arrays are a great example of where the simplistic approach breaks > down. How can we specify that the first address now also has "Wi-fi" and > doesn't have the "cable" service anymore? With the current spec, we'd > struggle. > > These are not esoteric examples. I work for a telco and this is > stock-standard information that we need to maintain about our customers. > > { > ... > addresses: [ > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > ... > "country" : "Australia", > "available_services" : ["cable", "ADSL"] > }, > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > ... > "country" : "Australia", > "available_services: ["ADSL2+", "Wi-fi"] > } > ] > } > > Here's how I believe it should be done: > > PATCH /Users > > { > "operations" : [ > { > "INCLUDE" : { > "key" : "addresses.d6ea365462f5.available_services", > "value" : "Wi-fi" > }, > "RETIRE" : { > "key" : "addresses.d6ea365462f5.available_services.9be6378dc303" > } > } > ] > } > > because the resource structure would be like this: > > { > ... > addresses: { > "d6ea365462f5" : > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > ... > "country" : "Australia", > "available_services" : { > "9be6378dc303" : "cable", > "6aa1429eba34" : "ADSL" > } > }, > "3cbaaff8e84e" : > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > ... > "country" : "Australia", > "available_services: { > "2beca1fdf3e5" : "ADSL2+", > "8c3dcc204a33" : "Wi-fi" > } > } > } > } > > I think nested arrays are the clincher in favour of the > unique-key-per-value approach. The difference of opinion is then just > whether you think nested arrays are a common occurrence or not. I've just > provided an example from my current industry where it is. > > Regards, > Ganesh > > On 12 August 2012 14:28, Ganesh and Sashi Prasad wr= ote: > >> > It just comes down to a difference of opinion. >> >> Yes, but do consider that the unique key approach allows uniformity of >> treatment regardless of level in the hierarchy for _all_ operations - ad= d, >> modify and delete, with "modify" having three sub-elements of its own (a= dd >> attribute, modify attribute, delete attribute). >> >> INCLUDE and RETIRE (add a new dictionary element to this collection, or >> remove the entire collection): >> key =3D "addresses" >> >> REPLACE, FORCE and RETIRE (update or remove one complete dictionary >> element in the collection): >> key =3D "addresses.3cbaaff8e84e" >> >> PLACE and FORCE (introduce a new dictionary element with a pre-assigned >> unique key - not the client's internal key, of course): >> key =3D "addresses.7956063c59a1" >> >> REPLACE, FORCE and RETIRE (update of the dictionary element, updating or >> removing an _existing_ sub-element): >> key =3D "addresses.3cbaaff8e84e.street-number" >> key =3D "addresses.3cbaaff8e84e.street-name" >> ... >> key =3D "addresses.3cbaaff8e84e.country" >> >> PLACE and FORCE (update of the dictionary element, introducing a _new_ >> sub-element): >> key =3D "addresses.3cbaaff8e84e.city" >> >> INCLUDE (update of the dictionary element, introducing one or more _new_ >> values for a multi-valued sub-element): >> key =3D "addresses.3cbaaff8e84e.available-services" >> value =3D ["cable", "ADSL"] >> (This in turn returns keys for the two new dictionary elements that it >> creates.) >> >> There's just one standard syntax for all of these operations. There's a >> bit of an initial conceptual hurdle for a reader of the spec to grok thi= s >> approach and also a one-time implementation hurdle for the SPs, but >> thereafter it's simple and elegant. >> >> Once again I'd like to ask, is there any SP representative on this >> working group who can tell us exactly what it would entail for them to >> implement a unique-key-per-value scheme? I want to understand how much o= f a >> burden this really is, because I reckon this would knock a few pages off >> the spec document (which is another index of simplicity). >> >> Regards, >> Ganesh >> >> On 12 August 2012 13:25, Kelly Grizzle wrot= e: >> >>> > how are you proposing that the following element be updated if we >>> can't use positional indexes? >>> >>> My proposal is what is currently in the spec - >>> http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2. >>> >>> Attributes that do not have a value Sub-Attribute or that have a >>> >>> non-unique value Sub-Attribute are matched by comparing all >>> >>> Sub-Attribute values from the PATCH request body to the Sub-Attri= bute >>> >>> values of the Resource. >>> >>> >>> Another way to say this is "the whole dictionary element", which I >>> don't believe is impractical. I understand your proposal and the >>> implications of using uid for each element vs. not. It just comes down= to >>> a difference of opinion. >>> >>> --Kelly >>> >>> ------------------------------ >>> *From:* Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>> *Sent:* Saturday, August 11, 2012 9:53 PM >>> *To:* Kelly Grizzle >>> *Cc:* Phil Hunt; scim@ietf.org >>> >>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >>> >>> > Multi-valued attributes that don't have a value sub-attribute (eg - >>> address) have to specified completely for uniqueness. >>> >>> That's exactly the point. How do we "specify completely for >>> uniqueness"? >>> >>> In the example below, how are you proposing that the following element >>> be updated if we can't use positional indexes? >>> >>> addresses[1].street-number =3D "243" >>> >>> User object: >>> >>> { >>> ... >>> addresses: [ >>> { >>> "type" : "home", >>> "street-number" : "35", >>> "street-name" : "High Road", >>> "suburb" : "East Camden", >>> "postcode" : "5346", >>> "state" : "SA", >>> "country" : "Australia" >>> }, >>> { >>> "type" : "office", >>> "street-number" : "213", >>> "street-name" : "Main Street", >>> "suburb" : "Adelaide", >>> "postcode" : "5000", >>> "state" : "SA", >>> "country" : "Australia" >>> } >>> ] >>> } >>> >>> It's impractical to use the value because it's the whole dictionary >>> element: >>> >>> { >>> "type" : "office", >>> "street-number" : "213", >>> "street-name" : "Main Street", >>> "suburb" : "Adelaide", >>> "postcode" : "5000", >>> "state" : "SA", >>> "country" : "Australia" >>> } >>> >>> With my proposal, the "addresses" array gets converted to a >>> dictionary, and then we have a stable way of referencing this element: >>> >>> addresses.3cbaaff8e84e.street-number =3D "243" >>> >>> { >>> ... >>> addresses: { >>> "d6ea365462f5" : >>> { >>> "type" : "home", >>> "street-number" : "35", >>> "street-name" : "High Road", >>> "suburb" : "East Camden", >>> "postcode" : "5346", >>> "state" : "SA", >>> "country" : "Australia" >>> }, >>> "3cbaaff8e84e" : >>> { >>> "type" : "office", >>> "street-number" : "213", >>> "street-name" : "Main Street", >>> "suburb" : "Adelaide", >>> "postcode" : "5000", >>> "state" : "SA", >>> "country" : "Australia" >>> } >>> } >>> } >>> >>> If you're proposing one mechanism for composite attributes and another >>> mechanism for simple attributes, I would suggest that's actually more >>> complex than adopting a single mechanism that works the same way for _a= ll_ >>> attributes. Remember that a lot of the administration is probably going= to >>> be scripted rather than done by hand, and having two mechanisms (depend= ing >>> on whether the attribute is simple or composite) will complicate every >>> script that has to be written. >>> >>> There's a lot of talk about the "burden" on the SPs, but I believe >>> this is overblown. Is there any SP representative in this WG who can te= ll >>> us what this proposal will actually entail for them? >>> >>> Regards, >>> Ganesh >>> >>> On 12 August 2012 11:53, Kelly Grizzle wro= te: >>> >>>> Ganesh, >>>> >>>> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >>>> that have a value sub-attribute can be removed by specifying only the = value >>>> since it is unique. Multi-valued attributes that don't have a value >>>> sub-attribute (eg - address) have to specified completely for uniquene= ss. >>>> As I have said before, I am very opposed to adding a unique identifie= r to >>>> each element in a multi-valued collection due to the burden it will pu= t on >>>> SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleg= ance >>>> affect adoption? My opinion is that adding unique keys to each elemen= t >>>> will have a much more detrimental effect on adoption. >>>> >>>> I do believe that in general PATCH can be made more intuitive without >>>> adding uids to each element. The verbs that you propose make sense. = There >>>> is also a JSON Patch informational draft in the IETF that is interesti= ng - >>>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It >>>> relies on a JSON Pointer draft which uses index-based addressing for >>>> multi-valued attributes. I think that this is something that should b= e >>>> looked at within the WG and I would be willing to lead this effort. >>>> >>>> I'm curious if anyone else in the WG is in favor of unique >>>> identifiers for every multi-valued element. >>>> >>>> --Kelly >>>> >>>> ------------------------------ >>>> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >>>> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>>> *Sent:* Saturday, August 11, 2012 10:50 AM >>>> *To:* Phil Hunt >>>> *Cc:* scim@ietf.org >>>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >>>> >>>> Phil, >>>> >>>> The reason we cannot use the value itself to identify an element is >>>> that this method will only work for simple elements, not for nested >>>> structures. i.e., if we had an array of dictionaries (e.g., we had to >>>> record an array of addresses for each customer, with each address elem= ent >>>> having sub-elements like street number, street name, suburb, etc.), th= en it >>>> would be clumsy to supply the entire value of the array element becaus= e >>>> it's itself a dictionary. Creating a unique key for each element scale= s >>>> better. >>>> >>>> Regards, >>>> Ganesh >>>> >>>> On 12 August 2012 01:12, Phil Hunt wrote: >>>> >>>>> Ganesh, >>>>> >>>>> Here's the sample that concerned me... >>>>> >>>>> The two operations differ significantly, and it's not very intuitive. >>>>> With my suggestion, here's how to delete a single member from a group= : >>>>> >>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com= Accept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>> W/"a330bc54f0671c9" { >>>>> "operations" : [ >>>>> { >>>>> "RETIRE" : { >>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>> } >>>>> } >>>>> ] } >>>>> >>>>> >>>>> >>>>> You gave other examples of an attribute with an identifier that >>>>> matched that value or of identifiers that were additional unique keys= . >>>>> >>>>> Given that multi-values must be each unique, I don't see the point >>>>> of the extra indexing to support this. Just use the value as the item= you >>>>> wish to delete. >>>>> >>>>> I agree, the delete value operation could be more explicit and clear >>>>> in general. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >>>>> >>>>> > For the multi-value example you gave you used the value as the >>>>> attribute name key. >>>>> >>>>> Now I'm confused :-). I don't believe any of my examples ever used a >>>>> value as the key. >>>>> >>>>> Could you please show me which example you mean, and which parts of >>>>> it you believe to be the value? >>>>> >>>>> Regards, >>>>> Ganesh >>>>> >>>>> On 11 August 2012 13:59, Phil Hunt wrote: >>>>> >>>>>> >>>>>> For the multi-value example you gave you used the value as the >>>>>> attribute name key. >>>>>> >>>>>> That means a lot more complex indexing structure. Better to just >>>>>> say delete a specific value. >>>>>> >>>>>> The spec already allows multiple values to have tags like home, >>>>>> work, etc. >>>>>> >>>>>> Phil >>>>>> >>>>>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad < >>>>>> g.c.prasad@gmail.com> wrote: >>>>>> >>>>>> > In your example you are conflating value with an attribute id. >>>>>> >>>>>> I don't believe so. >>>>>> >>>>>> I'm adopting a model where every attribute of the resource is a >>>>>> key-value pair. The key is a name or ID. >>>>>> >>>>>> For non-repeating attributes (both simple and composite), the key >>>>>> is the attribute name itself. >>>>>> >>>>>> Simple attribute: >>>>>> >>>>>> Key: "dob" >>>>>> Value: "01 Jan 1970" >>>>>> >>>>>> For composite attributes, the key employs dot notation to specify >>>>>> the fully-qualified attribute name, e.g., "address.postcode". >>>>>> >>>>>> Composite attribute: >>>>>> >>>>>> Key: "address.street-number" >>>>>> Value: "10" >>>>>> >>>>>> Key: "address.suburb" >>>>>> Value: "East Camden" >>>>>> >>>>>> For repeating (multi-valued) attributes, I'm suggesting that there >>>>>> be new keys for each individual value, otherwise they are impossible= to >>>>>> distinguish, and a positional index is inadequate. So we convert the= array >>>>>> into a dictionary and this then becomes a composite attribute using = dot >>>>>> notation for the key. >>>>>> >>>>>> Multi-valued attribute: >>>>>> >>>>>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>>>>> Value: "john_smith@yahoo.com" >>>>>> >>>>>> So this allows us to apply uniform treatment to any arbitrarily >>>>>> deep resource structure. We can refer to every leaf value with a key= that >>>>>> is the fully-qualified name using dot notation. >>>>>> >>>>>> The verbs are just unambiguous operations on these (now) explicitly >>>>>> addressable attributes. >>>>>> >>>>>> INCLUDE to a collection and specify only the value. The key is >>>>>> generated and returned. The fully-qualified key is >>>>>> . and the value is what was spe= cified >>>>>> in the INCLUDE. >>>>>> >>>>>> REPLACE a fully-qualified key with a new value. If the key doesn't >>>>>> exist, return a "404 Not Found". >>>>>> >>>>>> PLACE a value at the logical location implied by the >>>>>> fully-qualified key. If there is already a key with that name, retur= n a >>>>>> "409 Conflict". >>>>>> >>>>>> FORCE the fully-qualified key to hold the given value, regardless >>>>>> of whether it existed before or not. Only errors possible are "400 B= ad >>>>>> Request" and "500 Internal Error". >>>>>> >>>>>> RETIRE an attribute or a collection given its fully-qualified key. >>>>>> The implementation will determine whether the attribute will disappe= ar >>>>>> entirely or will exist holding a null value (the blank string "" or = the >>>>>> empty object {} ). >>>>>> >>>>>> I'll explain in a separate post why we need operation verbs like >>>>>> these that are independent of the HTTP verbs. >>>>>> >>>>>> Regards, >>>>>> Ganesh >>>>>> >>>>>> On 11 August 2012 10:38, wrote: >>>>>> >>>>>>> If you have received this digest without all the individual message >>>>>>> attachments you will need to update your digest options in your lis= t >>>>>>> subscription. To do so, go to >>>>>>> >>>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>>> >>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "Ge= t >>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>> globally for all the list digests you receive at this point. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Send scim mailing list submissions to >>>>>>> scim@ietf.org >>>>>>> >>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>> scim-request@ietf.org >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> scim-owner@ietf.org >>>>>>> >>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>> than "Re: Contents of scim digest..." >>>>>>> >>>>>>> Today's Topics: >>>>>>> >>>>>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>>>>>> >>>>>>> >>>>>>> ---------- Forwarded message ---------- >>>>>>> From: Phil Hunt >>>>>>> To: Ganesh and Sashi Prasad >>>>>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>>>>> edreux@cloudiway.com>, Trey Drake , Kelly >>>>>>> Grizzle , "scim@ietf.org" < >>>>>>> scim@ietf.org> >>>>>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>>>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>> Ganesh, >>>>>>> >>>>>>> In your example you are conflating value with an attribute id. I >>>>>>> find that confusing. >>>>>>> >>>>>>> I agree though that operations in patch could be a lot more >>>>>>> explicit. >>>>>>> >>>>>>> Eg explicitly deleting a value by saying delete or retire. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad < >>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>> >>>>>>> > I am concerned about your second suggestion: >>>>>>> >>>>>>> Let's discuss that now. >>>>>>> >>>>>>> The trade-offs are very clear here. >>>>>>> >>>>>>> Pros: >>>>>>> >>>>>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>>>>> consistent and intuitive when every individual attribute value gets= its own >>>>>>> ID. >>>>>>> >>>>>>> Here's how to delete a single member from a Group, as per the >>>>>>> current spec: >>>>>>> >>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>>> Host: example.com >>>>>>> Accept: application/json >>>>>>> Authorization: Bearer h480djs93hd8 >>>>>>> ETag: W/"a330bc54f0671c9" >>>>>>> >>>>>>> { >>>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>>> "members": [ >>>>>>> { >>>>>>> "display": "Babs Jensen", >>>>>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>>>>> "operation": "delete" >>>>>>> } >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Here's how to delete ALL members from a group according to the >>>>>>> current spec: >>>>>>> >>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>>> Host: example.com >>>>>>> Accept: application/json >>>>>>> Authorization: Bearer h480djs93hd8 >>>>>>> ETag: W/"a330bc54f0671c9" >>>>>>> >>>>>>> { >>>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>>> "meta": { >>>>>>> "attributes": [ >>>>>>> "members" >>>>>>> ] >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> The two operations differ significantly, and it's not very >>>>>>> intuitive. >>>>>>> With my suggestion, here's how to delete a single member from a >>>>>>> group: >>>>>>> >>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: >>>>>>> example.com Accept: application/json Authorization: Bearer >>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" { >>>>>>> "operations" : [ >>>>>>> { >>>>>>> "RETIRE" : { >>>>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>>>> } >>>>>>> } >>>>>>> ] } >>>>>>> Here's how I suggest deleting ALL members from a group: >>>>>>> >>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: >>>>>>> example.com Accept: application/json Authorization: Bearer >>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" { >>>>>>> "operations" : [ >>>>>>> { >>>>>>> "RETIRE" : { >>>>>>> "key" : "members" >>>>>>> } >>>>>>> } >>>>>>> ] } >>>>>>> >>>>>>> I'm sure you'll agree that this is simpler, more consistent and mor= e >>>>>>> intuitive to a reader. >>>>>>> >>>>>>> Pro 2: We can apply this mechanism consistently to three areas: >>>>>>> (a) Manipulating multi-valued attributes of a resource >>>>>>> (b) Manipulating members of a group >>>>>>> (c) Performing bulk operations, where we simply use HTTP verbs >>>>>>> instead of the specialised (and semantically less ambiguous) verbs = I >>>>>>> suggested for attributes, the "key" becomes the URI, and the "value= " >>>>>>> becomes the corresponding JSON object. >>>>>>> >>>>>>> All of them return "207 Multi-Status" with the "results" array >>>>>>> holding individual status codes. >>>>>>> >>>>>>> In the current spec, (a) and (b) are done similarly but (c) is >>>>>>> very different. >>>>>>> >>>>>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>>>>> because it's simpler for them. >>>>>>> >>>>>>> Pro 4: New (not incumbent) cloud providers will probably find this >>>>>>> easier to implement because they have no legacy. They will probably= use >>>>>>> some form of NoSQL database and won't be constrained by the limitat= ions of >>>>>>> LDAP directories. >>>>>>> >>>>>>> Cons: >>>>>>> >>>>>>> Con 1: Incumbent cloud providers with existing data stores in a >>>>>>> directory format (where multi-valued attributes are stored as >>>>>>> comma-separated values under a single attribute node) will find it >>>>>>> difficult to migrate to this model and store each attribute value a= s a >>>>>>> sub-node with its own key. This will "hinder adoption of the spec",= which >>>>>>> is what you fear. >>>>>>> >>>>>>> Have I summed up the Pros and Cons correctly? I'm biased of >>>>>>> course, so I could have missed a Con or hyped a Pro :-). >>>>>>> >>>>>>> In other words, we're debating interface complexity (current spec) >>>>>>> versus implementation complexity (my suggestion). Both can hinder a= doption >>>>>>> of the spec by different parties. >>>>>>> >>>>>>> Here's what we need to discuss - Do the Pros make the suggestion >>>>>>> worth adopting in spite of the Cons, or are the Cons so great that = it's >>>>>>> best to leave the spec as it is? >>>>>>> >>>>>>> Keep in mind that a complex spec that only favours incumbent cloud >>>>>>> providers can cut both ways. It opens the door to a simpler interfa= ce >>>>>>> offered by a new generation of nimbler SPs that don't have the same= legacy >>>>>>> issues, and there could be an exodus of clients to these new SPs. S= CIM >>>>>>> could end up being obsoleted very soon, because the API interface i= s very >>>>>>> complex and clumsy, as any new reader can attest. I was taken aback= by the >>>>>>> complexity when I saw it, which is why I was prompted to suggest so= mething >>>>>>> simpler. >>>>>>> >>>>>>> This is an issue where we need the opinions of many people, and >>>>>>> they need to state their affiliations. If most people weighing in b= elong to >>>>>>> incumbent SPs and they vote in favour of interface complexity to av= oid >>>>>>> implementation complexity, then it means the spec is not doing a go= od job >>>>>>> of balancing the interests of various groups. I think we should als= o poll >>>>>>> client organisations to see what they would want. >>>>>>> >>>>>>> (Gartner is trusted by enterprise clients to evaluate the >>>>>>> capabilities of vendors (SPs). I believe Gartner should take the le= ad in >>>>>>> representing client interests in this working group rather than tho= se of >>>>>>> incumbent vendors, which is what it seems like to me. Correct me if= I'm >>>>>>> being unfair.) >>>>>>> >>>>>>> Regards, >>>>>>> Ganesh >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11 August 2012 01:35, Diodati,Mark wro= te: >>>>>>> >>>>>>>> Hi Ganesh, >>>>>>>> >>>>>>>> >>>>>>>> I am concerned about your second suggestion: >>>>>>>> >>>>>>>> =932. When dealing with multi-valued attributes of a resource >>>>>>>> (expressed as arrays in JSON), they must be converted from an arra= y into a >>>>>>>> dictionary with unique keys (UUIDs generated by the cloud provider= when the >>>>>>>> attribute is created). Without unique keys for every attribute val= ue of a >>>>>>>> resource, manipulating it will be clumsy and inelegant.=94 >>>>>>>> >>>>>>>> >>>>>>>> One of the primary reasons that SPML failed was lack of adoption b= y >>>>>>>> service providers due to its complexity. Very few target applicati= ons >>>>>>>> implemented SPML. Most of the commercial provisioning systems had = an SPML >>>>>>>> interface (either v1 or v2), but not one of them was conformant to= the SPML >>>>>>>> standard because of complexity. If you are interested, I will forw= ard you >>>>>>>> the research documents that discuss these problems in detail. For = SCIM to >>>>>>>> be successful, it must be adopted by commercial target application= s (i.e., >>>>>>>> service providers). I am confident that a requirement for unique >>>>>>>> identifiers with multi-valued attributes will preclude its adoptio= n, >>>>>>>> because it requires major changes to the service provider=92s exis= ting >>>>>>>> identity storage mechanisms. >>>>>>>> >>>>>>>> Mark >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>>>>> >>>>>>>> *To:* Ganesh and Sashi Prasad >>>>>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>>>>> >>>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ganesh, >>>>>>>> >>>>>>>> >>>>>>>> I'll base my comments on your latest reply (below). >>>>>>>> >>>>>>>> >>>>>>>> The externalID is not part of the protocol. It is an *optional* >>>>>>>> attribute within the *schema* specification. As for #2, the proto= col spec >>>>>>>> works as you describe if "arbitrary URI parameters" equate to reso= urce >>>>>>>> attributes (Allow generic search using 'GET /Users' and arbitrary = URI >>>>>>>> parameters). Please clarify your suggestion. >>>>>>>> >>>>>>>> >>>>>>>> I'm not tracking your coupling concern. The client can search and >>>>>>>> hence retrieve resources on any attribute it chooses, externalId o= r >>>>>>>> otherwise. Nothing mandates use of externalId. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What do you mean by "candidate key"? Given >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>>> >>>>>>>> > I think scim gets its current simplicity from its single owner >>>>>>>> hub spoke model implementing tight coupling. [...] IMHO loose coup= ling is a >>>>>>>> much more complex solution. >>>>>>>> >>>>>>>> >>>>>>>> Phil, >>>>>>>> >>>>>>>> >>>>>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D si= mple" >>>>>>>> and "loose coupling =3D=3D complex". That's contrary to my experie= nce. >>>>>>>> >>>>>>>> >>>>>>>> When I say "loose coupling", I mean "no unnecessary dependencies". >>>>>>>> Invariably, a reduction in dependencies leads to greater simplicit= y. >>>>>>>> >>>>>>>> >>>>>>>> Let's not confuse reduction of dependencies in the data model with >>>>>>>> a hub-and-spokes architecture. They're entirely orthogonal aspects= of the >>>>>>>> solution. >>>>>>>> >>>>>>>> >>>>>>>> All that my suggestion involves is, >>>>>>>> >>>>>>>> >>>>>>>> 1. Take 'external ID' out of the protocol. >>>>>>>> >>>>>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI >>>>>>>> parameters >>>>>>>> >>>>>>>> >>>>>>>> No planned functionality is lost by this. >>>>>>>> >>>>>>>> >>>>>>>> 1. The client enterprise can still send its internal ID as part of >>>>>>>> the resource body, inside some attribute defined by them (but not = defined >>>>>>>> by the protocol). Let's say they call it 'myID'. >>>>>>>> >>>>>>>> 2. The client enterprise can search for resource URIs using any >>>>>>>> attribute, including this internal ID >>>>>>>> >>>>>>>> 'GET /Users?myID=3Dbjensen' >>>>>>>> >>>>>>>> Since myID is a candidate key, the server will return exactly one >>>>>>>> URI, which is the canonical URI for the resource >>>>>>>> >>>>>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>>>>> >>>>>>>> 3. The client can use this URI to perform all other operations as = usual. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So taking 'externalID' out of the protocol spec only does this: >>>>>>>> >>>>>>>> 1. It avoids enshrining tight coupling in the protocol (If clients= want to tightly couple themselves to the cloud provider by sending their i= nternal IDs, they can do so. Suicide is OK, but the protocol should not be = guilty of assisted suicide. ;-) >>>>>>>> >>>>>>>> 2. It encourages loose coupling by nudging clients towards maintai= ning their own internal-to-external identifier mappings. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That's what I'd like to see. I don't believe this complicates the = protocol. It simplifies it and it also lends itself to a loosely-coupled ap= proach. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'll address the multi-valued attribute suggestion separately. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ganesh >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad < >>>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>>> >>>>>>>> > storing this information in a mapping table outside of the >>>>>>>> SCIM spec is a great way to enable this solution. Part of the key= here is >>>>>>>> that SCIM is just a piece of the architecture for this solution, a= nd is >>>>>>>> only responsible for the transport layer between domains. >>>>>>>> >>>>>>>> I wasn't suggesting that the mapping table be part of the SCIM >>>>>>>> spec. I provided that example to illustrate that splitting and mer= ging >>>>>>>> identities is a common requirement, and that decoupling local iden= tifiers >>>>>>>> within a domain from shared identifiers between domains was the be= st way to >>>>>>>> facilitate it. >>>>>>>> >>>>>>>> >>>>>>>> I'm suggesting that the spec do less, not more. >>>>>>>> >>>>>>>> >>>>>>>> What the SCIM spec needs to do there is just refrain from >>>>>>>> introducing tight coupling. I would like to see a single identifie= r exposed >>>>>>>> through the API, with the implication (and perhaps the recommendat= ion) that >>>>>>>> it be the shared one. Allowing one domain to expose its internal i= dentifier >>>>>>>> to the other creates tight coupling and ensures that both domains = need >>>>>>>> simultaneously split or merge identities, which is not desirable. = So I >>>>>>>> recommend _taking out_ the "external id" field from the API. The s= pec >>>>>>>> shouldn't encourage tight coupling. If clients want to pass in the= ir >>>>>>>> internal ids as part of the resource body, no one can stop them, a= nd they >>>>>>>> can always do a search on that attribute to retrieve the URI exact= ly as you >>>>>>>> visualise they will with the "external id", but let's not elevate = an >>>>>>>> anti-pattern to a recommendation by enshrining the "external id" a= s an >>>>>>>> acceptable attribute. >>>>>>>> >>>>>>>> >>>>>>>> Am I making sense? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I see what you are saying. I think scim gets its current simplicit= y >>>>>>>> from its single owner hub spoke model implementing tight coupling. >>>>>>>> >>>>>>>> >>>>>>>> IMHO loose coupling is a much more complex solution. The reality i= s >>>>>>>> that each end-point has value to contribute and thus the single-ow= ner model >>>>>>>> will eventually need to become multi-owner or multi-hub. >>>>>>>> >>>>>>>> >>>>>>>> That said i think the current model provides a practical starting >>>>>>>> point. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > Regarding unique identifiers for multi-valued attributes there >>>>>>>> is a trade-off involved. On one hand this makes PATCH semantics e= asier. >>>>>>>> On the other hand it puts extra burden on service providers. >>>>>>>> >>>>>>>> >>>>>>>> Precisely. The spec has to strike the right balance. It would be >>>>>>>> interesting to hear from the other members of the spec mailing lis= t. You >>>>>>>> know where I stand on this. It would be good to hear the spectrum = of >>>>>>>> opinions. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Ganesh >>>>>>>> >>>>>>>> On 10 August 2012 00:28, Kelly Grizzle >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks Emmanuel. I had started writing up a similar response. As >>>>>>>> you suggest, storing this information in a mapping table outside o= f the >>>>>>>> SCIM spec is a great way to enable this solution. Part of the key= here is >>>>>>>> that SCIM is just a piece of the architecture for this solution, a= nd is >>>>>>>> only responsible for the transport layer between domains. >>>>>>>> >>>>>>>> >>>>>>>> You could also model these ID mappings in the SCIM user as an >>>>>>>> extension but would probably not want to expose these externally. = Here is >>>>>>>> an example of how to model the end state of the false positive sce= nario >>>>>>>> (splitting a user): >>>>>>>> >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>>> true | >>>>>>>> >>>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>>>>> true | >>>>>>>> >>>>>>>> >>>>>>>> This could be represented as two SCIM users that contain >>>>>>>> information about the entities on other domains. >>>>>>>> >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>> >>>>>>>> "id": "9caf78aac3d6", >>>>>>>> >>>>>>>> "userName": "John Smith", >>>>>>>> >>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>> >>>>>>>> "linkedUsers": [ >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "domain": "D2", >>>>>>>> >>>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> ] >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>> >>>>>>>> "id": "a99a5feba839", >>>>>>>> >>>>>>>> "userName": "John Smith", >>>>>>>> >>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>> >>>>>>>> "linkedUsers": [ >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "domain": "D2", >>>>>>>> >>>>>>>> "externalEntityId": "7a87f27c1dd8" >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> ] >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> In the second user, the linkedUsers attribute would be empty until >>>>>>>> the split user was synced to domain 2. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Similarly, the false negative use case (merging two users) looked >>>>>>>> like this at the end: >>>>>>>> >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>>> true | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>>>>> false | >>>>>>>> >>>>>>>> >>>>>>>> This could be represented with the following SCIM user: >>>>>>>> >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>> >>>>>>>> "id": "9caf78aac3d6", >>>>>>>> >>>>>>>> "userName": "John Smith", >>>>>>>> >>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>> >>>>>>>> "linkedUsers": [ >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "domain": "D2", >>>>>>>> >>>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>>> >>>>>>>> }, >>>>>>>> >>>>>>>> { >>>>>>>> >>>>>>>> "domain": "D2", >>>>>>>> >>>>>>>> "externalEntityId": "41206cc97c8b", >>>>>>>> >>>>>>>> "deletionRequired": true >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> ] >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regarding unique identifiers for multi-valued attributes there is = a >>>>>>>> trade-off involved. On one hand this makes PATCH semantics easier= . On the >>>>>>>> other hand it puts extra burden on service providers. Since the i= nception >>>>>>>> of SCIM, a key goal has been to foster adoption by service provide= rs by >>>>>>>> making things fit easily onto existing systems. IMO the value gai= ned by >>>>>>>> unique identifiers for multi-valued attributes is not worth the de= mands put >>>>>>>> on a service provider. I also think that vendors that have a >>>>>>>> non-SCIM-compliant API will choose to keep things that way if the = spec is >>>>>>>> too hard for them to implement. In a green field environment we d= o have >>>>>>>> the luxury of mandating a model to make certain operations more el= egant. >>>>>>>> However, we can=92t ignore legacy systems. >>>>>>>> >>>>>>>> >>>>>>>> --Kelly >>>>>>>> >>>>>>>> >>>>>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>>>>> Behalf Of *Emmanuel Dreux >>>>>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>>>>> *Cc:* scim@ietf.org >>>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t >>>>>>>> >>>>>>>> >>>>>>>> Hi Ganesh, >>>>>>>> >>>>>>>> >>>>>>>> Nothing prevents you in your SCIM implementation (client or server= ) >>>>>>>> to generate a unique identifier for each synchronized object and m= aintain >>>>>>>> an internal mapping table ( you would have to map group membership= as well). >>>>>>>> >>>>>>>> >>>>>>>> This is what we are doing with Active Directory sources or targets= : >>>>>>>> >>>>>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid ca= n change >>>>>>>> if an AD domain is migrated), we decided to generate and maintain = an >>>>>>>> internal table of ids. This fits your requirements as it hides int= ernal ids. >>>>>>>> >>>>>>>> >>>>>>>> This was written in dotnet and we have started a project to rewrit= e >>>>>>>> our SCIM stack in PHP and will give it to the Open Source communit= y. This >>>>>>>> implementation will have a parameter : AllocateIds versus UseExist= ingIDs. >>>>>>>> >>>>>>>> This will give the choice of =93hiding=94 internalIDs or use them = as >>>>>>>> unique ID. >>>>>>>> >>>>>>>> >>>>>>>> You can also implement such feature without violating the SCIM >>>>>>>> specs, or without asking to include it in the specs. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Emmanuel Dreux >>>>>>>> >>>>>>>> http://www.cloudiway.com >>>>>>>> >>>>>>>> Tel: +33 4 26 78 17 58 >>>>>>>> >>>>>>>> Mobile: +33 6 47 81 26 70 >>>>>>>> >>>>>>>> skype: Emmanuel.Dreux >>>>>>>> >>>>>>>> >>>>>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>>>>> >>>>>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>>>>> *=C0 :* Kelly Grizzle >>>>>>>> *Cc :* scim@ietf.org >>>>>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>>> >>>>>>>> >>>>>>>> Hi Kelly, >>>>>>>> >>>>>>>> Thanks for your response. Let me first respond in brief to the two >>>>>>>> main points you have made, and then elaborate on the first. >>>>>>>> >>>>>>>> 1. Why should domains not expose their internal identifiers >>>>>>>> to other domains? >>>>>>>> >>>>>>>> a. >>>>>>>> >>>>>>>> We are designing a protocol for a federated system of domains, >>>>>>>> where all domains are co-equal peers. (In physics too, N-body prob= lems are >>>>>>>> much harder than 2-body problems. :-) Therefore, assuming that the= re are >>>>>>>> only two players in the interaction makes this tightly coupled in = a number >>>>>>>> of ways. We should rely on messaging and notification, with encaps= ulation >>>>>>>> of domain-specific data. >>>>>>>> >>>>>>>> b. >>>>>>>> >>>>>>>> In any non-trivial data store, there will always be the ongoing >>>>>>>> need to merge and split identities as and when =93false negatives= =94 and =93false >>>>>>>> positives=94 are discovered. A domain should be able to handle thi= s internal >>>>>>>> housekeeping freely, only notifying other domains when convenient.= Mapping >>>>>>>> of internal identifiers to external ones and maintaining this mapp= ing >>>>>>>> internally allows this loosely-coupled housekeeping to take place.= Sharing >>>>>>>> internal identifiers (or otherwise outsourcing the mapping of inte= rnal to >>>>>>>> external identifiers) forces housekeeping activities to be done in >>>>>>>> lock-step across domains. >>>>>>>> >>>>>>>> c. >>>>>>>> >>>>>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>>>>> protocol which can be designed later. The data model plays a cruci= al role >>>>>>>> in enabling or constraining such interaction. A tightly-coupled da= ta model >>>>>>>> will force the use of synchronous interactions, and the exposure o= f >>>>>>>> internal identifiers is a key part of this tight coupling. >>>>>>>> >>>>>>>> 2. The difficulty of assigning unique identifiers to the individua= l >>>>>>>> values of multi-valued attributes: >>>>>>>> >>>>>>>> a. >>>>>>>> >>>>>>>> I'm not belittling the effort involved in migrating legacy data >>>>>>>> stores to such a model. However, in the larger historical context = of >>>>>>>> cross-domain identity management, we are really at the very early = stages. >>>>>>>> If a relatively new discipline and a brand new spec are held capti= ve to >>>>>>>> legacy considerations, we are losing an opportunity to provide a c= lean and >>>>>>>> elegant model to subsequent users of the spec, and this will have >>>>>>>> repercussions over many years or even decades. >>>>>>>> >>>>>>>> b. >>>>>>>> >>>>>>>> If incumbent cloud providers find it hard to immediately adopt the >>>>>>>> dictionary model for existing multi-valued attributes, they can tr= ansition >>>>>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SCI= M-compliant=94 >>>>>>>> APIs to their customers and encouraging new customers to adopt the >>>>>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using = a >>>>>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and gr= adually >>>>>>>> migrated to the SCIM-compliant API. The logistics are not insurmou= ntable, >>>>>>>> and shouldn't prevent the adoption of a dictionary model for multi= -valued >>>>>>>> attributes. >>>>>>>> >>>>>>>> Elaboration of Point 1: >>>>>>>> >>>>>>>> When we consider federated identity across more than one domain, w= e >>>>>>>> have to assume that domains are not necessarily master-slave in th= eir >>>>>>>> interaction. The most generic interaction model is peer-to-peer, w= here >>>>>>>> entity lifecycle events within a domain are notified to other doma= ins (when >>>>>>>> necessary) in an asynchronous manner (i.e., through messaging) and= the >>>>>>>> other domains are free to respond to these events in an appropriat= e manner >>>>>>>> and at a time of their convenience. >>>>>>>> >>>>>>>> A key set of lifecycle events for an entity is the merging and >>>>>>>> splitting of identity that is often required. >>>>>>>> >>>>>>>> The question =93Is this one entity?=94 can be answered either yes >>>>>>>> (positive) or no (negative). But sometimes, we can discover false = positives >>>>>>>> and false negatives in our data stores. >>>>>>>> >>>>>>>> Consider a case where customers sign up online, and two customers >>>>>>>> who are privacy-conscious enter fake IDs such as =93John Smith=94,= and also use >>>>>>>> the same date of birth (say, 1 Jan 1970) or similar attributes. Th= e >>>>>>>> front-end application may make an intelligent (but incorrect) gues= s that >>>>>>>> these two persons are the same, and re-assign the same identifier = to the >>>>>>>> second person. This is a false positive. They appear to be the sam= e entity, >>>>>>>> but they're actually different. When the error is discovered, the >>>>>>>> identities will need to be split, with a new identifier generated = for one >>>>>>>> of them. >>>>>>>> >>>>>>>> Consider the opposite case where a customer signs up through two >>>>>>>> different portals or in two different sessions, using the names = =93JSmith=94 >>>>>>>> and =93JohnS=94. It is very likely that they will be treated as tw= o different >>>>>>>> customers and assigned two unique identifiers. This is a false neg= ative. >>>>>>>> They appear to be two entities, but are actually the same. At a la= ter >>>>>>>> stage, when the error is discovered, the identities will have to b= e merged, >>>>>>>> and one of the identifiers will have to be dropped. >>>>>>>> >>>>>>>> These are not theoretical use cases. They form a significant >>>>>>>> proportion of the user base in most large Web-facing applications.= Let's >>>>>>>> see how these can be managed in a federated way by mapping interna= l >>>>>>>> identifiers to external ones and only exposing external identifier= s to >>>>>>>> other domains. >>>>>>>> >>>>>>>> a. False positives: >>>>>>>> >>>>>>>> Domain 1 has the following information about a customer in its dat= a >>>>>>>> store: >>>>>>>> >>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>> >>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>> >>>>>>>> When requesting the provisioning of this entity in Domain 2, the >>>>>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>>>>> >>>>>>>> Domain 1 then maintains the following in a mapping table and uses >>>>>>>> it for translation when talking to Domain 2, taking care never to = expose >>>>>>>> its internal identifier: >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>> >>>>>>>> When the false positive is discovered and the entity is split, >>>>>>>> Domain 1 creates a new internal identifier and now has the followi= ng entity >>>>>>>> information. >>>>>>>> >>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>> >>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>> >>>>>>>> Internal ID: a99a5feba839 >>>>>>>> >>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>> >>>>>>>> This second entity with its own internal identifier is invisible t= o >>>>>>>> Domain 2, and this is by design. Communication about the original = entity >>>>>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff487230= b3a0=94 and >>>>>>>> vice-versa. At some convenient time (importantly, this doesn't hav= e to be >>>>>>>> at the time the split happens), Domain 2 can be requested to provi= sion a >>>>>>>> second entity, and when it responds with an identifier of =937a87f= 27c1dd8=94, >>>>>>>> this can go into the mapping table as a new record associated with= the >>>>>>>> second entity's internal identifier. >>>>>>>> >>>>>>>> The mapping table now contains the following entries: >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>> >>>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>>>>> >>>>>>>> Domain 2 is not even aware that a split has happened, and the >>>>>>>> provisioning that it does is not in lockstep with the split in ide= ntity >>>>>>>> that occurred in Domain 1. >>>>>>>> >>>>>>>> (What is the =93Primary flag=94 used for? We'll see when we cover = the >>>>>>>> treatment of false negatives.) >>>>>>>> >>>>>>>> b. False negatives: >>>>>>>> >>>>>>>> Domain 1 has the following information about what it thinks are tw= o >>>>>>>> distinct customers in its data store: >>>>>>>> >>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>> >>>>>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>>>>> >>>>>>>> Internal ID: 273d36e30d09 >>>>>>>> >>>>>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>>>>> >>>>>>>> When requesting the provisioning of these entities in Domain 2, th= e >>>>>>>> following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97= c8b. >>>>>>>> >>>>>>>> Domain 1 then maintains the following in a mapping table and uses >>>>>>>> it for translation when talking to Domain 2, taking care never to = expose >>>>>>>> its internal identifiers: >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>> >>>>>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>>>>> >>>>>>>> When the false negative is discovered and the two entities are >>>>>>>> merged, Domain 1 drops one of the internal identifiers and rationa= lises the >>>>>>>> name of the customer (say, to =93John Smith=94). Let's say it reta= ins the first >>>>>>>> ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>>>>> >>>>>>>> The mapping table now looks like this: >>>>>>>> >>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>> Primary flag | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>> >>>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>>>>> >>>>>>>> Now two external identifiers map to the same internal one, so >>>>>>>> inbound communication from Domain 2 can be unambi >>>>>>>> >>>>>>> _______________________________________________ >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> >>>> >>> >> > --0015175cba22a756df04c70b0fb6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 Multi-valued attributes that have a value sub-attribute can b= e removed by specifying only the value since it is unique.=A0=A0
I don't know how I let this one pass!

A JSON array is a List, not a Set. There is _no uniqueness constrain= t_ on its values, so your assumption is not justified.

If I wanted to model the medal winners of the men's 100 metre race= at the London Olympics (won by Usain Bolt and his compatriots), I might wa= nt to say:

"medallists" : [ "Jamaic= a", "Jamaica", "Jamaica" ]

Are you saying this will not be allowed by SCIM because= the values are not unique? Why not? When JSON allows it, why should SCIM o= bject?

Until now, I assumed that the spec was only= _clumsy_. If it's based on the assumption that array values are unique= , then it is _wrong_.

Regards,
Ganesh

On 12 August 2012 15:01, Ganesh and Sashi Prasad <= ;g.c.prasad@gmail= .com> wrote:
(I'm aware that I'm pushing ver= y hard on this, and apologies if this is putting anyone off. I think it'= ;s in the best interests of the spec to have a robust (but respectful) disc= ussion.)

Nested arrays are a great example of where the simplistic approach breaks d= own. How can we specify that the first address now also has "Wi-fi&quo= t; and doesn't have the "cable" service anymore? With the cur= rent spec, we'd struggle.

These are not esoteric examples. I work for a telco and this= is stock-standard information that we need to maintain about our customers= .

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
= =A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia",
=A0 =A0 =A0 "available_services" : ["cable", "= ;ADSL"]
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0= =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "= Australia",
=A0 =A0 =A0 "available_services: ["ADS= L2+", "Wi-fi"]
=A0 =A0 }
=A0 ]
}

Here= 9;s how I believe it should be done:

PATCH /U= sers

{
=A0 "operations" : [
=A0 =A0 {
=A0 =A0 =A0 "INCLUDE" : {
=A0 =A0 = =A0 =A0 "key" : "addresses.d6ea365462f5.available_services&q= uot;,
=A0 =A0 =A0 =A0 "value" : "Wi-fi"
=
=A0 =A0 =A0 },
=A0 =A0 =A0 "RETIRE" : {
=A0 =A0 =A0 =A0 "key"= ; : "addresses.d6ea365462f5.available_services.9be6378dc303"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 ]
}

because the resource structure would be like this:

{
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f5" :
=A0 =A0 {
=A0 = =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 = =A0 =A0 "street-name" : "High Road",
= =A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia= ",
=A0 =A0 =A0 "available_services" : {
=A0 =A0 =A0 =A0 "9be6378dc303" : "cable",=A0
=
=A0 =A0 =A0 =A0 "6aa1429eba34" : "ADSL"
=A0 =A0 =A0 }
=A0 =A0 },
=A0 =A0 &quo= t;3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 &q= uot;street-number" : "213",
=A0 =A0 =A0 "stre= et-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia",
=A0 =A0 =A0 "available_services: {
=A0 =A0 =A0 =A0 &quo= t;2beca1fdf3e5" : "ADSL2+",=A0
=A0 =A0 =A0 =A0 &qu= ot;8c3dcc204a33" : "Wi-fi"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 }
}

I think nested arrays are the clinche= r in favour of the unique-key-per-value approach. The difference of opinion= is then just whether you think nested arrays are a common occurrence or no= t. I've just provided an example from my current industry where it is.<= /div>

Regards,
Ganesh
<= br>
On 12 August 2012 14:28, Ganesh and Sashi Pra= sad <g.c.prasad@gmail.com> wrote:
>=A0 It j= ust comes down to a difference of opinion.=A0

Yes, but do consider that the unique key approach allows uniformity of t= reatment regardless of level in the hierarchy for _all_ operations - add, m= odify and delete, with "modify" having three sub-elements of its = own (add attribute, modify attribute, delete attribute).=A0

INCLUDE and RETIRE (add a new dictionary element to thi= s collection, or remove the entire collection):
key =3D "add= resses"

REPLACE, FORCE and RETIRE (update or = remove one complete dictionary element in the collection):
key =3D "addresses.3cbaaff= 8e84e"

PLACE and FORCE (= introduce a new dictionary element with a pre-assigned unique key - not the= client's internal key, of course):
key =3D "addresses.7956063c59a1"

REPLACE, FORCE and RETIRE (update of the dictiona= ry element, updating or removing an _existing_ sub-element):
key =3D "addresses.3c= baaff8e84e.street-number"
key =3D "addresses.3cbaaff8e84e.street-name"
=
...
key =3D "addresses.3cbaaff8e84e.country"

=
PLAC= E and FORCE (update of the dictionary element, introducing a _new_ sub-elem= ent):
key =3D "addresses.3cbaaff8e84e.city"

=
INCLUDE (update of the dictionary element, introducing one or more= _new_ values for a multi-valued sub-element):
key = =3D=A0"addresses.3c= baaff8e84e.available-services"
= value =3D ["cable", &= quot;ADSL"]
(Thi= s in turn returns keys for the two new dictionary elements that it creates.= )

There's just one standard = syntax for all of these operations.=A0There's a bit of an initial conce= ptual hurdle for a reader of the spec to grok this approach and also a one-= time implementation hurdle for the SPs, but thereafter it's simple and = elegant.

Once again = I'd like to ask, is there any SP representative on this working group w= ho can tell us exactly what it would entail for them to implement a unique-= key-per-value scheme? I want to understand how much of a burden this really= is, because I reckon this would knock a few pages off the spec document (w= hich is another index of simplicity).

Regards,
Ganesh

On 12 August 2012 13:25, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:
>=A0how are you proposing that the following element be upda= ted if we can't use positional indexes?
<= br>
My proposal is what is= currently in the spec -=A0http://tools.ietf.org/html/draft-s= cim-api-00#section-3.3.2.

      Attr=
ibutes that do not have a value Sub-Attribute or that have a
      non-=
unique value Sub-Attribute are matched by comparing all
      Sub-=
Attribute values from the PATCH request body to the Sub-Attribute

      valu=
es of the Resource.

Another way to say this is &= quot;the whole dictionary element", which I don't believe is impra= ctical. =A0I understand your proposal and the implications of using uid for= each element vs. not. =A0It just comes down to a difference of opinion.

--Kelly

Fro= m: Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; sc= im@ietf.org

Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

That's exactly the point. How do we "specify completely for u= niqueness"?

In the example below, how are you proposing that the following element= be updated if we can't use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 ]
}

It's impractical to use the value because it's the whole dicti= onary element:

{
=A0 "type" : "office",
=A0 "street-number" : "213",
=A0 "street-name" : "Main Street",
=A0 "suburb" : "Adelaide",
=A0 "postcode" : "5000",
=A0 "state" : "SA",
=A0 "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243"

{
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 "3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 }
}

If you're proposing one mechanism for composite attributes and ano= ther mechanism for simple attributes, I would suggest that's actually m= ore complex than adopting a single mechanism that works the same way for _a= ll_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, = and having two mechanisms (depending on whether the attribute is simple or = composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but= I believe this is overblown. Is there any SP representative in this WG who= can tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued att= ributes that have a value sub-attribute can be removed by specifying only t= he value since it is unique. =A0Multi-valued attributes that don't have= a value sub-attribute (eg - address) have to specified completely for uniqueness. =A0As I have said before, I am ver= y opposed to adding a unique identifier to each element in a multi-valued c= ollection due to the burden it will put on SPs. =A0Is it elegant? =A0No. = =A0Is it functional? =A0Yes. =A0Will this non-elegance affect adoption? =A0My opinion is that adding unique keys to each element = will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element. =A0The verbs that you propose make sense= . =A0There is also a JSON Patch informational draft in the IETF that is int= eresting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-j= son-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= /div>

I'm curious if anyone else in the WG is in favor of unique i= dentifiers for every multi-valued element.

--Kelly
From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique ke= y for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuiti= ve.=A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }


You gave other examples of an attribute with an identifier that matched= that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point = of the extra indexing to support this. Just use the value as the item you w= ish to delete.

I agree, the delete value operation could be more explicit and clear in= general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>=A0 For the multi-value example you gave you = used the value as the attribute name key.=A0

Now I'm confused :-). I don't believe any of my examples ever = used a value as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key.=A0

That means a lot more complex indexing structure. Better to just say d= elete a specific value.=A0

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.= =A0

I don't believe so.

I'm adopting a model where every attribute of the resource is a ke= y-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself.=A0

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there= be new keys for each individual value, otherwise they are impossible to di= stinguish, and a positional index is inadequate. So we convert the array in= to a dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't= exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like t= hese that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing.=A0

I agree though that operations in patch could be a lot more explicit.= =A0

Eg explicitly deleting a value by saying delete or retire.=A0

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the curr= ent spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current = spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive.= =A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LD= AP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course= , so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion w= orth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issu= es, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0
=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0






On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0







I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0








I'm suggesting that the spec do less, not more.<=
/p>



=A0






What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0








Am I making sense?










=A0








I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0








IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0










=A0








That said i think the current model provides a pract=
ical starting point.=A0














=A0








>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.










=A0








Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a
 great way to enable this solution.=A0 Part of the key here is that SCIM is=
 just a piece of the architecture for this solution, and is only responsibl=
e for the transport layer between domains.


=A0




You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how
 to model the end state of the false positive scenario (splitting a user):<=
/span>




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.






=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.






=A0




=A0




Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 with the following SCIM user:


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=







=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




=A0




Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand
 it puts extra burden on service providers.=A0 Since the inception of SCIM,=
 a key goal has been to foster adoption by service providers by making thin=
gs fit easily onto existing systems.=A0 IMO the value gained by unique iden=
tifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0




--Kelly


=A0








From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0




Hi Ganesh,


=A0




Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal
 mapping table ( you would have to map group membership as well).

=A0




This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0




This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0




You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.






=A0




--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com






Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0






De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0




Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=








b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.






Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:






| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.






Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.






(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:






| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_______________________________________________

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






--0015175cba22a756df04c70b0fb6-- From g.c.prasad@gmail.com Sat Aug 11 23:42:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D68C11E808E for ; Sat, 11 Aug 2012 23:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcJGTSosU1dU for ; Sat, 11 Aug 2012 23:42:02 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 860DF11E809B for ; Sat, 11 Aug 2012 23:42:01 -0700 (PDT) Received: by bkty7 with SMTP id y7so1199599bkt.31 for ; Sat, 11 Aug 2012 23:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4yBA9VQqmbcrI8obAP7cL6I4zdf5Kjq5Fe/Bl6MdVCc=; b=diTJJcdMlP5a4CpVysDrFLBsJ+WdXwVIBtRE8CMY6EtCd6a+5R+0aq4BzU7dJuXxnI ZI3yZ/9TIw+h5MB9FGVetoOjrdANpIt4NPFMa5B3oXcAWwtfO+jSozEBXQpUFOsKcMHA t+RDTK7j4ifN57lH7yFGIxQTzQ5FHIbI/vff4BQMJd+kk4cxPkZqr8k5I9cF/qfOVqYS JZVQ4tgsv+GaUSdNMU4EfR1YyHD77jAAAYkdmMIdh/oYSIzSNAVGk1PsIMVL8fC2maKh T2zIR1KHT89gH2hIgIE9RXyRajYrJQI5wKwlEITp97EZRugill8HSyIeq8QEOGguBw9Q zPQw== Received: by 10.204.156.87 with SMTP id v23mr2947423bkw.0.1344753720432; Sat, 11 Aug 2012 23:42:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.240.12 with HTTP; Sat, 11 Aug 2012 23:41:40 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302585C@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Sun, 12 Aug 2012 16:41:40 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015175cba22d117b504c70bdf0f Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 06:42:08 -0000 --0015175cba22d117b504c70bdf0f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > > Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. Ignore my last comment. I think I understand what you're trying to say. You're describing a dictionary masquerading as an array, with the keys embedded within the values! And what you're referring to as the "value" sub-attribute is actually the "key". This is what has confused the heck out of me :-). i.e., you're talking about arrays like this: x =3D [ { "key" : "9e076b1f6f21", "a" : "1", "b" : "2"}, { "key" : "f02abe1a7f8e", "a" : "5", "b" : "6"} ] You're asking "why should we generate a new key for each element when we already have a key inside?" The answer is, we don't have to! We can turn this into a proper dictionary using the existing key, like this: x =3D { "9e076b1f6f21" : {"a" : "1", "b" : "2"}, "f02abe1a7f8e" : {"a" : "5= ", "b" : "6"} } And now we can refer to the elements using dot notation. We don't have to search inside the arrays for the attribute containing the key. If we're already planning to ask the SPs to support the above array notation, then there's no extra _implementation_ effort to support the proper dictionary notation because it's just a change of _representation_ to simplify the API. Is this more acceptable? Regards, Ganesh On 12 August 2012 15:43, Ganesh and Sashi Prasad wrot= e: > > Multi-valued attributes that have a value sub-attribute can be removed > by specifying only the value since it is unique. > > I don't know how I let this one pass! > > A JSON array is a List, not a Set. There is _no uniqueness constraint_ on > its values, so your assumption is not justified. > > If I wanted to model the medal winners of the men's 100 metre race at the > London Olympics (won by Usain Bolt and his compatriots), I might want to > say: > > "medallists" : [ "Jamaica", "Jamaica", "Jamaica" ] > > Are you saying this will not be allowed by SCIM because the values are no= t > unique? Why not? When JSON allows it, why should SCIM object? > > Until now, I assumed that the spec was only _clumsy_. If it's based on th= e > assumption that array values are unique, then it is _wrong_. > > Regards, > Ganesh > > > On 12 August 2012 15:01, Ganesh and Sashi Prasad wr= ote: > >> (I'm aware that I'm pushing very hard on this, and apologies if this is >> putting anyone off. I think it's in the best interests of the spec to ha= ve >> a robust (but respectful) discussion.) >> >> Nested arrays are a great example of where the simplistic approach break= s >> down. How can we specify that the first address now also has "Wi-fi" and >> doesn't have the "cable" service anymore? With the current spec, we'd >> struggle. >> >> These are not esoteric examples. I work for a telco and this is >> stock-standard information that we need to maintain about our customers. >> >> { >> ... >> addresses: [ >> { >> "type" : "home", >> "street-number" : "35", >> "street-name" : "High Road", >> ... >> "country" : "Australia", >> "available_services" : ["cable", "ADSL"] >> }, >> { >> "type" : "office", >> "street-number" : "213", >> "street-name" : "Main Street", >> ... >> "country" : "Australia", >> "available_services: ["ADSL2+", "Wi-fi"] >> } >> ] >> } >> >> Here's how I believe it should be done: >> >> PATCH /Users >> >> { >> "operations" : [ >> { >> "INCLUDE" : { >> "key" : "addresses.d6ea365462f5.available_services", >> "value" : "Wi-fi" >> }, >> "RETIRE" : { >> "key" : "addresses.d6ea365462f5.available_services.9be6378dc303" >> } >> } >> ] >> } >> >> because the resource structure would be like this: >> >> { >> ... >> addresses: { >> "d6ea365462f5" : >> { >> "type" : "home", >> "street-number" : "35", >> "street-name" : "High Road", >> ... >> "country" : "Australia", >> "available_services" : { >> "9be6378dc303" : "cable", >> "6aa1429eba34" : "ADSL" >> } >> }, >> "3cbaaff8e84e" : >> { >> "type" : "office", >> "street-number" : "213", >> "street-name" : "Main Street", >> ... >> "country" : "Australia", >> "available_services: { >> "2beca1fdf3e5" : "ADSL2+", >> "8c3dcc204a33" : "Wi-fi" >> } >> } >> } >> } >> >> I think nested arrays are the clincher in favour of the >> unique-key-per-value approach. The difference of opinion is then just >> whether you think nested arrays are a common occurrence or not. I've jus= t >> provided an example from my current industry where it is. >> >> Regards, >> Ganesh >> >> On 12 August 2012 14:28, Ganesh and Sashi Prasad w= rote: >> >>> > It just comes down to a difference of opinion. >>> >>> Yes, but do consider that the unique key approach allows uniformity of >>> treatment regardless of level in the hierarchy for _all_ operations - a= dd, >>> modify and delete, with "modify" having three sub-elements of its own (= add >>> attribute, modify attribute, delete attribute). >>> >>> INCLUDE and RETIRE (add a new dictionary element to this collection, or >>> remove the entire collection): >>> key =3D "addresses" >>> >>> REPLACE, FORCE and RETIRE (update or remove one complete dictionary >>> element in the collection): >>> key =3D "addresses.3cbaaff8e84e" >>> >>> PLACE and FORCE (introduce a new dictionary element with a pre-assigned >>> unique key - not the client's internal key, of course): >>> key =3D "addresses.7956063c59a1" >>> >>> REPLACE, FORCE and RETIRE (update of the dictionary element, updating o= r >>> removing an _existing_ sub-element): >>> key =3D "addresses.3cbaaff8e84e.street-number" >>> key =3D "addresses.3cbaaff8e84e.street-name" >>> ... >>> key =3D "addresses.3cbaaff8e84e.country" >>> >>> PLACE and FORCE (update of the dictionary element, introducing a _new_ >>> sub-element): >>> key =3D "addresses.3cbaaff8e84e.city" >>> >>> INCLUDE (update of the dictionary element, introducing one or more _new= _ >>> values for a multi-valued sub-element): >>> key =3D "addresses.3cbaaff8e84e.available-services" >>> value =3D ["cable", "ADSL"] >>> (This in turn returns keys for the two new dictionary elements that it >>> creates.) >>> >>> There's just one standard syntax for all of these operations. There's a >>> bit of an initial conceptual hurdle for a reader of the spec to grok th= is >>> approach and also a one-time implementation hurdle for the SPs, but >>> thereafter it's simple and elegant. >>> >>> Once again I'd like to ask, is there any SP representative on this >>> working group who can tell us exactly what it would entail for them to >>> implement a unique-key-per-value scheme? I want to understand how much = of a >>> burden this really is, because I reckon this would knock a few pages of= f >>> the spec document (which is another index of simplicity). >>> >>> Regards, >>> Ganesh >>> >>> On 12 August 2012 13:25, Kelly Grizzle wro= te: >>> >>>> > how are you proposing that the following element be updated if we >>>> can't use positional indexes? >>>> >>>> My proposal is what is currently in the spec - >>>> http://tools.ietf.org/html/draft-scim-api-00#section-3.3.2. >>>> >>>> Attributes that do not have a value Sub-Attribute or that have = a >>>> >>>> non-unique value Sub-Attribute are matched by comparing all >>>> >>>> Sub-Attribute values from the PATCH request body to the Sub-Attr= ibute >>>> >>>> values of the Resource. >>>> >>>> >>>> Another way to say this is "the whole dictionary element", which I >>>> don't believe is impractical. I understand your proposal and the >>>> implications of using uid for each element vs. not. It just comes dow= n to >>>> a difference of opinion. >>>> >>>> --Kelly >>>> >>>> ------------------------------ >>>> *From:* Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>>> *Sent:* Saturday, August 11, 2012 9:53 PM >>>> *To:* Kelly Grizzle >>>> *Cc:* Phil Hunt; scim@ietf.org >>>> >>>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >>>> >>>> > Multi-valued attributes that don't have a value sub-attribute (eg >>>> - address) have to specified completely for uniqueness. >>>> >>>> That's exactly the point. How do we "specify completely for >>>> uniqueness"? >>>> >>>> In the example below, how are you proposing that the following >>>> element be updated if we can't use positional indexes? >>>> >>>> addresses[1].street-number =3D "243" >>>> >>>> User object: >>>> >>>> { >>>> ... >>>> addresses: [ >>>> { >>>> "type" : "home", >>>> "street-number" : "35", >>>> "street-name" : "High Road", >>>> "suburb" : "East Camden", >>>> "postcode" : "5346", >>>> "state" : "SA", >>>> "country" : "Australia" >>>> }, >>>> { >>>> "type" : "office", >>>> "street-number" : "213", >>>> "street-name" : "Main Street", >>>> "suburb" : "Adelaide", >>>> "postcode" : "5000", >>>> "state" : "SA", >>>> "country" : "Australia" >>>> } >>>> ] >>>> } >>>> >>>> It's impractical to use the value because it's the whole dictionary >>>> element: >>>> >>>> { >>>> "type" : "office", >>>> "street-number" : "213", >>>> "street-name" : "Main Street", >>>> "suburb" : "Adelaide", >>>> "postcode" : "5000", >>>> "state" : "SA", >>>> "country" : "Australia" >>>> } >>>> >>>> With my proposal, the "addresses" array gets converted to a >>>> dictionary, and then we have a stable way of referencing this element: >>>> >>>> addresses.3cbaaff8e84e.street-number =3D "243" >>>> >>>> { >>>> ... >>>> addresses: { >>>> "d6ea365462f5" : >>>> { >>>> "type" : "home", >>>> "street-number" : "35", >>>> "street-name" : "High Road", >>>> "suburb" : "East Camden", >>>> "postcode" : "5346", >>>> "state" : "SA", >>>> "country" : "Australia" >>>> }, >>>> "3cbaaff8e84e" : >>>> { >>>> "type" : "office", >>>> "street-number" : "213", >>>> "street-name" : "Main Street", >>>> "suburb" : "Adelaide", >>>> "postcode" : "5000", >>>> "state" : "SA", >>>> "country" : "Australia" >>>> } >>>> } >>>> } >>>> >>>> If you're proposing one mechanism for composite attributes and >>>> another mechanism for simple attributes, I would suggest that's actual= ly >>>> more complex than adopting a single mechanism that works the same way = for >>>> _all_ attributes. Remember that a lot of the administration is probabl= y >>>> going to be scripted rather than done by hand, and having two mechanis= ms >>>> (depending on whether the attribute is simple or composite) will compl= icate >>>> every script that has to be written. >>>> >>>> There's a lot of talk about the "burden" on the SPs, but I believe >>>> this is overblown. Is there any SP representative in this WG who can t= ell >>>> us what this proposal will actually entail for them? >>>> >>>> Regards, >>>> Ganesh >>>> >>>> On 12 August 2012 11:53, Kelly Grizzle wr= ote: >>>> >>>>> Ganesh, >>>>> >>>>> This is exactly how PATCH works in SCIM 1.0. Multi-valued >>>>> attributes that have a value sub-attribute can be removed by specifyi= ng >>>>> only the value since it is unique. Multi-valued attributes that don'= t have >>>>> a value sub-attribute (eg - address) have to specified completely for >>>>> uniqueness. As I have said before, I am very opposed to adding a uni= que >>>>> identifier to each element in a multi-valued collection due to the bu= rden >>>>> it will put on SPs. Is it elegant? No. Is it functional? Yes. Wi= ll >>>>> this non-elegance affect adoption? My opinion is that adding unique = keys >>>>> to each element will have a much more detrimental effect on adoption. >>>>> >>>>> I do believe that in general PATCH can be made more intuitive >>>>> without adding uids to each element. The verbs that you propose make >>>>> sense. There is also a JSON Patch informational draft in the IETF th= at is >>>>> interesting - >>>>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It >>>>> relies on a JSON Pointer draft which uses index-based addressing for >>>>> multi-valued attributes. I think that this is something that should = be >>>>> looked at within the WG and I would be willing to lead this effort. >>>>> >>>>> I'm curious if anyone else in the WG is in favor of unique >>>>> identifiers for every multi-valued element. >>>>> >>>>> --Kelly >>>>> >>>>> ------------------------------ >>>>> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >>>>> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>>>> *Sent:* Saturday, August 11, 2012 10:50 AM >>>>> *To:* Phil Hunt >>>>> *Cc:* scim@ietf.org >>>>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24 >>>>> >>>>> Phil, >>>>> >>>>> The reason we cannot use the value itself to identify an element is >>>>> that this method will only work for simple elements, not for nested >>>>> structures. i.e., if we had an array of dictionaries (e.g., we had to >>>>> record an array of addresses for each customer, with each address ele= ment >>>>> having sub-elements like street number, street name, suburb, etc.), t= hen it >>>>> would be clumsy to supply the entire value of the array element becau= se >>>>> it's itself a dictionary. Creating a unique key for each element scal= es >>>>> better. >>>>> >>>>> Regards, >>>>> Ganesh >>>>> >>>>> On 12 August 2012 01:12, Phil Hunt wrote: >>>>> >>>>>> Ganesh, >>>>>> >>>>>> Here's the sample that concerned me... >>>>>> >>>>>> The two operations differ significantly, and it's not very intuitive= . >>>>>> With my suggestion, here's how to delete a single member from a grou= p: >>>>>> >>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.co= mAccept: application/json Authorization: Bearer h480djs93hd8 ETag: >>>>>> W/"a330bc54f0671c9" { >>>>>> "operations" : [ >>>>>> { >>>>>> "RETIRE" : { >>>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>>> } >>>>>> } >>>>>> ] } >>>>>> >>>>>> >>>>>> >>>>>> You gave other examples of an attribute with an identifier that >>>>>> matched that value or of identifiers that were additional unique key= s. >>>>>> >>>>>> Given that multi-values must be each unique, I don't see the point >>>>>> of the extra indexing to support this. Just use the value as the ite= m you >>>>>> wish to delete. >>>>>> >>>>>> I agree, the delete value operation could be more explicit and >>>>>> clear in general. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.hunt@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >>>>>> >>>>>> > For the multi-value example you gave you used the value as the >>>>>> attribute name key. >>>>>> >>>>>> Now I'm confused :-). I don't believe any of my examples ever used >>>>>> a value as the key. >>>>>> >>>>>> Could you please show me which example you mean, and which parts of >>>>>> it you believe to be the value? >>>>>> >>>>>> Regards, >>>>>> Ganesh >>>>>> >>>>>> On 11 August 2012 13:59, Phil Hunt wrote: >>>>>> >>>>>>> >>>>>>> For the multi-value example you gave you used the value as the >>>>>>> attribute name key. >>>>>>> >>>>>>> That means a lot more complex indexing structure. Better to just >>>>>>> say delete a specific value. >>>>>>> >>>>>>> The spec already allows multiple values to have tags like home, >>>>>>> work, etc. >>>>>>> >>>>>>> Phil >>>>>>> >>>>>>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad < >>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>> >>>>>>> > In your example you are conflating value with an attribute >>>>>>> id. >>>>>>> >>>>>>> I don't believe so. >>>>>>> >>>>>>> I'm adopting a model where every attribute of the resource is a >>>>>>> key-value pair. The key is a name or ID. >>>>>>> >>>>>>> For non-repeating attributes (both simple and composite), the key >>>>>>> is the attribute name itself. >>>>>>> >>>>>>> Simple attribute: >>>>>>> >>>>>>> Key: "dob" >>>>>>> Value: "01 Jan 1970" >>>>>>> >>>>>>> For composite attributes, the key employs dot notation to specify >>>>>>> the fully-qualified attribute name, e.g., "address.postcode". >>>>>>> >>>>>>> Composite attribute: >>>>>>> >>>>>>> Key: "address.street-number" >>>>>>> Value: "10" >>>>>>> >>>>>>> Key: "address.suburb" >>>>>>> Value: "East Camden" >>>>>>> >>>>>>> For repeating (multi-valued) attributes, I'm suggesting that there >>>>>>> be new keys for each individual value, otherwise they are impossibl= e to >>>>>>> distinguish, and a positional index is inadequate. So we convert th= e array >>>>>>> into a dictionary and this then becomes a composite attribute using= dot >>>>>>> notation for the key. >>>>>>> >>>>>>> Multi-valued attribute: >>>>>>> >>>>>>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>>>>>> Value: "john_smith@yahoo.com" >>>>>>> >>>>>>> So this allows us to apply uniform treatment to any arbitrarily >>>>>>> deep resource structure. We can refer to every leaf value with a ke= y that >>>>>>> is the fully-qualified name using dot notation. >>>>>>> >>>>>>> The verbs are just unambiguous operations on these (now) >>>>>>> explicitly addressable attributes. >>>>>>> >>>>>>> INCLUDE to a collection and specify only the value. The key is >>>>>>> generated and returned. The fully-qualified key is >>>>>>> . and the value is what was sp= ecified >>>>>>> in the INCLUDE. >>>>>>> >>>>>>> REPLACE a fully-qualified key with a new value. If the key doesn't >>>>>>> exist, return a "404 Not Found". >>>>>>> >>>>>>> PLACE a value at the logical location implied by the >>>>>>> fully-qualified key. If there is already a key with that name, retu= rn a >>>>>>> "409 Conflict". >>>>>>> >>>>>>> FORCE the fully-qualified key to hold the given value, regardless >>>>>>> of whether it existed before or not. Only errors possible are "400 = Bad >>>>>>> Request" and "500 Internal Error". >>>>>>> >>>>>>> RETIRE an attribute or a collection given its fully-qualified key. >>>>>>> The implementation will determine whether the attribute will disapp= ear >>>>>>> entirely or will exist holding a null value (the blank string "" or= the >>>>>>> empty object {} ). >>>>>>> >>>>>>> I'll explain in a separate post why we need operation verbs like >>>>>>> these that are independent of the HTTP verbs. >>>>>>> >>>>>>> Regards, >>>>>>> Ganesh >>>>>>> >>>>>>> On 11 August 2012 10:38, wrote: >>>>>>> >>>>>>>> If you have received this digest without all the individual messag= e >>>>>>>> attachments you will need to update your digest options in your li= st >>>>>>>> subscription. To do so, go to >>>>>>>> >>>>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>>>> >>>>>>>> Click the 'Unsubscribe or edit options' button, log in, and set "G= et >>>>>>>> MIME or Plain Text Digests?" to MIME. You can set this option >>>>>>>> globally for all the list digests you receive at this point. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Send scim mailing list submissions to >>>>>>>> scim@ietf.org >>>>>>>> >>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> https://www.ietf.org/mailman/listinfo/scim >>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>> scim-request@ietf.org >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> scim-owner@ietf.org >>>>>>>> >>>>>>>> When replying, please edit your Subject line so it is more specifi= c >>>>>>>> than "Re: Contents of scim digest..." >>>>>>>> >>>>>>>> Today's Topics: >>>>>>>> >>>>>>>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt= ) >>>>>>>> >>>>>>>> >>>>>>>> ---------- Forwarded message ---------- >>>>>>>> From: Phil Hunt >>>>>>>> To: Ganesh and Sashi Prasad >>>>>>>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>>>>>>> edreux@cloudiway.com>, Trey Drake , >>>>>>>> Kelly Grizzle , "scim@ietf.org" < >>>>>>>> scim@ietf.org> >>>>>>>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>>>>>>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>>>>>>> Ganesh, >>>>>>>> >>>>>>>> In your example you are conflating value with an attribute id. I >>>>>>>> find that confusing. >>>>>>>> >>>>>>>> I agree though that operations in patch could be a lot more >>>>>>>> explicit. >>>>>>>> >>>>>>>> Eg explicitly deleting a value by saying delete or retire. >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad < >>>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>>> >>>>>>>> > I am concerned about your second suggestion: >>>>>>>> >>>>>>>> Let's discuss that now. >>>>>>>> >>>>>>>> The trade-offs are very clear here. >>>>>>>> >>>>>>>> Pros: >>>>>>>> >>>>>>>> Pro 1. The API to manipulate resources becomes so much cleaner, >>>>>>>> consistent and intuitive when every individual attribute value get= s its own >>>>>>>> ID. >>>>>>>> >>>>>>>> Here's how to delete a single member from a Group, as per the >>>>>>>> current spec: >>>>>>>> >>>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>>>> Host: example.com >>>>>>>> Accept: application/json >>>>>>>> Authorization: Bearer h480djs93hd8 >>>>>>>> ETag: W/"a330bc54f0671c9" >>>>>>>> >>>>>>>> { >>>>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>>>> "members": [ >>>>>>>> { >>>>>>>> "display": "Babs Jensen", >>>>>>>> "value": "2819c223-7f76-453a-919d-413861904646" >>>>>>>> "operation": "delete" >>>>>>>> } >>>>>>>> ] >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> Here's how to delete ALL members from a group according to the >>>>>>>> current spec: >>>>>>>> >>>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >>>>>>>> Host: example.com >>>>>>>> Accept: application/json >>>>>>>> Authorization: Bearer h480djs93hd8 >>>>>>>> ETag: W/"a330bc54f0671c9" >>>>>>>> >>>>>>>> { >>>>>>>> "schemas": ["urn:scim:schemas:core:1.0"], >>>>>>>> "meta": { >>>>>>>> "attributes": [ >>>>>>>> "members" >>>>>>>> ] >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> The two operations differ significantly, and it's not very >>>>>>>> intuitive. >>>>>>>> With my suggestion, here's how to delete a single member from a >>>>>>>> group: >>>>>>>> >>>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: >>>>>>>> example.com Accept: application/json Authorization: Bearer >>>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" { >>>>>>>> "operations" : [ >>>>>>>> { >>>>>>>> "RETIRE" : { >>>>>>>> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>>>>>>> } >>>>>>>> } >>>>>>>> ] } >>>>>>>> Here's how I suggest deleting ALL members from a group: >>>>>>>> >>>>>>>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: >>>>>>>> example.com Accept: application/json Authorization: Bearer >>>>>>>> h480djs93hd8 ETag: W/"a330bc54f0671c9" { >>>>>>>> "operations" : [ >>>>>>>> { >>>>>>>> "RETIRE" : { >>>>>>>> "key" : "members" >>>>>>>> } >>>>>>>> } >>>>>>>> ] } >>>>>>>> >>>>>>>> I'm sure you'll agree that this is simpler, more consistent and >>>>>>>> more intuitive to a reader. >>>>>>>> >>>>>>>> Pro 2: We can apply this mechanism consistently to three areas: >>>>>>>> (a) Manipulating multi-valued attributes of a resource >>>>>>>> (b) Manipulating members of a group >>>>>>>> (c) Performing bulk operations, where we simply use HTTP verbs >>>>>>>> instead of the specialised (and semantically less ambiguous) verbs= I >>>>>>>> suggested for attributes, the "key" becomes the URI, and the "valu= e" >>>>>>>> becomes the corresponding JSON object. >>>>>>>> >>>>>>>> All of them return "207 Multi-Status" with the "results" array >>>>>>>> holding individual status codes. >>>>>>>> >>>>>>>> In the current spec, (a) and (b) are done similarly but (c) is >>>>>>>> very different. >>>>>>>> >>>>>>>> Pro 3: Adoption of the standard by clients is likely to be higher >>>>>>>> because it's simpler for them. >>>>>>>> >>>>>>>> Pro 4: New (not incumbent) cloud providers will probably find >>>>>>>> this easier to implement because they have no legacy. They will pr= obably >>>>>>>> use some form of NoSQL database and won't be constrained by the li= mitations >>>>>>>> of LDAP directories. >>>>>>>> >>>>>>>> Cons: >>>>>>>> >>>>>>>> Con 1: Incumbent cloud providers with existing data stores in a >>>>>>>> directory format (where multi-valued attributes are stored as >>>>>>>> comma-separated values under a single attribute node) will find it >>>>>>>> difficult to migrate to this model and store each attribute value = as a >>>>>>>> sub-node with its own key. This will "hinder adoption of the spec"= , which >>>>>>>> is what you fear. >>>>>>>> >>>>>>>> Have I summed up the Pros and Cons correctly? I'm biased of >>>>>>>> course, so I could have missed a Con or hyped a Pro :-). >>>>>>>> >>>>>>>> In other words, we're debating interface complexity (current spec) >>>>>>>> versus implementation complexity (my suggestion). Both can hinder = adoption >>>>>>>> of the spec by different parties. >>>>>>>> >>>>>>>> Here's what we need to discuss - Do the Pros make the suggestion >>>>>>>> worth adopting in spite of the Cons, or are the Cons so great that= it's >>>>>>>> best to leave the spec as it is? >>>>>>>> >>>>>>>> Keep in mind that a complex spec that only favours incumbent >>>>>>>> cloud providers can cut both ways. It opens the door to a simpler = interface >>>>>>>> offered by a new generation of nimbler SPs that don't have the sam= e legacy >>>>>>>> issues, and there could be an exodus of clients to these new SPs. = SCIM >>>>>>>> could end up being obsoleted very soon, because the API interface = is very >>>>>>>> complex and clumsy, as any new reader can attest. I was taken abac= k by the >>>>>>>> complexity when I saw it, which is why I was prompted to suggest s= omething >>>>>>>> simpler. >>>>>>>> >>>>>>>> This is an issue where we need the opinions of many people, and >>>>>>>> they need to state their affiliations. If most people weighing in = belong to >>>>>>>> incumbent SPs and they vote in favour of interface complexity to a= void >>>>>>>> implementation complexity, then it means the spec is not doing a g= ood job >>>>>>>> of balancing the interests of various groups. I think we should al= so poll >>>>>>>> client organisations to see what they would want. >>>>>>>> >>>>>>>> (Gartner is trusted by enterprise clients to evaluate the >>>>>>>> capabilities of vendors (SPs). I believe Gartner should take the l= ead in >>>>>>>> representing client interests in this working group rather than th= ose of >>>>>>>> incumbent vendors, which is what it seems like to me. Correct me i= f I'm >>>>>>>> being unfair.) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ganesh >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11 August 2012 01:35, Diodati,Mark wr= ote: >>>>>>>> >>>>>>>>> Hi Ganesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> I am concerned about your second suggestion: >>>>>>>>> >>>>>>>>> =932. When dealing with multi-valued attributes of a resource >>>>>>>>> (expressed as arrays in JSON), they must be converted from an arr= ay into a >>>>>>>>> dictionary with unique keys (UUIDs generated by the cloud provide= r when the >>>>>>>>> attribute is created). Without unique keys for every attribute va= lue of a >>>>>>>>> resource, manipulating it will be clumsy and inelegant.=94 >>>>>>>>> >>>>>>>>> >>>>>>>>> One of the primary reasons that SPML failed was lack of adoption >>>>>>>>> by service providers due to its complexity. Very few target appli= cations >>>>>>>>> implemented SPML. Most of the commercial provisioning systems had= an SPML >>>>>>>>> interface (either v1 or v2), but not one of them was conformant t= o the SPML >>>>>>>>> standard because of complexity. If you are interested, I will for= ward you >>>>>>>>> the research documents that discuss these problems in detail. For= SCIM to >>>>>>>>> be successful, it must be adopted by commercial target applicatio= ns (i.e., >>>>>>>>> service providers). I am confident that a requirement for unique >>>>>>>>> identifiers with multi-valued attributes will preclude its adopti= on, >>>>>>>>> because it requires major changes to the service provider=92s exi= sting >>>>>>>>> identity storage mechanisms. >>>>>>>>> >>>>>>>>> Mark >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* Trey Drake [mailto:trey.drake@unboundid.com] >>>>>>>>> *Sent:* Friday, August 10, 2012 9:51 AM >>>>>>>>> >>>>>>>>> *To:* Ganesh and Sashi Prasad >>>>>>>>> *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt >>>>>>>>> >>>>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for >>>>>>>>> improvement >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ganesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll base my comments on your latest reply (below). >>>>>>>>> >>>>>>>>> >>>>>>>>> The externalID is not part of the protocol. It is an *optional* >>>>>>>>> attribute within the *schema* specification. As for #2, the prot= ocol spec >>>>>>>>> works as you describe if "arbitrary URI parameters" equate to res= ource >>>>>>>>> attributes (Allow generic search using 'GET /Users' and arbitrary= URI >>>>>>>>> parameters). Please clarify your suggestion. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm not tracking your coupling concern. The client can search an= d >>>>>>>>> hence retrieve resources on any attribute it chooses, externalId = or >>>>>>>>> otherwise. Nothing mandates use of externalId. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> What do you mean by "candidate key"? Given >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < >>>>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>>>> >>>>>>>>> > I think scim gets its current simplicity from its single owner >>>>>>>>> hub spoke model implementing tight coupling. [...] IMHO loose cou= pling is a >>>>>>>>> much more complex solution. >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil, >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm a bit surprised that you're implying "tight coupling =3D=3D >>>>>>>>> simple" and "loose coupling =3D=3D complex". That's contrary to m= y experience. >>>>>>>>> >>>>>>>>> >>>>>>>>> When I say "loose coupling", I mean "no unnecessary dependencies"= . >>>>>>>>> Invariably, a reduction in dependencies leads to greater simplici= ty. >>>>>>>>> >>>>>>>>> >>>>>>>>> Let's not confuse reduction of dependencies in the data model wit= h >>>>>>>>> a hub-and-spokes architecture. They're entirely orthogonal aspect= s of the >>>>>>>>> solution. >>>>>>>>> >>>>>>>>> >>>>>>>>> All that my suggestion involves is, >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. Take 'external ID' out of the protocol. >>>>>>>>> >>>>>>>>> 2. Allow generic search using 'GET /Users' and arbitrary URI >>>>>>>>> parameters >>>>>>>>> >>>>>>>>> >>>>>>>>> No planned functionality is lost by this. >>>>>>>>> >>>>>>>>> >>>>>>>>> 1. The client enterprise can still send its internal ID as part o= f >>>>>>>>> the resource body, inside some attribute defined by them (but not= defined >>>>>>>>> by the protocol). Let's say they call it 'myID'. >>>>>>>>> >>>>>>>>> 2. The client enterprise can search for resource URIs using any >>>>>>>>> attribute, including this internal ID >>>>>>>>> >>>>>>>>> 'GET /Users?myID=3Dbjensen' >>>>>>>>> >>>>>>>>> Since myID is a candidate key, the server will return exactly one >>>>>>>>> URI, which is the canonical URI for the resource >>>>>>>>> >>>>>>>>> https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 >>>>>>>>> >>>>>>>>> 3. The client can use this URI to perform all other operations as= usual. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> So taking 'externalID' out of the protocol spec only does this: >>>>>>>>> >>>>>>>>> 1. It avoids enshrining tight coupling in the protocol (If client= s want to tightly couple themselves to the cloud provider by sending their = internal IDs, they can do so. Suicide is OK, but the protocol should not be= guilty of assisted suicide. ;-) >>>>>>>>> >>>>>>>>> 2. It encourages loose coupling by nudging clients towards mainta= ining their own internal-to-external identifier mappings. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> That's what I'd like to see. I don't believe this complicates the= protocol. It simplifies it and it also lends itself to a loosely-coupled a= pproach. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'll address the multi-valued attribute suggestion separately. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ganesh >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10 August 2012 07:53, Phil Hunt wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2012-08-09, at 14:14, Ganesh and Sashi Prasad < >>>>>>>>> g.c.prasad@gmail.com> wrote: >>>>>>>>> >>>>>>>>> > storing this information in a mapping table outside of the >>>>>>>>> SCIM spec is a great way to enable this solution. Part of the ke= y here is >>>>>>>>> that SCIM is just a piece of the architecture for this solution, = and is >>>>>>>>> only responsible for the transport layer between domains. >>>>>>>>> >>>>>>>>> I wasn't suggesting that the mapping table be part of the SCIM >>>>>>>>> spec. I provided that example to illustrate that splitting and me= rging >>>>>>>>> identities is a common requirement, and that decoupling local ide= ntifiers >>>>>>>>> within a domain from shared identifiers between domains was the b= est way to >>>>>>>>> facilitate it. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm suggesting that the spec do less, not more. >>>>>>>>> >>>>>>>>> >>>>>>>>> What the SCIM spec needs to do there is just refrain from >>>>>>>>> introducing tight coupling. I would like to see a single identifi= er exposed >>>>>>>>> through the API, with the implication (and perhaps the recommenda= tion) that >>>>>>>>> it be the shared one. Allowing one domain to expose its internal = identifier >>>>>>>>> to the other creates tight coupling and ensures that both domains= need >>>>>>>>> simultaneously split or merge identities, which is not desirable.= So I >>>>>>>>> recommend _taking out_ the "external id" field from the API. The = spec >>>>>>>>> shouldn't encourage tight coupling. If clients want to pass in th= eir >>>>>>>>> internal ids as part of the resource body, no one can stop them, = and they >>>>>>>>> can always do a search on that attribute to retrieve the URI exac= tly as you >>>>>>>>> visualise they will with the "external id", but let's not elevate= an >>>>>>>>> anti-pattern to a recommendation by enshrining the "external id" = as an >>>>>>>>> acceptable attribute. >>>>>>>>> >>>>>>>>> >>>>>>>>> Am I making sense? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I see what you are saying. I think scim gets its current >>>>>>>>> simplicity from its single owner hub spoke model implementing tig= ht >>>>>>>>> coupling. >>>>>>>>> >>>>>>>>> >>>>>>>>> IMHO loose coupling is a much more complex solution. The reality >>>>>>>>> is that each end-point has value to contribute and thus the singl= e-owner >>>>>>>>> model will eventually need to become multi-owner or multi-hub. >>>>>>>>> >>>>>>>>> >>>>>>>>> That said i think the current model provides a practical starting >>>>>>>>> point. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > Regarding unique identifiers for multi-valued attributes there >>>>>>>>> is a trade-off involved. On one hand this makes PATCH semantics = easier. >>>>>>>>> On the other hand it puts extra burden on service providers. >>>>>>>>> >>>>>>>>> >>>>>>>>> Precisely. The spec has to strike the right balance. It would be >>>>>>>>> interesting to hear from the other members of the spec mailing li= st. You >>>>>>>>> know where I stand on this. It would be good to hear the spectrum= of >>>>>>>>> opinions. >>>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Ganesh >>>>>>>>> >>>>>>>>> On 10 August 2012 00:28, Kelly Grizzle < >>>>>>>>> kelly.grizzle@sailpoint.com> wrote: >>>>>>>>> >>>>>>>>> Thanks Emmanuel. I had started writing up a similar response. A= s >>>>>>>>> you suggest, storing this information in a mapping table outside = of the >>>>>>>>> SCIM spec is a great way to enable this solution. Part of the ke= y here is >>>>>>>>> that SCIM is just a piece of the architecture for this solution, = and is >>>>>>>>> only responsible for the transport layer between domains. >>>>>>>>> >>>>>>>>> >>>>>>>>> You could also model these ID mappings in the SCIM user as an >>>>>>>>> extension but would probably not want to expose these externally.= Here is >>>>>>>>> an example of how to model the end state of the false positive sc= enario >>>>>>>>> (splitting a user): >>>>>>>>> >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>>>> true | >>>>>>>>> >>>>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | >>>>>>>>> true | >>>>>>>>> >>>>>>>>> >>>>>>>>> This could be represented as two SCIM users that contain >>>>>>>>> information about the entities on other domains. >>>>>>>>> >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>>> >>>>>>>>> "id": "9caf78aac3d6", >>>>>>>>> >>>>>>>>> "userName": "John Smith", >>>>>>>>> >>>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>>> >>>>>>>>> "linkedUsers": [ >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "domain": "D2", >>>>>>>>> >>>>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> ] >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>>> >>>>>>>>> "id": "a99a5feba839", >>>>>>>>> >>>>>>>>> "userName": "John Smith", >>>>>>>>> >>>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>>> >>>>>>>>> "linkedUsers": [ >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "domain": "D2", >>>>>>>>> >>>>>>>>> "externalEntityId": "7a87f27c1dd8" >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> ] >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> In the second user, the linkedUsers attribute would be empty unti= l >>>>>>>>> the split user was synced to domain 2. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Similarly, the false negative use case (merging two users) looked >>>>>>>>> like this at the end: >>>>>>>>> >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | >>>>>>>>> true | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | >>>>>>>>> false | >>>>>>>>> >>>>>>>>> >>>>>>>>> This could be represented with the following SCIM user: >>>>>>>>> >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "schemas": ["urn:scim:schemas:core:1.0", >>>>>>>>> "urn:scim:schemas:extension:federation:1.0"], >>>>>>>>> >>>>>>>>> "id": "9caf78aac3d6", >>>>>>>>> >>>>>>>>> "userName": "John Smith", >>>>>>>>> >>>>>>>>> "urn:scim:schemas:extension:federation:1.0": { >>>>>>>>> >>>>>>>>> "linkedUsers": [ >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "domain": "D2", >>>>>>>>> >>>>>>>>> "externalEntityId": "ff487230b3a0" >>>>>>>>> >>>>>>>>> }, >>>>>>>>> >>>>>>>>> { >>>>>>>>> >>>>>>>>> "domain": "D2", >>>>>>>>> >>>>>>>>> "externalEntityId": "41206cc97c8b", >>>>>>>>> >>>>>>>>> "deletionRequired": true >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> ] >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Regarding unique identifiers for multi-valued attributes there is >>>>>>>>> a trade-off involved. On one hand this makes PATCH semantics eas= ier. On >>>>>>>>> the other hand it puts extra burden on service providers. Since = the >>>>>>>>> inception of SCIM, a key goal has been to foster adoption by serv= ice >>>>>>>>> providers by making things fit easily onto existing systems. IMO= the value >>>>>>>>> gained by unique identifiers for multi-valued attributes is not w= orth the >>>>>>>>> demands put on a service provider. I also think that vendors tha= t have a >>>>>>>>> non-SCIM-compliant API will choose to keep things that way if the= spec is >>>>>>>>> too hard for them to implement. In a green field environment we = do have >>>>>>>>> the luxury of mandating a model to make certain operations more e= legant. >>>>>>>>> However, we can=92t ignore legacy systems. >>>>>>>>> >>>>>>>>> >>>>>>>>> --Kelly >>>>>>>>> >>>>>>>>> >>>>>>>>> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On >>>>>>>>> Behalf Of *Emmanuel Dreux >>>>>>>>> *Sent:* Thursday, August 09, 2012 3:18 AM >>>>>>>>> *To:* Ganesh and Sashi Prasad; Kelly Grizzle >>>>>>>>> *Cc:* scim@ietf.org >>>>>>>>> *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for >>>>>>>>> improvement >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Ganesh, >>>>>>>>> >>>>>>>>> >>>>>>>>> Nothing prevents you in your SCIM implementation (client or >>>>>>>>> server) to generate a unique identifier for each synchronized obj= ect and >>>>>>>>> maintain an internal mapping table ( you would have to map group = membership >>>>>>>>> as well). >>>>>>>>> >>>>>>>>> >>>>>>>>> This is what we are doing with Active Directory sources or target= s: >>>>>>>>> >>>>>>>>> As we didn=92t find an immutable uniqueID in AD systems >>>>>>>>> (DN,samAccountName, UPN) are subject to change (even objectGuid c= an change >>>>>>>>> if an AD domain is migrated), we decided to generate and maintain= an >>>>>>>>> internal table of ids. This fits your requirements as it hides in= ternal ids. >>>>>>>>> >>>>>>>>> >>>>>>>>> This was written in dotnet and we have started a project to >>>>>>>>> rewrite our SCIM stack in PHP and will give it to the Open Source >>>>>>>>> community. This implementation will have a parameter : AllocateId= s versus >>>>>>>>> UseExistingIDs. >>>>>>>>> >>>>>>>>> This will give the choice of =93hiding=94 internalIDs or use them= as >>>>>>>>> unique ID. >>>>>>>>> >>>>>>>>> >>>>>>>>> You can also implement such feature without violating the SCIM >>>>>>>>> specs, or without asking to include it in the specs. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Emmanuel Dreux >>>>>>>>> >>>>>>>>> http://www.cloudiway.com >>>>>>>>> >>>>>>>>> Tel: +33 4 26 78 17 58 >>>>>>>>> >>>>>>>>> Mobile: +33 6 47 81 26 70 >>>>>>>>> >>>>>>>>> skype: Emmanuel.Dreux >>>>>>>>> >>>>>>>>> >>>>>>>>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>>>>>>>> >>>>>>>>> *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 >>>>>>>>> *=C0 :* Kelly Grizzle >>>>>>>>> *Cc :* scim@ietf.org >>>>>>>>> *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Kelly, >>>>>>>>> >>>>>>>>> Thanks for your response. Let me first respond in brief to the tw= o >>>>>>>>> main points you have made, and then elaborate on the first. >>>>>>>>> >>>>>>>>> 1. Why should domains not expose their internal identifiers >>>>>>>>> to other domains? >>>>>>>>> >>>>>>>>> a. >>>>>>>>> >>>>>>>>> We are designing a protocol for a federated system of domains, >>>>>>>>> where all domains are co-equal peers. (In physics too, N-body pro= blems are >>>>>>>>> much harder than 2-body problems. :-) Therefore, assuming that th= ere are >>>>>>>>> only two players in the interaction makes this tightly coupled in= a number >>>>>>>>> of ways. We should rely on messaging and notification, with encap= sulation >>>>>>>>> of domain-specific data. >>>>>>>>> >>>>>>>>> b. >>>>>>>>> >>>>>>>>> In any non-trivial data store, there will always be the ongoing >>>>>>>>> need to merge and split identities as and when =93false negatives= =94 and =93false >>>>>>>>> positives=94 are discovered. A domain should be able to handle th= is internal >>>>>>>>> housekeeping freely, only notifying other domains when convenient= . Mapping >>>>>>>>> of internal identifiers to external ones and maintaining this map= ping >>>>>>>>> internally allows this loosely-coupled housekeeping to take place= . Sharing >>>>>>>>> internal identifiers (or otherwise outsourcing the mapping of int= ernal to >>>>>>>>> external identifiers) forces housekeeping activities to be done i= n >>>>>>>>> lock-step across domains. >>>>>>>>> >>>>>>>>> c. >>>>>>>>> >>>>>>>>> Asynchronous interaction is not just a matter of a suitable wire >>>>>>>>> protocol which can be designed later. The data model plays a cruc= ial role >>>>>>>>> in enabling or constraining such interaction. A tightly-coupled d= ata model >>>>>>>>> will force the use of synchronous interactions, and the exposure = of >>>>>>>>> internal identifiers is a key part of this tight coupling. >>>>>>>>> >>>>>>>>> 2. The difficulty of assigning unique identifiers to the >>>>>>>>> individual values of multi-valued attributes: >>>>>>>>> >>>>>>>>> a. >>>>>>>>> >>>>>>>>> I'm not belittling the effort involved in migrating legacy data >>>>>>>>> stores to such a model. However, in the larger historical context= of >>>>>>>>> cross-domain identity management, we are really at the very early= stages. >>>>>>>>> If a relatively new discipline and a brand new spec are held capt= ive to >>>>>>>>> legacy considerations, we are losing an opportunity to provide a = clean and >>>>>>>>> elegant model to subsequent users of the spec, and this will have >>>>>>>>> repercussions over many years or even decades. >>>>>>>>> >>>>>>>>> b. >>>>>>>>> >>>>>>>>> If incumbent cloud providers find it hard to immediately adopt th= e >>>>>>>>> dictionary model for existing multi-valued attributes, they can t= ransition >>>>>>>>> to this model by offering both =93SCIM-compliant=94 and =93non-SC= IM-compliant=94 >>>>>>>>> APIs to their customers and encouraging new customers to adopt th= e >>>>>>>>> =93SCIM-compliant=94 API. Legacy customers can be supported using= a >>>>>>>>> =93non-SCIM-compliant=94 API for an arbitrarily long period and g= radually >>>>>>>>> migrated to the SCIM-compliant API. The logistics are not insurmo= untable, >>>>>>>>> and shouldn't prevent the adoption of a dictionary model for mult= i-valued >>>>>>>>> attributes. >>>>>>>>> >>>>>>>>> Elaboration of Point 1: >>>>>>>>> >>>>>>>>> When we consider federated identity across more than one domain, >>>>>>>>> we have to assume that domains are not necessarily master-slave i= n their >>>>>>>>> interaction. The most generic interaction model is peer-to-peer, = where >>>>>>>>> entity lifecycle events within a domain are notified to other dom= ains (when >>>>>>>>> necessary) in an asynchronous manner (i.e., through messaging) an= d the >>>>>>>>> other domains are free to respond to these events in an appropria= te manner >>>>>>>>> and at a time of their convenience. >>>>>>>>> >>>>>>>>> A key set of lifecycle events for an entity is the merging and >>>>>>>>> splitting of identity that is often required. >>>>>>>>> >>>>>>>>> The question =93Is this one entity?=94 can be answered either yes >>>>>>>>> (positive) or no (negative). But sometimes, we can discover false= positives >>>>>>>>> and false negatives in our data stores. >>>>>>>>> >>>>>>>>> Consider a case where customers sign up online, and two customers >>>>>>>>> who are privacy-conscious enter fake IDs such as =93John Smith=94= , and also use >>>>>>>>> the same date of birth (say, 1 Jan 1970) or similar attributes. T= he >>>>>>>>> front-end application may make an intelligent (but incorrect) gue= ss that >>>>>>>>> these two persons are the same, and re-assign the same identifier= to the >>>>>>>>> second person. This is a false positive. They appear to be the sa= me entity, >>>>>>>>> but they're actually different. When the error is discovered, the >>>>>>>>> identities will need to be split, with a new identifier generated= for one >>>>>>>>> of them. >>>>>>>>> >>>>>>>>> Consider the opposite case where a customer signs up through two >>>>>>>>> different portals or in two different sessions, using the names = =93JSmith=94 >>>>>>>>> and =93JohnS=94. It is very likely that they will be treated as t= wo different >>>>>>>>> customers and assigned two unique identifiers. This is a false ne= gative. >>>>>>>>> They appear to be two entities, but are actually the same. At a l= ater >>>>>>>>> stage, when the error is discovered, the identities will have to = be merged, >>>>>>>>> and one of the identifiers will have to be dropped. >>>>>>>>> >>>>>>>>> These are not theoretical use cases. They form a significant >>>>>>>>> proportion of the user base in most large Web-facing applications= . Let's >>>>>>>>> see how these can be managed in a federated way by mapping intern= al >>>>>>>>> identifiers to external ones and only exposing external identifie= rs to >>>>>>>>> other domains. >>>>>>>>> >>>>>>>>> a. False positives: >>>>>>>>> >>>>>>>>> Domain 1 has the following information about a customer in its >>>>>>>>> data store: >>>>>>>>> >>>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>>> >>>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>>> >>>>>>>>> When requesting the provisioning of this entity in Domain 2, the >>>>>>>>> following ID is returned by Domain 2: ff487230b3a0. >>>>>>>>> >>>>>>>>> Domain 1 then maintains the following in a mapping table and uses >>>>>>>>> it for translation when talking to Domain 2, taking care never to= expose >>>>>>>>> its internal identifier: >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>>> >>>>>>>>> When the false positive is discovered and the entity is split, >>>>>>>>> Domain 1 creates a new internal identifier and now has the follow= ing entity >>>>>>>>> information. >>>>>>>>> >>>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>>> >>>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>>> >>>>>>>>> Internal ID: a99a5feba839 >>>>>>>>> >>>>>>>>> Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94} >>>>>>>>> >>>>>>>>> This second entity with its own internal identifier is invisible >>>>>>>>> to Domain 2, and this is by design. Communication about the origi= nal entity >>>>>>>>> takes place as before by mapping =939caf78aac3d6=94 to =93ff48723= 0b3a0=94 and >>>>>>>>> vice-versa. At some convenient time (importantly, this doesn't ha= ve to be >>>>>>>>> at the time the split happens), Domain 2 can be requested to prov= ision a >>>>>>>>> second entity, and when it responds with an identifier of =937a87= f27c1dd8=94, >>>>>>>>> this can go into the mapping table as a new record associated wit= h the >>>>>>>>> second entity's internal identifier. >>>>>>>>> >>>>>>>>> The mapping table now contains the following entries: >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>>> >>>>>>>>> | a99a5feba839 | D2 | 7a87f27c1dd8 | true | >>>>>>>>> >>>>>>>>> Domain 2 is not even aware that a split has happened, and the >>>>>>>>> provisioning that it does is not in lockstep with the split in id= entity >>>>>>>>> that occurred in Domain 1. >>>>>>>>> >>>>>>>>> (What is the =93Primary flag=94 used for? We'll see when we cover= the >>>>>>>>> treatment of false negatives.) >>>>>>>>> >>>>>>>>> b. False negatives: >>>>>>>>> >>>>>>>>> Domain 1 has the following information about what it thinks are >>>>>>>>> two distinct customers in its data store: >>>>>>>>> >>>>>>>>> Internal ID: 9caf78aac3d6 >>>>>>>>> >>>>>>>>> Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94} >>>>>>>>> >>>>>>>>> Internal ID: 273d36e30d09 >>>>>>>>> >>>>>>>>> Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94} >>>>>>>>> >>>>>>>>> When requesting the provisioning of these entities in Domain 2, >>>>>>>>> the following IDs are returned by Domain 2: ff487230b3a0 and 4120= 6cc97c8b. >>>>>>>>> >>>>>>>>> Domain 1 then maintains the following in a mapping table and uses >>>>>>>>> it for translation when talking to Domain 2, taking care never to= expose >>>>>>>>> its internal identifiers: >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>>> >>>>>>>>> | 273d36e30d09 | D2 | 41206cc97c8b | true | >>>>>>>>> >>>>>>>>> When the false negative is discovered and the two entities are >>>>>>>>> merged, Domain 1 drops one of the internal identifiers and ration= alises the >>>>>>>>> name of the customer (say, to =93John Smith=94). Let's say it ret= ains the first >>>>>>>>> ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94. >>>>>>>>> >>>>>>>>> The mapping table now looks like this: >>>>>>>>> >>>>>>>>> | Internal Entity ID | External Domain ID | External Entity ID | >>>>>>>>> Primary flag | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | ff487230b3a0 | true | >>>>>>>>> >>>>>>>>> | 9caf78aac3d6 | D2 | 41206cc97c8b | false | >>>>>>>>> >>>>>>>>> Now two external identifiers map to the same internal one, so >>>>>>>>> inbound communication from Domain 2 can be unambi >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --0015175cba22d117b504c70bdf0f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0 >=A0=A0Multi-valued attributes that have a value sub-attribute can be rem= oved by specifying only the value since it is unique.=A0=A0

Ignore my last comment. I think I understand what you're trying to = say.

You're describing a dictionary masquerading as = an array, with the keys embedded within the values! And what you're ref= erring to as the "value" sub-attribute is actually the "key&= quot;. This is what has confused the heck out of me :-).

i.e., you're talking about arrays like this:
<= div>
x =3D [ { "key" : "9e076b1f6f21", &q= uot;a" : "1", "b" : "2"}, {=A0"key&= quot; : "f02abe1a7f8e", "a" : "5", "b&qu= ot; : "6"} ]

You're asking "why should we generate a new ke= y for each element when we already have a key inside?"

<= /div>
The answer is, we don't have to! We can turn this into a prop= er dictionary using the existing key, like this:

x =3D { "9e076b1f6f21" : {"a" : &qu= ot;1", "b" : "2"}, "f02abe1a7f8e" : {&qu= ot;a" : "5", "b" : "6"} }

And now we can refer to the elements using dot notation. We don&= #39;t have to search inside the arrays for the attribute containing the key= .

If we're already planning to ask the SPs to = support the above array notation, then there's no extra _implementation= _ effort to support the proper dictionary notation because it's just a = change of _representation_ to simplify the API.

Is this more acceptable?

Regar= ds,
Ganesh

On 12 August = 2012 15:43, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
>=A0 Multi-valued attribu= tes that have a value sub-attribute can be removed by specifying only the v= alue since it is unique.=A0=A0

I don't know how I let this one pass!
A JSON array is a List, not a Set. There is _no uniqueness con= straint_ on its values, so your assumption is not justified.

If I wanted to model the medal winners of the men's 100 metre race= at the London Olympics (won by Usain Bolt and his compatriots), I might wa= nt to say:

"medallists" : [ "Jamaic= a", "Jamaica", "Jamaica" ]

Are you saying this will not be allowed by SCIM because= the values are not unique? Why not? When JSON allows it, why should SCIM o= bject?

Until now, I assumed that the spec was only= _clumsy_. If it's based on the assumption that array values are unique= , then it is _wrong_.

Regards,
Ganesh

On 12 August 2012 15:01, Ganesh and Sashi Prasa= d <g.c.prasad@gmail.com> wrote:
(I'm aware that I'm pushing ver= y hard on this, and apologies if this is putting anyone off. I think it'= ;s in the best interests of the spec to have a robust (but respectful) disc= ussion.)

Nested arrays are a great example of where the simplistic approach breaks d= own. How can we specify that the first address now also has "Wi-fi&quo= t; and doesn't have the "cable" service anymore? With the cur= rent spec, we'd struggle.

These are not esoteric examples. I work for a telco and this= is stock-standard information that we need to maintain about our customers= .

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
= =A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia",
=A0 =A0 =A0 "available_services" : ["cable", "= ;ADSL"]
=A0 =A0 },
=A0 =A0 {
=A0 = =A0 =A0 "type" : "office",
=A0 =A0 =A0 "= street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "= Australia",
=A0 =A0 =A0 "available_services: ["ADS= L2+", "Wi-fi"]
=A0 =A0 }
=A0 ]
}

Here= 9;s how I believe it should be done:

PATCH /U= sers

{
=A0 "operations" : [
=A0 =A0 {
=A0 =A0 =A0 "INCLUDE" : {
=A0 =A0 = =A0 =A0 "key" : "addresses.d6ea365462f5.available_services&q= uot;,
=A0 =A0 =A0 =A0 "value" : "Wi-fi"
=
=A0 =A0 =A0 },
=A0 =A0 =A0 "RETIRE" : {
=A0 =A0 =A0 =A0 "key"= ; : "addresses.d6ea365462f5.available_services.9be6378dc303"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 ]
}

because the resource structure would be like this:

{
=A0 ...
=A0 addresses: {
=A0 =A0= "d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "= ;type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 = =A0 =A0 "street-name" : "High Road",
= =A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia= ",
=A0 =A0 =A0 "available_services" : {
=A0 =A0 =A0 =A0 "9be6378dc303" : "cable",=A0
=
=A0 =A0 =A0 =A0 "6aa1429eba34" : "ADSL"
=
=A0 =A0 =A0 }
=A0 =A0 },
=A0 =A0 "3cbaaff8e84= e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 &q= uot;street-number" : "213",
=A0 =A0 =A0 "stre= et-name" : "Main Street",
=A0 =A0 =A0 ...
=A0 =A0 =A0 "country" : "Australia",
=A0 =A0 =A0 "available_services: {
=A0 =A0 =A0 =A0 &quo= t;2beca1fdf3e5" : "ADSL2+",=A0
=A0 =A0 =A0 =A0 &qu= ot;8c3dcc204a33" : "Wi-fi"
=A0 =A0 =A0 }
=A0 =A0 }
=A0 }
}

I think nested arrays are the clinche= r in favour of the unique-key-per-value approach. The difference of opinion= is then just whether you think nested arrays are a common occurrence or no= t. I've just provided an example from my current industry where it is.<= /div>

Regards,
Ganesh

On 12 August 2012 14:28, Ganesh and Sashi Prasad <g.c.= prasad@gmail.com> wrote:
>=A0 It j= ust comes down to a difference of opinion.=A0

Yes, but do consider that the unique key approach allows uniformity of t= reatment regardless of level in the hierarchy for _all_ operations - add, m= odify and delete, with "modify" having three sub-elements of its = own (add attribute, modify attribute, delete attribute).=A0

INCLUDE and RETIRE (add a new dictionary element to thi= s collection, or remove the entire collection):
key =3D "add= resses"

REPLACE, FORCE and RETIRE (update or = remove one complete dictionary element in the collection):
key =3D "addresses.3cbaaff= 8e84e"

PLACE and FORCE (= introduce a new dictionary element with a pre-assigned unique key - not the= client's internal key, of course):
key =3D "addresses.7956063c59a1"

REPLACE, FORCE and RETIRE (update of the dictiona= ry element, updating or removing an _existing_ sub-element):
key =3D "addresses.3c= baaff8e84e.street-number"
key =3D "addresses.3cbaaff8e84e.street-name"
=
...
key =3D "addresses.3cbaaff8e84e.country"

=
PLAC= E and FORCE (update of the dictionary element, introducing a _new_ sub-elem= ent):
key =3D "addresses.3cbaaff8e84e.city"

=
INCLUDE (update of the dictionary element, introducing one or more= _new_ values for a multi-valued sub-element):
key = =3D=A0"addresses.3c= baaff8e84e.available-services"
= value =3D ["cable", &= quot;ADSL"]
(Thi= s in turn returns keys for the two new dictionary elements that it creates.= )

There's just one standard = syntax for all of these operations.=A0There's a bit of an initial conce= ptual hurdle for a reader of the spec to grok this approach and also a one-= time implementation hurdle for the SPs, but thereafter it's simple and = elegant.

Once again = I'd like to ask, is there any SP representative on this working group w= ho can tell us exactly what it would entail for them to implement a unique-= key-per-value scheme? I want to understand how much of a burden this really= is, because I reckon this would knock a few pages off the spec document (w= hich is another index of simplicity).

Regards,
Ganesh

On 12 August 2012 13:25, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:
>=A0how are you proposing that the following element be upda= ted if we can't use positional indexes?
<= br>
My proposal is what is= currently in the spec -=A0http://tools.ietf.org/html/draft-s= cim-api-00#section-3.3.2.

      Attr=
ibutes that do not have a value Sub-Attribute or that have a
      non-=
unique value Sub-Attribute are matched by comparing all
      Sub-=
Attribute values from the PATCH request body to the Sub-Attribute

      valu=
es of the Resource.

Another way to say this is &= quot;the whole dictionary element", which I don't believe is impra= ctical. =A0I understand your proposal and the implications of using uid for= each element vs. not. =A0It just comes down to a difference of opinion.

--Kelly

Fro= m: Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 9:53 PM
To: Kelly Grizzle
Cc: Phil Hunt; sc= im@ietf.org

Subject: Re: [scim] scim Digest, Vol 8, Issue 24

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

That's exactly the point. How do we "specify completely for u= niqueness"?

In the example below, how are you proposing that the following element= be updated if we can't use positional indexes?

addresses[1].street-number =3D "243"

User object:

{
=A0 ...
=A0 addresses: [
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 ]
}

It's impractical to use the value because it's the whole dicti= onary element:

{
=A0 "type" : "office",
=A0 "street-number" : "213",
=A0 "street-name" : "Main Street",
=A0 "suburb" : "Adelaide",
=A0 "postcode" : "5000",
=A0 "state" : "SA",
=A0 "country" : "Australia"
}

With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element:

addresses.3cbaaff8e84e.street-number =3D "243"

{
=A0 ...
=A0 addresses: {
=A0 =A0 "d6ea365462f5" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "home",
=A0 =A0 =A0 "street-number" : "35",
=A0 =A0 =A0 "street-name" : "High Road",
=A0 =A0 =A0 "suburb" : "East Camden",
=A0 =A0 =A0 "postcode" : "5346",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 },
=A0 =A0 "3cbaaff8e84e" :
=A0 =A0 {
=A0 =A0 =A0 "type" : "office",
=A0 =A0 =A0 "street-number" : "213",
=A0 =A0 =A0 "street-name" : "Main Street",
=A0 =A0 =A0 "suburb" : "Adelaide",
=A0 =A0 =A0 "postcode" : "5000",
=A0 =A0 =A0 "state" : "SA",
=A0 =A0 =A0 "country" : "Australia"
=A0 =A0 }
=A0 }
}

If you're proposing one mechanism for composite attributes and ano= ther mechanism for simple attributes, I would suggest that's actually m= ore complex than adopting a single mechanism that works the same way for _a= ll_ attributes. Remember that a lot of the administration is probably going to be scripted rather than done by hand, = and having two mechanisms (depending on whether the attribute is simple or = composite) will complicate every script that has to be written.

There's a lot of talk about the "burden" on the SPs, but= I believe this is overblown. Is there any SP representative in this WG who= can tell us what this proposal will actually entail for them?

Regards,
Ganesh

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
Ganesh,

This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued att= ributes that have a value sub-attribute can be removed by specifying only t= he value since it is unique. =A0Multi-valued attributes that don't have= a value sub-attribute (eg - address) have to specified completely for uniqueness. =A0As I have said before, I am ver= y opposed to adding a unique identifier to each element in a multi-valued c= ollection due to the burden it will put on SPs. =A0Is it elegant? =A0No. = =A0Is it functional? =A0Yes. =A0Will this non-elegance affect adoption? =A0My opinion is that adding unique keys to each element = will have a much more detrimental effect on adoption.

I do believe that in general PATCH can be made more intuitive wi= thout adding uids to each element. =A0The verbs that you propose make sense= . =A0There is also a JSON Patch informational draft in the IETF that is int= eresting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-j= son-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= /div>

I'm curious if anyone else in the WG is in favor of unique i= dentifiers for every multi-valued element.

--Kelly
From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

The reason we cannot use the value itself to identify an element is th= at this method will only work for simple elements, not for nested structure= s. i.e., if we had an array of dictionaries (e.g., we had to record an arra= y of addresses for each customer, with each address element having sub-elements like street number, street n= ame, suburb, etc.), then it would be clumsy to supply the entire value of t= he array element because it's itself a dictionary. Creating a unique ke= y for each element scales better.

Regards,
Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hun= t@oracle.com> wrote:
Ganesh,

Here's the sample that concerned me...
The two operations differ significantly, and it's not very intuiti= ve.=A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }


You gave other examples of an attribute with an identifier that matched= that value or of identifiers that were additional unique keys.

Given that multi-values must be each unique, I don't see the point = of the extra indexing to support this. Just use the value as the item you w= ish to delete.

I agree, the delete value operation could be more explicit and clear in= general.


On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:

>=A0 For the multi-value example you gave you = used the value as the attribute name key.=A0

Now I'm confused :-). I don't believe any of my examples ever = used a value as the key.

Could you please show me which example you mean, and which parts of it= you believe to be the value?

Regards,
Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hun= t@oracle.com> wrote:

For the multi-value example you gave you used the value as the attribute na= me key.=A0

That means a lot more complex indexing structure. Better to just say d= elete a specific value.=A0

The spec already allows multiple values to have tags like home, work, = etc.

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are conflating value with an attribute id.= =A0

I don't believe so.

I'm adopting a model where every attribute of the resource is a ke= y-value pair. The key is a name or ID.

For non-repeating attributes (both simple and composite), the key is t= he attribute name itself.=A0

Simple attribute:

Key: "dob"
Value: "01 Jan 1970"

For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode".

Composite attribute:

Key: "address.street-number"
Value: "10"

Key: "address.suburb"
Value: "East Camden"

For repeating (multi-valued) attributes, I'm suggesting that there= be new keys for each individual value, otherwise they are impossible to di= stinguish, and a positional index is inadequate. So we convert the array in= to a dictionary and this then becomes a composite attribute using dot notation for the key.

Multi-valued attribute:

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

So this allows us to apply uniform treatment to any arbitrarily deep r= esource structure. We can refer to every leaf value with a key that is the = fully-qualified name using dot notation.

The verbs are just unambiguous operations on these (now) explicitly ad= dressable attributes.

INCLUDE to a collection and specify only the value. The key is generat= ed and returned. The fully-qualified key is <collection-name>.<new= ly-generated-ID> and the value is what was specified in the INCLUDE.

REPLACE a fully-qualified key with a new value. If the key doesn't= exist, return a "404 Not Found".

PLACE a value at the logical location implied by the fully-qualified k= ey. If there is already a key with that name, return a "409 Conflict&q= uot;.

FORCE the fully-qualified key to hold the given value, regardless of w= hether it existed before or not. Only errors possible are "400 Bad Req= uest" and "500 Internal Error".

RETIRE an attribute or a collection given its fully-qualified key. The= implementation will determine whether the attribute will disappear entirel= y or will exist holding a null value (the blank string "" or the = empty object {} ).

I'll explain in a separate post why we need operation verbs like t= hese that are independent of the HTTP verbs.

Regards,
Ganesh

On 11 August 2012 10:38, <<= a href=3D"mailto:scim-request@ietf.org" target=3D"_blank">scim-request@ietf= .org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement
Ganesh,

In your example you are conflating value with an attribute id. I find = that confusing.=A0

I agree though that operations in patch could be a lot more explicit.= =A0

Eg explicitly deleting a value by saying delete or retire.=A0

Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

Let's discuss that now.

The trade-offs are very clear here.

Pros:

Pro 1. The API to manipulate resources becomes so much cleaner, consis= tent and intuitive when every individual attribute value gets its own ID.

Here's how to delete a single member from a Group, as per the curr= ent spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "members": [
       {
         "display": "Babs Jensen",
         "value": "2819c223-7f76-453a-919d-413861904646"=
;
         "operation": "delete"
       }
     ]
   }

Here's how to delete ALL members from a group according to the current = spec:

   PATCH /Gro=
ups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json
   Authorization: Bearer h480djs93hd8
   ETag: W/"a330bc54f0671c9"

   {
     "schemas": ["urn:scim:schemas:core:1.0"],
     "meta": {
       "attributes": [
         "members"
       ]
     }
   }

The two operations differ significantly, and it's not very intuitive.= =A0
With my suggestion, here's how to delete a single member from a gr= oup:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members.2819c223-7f76-453a-919d-413861904= 646"
}
}
] }
Here's how I suggest deleting ALL members from a group:

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {
"operations" : [
{
"RETIRE" : {
"key" : "members"
}
}
] }

I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

Pro 2: We can apply this mechanism consistently to three areas:
(a) Manipulating multi-valued attributes of a resource
(b) Manipulating members of a group
(c) Performing bulk operations, where we simply use HTTP verbs instead= of the specialised (and semantically less ambiguous) verbs I suggested for= attributes, the "key" becomes the URI, and the "value"= becomes the corresponding JSON object.

All of them return "207 Multi-Status" with the "results= " array holding individual status codes.

In the current spec, (a) and (b) are done similarly but (c) is very di= fferent.

Pro 3: Adoption of the standard by clients is likely to be higher beca= use it's simpler for them.

Pro 4: New (not incumbent) cloud providers will probably find this eas= ier to implement because they have no legacy. They will probably use some f= orm of NoSQL database and won't be constrained by the limitations of LD= AP directories.

Cons:

Con 1: Incumbent cloud providers with existing data stores in a direct= ory format (where multi-valued attributes are stored as comma-separated val= ues under a single attribute node) will find it difficult to migrate to thi= s model and store each attribute value as a sub-node with its own key. This will "hinder adoption of t= he spec", which is what you fear.

Have I summed up the Pros and Cons correctly? I'm biased of course= , so I could have missed a Con or hyped a Pro :-).

In other words, we're debating interface complexity (current spec)= versus implementation complexity (my suggestion). Both can hinder adoption= of the spec by different parties.

Here's what we need to discuss - Do the Pros make the suggestion w= orth adopting in spite of the Cons, or are the Cons so great that it's = best to leave the spec as it is?

Keep in mind that a complex spec that only favours incumbent cloud pro= viders can cut both ways. It opens the door to a simpler interface offered = by a new generation of nimbler SPs that don't have the same legacy issu= es, and there could be an exodus of clients to these new SPs. SCIM could end up being obsoleted very soon, bec= ause the API interface is very complex and clumsy, as any new reader can at= test. I was taken aback by the complexity when I saw it, which is why I was= prompted to suggest something simpler.

This is an issue where we need the opinions of many people, and they n= eed to state their affiliations. If most people weighing in belong to incum= bent SPs and they vote in favour of interface complexity to avoid implement= ation complexity, then it means the spec is not doing a good job of balancing the interests of various gro= ups. I think we should also poll client organisations to see what they woul= d want.

(Gartner is trusted by enterprise clients to evaluate the capabilities= of vendors (SPs). I believe Gartner should take the lead in representing c= lient interests in this working group rather than those of incumbent vendor= s, which is what it seems like to me. Correct me if I'm being unfair.)

Regards,
Ganesh



On 11 August 2012 01:35, Diodati,Mark <= Mark.Diodati@gartner.com> wrote:

Hi Ganesh,

=A0

I am concerned about your= second suggestion:

=932. When dealing with m= ulti-valued attributes of a resource (expressed as arrays in JSON), they mu= st be converted from an array into a dictionary with unique keys (UUIDs generated by the cloud provider when the attribute is created)= . Without unique keys for every attribute value of a resource, manipulating= it will be clumsy and inelegant.=94

=A0

One of the primary reason= s that SPML failed was lack of adoption by service providers due to its com= plexity. Very few target applications implemented SPML. Most of the commercial provisioning systems had an SPML interface (either = v1 or v2), but not one of them was conformant to the SPML standard because = of complexity. If you are interested, I will forward you the research docum= ents that discuss these problems in detail. For SCIM to be successful, it must be adopted by commercial tar= get applications (i.e., service providers). I am confident that a requireme= nt for unique identifiers with multi-valued attributes will preclude its ad= option, because it requires major changes to the service provider=92s existing identity storage mechanisms. =

Mark

=A0
=A0
=A0

From: Trey Dra= ke [mailto:tr= ey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad
Cc: scim@ietf.org= ; Emmanuel Dreux; Kelly Grizzle; Phil Hunt

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

=A0

Ganesh,

=A0

I'll base my comments on your latest reply (belo= w). =A0

=A0

The externalID is not part of the protocol. =A0It is= an *optional* attribute within the *schema* specification. =A0As for #2, t= he protocol spec works as you describe if "arbitrary URI parameters&qu= ot; equate to resource attributes (Allow generic search using 'GET /Users' and arbitrary URI parameters). =A0Please= clarify your suggestion.

=A0

I'm not tracking your coupling concern. =A0The c= lient can search and hence retrieve resources on any attribute it chooses, = externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0
=A0

What do you mean by "candidate key"? =A0Gi= ven=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Pr= asad <g.c.pras= ad@gmail.com> wrote:

>=A0 I think scim gets its current simplicity fro= m its single owner hub spoke model implementing tight coupling. [...]=A0IMH= O loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that you're implying &qu= ot;tight coupling =3D=3D simple" and "loose coupling =3D=3D compl= ex". That's contrary to my experience.

=A0

When I say "loose coupling", I mean "= no unnecessary dependencies". Invariably, a reduction in dependencies = leads to greater simplicity.

=A0

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orth= ogonal aspects of the solution.

=A0

All that my suggestion involves is,

=A0

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' a= nd arbitrary URI parameters

=A0

No planned functionality is lost by this.

=A0

1. The client enterprise can still send its internal= ID as part of the resource body, inside some attribute defined by them (bu= t not defined by the protocol). Let's say they call it 'myID'.<= /p>

2. The client enterprise can search for resource URI= s using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen'

Since myID is a candidate key, the server will retur= n exactly one URI, which is the canonical URI for the resource

<=
a href=3D"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646=
" target=3D"_blank">https://example.com/v1/Users/2819c223-7f76-453a-919d-41=
3861904646
3=
. The client can use this URI to perform all other operations as usual.
=A0
S=
o taking 'externalID' out of the protocol spec only does this:
1=
. It avoids enshrining tight coupling in the protocol (If clients want to t=
ightly couple themselves to the cloud provider by sending their internal ID=
s, they can do so. Suicide is OK, but the protocol should not be guilty of =
assisted suicide. ;-)
2=
. It encourages loose coupling by nudging clients towards maintaining their=
 own internal-to-external identifier mappings.
=A0
T=
hat's what I'd like to see. I don't believe this complicates th=
e protocol. It simplifies it and it also lends itself to a loosely-coupled =
approach.
=A0
I=
'll address the multi-valued attribute suggestion separately.

=A0


R=
egards,


G=
anesh






=A0


=A0


=A0


=A0






On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> w=
rote:










Phil










On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








>=A0 
storing this information in a mapping table outside of the SCIM spec is a g=
reat way to enable this solution.=A0 Part of the key here is that SCIM is j=
ust a piece of the architecture for this solution, and is only responsible =
for the transport layer between domains.=A0








I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.




=A0








I'm suggesting that the spec do less, not more.<=
/p>



=A0






What the SCIM spec needs to do there is just refrain=
 from introducing tight coupling. I would like to see a single identifier e=
xposed through the API, with the implication (and perhaps the recommendatio=
n) that it be the shared one. Allowing
 one domain to expose its internal identifier to the other creates tight co=
upling and ensures that both domains need simultaneously split or merge ide=
ntities, which is not desirable. So I recommend _taking out_ the "exte=
rnal id" field from the API. The spec
 shouldn't encourage tight coupling. If clients want to pass in their i=
nternal ids as part of the resource body, no one can stop them, and they ca=
n always do a search on that attribute to retrieve the URI exactly as you v=
isualise they will with the "external
 id", but let's not elevate an anti-pattern to a recommendation by=
 enshrining the "external id" as an acceptable attribute.






=A0








Am I making sense?










=A0








I see what you are saying. I think scim gets its cur=
rent simplicity from its single owner hub spoke model implementing tight co=
upling.=A0




=A0








IMHO loose coupling is a much more complex solution.=
 The reality is that each end-point has value to contribute and thus the si=
ngle-owner model will eventually need to become multi-owner or multi-hub.=
=A0











=A0








That said i think the current model provides a pract=
ical starting point.=A0














=A0








>=A0 
Regarding unique identifiers for multi-valued attributes there is a trade-o=
ff involved.=A0 On one hand this makes PATCH semantics easier.=A0 On the ot=
her hand it puts extra burden on service providers.=A0








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.











=A0








Regards,






Ganesh




On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:






Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a
 great way to enable this solution.=A0 Part of the key here is that SCIM is=
 just a piece of the architecture for this solution, and is only responsibl=
e for the transport layer between domains.


=A0




You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how
 to model the end state of the false positive scenario (splitting a user):<=
/span>




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 as two SCIM users that contain information about the entities on other dom=
ains.







=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=








=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=








=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.







=A0




=A0




Similarly, the false nega=
tive use case (merging two users) looked like this at the end:




=A0




| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0






This could be represented=
 with the following SCIM user:


=A0




{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=








=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [

=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0




=A0




Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand
 it puts extra burden on service providers.=A0 Since the inception of SCIM,=
 a key goal has been to foster adoption by service providers by making thin=
gs fit easily onto existing systems.=A0 IMO the value gained by unique iden=
tifiers for multi-valued attributes
 is not worth the demands put on a service provider.=A0 I also think that v=
endors that have a non-SCIM-compliant API will choose to keep things that w=
ay if the spec is too hard for them to implement.=A0 In a green field envir=
onment we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0




--Kelly


=A0








From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement










=A0




Hi Ganesh,


=A0




Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal
 mapping table ( you would have to map group membership as well).

=A0




This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0




This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.


=A0




You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.







=A0




--


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com







Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanu=
el.Dreux


=A0






De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0




Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=
=A0=A0=A0=A0 Why should domains not expose their i=
nternal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=









b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.


Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction model is
 peer-to-peer, where entity lifecycle events within a domain are notified t=
o other domains (when necessary) in an asynchronous manner (i.e., through m=
essaging) and the other domains are free to respond to these events in an a=
ppropriate manner and at a time
 of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.







Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan 1970) or similar
 attributes. The front-end application may make an intelligent (but incorre=
ct) guess that these two persons are the same, and re-assign the same ident=
ifier to the second person. This is a false positive. They appear to be the=
 same entity, but they're actually
 different. When the error is discovered, the identities will need to be sp=
lit, with a new identifier generated for one of them.


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that they will be treated
 as two different customers and assigned two unique identifiers. This is a =
false negative. They appear to be two entities, but are actually the same. =
At a later stage, when the error is discovered, the identities will have to=
 be merged, and one of the identifiers
 will have to be dropped.


Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated way by mapping
 internal identifiers to external ones and only exposing external identifie=
rs to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:







| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.







Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping =939caf78aac3d6=94
 to =93ff487230b3a0=94 and vice-versa. At some convenient time (importantly=
, this doesn't have to be at the time the split happens), Domain 2 can =
be requested to provision a second entity, and when it responds with an ide=
ntifier of =937a87f27c1dd8=94, this can go into
 the mapping table as a new record associated with the second entity's =
internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |


Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in Domain 1.







(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:







| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 273d36e30d09 | =
D2 | 41206cc97c8b | true |


When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John Smith=94). Let's
 say it retains the first ID =939caf78aac3d6=94 and drops the second =93273=
d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |


| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |


| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |


Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambi
_______________________________________________

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







--0015175cba22d117b504c70bdf0f-- From leifj@mnt.se Sun Aug 12 06:18:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3976A21F8533 for ; Sun, 12 Aug 2012 06:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPZlkMEZp78e for ; Sun, 12 Aug 2012 06:18:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0421F8522 for ; Sun, 12 Aug 2012 06:18:54 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7CDInFS026552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 12 Aug 2012 15:18:52 +0200 (CEST) Message-ID: <5027AD39.3060501@mnt.se> Date: Sun, 12 Aug 2012 15:18:49 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <50252a3a.e164340a.0971.ffff9a60SMTPIN_ADDED@mx.google.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 13:18:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > (Gartner is trusted by enterprise clients to evaluate the > capabilities of vendors (SPs). I believe Gartner should take the > lead in representing client interests in this working group rather > than those of incumbent vendors, which is what it seems like to me. > Correct me if I'm being unfair.) Ganesh, If you have contacts at Gartner who are interested in participating please encourage them to do so. However, participants in IETF WGs are not selected to "represent" any one constituency as somebody already pointed out. As co-chair of this WG , may I suggest that you present your proposal for an alternative SCIM protocol in the form of an Internet Draft. That way the WG can comment on your proposals as a whole. Best R, Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAnrTkACgkQ8Jx8FtbMZnci7wCfce1QPfBzbAG7d6nCGJLIoArr WLMAnilN6fj9060KMuchChzPXN/z+6dX =T8sJ -----END PGP SIGNATURE----- From leifj@mnt.se Sun Aug 12 06:22:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EDE21F8522 for ; Sun, 12 Aug 2012 06:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoMQIealejsx for ; Sun, 12 Aug 2012 06:22:46 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D6C6021F84A5 for ; Sun, 12 Aug 2012 06:22:45 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7CDMfBr026808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 12 Aug 2012 15:22:44 +0200 (CEST) Message-ID: <5027AE21.5010605@mnt.se> Date: Sun, 12 Aug 2012 15:22:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C34373302493F@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733024BFD@BY2PRD0410MB354.namprd04.prod.outlook.com> <21A0F3F7-77B4-4538-9F86-6C16AB756232@oracle.com> <411B68AE-A698-4DFE-9D35-1D4D5857528C@unboundid.com> <502564FD.7050102@oracle.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Where are the remaining SCIM 1.1 IETF drafts? X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 13:22:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/10/2012 09:51 PM, Trey Drake wrote: > Core schema is here: > https://datatracker.ietf.org/doc/draft-scim-core-schema/ > > I suppose the API is still making its way through the manual > submission process. It was submitted. > I was wondering about that - why not cancel the submission and re-submit with corrected metadata using the automatic submissions process? The reason these drafts don't show up in the wg page on datatracker is that they were named draft-scim-* instead of draft--scim-* which is the norm for individual submissions to the IETF. However I don't propose changing that now since we'll have a consensus call in the WG to adopt (or not) these drafts as WG documents in which case they will change names anyway. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAnriEACgkQ8Jx8FtbMZnfVVACgxY6RJQUUH2zmu0nSkYwdmDPU fygAn0npLCSwaNzBci39nQ8CSNSEOR62 =g1Js -----END PGP SIGNATURE----- From edreux@cloudiway.com Sun Aug 12 11:29:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F6721F866D for ; Sun, 12 Aug 2012 11:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRAIF5GxDSA5 for ; Sun, 12 Aug 2012 11:29:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9B21F8600 for ; Sun, 12 Aug 2012 11:29:27 -0700 (PDT) Received: from mail6-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Sun, 12 Aug 2012 18:29:26 +0000 Received: from mail6-ch1 (localhost [127.0.0.1]) by mail6-ch1-R.bigfish.com (Postfix) with ESMTP id AE2E71E02B6; Sun, 12 Aug 2012 18:29:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT005.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -96 X-BigFish: PS-96(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc430Ic85dh1432I1418Iac5W9d9Rzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail6-ch1: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT005.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail6-ch1 (localhost.localdomain [127.0.0.1]) by mail6-ch1 (MessageSwitch) id 1344796161470529_8751; Sun, 12 Aug 2012 18:29:21 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail6-ch1.bigfish.com (Postfix) with ESMTP id 6585E140217; Sun, 12 Aug 2012 18:29:21 +0000 (UTC) Received: from AMXPRD0610HT005.eurprd06.prod.outlook.com (157.56.248.213) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 12 Aug 2012 18:29:20 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.209]) by AMXPRD0610HT005.eurprd06.prod.outlook.com ([10.255.58.40]) with mapi id 14.16.0175.005; Sun, 12 Aug 2012 18:29:18 +0000 From: Emmanuel Dreux To: Ganesh and Sashi Prasad , Kelly Grizzle Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNeDWynYh07cptlESyDB67eV+Ku5dWfMaQ Date: Sun, 12 Aug 2012 18:29:18 +0000 Message-ID: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.207.127.168] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD27417467AMXPRD0610MB353_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.248.213$sailpoint.com%0%1%cloudiway.com%False%False%0$ X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 18:29:47 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD27417467AMXPRD0610MB353_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =F0 addresses.3cbaaff8e84e.street-number =3D "243" Where would 3cbaaff8e84e come from? Would it have to be stored on the accou= nt database of the service provider? If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposi= tory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. This would be a show stopper. SCIM must be transparent, and must be able to= be put on top of an existing system to provide provisioning apis. Said differently, SCIM must not be intrusive for existing systems and must = not require modifications to allow its integration. Correct me if I misunderstood your suggestion. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 =C0 : Kelly Grizzle Cc : scim@ietf.org; Phil Hunt Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestion worth adop= ting in spite of the Cons, or are the Cons so great that it's best to leave= the spec as it is? Keep in mind that a complex spec that only favours incumbent cloud provider= s can cut both ways. It opens the door to a simpler interface offered by a = new generation of nimbler SPs that don't have the same legacy issues, and t= here could be an exodus of clients to these new SPs. SCIM could end up bein= g obsoleted very soon, because the API interface is very complex and clumsy= , as any new reader can attest. I was taken aback by the complexity when I = saw it, which is why I was prompted to suggest something simpler. This is an issue where we need the opinions of many people, and they need t= o state their affiliations. If most people weighing in belong to incumbent = SPs and they vote in favour of interface complexity to avoid implementation= complexity, then it means the spec is not doing a good job of balancing th= e interests of various groups. I think we should also poll client organisat= ions to see what they would want. (Gartner is trusted by enterprise clients to evaluate the capabilities of v= endors (SPs). I believe Gartner should take the lead in representing client= interests in this working group rather than those of incumbent vendors, wh= ich is what it seems like to me. Correct me if I'm being unfair.) Regards, Ganesh On 11 August 2012 01:35, Diodati,Mark > wrote: Hi Ganesh, I am concerned about your second suggestion: "2. When dealing with multi-valued attributes of a resource (expressed as a= rrays in JSON), they must be converted from an array into a dictionary with= unique keys (UUIDs generated by the cloud provider when the attribute is c= reated). Without unique keys for every attribute value of a resource, manip= ulating it will be clumsy and inelegant." One of the primary reasons that SPML failed was lack of adoption by service= providers due to its complexity. Very few target applications implemented = SPML. Most of the commercial provisioning systems had an SPML interface (ei= ther v1 or v2), but not one of them was conformant to the SPML standard bec= ause of complexity. If you are interested, I will forward you the research = documents that discuss these problems in detail. For SCIM to be successful,= it must be adopted by commercial target applications (i.e., service provid= ers). I am confident that a requirement for unique identifiers with multi-v= alued attributes will preclude its adoption, because it requires major chan= ges to the service provider's existing identity storage mechanisms. Mark From: Trey Drake [mailto:trey.drake@unboundid.com] Sent: Friday, August 10, 2012 9:51 AM To: Ganesh and Sashi Prasad Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phi= l Hunt Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, I'll base my comments on your latest reply (below). The externalID is not part of the protocol. It is an *optional* attribute = within the *schema* specification. As for #2, the protocol spec works as y= ou describe if "arbitrary URI parameters" equate to resource attributes (Al= low generic search using 'GET /Users' and arbitrary URI parameters). Pleas= e clarify your suggestion. I'm not tracking your coupling concern. The client can search and hence re= trieve resources on any attribute it chooses, externalId or otherwise. Not= hing mandates use of externalId. What do you mean by "candidate key"? Given On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad > wrote: > I think scim gets its current simplicity from its single owner hub spoke= model implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution. Phil, I'm a bit surprised that you're implying "tight coupling =3D=3D simple" and= "loose coupling =3D=3D complex". That's contrary to my experience. When I say "loose coupling", I mean "no unnecessary dependencies". Invariab= ly, a reduction in dependencies leads to greater simplicity. Let's not confuse reduction of dependencies in the data model with a hub-an= d-spokes architecture. They're entirely orthogonal aspects of the solution. All that my suggestion involves is, 1. Take 'external ID' out of the protocol. 2. Allow generic search using 'GET /Users' and arbitrary URI parameters No planned functionality is lost by this. 1. The client enterprise can still send its internal ID as part of the reso= urce body, inside some attribute defined by them (but not defined by the pr= otocol). Let's say they call it 'myID'. 2. The client enterprise can search for resource URIs using any attribute, = including this internal ID 'GET /Users?myID=3Dbjensen' Since myID is a candidate key, the server will return exactly one URI, whic= h is the canonical URI for the resource https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646 3. The client can use this URI to perform all other operations as usual. So taking 'externalID' out of the protocol spec only does this: 1. It avoids enshrining tight coupling in the protocol (If clients want to = tightly couple themselves to the cloud provider by sending their internal I= Ds, they can do so. Suicide is OK, but the protocol should not be guilty of= assisted suicide. ;-) 2. It encourages loose coupling by nudging clients towards maintaining thei= r own internal-to-external identifier mappings. That's what I'd like to see. I don't believe this complicates the protocol.= It simplifies it and it also lends itself to a loosely-coupled approach. I'll address the multi-valued attribute suggestion separately. Regards, Ganesh On 10 August 2012 07:53, Phil Hunt > wrote: Phil On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote: > storing this information in a mapping table outside of the SCIM spec is = a great way to enable this solution. Part of the key here is that SCIM is = just a piece of the architecture for this solution, and is only responsible= for the transport layer between domains. I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it. I'm suggesting that the spec do less, not more. What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API,= with the implication (and perhaps the recommendation) that it be the share= d one. Allowing one domain to expose its internal identifier to the other c= reates tight coupling and ensures that both domains need simultaneously spl= it or merge identities, which is not desirable. So I recommend _taking out_= the "external id" field from the API. The spec shouldn't encourage tight c= oupling. If clients want to pass in their internal ids as part of the resou= rce body, no one can stop them, and they can always do a search on that att= ribute to retrieve the URI exactly as you visualise they will with the "ext= ernal id", but let's not elevate an anti-pattern to a recommendation by ens= hrining the "external id" as an acceptable attribute. Am I making sense? I see what you are saying. I think scim gets its current simplicity from it= s single owner hub spoke model implementing tight coupling. IMHO loose coupling is a much more complex solution. The reality is that ea= ch end-point has value to contribute and thus the single-owner model will e= ventually need to become multi-owner or multi-hub. That said i think the current model provides a practical starting point. > Regarding unique identifiers for multi-valued attributes there is a trad= e-off involved. On one hand this makes PATCH semantics easier. On the oth= er hand it puts extra burden on service providers. Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions. Regards, Ganesh On 10 August 2012 00:28, Kelly Grizzle > wrote: Thanks Emmanuel. I had started writing up a similar response. As you sugg= est, storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution. Part of the key here is that SCIM i= s just a piece of the architecture for this solution, and is only responsib= le for the transport layer between domains. You could also model these ID mappings in the SCIM user as an extension but= would probably not want to expose these externally. Here is an example of= how to model the end state of the false positive scenario (splitting a use= r): | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | a99a5feba839 | D2 | 7a87f27c1dd8 | true = | This could be represented as two SCIM users that contain information about = the entities on other domains. { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" } ] } } { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "a99a5feba839", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "7a87f27c1dd8" } ] } } In the second user, the linkedUsers attribute would be empty until the spli= t user was synced to domain 2. Similarly, the false negative use case (merging two users) looked like this= at the end: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true = | | 9caf78aac3d6 | D2 | 41206cc97c8b | false = | This could be represented with the following SCIM user: { "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:fede= ration:1.0"], "id": "9caf78aac3d6", "userName": "John Smith", "urn:scim:schemas:extension:federation:1.0": { "linkedUsers": [ { "domain": "D2", "externalEntityId": "ff487230b3a0" }, { "domain": "D2", "externalEntityId": "41206cc97c8b", "deletionRequired": true } ] } } Regarding unique identifiers for multi-valued attributes there is a trade-o= ff involved. On one hand this makes PATCH semantics easier. On the other = hand it puts extra burden on service providers. Since the inception of SCI= M, a key goal has been to foster adoption by service providers by making th= ings fit easily onto existing systems. IMO the value gained by unique iden= tifiers for multi-valued attributes is not worth the demands put on a servi= ce provider. I also think that vendors that have a non-SCIM-compliant API = will choose to keep things that way if the spec is too hard for them to imp= lement. In a green field environment we do have the luxury of mandating a = model to make certain operations more elegant. However, we can't ignore le= gacy systems. --Kelly From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Emmanuel Dreux Sent: Thursday, August 09, 2012 3:18 AM To: Ganesh and Sashi Prasad; Kelly Grizzle Cc: scim@ietf.org Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Ganesh, Nothing prevents you in your SCIM implementation (client or server) to gene= rate a unique identifier for each synchronized object and maintain an inter= nal mapping table ( you would have to map group membership as well). This is what we are doing with Active Directory sources or targets: As we didn't find an immutable uniqueID in AD systems (DN,samAccountName, U= PN) are subject to change (even objectGuid can change if an AD domain is mi= grated), we decided to generate and maintain an internal table of ids. This= fits your requirements as it hides internal ids. This was written in dotnet and we have started a project to rewrite our SCI= M stack in PHP and will give it to the Open Source community. This implemen= tation will have a parameter : AllocateIds versus UseExistingIDs. This will give the choice of "hiding" internalIDs or use them as unique ID. You can also implement such feature without violating the SCIM specs, or wi= thout asking to include it in the specs. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : jeudi 9 ao=FBt 2012 03:35 =C0 : Kelly Grizzle Cc : scim@ietf.org Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement Hi Kelly, Thanks for your response. Let me first respond in brief to the two main poi= nts you have made, and then elaborate on the first. 1. Why should domains not expose their internal identifiers to other d= omains? a. We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We sh= ould rely on messaging and notification, with encapsulation of domain-speci= fic data. b. In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when "false negatives" and "false positives"= are discovered. A domain should be able to handle this internal housekeepi= ng freely, only notifying other domains when convenient. Mapping of interna= l identifiers to external ones and maintaining this mapping internally allo= ws this loosely-coupled housekeeping to take place. Sharing internal identi= fiers (or otherwise outsourcing the mapping of internal to external identif= iers) forces housekeeping activities to be done in lock-step across domains= . c. Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifie= rs is a key part of this tight coupling. 2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes: a. I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations= , we are losing an opportunity to provide a clean and elegant model to subs= equent users of the spec, and this will have repercussions over many years = or even decades. b. If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both "SCIM-compliant" and "non-SCIM-compliant" APIs to th= eir customers and encouraging new customers to adopt the "SCIM-compliant" A= PI. Legacy customers can be supported using a "non-SCIM-compliant" API for = an arbitrarily long period and gradually migrated to the SCIM-compliant API= . The logistics are not insurmountable, and shouldn't prevent the adoption = of a dictionary model for multi-valued attributes. Elaboration of Point 1: When we consider federated identity across more than one domain, we have to= assume that domains are not necessarily master-slave in their interaction.= The most generic interaction model is peer-to-peer, where entity lifecycle= events within a domain are notified to other domains (when necessary) in a= n asynchronous manner (i.e., through messaging) and the other domains are f= ree to respond to these events in an appropriate manner and at a time of th= eir convenience. A key set of lifecycle events for an entity is the merging and splitting of= identity that is often required. The question "Is this one entity?" can be answered either yes (positive) or= no (negative). But sometimes, we can discover false positives and false ne= gatives in our data stores. Consider a case where customers sign up online, and two customers who are p= rivacy-conscious enter fake IDs such as "John Smith", and also use the same= date of birth (say, 1 Jan 1970) or similar attributes. The front-end appli= cation may make an intelligent (but incorrect) guess that these two persons= are the same, and re-assign the same identifier to the second person. This= is a false positive. They appear to be the same entity, but they're actual= ly different. When the error is discovered, the identities will need to be = split, with a new identifier generated for one of them. Consider the opposite case where a customer signs up through two different = portals or in two different sessions, using the names "JSmith" and "JohnS".= It is very likely that they will be treated as two different customers and= assigned two unique identifiers. This is a false negative. They appear to = be two entities, but are actually the same. At a later stage, when the erro= r is discovered, the identities will have to be merged, and one of the iden= tifiers will have to be dropped. These are not theoretical use cases. They form a significant proportion of = the user base in most large Web-facing applications. Let's see how these ca= n be managed in a federated way by mapping internal identifiers to external= ones and only exposing external identifiers to other domains. a. False positives: Domain 1 has the following information about a customer in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} When requesting the provisioning of this entity in Domain 2, the following = ID is returned by Domain 2: ff487230b3a0. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifier: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | When the false positive is discovered and the entity is split, Domain 1 cre= ates a new internal identifier and now has the following entity information= . Internal ID: 9caf78aac3d6 Attributes: {name: "John Smith", dob: "01-Jan-1970"} Internal ID: a99a5feba839 Attributes: {name: "John Smith", dob: "01-Jan-1970"} This second entity with its own internal identifier is invisible to Domain = 2, and this is by design. Communication about the original entity takes pla= ce as before by mapping "9caf78aac3d6" to "ff487230b3a0" and vice-versa. At= some convenient time (importantly, this doesn't have to be at the time the= split happens), Domain 2 can be requested to provision a second entity, an= d when it responds with an identifier of "7a87f27c1dd8", this can go into t= he mapping table as a new record associated with the second entity's intern= al identifier. The mapping table now contains the following entries: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | a99a5feba839 | D2 | 7a87f27c1dd8 | true | Domain 2 is not even aware that a split has happened, and the provisioning = that it does is not in lockstep with the split in identity that occurred in= Domain 1. (What is the "Primary flag" used for? We'll see when we cover the treatment= of false negatives.) b. False negatives: Domain 1 has the following information about what it thinks are two distinc= t customers in its data store: Internal ID: 9caf78aac3d6 Attributes: {name: "JSmith", dob: "01-Jan-1970"} Internal ID: 273d36e30d09 Attributes: {name: "JohnS", dob: "01-Jan-1970"} When requesting the provisioning of these entities in Domain 2, the followi= ng IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b. Domain 1 then maintains the following in a mapping table and uses it for tr= anslation when talking to Domain 2, taking care never to expose its interna= l identifiers: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 273d36e30d09 | D2 | 41206cc97c8b | true | When the false negative is discovered and the two entities are merged, Doma= in 1 drops one of the internal identifiers and rationalises the name of the= customer (say, to "John Smith"). Let's say it retains the first ID "9caf78= aac3d6" and drops the second "273d36e30d09". The mapping table now looks like this: | Internal Entity ID | External Domain ID | External Entity ID | Primary fl= ag | | 9caf78aac3d6 | D2 | ff487230b3a0 | true | | 9caf78aac3d6 | D2 | 41206cc97c8b | false | Now two external identifiers map to the same internal one, so inbound commu= nication from Domain 2 can be unambi _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_DF63ACC82673DB40A7AAC08FFA71DFBD27417467AMXPRD0610MB353_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=F0  addresses.3cbaaff8e84e.= street-number =3D "243"

 = ;

Where woul= d 3cbaaff8e84e come from? Would it have to be stored= on the account database of the service provider?

&n= bsp;

If so, = I believe that this is impracticable in the core schema. Indeed it implies = that a service provider must extend the schema of his account repository (L= DAP partition, SQL db, …) and “prepare it” for SCIM integration.

This wo= uld be a show stopper. SCIM must be transparent, and must be able to be put= on top of an existing system to provide provisioning apis.

&n= bsp;

Said di= fferently, SCIM must not be intrusive for existing systems and must not req= uire modifications to allow its integration.

Correct= me if I misunderstood your suggestion.

&n= bsp;

--

Regards,

Emmanuel Dreux=

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

Tel: +33 4 26 78 17 5= 8

Mobile: +33 6 47 81 2= 6 70

skype: Emmanuel.Dreux

 <= /p>

De : Gane= sh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : dimanche 12 ao=FBt 2012 04:53
=C0 : Kelly Grizzle
Cc : scim@ietf.org; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue 24

 

>  Multi-valued attributes that don't have a value sub-attribute (eg - address= ) have to specified completely for uniqueness.  

 

That's exactly the point. How do we "specify co= mpletely for uniqueness"?

 

In the example below, how are you proposing that the= following element be updated if we can't use positional indexes?

 

addresses[1].street-number =3D "243"<= /o:p>

 

User object:

 

{

  ...

  addresses: [

    {

      "type" : "home&q= uot;,

      "street-number" : &qu= ot;35",

      "street-name" : "= ;High Road",

      "suburb" : "East= Camden",

      "postcode" : "53= 46",

      "state" : "SA&qu= ot;,

      "country" : "Aus= tralia"

    },

    {

      "type" : "office= ",

      "street-number" : &qu= ot;213",

      "street-name" : "= ;Main Street",

      "suburb" : "Adel= aide",

      "postcode" : "50= 00",

      "state" : "SA&qu= ot;,

      "country" : "Aus= tralia"

    }

  ]

}

 

It's impractical to use the value because it's the w= hole dictionary element:

 

{

  "type" : "office",

  "street-number" : "213",<= o:p>

  "street-name" : "Main Street&q= uot;,

  "suburb" : "Adelaide",

  "postcode" : "5000",=

  "state" : "SA",

  "country" : "Australia"

}

 

With my proposal, the "addresses" array ge= ts converted to a dictionary, and then we have a stable way of referencing = this element:

 

addresses.3cbaaff8e84e.street-number =3D "243&q= uot;

 

{

  ...

  addresses: {

    "d6ea365462f5" :<= /p>

    {

      "type" : "home&q= uot;,

      "street-number" : &qu= ot;35",

      "street-name" : "= ;High Road",

      "suburb" : "East= Camden",

      "postcode" : "53= 46",

      "state" : "SA&qu= ot;,

      "country" : "Aus= tralia"

    },

    "3cbaaff8e84e" :<= /p>

    {

      "type" : "office= ",

      "street-number" : &qu= ot;213",

      "street-name" : "= ;Main Street",

      "suburb" : "Adel= aide",

      "postcode" : "50= 00",

      "state" : "SA&qu= ot;,

      "country" : "Aus= tralia"

    }

  }

}

 

If you're proposing one mechanism for composite attr= ibutes and another mechanism for simple attributes, I would suggest that's = actually more complex than adopting a single mechanism that works the same = way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather t= han done by hand, and having two mechanisms (depending on whether the attri= bute is simple or composite) will complicate every script that has to be wr= itten.

 

There's a lot of talk about the "burden" o= n the SPs, but I believe this is overblown. Is there any SP representative = in this WG who can tell us what this proposal will actually entail for them= ?

 

Regards,

Ganesh

 

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Ganesh,

 

This is exactly how PATCH works in SCIM = 1.0.  Multi-valued attributes that have a value sub-attribute can be r= emoved by specifying only the value since it is unique.  Multi-valued attributes that don't have a value sub-attribute (eg - address) have to sp= ecified completely for uniqueness.  As I have said before, I am very o= pposed to adding a unique identifier to each element in a multi-valued coll= ection due to the burden it will put on SPs.  Is it elegant?  No.  Is it functional?  Yes. =  Will this non-elegance affect adoption?  My opinion is that addi= ng unique keys to each element will have a much more detrimental effect on = adoption.

 

I do believe that in general PATCH can b= e made more intuitive without adding uids to each element.  The verbs = that you propose make sense.  There is also a JSON Patch informational draft in the IETF that is interesting - http://tools.i= etf.org/html/draft-ietf-appsawg-json-patch-02.  It relies on a JSO= N Pointer draft which uses index-based addressing for multi-valued attributes.  I think that this is something that sho= uld be looked at within the WG and I would be willing to lead this effort.<= o:p>

 

I'm curious if anyone else in the WG is = in favor of unique identifiers for every multi-valued element.

 

--Kelly

 

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

 

The reason we cannot use the value itself to identif= y an element is that this method will only work for simple elements, not fo= r nested structures. i.e., if we had an array of dictionaries (e.g., we had= to record an array of addresses for each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creating = a unique key for each element scales better.

 

Regards,

Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> w= rote:

Ganesh,

 

Here's the sample that concerned me...

The two operations differ significantly, and it's no= t very intuitive. 

With my suggestion, here's how to delete a single me= mber from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }

 

 

You gave other examples of an attribute with an identifier = that matched that value or of identifiers that were additional unique keys.=

 

Given that multi-values must be each unique, I don't see th= e point of the extra indexing to support this. Just use the value as the it= em you wish to delete.

 

I agree, the delete value operation could be more explicit = and clear in general.

 

 

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad w= rote:



>  For the multi-value example you gave you = used the value as the attribute name key. 

 

Now I'm confused :-). I don't believe any of my exam= ples ever used a value as the key.

 

Could you please show me which example you mean, and= which parts of it you believe to be the value?

 

Regards,

Ganesh 

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> w= rote:


For the multi-value example you gave you used the value as the attribute na= me key. 

 

That means a lot more complex indexing structure. Be= tter to just say delete a specific value. 

 

The spec already allows multiple values to have tags= like home, work, etc.

 

Phil=


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value w= ith an attribute id. 

I don't believe so.

 

I'm adopting a model where every attribute of the re= source is a key-value pair. The key is a name or ID.

 

For non-repeating attributes (both simple and compos= ite), the key is the attribute name itself. 

 

Simple attribute:

 

Key: "dob"

Value: "01 Jan 1970"

 

For composite attributes, the key employs dot notati= on to specify the fully-qualified attribute name, e.g., "address.postc= ode".

 

Composite attribute:

 

Key: "address.street-number"

Value: "10"

 

Key: "address.suburb"

Value: "East Camden"

 

For repeating (multi-valued) attributes, I'm suggest= ing that there be new keys for each individual value, otherwise they are im= possible to distinguish, and a positional index is inadequate. So we conver= t the array into a dictionary and this then becomes a composite attribute using dot notation for the key.

 

Multi-valued attribute:

 

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd9= 02"

 

So this allows us to apply uniform treatment to any = arbitrarily deep resource structure. We can refer to every leaf value with = a key that is the fully-qualified name using dot notation.

 

The verbs are just unambiguous operations on these (= now) explicitly addressable attributes.

 

INCLUDE to a collection and specify only the value. = The key is generated and returned. The fully-qualified key is <collectio= n-name>.<newly-generated-ID> and the value is what was specified i= n the INCLUDE.

 

REPLACE a fully-qualified key with a new value. If t= he key doesn't exist, return a "404 Not Found".

 

PLACE a value at the logical location implied by the= fully-qualified key. If there is already a key with that name, return a &q= uot;409 Conflict".

 

FORCE the fully-qualified key to hold the given valu= e, regardless of whether it existed before or not. Only errors possible are= "400 Bad Request" and "500 Internal Error".=

 

RETIRE an attribute or a collection given its fully-= qualified key. The implementation will determine whether the attribute will= disappear entirely or will exist holding a null value (the blank string &q= uot;" or the empty object {} ).

 

I'll explain in a separate post why we need operatio= n verbs like these that are independent of the HTTP verbs.

 

Regards,

Ganesh

 

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:

If you have received this digest without all the ind= ividual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun= t)


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudi= way.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

Ganesh,

 

In your example you are conflating value with an att= ribute id. I find that confusing. 

 

I agree though that operations in patch could be a l= ot more explicit. 

 

Eg explicitly deleting a value by saying delete or r= etire. 


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I a= m concerned about your second suggestion: 

 

Let's discuss that now.

 

The trade-offs are very clear here.

 

Pros:

 

Pro 1. The API to manipulate resources becomes so mu= ch cleaner, consistent and intuitive when every individual attribute value = gets its own ID.

 

Here's how to delete a single member from a Group, a= s per the current spec:

 

   PATCH /Groups/acbf3ae7-8=
463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json=

   Authorization: Bearer h4=
80djs93hd8
   ETag: W/"a330bc54f0=
671c9"
 
   {

     "schema=
s": ["urn:scim:schemas:core:1.0"],


     "member=
s": [


       =
{


      &=
nbsp;  "display": "Babs Jensen",=



      &=
nbsp;  "value": "2819c223-7f76-453a-919d-413861904646&q=
uot;


      &=
nbsp;  "operation": "delete"

       =
}


     ]=



   }



Here's how to delete ALL members from a group according to the current spec=
:

 

   PATCH /Groups/acbf3ae7-8=
463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json=

   Authorization: Bearer h4=
80djs93hd8
   ETag: W/"a330bc54f0=
671c9"
 
   {

     "schema=
s": ["urn:scim:schemas:core:1.0"],


     "meta&q=
uot;: {


       =
"attributes": [


      &=
nbsp;  "members"


       =
]


     }=



   }



The two operations differ significantly, and it's not very intuitive. =

With my suggestion, here's how to delete a single me= mber from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members"

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader.

 

Pro 2: We can apply this mechanism consistently to t= hree areas:

(a) Manipulating multi-valued attributes of a resour= ce

(b) Manipulating members of a group

(c) Performing bulk operations, where we simply use = HTTP verbs instead of the specialised (and semantically less ambiguous) ver= bs I suggested for attributes, the "key" becomes the URI, and the= "value" becomes the corresponding JSON object.

 

All of them return "207 Multi-Status" with= the "results" array holding individual status codes.<= /p>

 

In the current spec, (a) and (b) are done similarly = but (c) is very different.

 

Pro 3: Adoption of the standard by clients is likely= to be higher because it's simpler for them.

 

Pro 4: New (not incumbent) cloud providers will prob= ably find this easier to implement because they have no legacy. They will p= robably use some form of NoSQL database and won't be constrained by the lim= itations of LDAP directories.

 

Cons:

 

Con 1: Incumbent cloud providers with existing data = stores in a directory format (where multi-valued attributes are stored as c= omma-separated values under a single attribute node) will find it difficult= to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinde= r adoption of the spec", which is what you fear.

 

Have I summed up the Pros and Cons correctly? I'm bi= ased of course, so I could have missed a Con or hyped a Pro :-).=

 

In other words, we're debating interface complexity = (current spec) versus implementation complexity (my suggestion). Both can h= inder adoption of the spec by different parties.

 

Here's what we need to discuss - Do the Pros make th= e suggestion worth adopting in spite of the Cons, or are the Cons so great = that it's best to leave the spec as it is?

 

Keep in mind that a complex spec that only favours i= ncumbent cloud providers can cut both ways. It opens the door to a simpler = interface offered by a new generation of nimbler SPs that don't have the sa= me legacy issues, and there could be an exodus of clients to these new SPs. SCIM could end up being obsolete= d very soon, because the API interface is very complex and clumsy, as any n= ew reader can attest. I was taken aback by the complexity when I saw it, wh= ich is why I was prompted to suggest something simpler.

 

This is an issue where we need the opinions of many = people, and they need to state their affiliations. If most people weighing = in belong to incumbent SPs and they vote in favour of interface complexity = to avoid implementation complexity, then it means the spec is not doing a good job of balancing the interests = of various groups. I think we should also poll client organisations to see = what they would want.

 

(Gartner is trusted by enterprise clients to evaluat= e the capabilities of vendors (SPs). I believe Gartner should take the lead= in representing client interests in this working group rather than those o= f incumbent vendors, which is what it seems like to me. Correct me if I'm being unfair.)

 

Regards,

Ganesh

 

 

On 11 August 2012 01:35, Diodati,Mark <Mark.Diodati@gartner.co= m> wrote:

Hi Ganesh,

 

I am concerned about you= r second suggestion:

“2. When dealing w= ith multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique = keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating = it will be clumsy and inelegant.”

 

One of the primary reaso= ns that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most= of the commercial provisioning systems had an SPML interface (either v1 or= v2), but not one of them was conformant to the SPML standard because of co= mplexity. If you are interested, I will forward you the research documents that discuss these problems in d= etail. For SCIM to be successful, it must be adopted by commercial target a= pplications (i.e., service providers). I am confident that a requirement fo= r unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes t= o the service provider’s existing identity storage mechanisms.

Mark

 

 

 

From: Trey Drake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM


To: Ganesh and Sashi Prasad

Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

 

Ganesh,

 

I'll base my comments on your latest reply (b= elow).  

 

The externalID is not part of the protocol. &= nbsp;It is an *optional* attribute within the *schema* specification.  = ;As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters).  P= lease clarify your suggestion.

 

I'm not tracking your coupling concern.  = ;The client can search and hence retrieve resources on any attribute it cho= oses, externalId or otherwise.  Nothing mandates use of externalId.   

 

 

What do you mean by "candidate key"= ?  Given 

 

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and S= ashi Prasad <g= .c.prasad@gmail.com> wrote:

>  I think scim gets its current simp= licity from its single owner hub spoke model implementing tight coupling. [= ...] IMHO loose coupling is a much more complex solution.

 

Phil,

 

I'm a bit surprised that you're implying &quo= t;tight coupling =3D=3D simple" and "loose coupling =3D=3D comple= x". That's contrary to my experience.

 

When I say "loose coupling", I mean= "no unnecessary dependencies". Invariably, a reduction in depend= encies leads to greater simplicity.

 

Let's not confuse reduction of dependencies i= n the data model with a hub-and-spokes architecture. They're entirely ortho= gonal aspects of the solution.

 

All that my suggestion involves is,

 

1. Take 'external ID' out of the protocol.

2. Allow generic search using 'GET /Users' an= d arbitrary URI parameters

 

No planned functionality is lost by this.

 

1. The client enterprise can still send its i= nternal ID as part of the resource body, inside some attribute defined by t= hem (but not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can search for resou= rce URIs using any attribute, including this internal ID<= /p>

'GET /Users?myID=3Dbjensen'=

Since myID is a candidate key, the server wil= l return exactly one URI, which is the canonical URI for the resource<= /o:p>

https://example.com/v1/Users/2819c223-7f=
76-453a-919d-413861904646=

3. The client can use this URI to perform all other operation=
s as usual.
 
So taking 'externalID' out of the protocol spec only does thi=
s:
1. It avoids enshrining tight coupling in the protocol (If cl=
ients want to tightly couple themselves to the cloud provider by sending th=
eir internal IDs, they can do so. Suicide is OK, but the protocol should no=
t be guilty of assisted suicide. ;-)=

2. It encourages loose coupling by nudging clients towards ma=
intaining their own internal-to-external identifier mappings.
 
That's what I'd like to see. I don't believe this complicates=
 the protocol. It simplifies it and it also lends itself to a loosely-coupl=
ed approach.
 
I'll address the multi-valued attribute suggestion separately=
.
 
Regards,
Ganesh
 
 
 

 

On 10 August 2012 07:53, Phil Hunt <phil.hunt@oracle.com> wrote:



Phil

>  storing this information i= n a mapping table outside of the SCIM spec is a great way to enable this so= lution.  Part of the key here is that SCIM is just a piece of the architecture for this solution, and is only responsible for the tra= nsport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I prov= ided that example to illustrate that splitting and merging identities is a = common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.

 

I'm suggesting that the spec do less, not mor= e.

 

What the SCIM spec needs to do there is just = refrain from introducing tight coupling. I would like to see a single ident= ifier exposed through the API, with the implication (and perhaps the recommendation) that it be the shared one. Al= lowing one domain to expose its internal identifier to the other creates ti= ght coupling and ensures that both domains need simultaneously split or mer= ge identities, which is not desirable. So I recommend _taking out_ the "external id" field from the API= . The spec shouldn't encourage tight coupling. If clients want to pass in t= heir internal ids as part of the resource body, no one can stop them, and t= hey can always do a search on that attribute to retrieve the URI exactly as you visualise they will with the "exte= rnal id", but let's not elevate an anti-pattern to a recommendation by= enshrining the "external id" as an acceptable attribute.

 

Am I making sense?

 

I see what you are saying. I think scim gets = its current simplicity from its single owner hub spoke model implementing t= ight coupling. 

 

IMHO loose coupling is a much more complex so= lution. The reality is that each end-point has value to contribute and thus= the single-owner model will eventually need to become multi-owner or multi-hub. 

 

That said i think the current model provides a prac= tical starting point. 

 

>  Regarding unique identifie= rs for multi-valued attributes there is a trade-off involved.  On one = hand this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers. <= o:p>


Precisely. The spec has to strike the right balance. It would be interestin= g to hear from the other members of the spec mailing list. You know where I= stand on this. It would be good to hear the spectrum of opinions.

 

Regards,

Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzl= e@sailpoint.com> wrote:

Thanks Emmanuel.  I= had started writing up a similar response.  As you suggest, storing this information in a mapping table outside of the SCIM spec is a great wa= y to enable this solution.  Part of the key here is that SCIM is just = a piece of the architecture for this solution, and is only responsible for = the transport layer between domains.=

 

You could also model the= se ID mappings in the SCIM user as an extension but would probably not want to expose these externally.  Here is an example of how to mo= del the end state of the false positive scenario (splitting a user):=

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |<= /span>

| 9caf78aac3d6     =   | D2          &nbs= p;      | ff487230b3a0    &nbs= p;  | true         |

| a99a5feba839     =   | D2          &nbs= p;      | 7a87f27c1dd8    &nbs= p;  | true         |

 

This could be represente= d as two SCIM users that contain information about the entities on other domains.

 

{

  "schemas": ["urn:scim:= schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&quo= t;],

  "id": "9caf78aac3d6&qu= ot;,

  "userName": "John Smit= h",

  "urn:scim:schemas:extension:fede= ration:1.0": {

    "linkedUsers": = [

      {

        &= quot;domain": "D2",

        &= quot;externalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:= schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&quo= t;],

  "id": "a99a5feba839&qu= ot;,

  "userName": "John Smit= h",

  "urn:scim:schemas:extension:fede= ration:1.0": {

    "linkedUsers": = [

      {

        &= quot;domain": "D2",

        &= quot;externalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the = linkedUsers attribute would be empty until the split user was synced to domain 2.

 

 

Similarly, the false neg= ative use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain ID | = External Entity ID | Primary flag |<= /span>

| 9caf78aac3d6     =   | D2          &nbs= p;      | ff487230b3a0    &nbs= p;  | true         |

| 9caf78aac3d6     =   | D2          &nbs= p;      | 41206cc97c8b    &nbs= p;  | false        |

 

This could be represente= d with the following SCIM user:

 

{

  "schemas": ["urn:scim:= schemas:core:1.0", "urn:scim:schemas:extension:federation:1.0&quo= t;],

  "id": "9caf78aac3d6&qu= ot;,

  "userName": "John Smit= h",

  "urn:scim:schemas:extension:fede= ration:1.0": {

    "linkedUsers": = [

      {

        &= quot;domain": "D2",

        &= quot;externalEntityId": "ff487230b3a0"

      },

      {

        &= quot;domain": "D2",

        &= quot;externalEntityId": "41206cc97c8b",

        &= quot;deletionRequired": true

      }

    ]

  }

}

 

 

Regarding unique identif= iers for multi-valued attributes there is a trade-off involved.  On one hand this makes PATCH semantics easier.  On the other hand it = puts extra burden on service providers.  Since the inception of SCIM, = a key goal has been to foster adoption by service providers by making thing= s fit easily onto existing systems.  IMO the value gained by unique identifiers for multi-valued attributes is not wort= h the demands put on a service provider.  I also think that vendors th= at have a non-SCIM-compliant API will choose to keep things that way if the= spec is too hard for them to implement.  In a green field environment we do have the luxury of mandating a model to= make certain operations more elegant.  However, we can’t ignore= legacy systems.

 

--Kelly

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org=
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

 

Hi Ganesh,<= o:p>

 

Nothing prevents you in = your SCIM implementation (client or server) to generate a unique identifier for each synchronized object and maintain an internal mapping t= able ( you would have to map group membership as well).

 

This is what we are doin= g with Active Directory sources or targets:

As we didn’t find = an immutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid can change if an AD domain is migrated), we dec= ided to generate and maintain an internal table of ids. This fits your requ= irements as it hides internal ids.

 

This was written in dotn= et and we have started a project to rewrite our SCIM stack in PHP and will give it to the Open Source community. This implementation wil= l have a parameter : AllocateIds versus UseExistingIDs.

This will give the choic= e of “hiding” internalIDs or use them as unique ID.

 

You can also implement s= uch feature without violating the SCIM specs, or without asking to include it in the specs.<= /p>

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 2= 6 78 17 58

Mobile: +33 6 4= 7 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi P= rasad [mailto:g.c= .prasad@gmail.com]
Envoy=E9 : jeudi 9 ao=FBt 2012 03:35
=C0 : Kelly Grizzle
Cc : scim@ie= tf.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvemen= t

 

Hi Kelly,

Thanks for your respon= se. Let me first respond in brief to the two main points you have made, and= then elaborate on the first.

1.      Why= should domains not expose their internal identifiers to other domains?

a.

We are designing a protocol for a federated system of domains, where all do= mains are co-equal peers. (In physics too, N-body problems are much harder = than 2-body problems. :-) Therefore, assuming that there are only two playe= rs in the interaction makes this tightly coupled in a number of ways. We should rely on messaging and notif= ication, with encapsulation of domain-specific data.

b.

In any non-trivial data store, there will always be the ongoing need to mer= ge and split identities as and when “false negatives” and ̶= 0;false positives” are discovered. A domain should be able to handle = this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to external ones = and maintaining this mapping internally allows this loosely-coupled houseke= eping to take place. Sharing internal identifiers (or otherwise outsourcing= the mapping of internal to external identifiers) forces housekeeping activities to be done in lock-step across= domains.

c.

Asynchronous interaction is not just a matter of a suitable wire protocol w= hich can be designed later. The data model plays a crucial role in enabling= or constraining such interaction. A tightly-coupled data model will force = the use of synchronous interactions, and the exposure of internal identifiers is a key part of this tight coupl= ing.

2. The difficulty of assigning unique identifiers to the individual values = of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy data stores to s= uch a model. However, in the larger historical context of cross-domain iden= tity management, we are really at the very early stages. If a relatively ne= w discipline and a brand new spec are held captive to legacy considerations, we are losing an opportunity to= provide a clean and elegant model to subsequent users of the spec, and thi= s will have repercussions over many years or even decades.

b.

If incumbent cloud providers find it hard to immediately adopt the dictiona= ry model for existing multi-valued attributes, they can transition to this = model by offering both “SCIM-compliant” and “non-SCIM-com= pliant” APIs to their customers and encouraging new customers to adopt the “SCIM-compliant” API. Legacy customers = can be supported using a “non-SCIM-compliant” API for an arbitr= arily long period and gradually migrated to the SCIM-compliant API. The log= istics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.

Elaboration of Point 1= :

When we consider feder= ated identity across more than one domain, we have to assume that domains a= re not necessarily master-slave in their interaction. The most generic inte= raction model is peer-to-peer, where entity lifecycle events within a domain are notified to other domains (whe= n necessary) in an asynchronous manner (i.e., through messaging) and the ot= her domains are free to respond to these events in an appropriate manner an= d at a time of their convenience.

A key set of lifecycle= events for an entity is the merging and splitting of identity that is ofte= n required.

The question “Is= this one entity?” can be answered either yes (positive) or no (negat= ive). But sometimes, we can discover false positives and false negatives in= our data stores.

Consider a case where = customers sign up online, and two customers who are privacy-conscious enter= fake IDs such as “John Smith”, and also use the same date of b= irth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intelligent (but incorrect) guess th= at these two persons are the same, and re-assign the same identifier to the= second person. This is a false positive. They appear to be the same entity= , but they're actually different. When the error is discovered, the identities will need to be split, with a= new identifier generated for one of them.<= /span>

Consider the opposite = case where a customer signs up through two different portals or in two diff= erent sessions, using the names “JSmith” and “JohnS”= ;. It is very likely that they will be treated as two different customers and assigned two unique identifiers. This is a false negative. T= hey appear to be two entities, but are actually the same. At a later stage,= when the error is discovered, the identities will have to be merged, and o= ne of the identifiers will have to be dropped.

These are not theoreti= cal use cases. They form a significant proportion of the user base in most = large Web-facing applications. Let's see how these can be managed in a fede= rated way by mapping internal identifiers to external ones and only exposing external identifiers to other domains.<= span lang=3D"EN-US">

a. False positives:

Domain 1 has the follo= wing information about a customer in its data store:

Internal ID: 9caf78aac= 3d6

Attributes: {name: = 220;John Smith”, dob: “01-Jan-1970”}=

When requesting the pr= ovisioning of this entity in Domain 2, the following ID is returned by Doma= in 2: ff487230b3a0.

Domain 1 then maintain= s the following in a mapping table and uses it for translation when talking= to Domain 2, taking care never to expose its internal identifier:

| Internal Entity ID | Extern= al Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff48723= 0b3a0 | true |

When the false positiv= e is discovered and the entity is split, Domain 1 creates a new internal id= entifier and now has the following entity information.=

Internal ID: 9caf78aac= 3d6

Attributes: {name: = 220;John Smith”, dob: “01-Jan-1970”}=

Internal ID: a99a5feba= 839

Attributes: {name: = 220;John Smith”, dob: “01-Jan-1970”}=

This second entity wit= h its own internal identifier is invisible to Domain 2, and this is by desi= gn. Communication about the original entity takes place as before by mappin= g “9caf78aac3d6” to “ff487230b3a0” and vice-versa. At some convenient time (importantly, this doesn't have to= be at the time the split happens), Domain 2 can be requested to provision = a second entity, and when it responds with an identifier of “7a87f27c= 1dd8”, this can go into the mapping table as a new record associated with the second entity's internal identifier.

The mapping table now = contains the following entries:

| Internal Entity ID | Extern= al Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff48723= 0b3a0 | true |

| a99a5feba839 | D2 | 7a87f27= c1dd8 | true |

Domain 2 is not even aware that a split has happened, and the pr= ovisioning that it does is not in lockstep with the split in identity that = occurred in Domain 1.

(What is the “Pr= imary flag” used for? We'll see when we cover the treatment of false = negatives.)

b. False negatives:

Domain 1 has the follo= wing information about what it thinks are two distinct customers in its dat= a store:

Internal ID: 9caf78aac= 3d6

Attributes: {name: = 220;JSmith”, dob: “01-Jan-1970”}

Internal ID: 273d36e30= d09

Attributes: {name: = 220;JohnS”, dob: “01-Jan-1970”}=

When requesting the pr= ovisioning of these entities in Domain 2, the following IDs are returned by= Domain 2: ff487230b3a0 and 41206cc97c8b.

Domain 1 then maintain= s the following in a mapping table and uses it for translation when talking= to Domain 2, taking care never to expose its internal identifiers:

| Internal Entity ID | Extern= al Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff48723= 0b3a0 | true |

| 273d36e30d09 | D2 | 41206cc= 97c8b | true |

When the false negativ= e is discovered and the two entities are merged, Domain 1 drops one of the = internal identifiers and rationalises the name of the customer (say, to = 220;John Smith”). Let's say it retains the first ID “9caf78aac3d6” and drops the second “273d36e30d= 09”.

The mapping table now = looks like this:

| Internal Entity ID | Extern= al Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2 | ff48723= 0b3a0 | true |

| 9caf78aac3d6 | D2 | 41206cc= 97c8b | false |

Now two external ident= ifiers map to the same internal one, so inbound communication from Domain 2= can be unambi

_______________________________________________

 

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

 

 

 

--_000_DF63ACC82673DB40A7AAC08FFA71DFBD27417467AMXPRD0610MB353_-- From g.c.prasad@gmail.com Sun Aug 12 14:30:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A421F868A for ; Sun, 12 Aug 2012 14:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SarNKBPl2d-G for ; Sun, 12 Aug 2012 14:29:56 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45FE521F869D for ; Sun, 12 Aug 2012 14:29:55 -0700 (PDT) Received: by bkty7 with SMTP id y7so1354055bkt.31 for ; Sun, 12 Aug 2012 14:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ducaO6uJ74/EJt/S16JYoYHHiBhUIhPSnSoaBhsK6BA=; b=Ahuzj+SAmK6yLWnuH8ctl+BLu2wKVuEQEWYN5/USgYjFHJ10e9DXfyN+TqJlM45l1O Vh18MslQTkXv6hQtJFbNd8v123csSgKd1YC/pKzSr0LZhUDp2WAp7uhkRDhf0dL0fwXA 7yu5uf2ZIGVtNWnNUC7OwkEnVun+pzgkvipWHv6JRTydD5Lg2WEbzNZfrmbKfj1Bd4ga pX8IHi11lrNcy7mzvyi4J4yXln2SI1hj8qt0voyl6xKsAvdBmgJwd5ffO36qR10P4gHo IqucK+1FJD80oLueT3dO+/228N6yNFSjMAWzTrzc7ikpbHU74UtFd+xve8YhmfGyFW4Z ZXEA== Received: by 10.204.129.208 with SMTP id p16mr3299182bks.129.1344806993802; Sun, 12 Aug 2012 14:29:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Sun, 12 Aug 2012 14:29:32 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Mon, 13 Aug 2012 07:29:32 +1000 Message-ID: To: Emmanuel Dreux Content-Type: multipart/alternative; boundary=00151747ba0628388a04c71847c7 Cc: "scim@ietf.org" , Phil Hunt , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 21:30:01 -0000 --00151747ba0628388a04c71847c7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > Would it have to be stored on the account database of the service provider?**** ** ** Yes. > If so, I believe that this is impracticable in the core schema. Indeed it implies that a service provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration. Why? That doesn't necessarily follow. Implementation is independent of representation. We're talking about a change in representation to make the API cleaner. As a simple example, if an LDAP node is being used to hold a list of comma-separated email addresses, it can just as easily store comma-separated name-value pairs. mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com can be changed to mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com That's why I asked if there was an SP representative on this working group who could explain what such a change could mean for them. As of now, it looks like other people are presuming that SPs will not be able to implement these changes easily and are rejecting them for that reason. Regards, Ganesh On 13 August 2012 04:29, Emmanuel Dreux wrote: > **=F0 **addresses.3cbaaff8e84e.street-number =3D "243"**** > > ** ** > > Where would 3cbaaff8e84e come from? Would it have to be stored on the > account database of the service provider?**** > > ** ** > > If so, I believe that this is impracticable in the core schema. Indeed it > implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > This would be a show stopper. SCIM must be transparent, and must be able > to be put on top of an existing system to provide provisioning apis.**** > > ** ** > > Said differently, SCIM must not be intrusive for existing systems and mus= t > not require modifications to allow its integration.**** > > Correct me if I misunderstood your suggestion.**** > > ** ** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > ** ** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org; Phil Hunt > *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** > > ** ** > > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. **** > > ** ** > > That's exactly the point. How do we "specify completely for uniqueness"?*= * > ** > > ** ** > > In the example below, how are you proposing that the following element be > updated if we can't use positional indexes?**** > > ** ** > > addresses[1].street-number =3D "243"**** > > ** ** > > User object:**** > > ** ** > > {**** > > ...**** > > addresses: [**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > ]**** > > }**** > > ** ** > > It's impractical to use the value because it's the whole dictionary > element:**** > > ** ** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > ** ** > > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element:**** > > ** ** > > addresses.3cbaaff8e84e.street-number =3D "243"**** > > ** ** > > {**** > > ...**** > > addresses: {**** > > "d6ea365462f5" :**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > "3cbaaff8e84e" :**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > }**** > > }**** > > ** ** > > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written.**** > > ** ** > > There's a lot of talk about the "burden" on the SPs, but I believe this i= s > overblown. Is there any SP representative in this WG who can tell us what > this proposal will actually entail for them?**** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > On 12 August 2012 11:53, Kelly Grizzle > wrote:**** > > Ganesh,**** > > ** ** > > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t > have a value sub-attribute can be removed by specifying only the value > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption.**** > > ** ** > > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort.**** > > ** ** > > I'm curious if anyone else in the WG is in favor of unique identifiers fo= r > every multi-valued element.**** > > ** ** > > --Kelly**** > > ** ** > ------------------------------ > > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > Phil, **** > > ** ** > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > **** > > ** ** > > Regards,**** > > Ganesh**** > > On 12 August 2012 01:12, Phil Hunt wrote:**** > > Ganesh, **** > > ** ** > > Here's the sample that concerned me...**** > > The two operations differ significantly, and it's not very intuitive. **= * > * > > With my suggestion, here's how to delete a single member from a group:***= * > > ** ** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } **** > > ** ** > > ** ** > > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys.**** > > ** ** > > Given that multi-values must be each unique, I don't see the point of the > extra indexing to support this. Just use the value as the item you wish t= o > delete.**** > > ** ** > > I agree, the delete value operation could be more explicit and clear in > general.**** > > ** ** > > Phil**** > > ** ** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > ** ** > > ** ** > > ** ** > > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** > > > > **** > > > For the multi-value example you gave you used the value as the > attribute name key. **** > > ** ** > > Now I'm confused :-). I don't believe any of my examples ever used a valu= e > as the key.**** > > ** ** > > Could you please show me which example you mean, and which parts of it yo= u > believe to be the value?**** > > ** ** > > Regards,**** > > Ganesh **** > > On 11 August 2012 13:59, Phil Hunt wrote:**** > > > For the multi-value example you gave you used the value as the attribute > name key. **** > > ** ** > > That means a lot more complex indexing structure. Better to just say > delete a specific value. **** > > ** ** > > The spec already allows multiple values to have tags like home, work, etc= . > **** > > ** ** > > Phil**** > > > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote:**** > > > In your example you are conflating value with an attribute id. > > I don't believe so. **** > > ** ** > > I'm adopting a model where every attribute of the resource is a key-value > pair. The key is a name or ID.**** > > ** ** > > For non-repeating attributes (both simple and composite), the key is the > attribute name itself. **** > > ** ** > > Simple attribute:**** > > ** ** > > Key: "dob"**** > > Value: "01 Jan 1970"**** > > ** ** > > For composite attributes, the key employs dot notation to specify the > fully-qualified attribute name, e.g., "address.postcode".**** > > ** ** > > Composite attribute:**** > > ** ** > > Key: "address.street-number"**** > > Value: "10"**** > > ** ** > > Key: "address.suburb"**** > > Value: "East Camden"**** > > ** ** > > For repeating (multi-valued) attributes, I'm suggesting that there be new > keys for each individual value, otherwise they are impossible to > distinguish, and a positional index is inadequate. So we convert the arra= y > into a dictionary and this then becomes a composite attribute using dot > notation for the key.**** > > ** ** > > Multi-valued attribute:**** > > ** ** > > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** > > Value: "john_smith@yahoo.com"**** > > ** ** > > So this allows us to apply uniform treatment to any arbitrarily deep > resource structure. We can refer to every leaf value with a key that is t= he > fully-qualified name using dot notation.**** > > ** ** > > The verbs are just unambiguous operations on these (now) explicitly > addressable attributes.**** > > ** ** > > INCLUDE to a collection and specify only the value. The key is generated > and returned. The fully-qualified key is > . and the value is what was specifie= d > in the INCLUDE.**** > > ** ** > > REPLACE a fully-qualified key with a new value. If the key doesn't exist, > return a "404 Not Found".**** > > ** ** > > PLACE a value at the logical location implied by the fully-qualified key. > If there is already a key with that name, return a "409 Conflict".**** > > ** ** > > FORCE the fully-qualified key to hold the given value, regardless of > whether it existed before or not. Only errors possible are "400 Bad > Request" and "500 Internal Error".**** > > ** ** > > RETIRE an attribute or a collection given its fully-qualified key. The > implementation will determine whether the attribute will disappear entire= ly > or will exist holding a null value (the blank string "" or the empty obje= ct > {} ).**** > > ** ** > > I'll explain in a separate post why we need operation verbs like these > that are independent of the HTTP verbs.**** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > On 11 August 2012 10:38, wrote:**** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) > > > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux < > edreux@cloudiway.com>, Trey Drake , Kelly > Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > Ganesh,**** > > ** ** > > In your example you are conflating value with an attribute id. I find tha= t > confusing. **** > > ** ** > > I agree though that operations in patch could be a lot more explicit. ***= * > > ** ** > > Eg explicitly deleting a value by saying delete or retire. **** > > > Phil**** > > > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote:**** > > > I am concerned about your second suggestion: **** > > ** ** > > Let's discuss that now.**** > > ** ** > > The trade-offs are very clear here.**** > > ** ** > > Pros:**** > > ** ** > > Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t > and intuitive when every individual attribute value gets its own ID.**** > > ** ** > > Here's how to delete a single member from a Group, as per the current spe= c: > **** > > ** ** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > ** ** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "members": [**** > > {**** > > "display": "Babs Jensen",**** > > "value": "2819c223-7f76-453a-919d-413861904646"**** > > "operation": "delete"**** > > }**** > > ]**** > > }**** > > > Here's how to delete ALL members from a group according to the current > spec:**** > > ** ** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > ** ** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "meta": {**** > > "attributes": [**** > > "members"**** > > ]**** > > }**** > > }**** > > > The two operations differ significantly, and it's not very intuitive. ***= * > > With my suggestion, here's how to delete a single member from a group:***= * > > ** ** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } > Here's how I suggest deleting ALL members from a group:**** > > ** ** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members"**** > > }**** > > }**** > > ] } **** > > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader.**** > > ** ** > > Pro 2: We can apply this mechanism consistently to three areas:**** > > (a) Manipulating multi-valued attributes of a resource**** > > (b) Manipulating members of a group**** > > (c) Performing bulk operations, where we simply use HTTP verbs instead of > the specialised (and semantically less ambiguous) verbs I suggested for > attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object.**** > > ** ** > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes.**** > > ** ** > > In the current spec, (a) and (b) are done similarly but (c) is very > different.**** > > ** ** > > Pro 3: Adoption of the standard by clients is likely to be higher because > it's simpler for them.**** > > ** ** > > Pro 4: New (not incumbent) cloud providers will probably find this easier > to implement because they have no legacy. They will probably use some for= m > of NoSQL database and won't be constrained by the limitations of LDAP > directories.**** > > ** ** > > Cons:**** > > ** ** > > Con 1: Incumbent cloud providers with existing data stores in a directory > format (where multi-valued attributes are stored as comma-separated value= s > under a single attribute node) will find it difficult to migrate to this > model and store each attribute value as a sub-node with its own key. This > will "hinder adoption of the spec", which is what you fear.**** > > ** ** > > Have I summed up the Pros and Cons correctly? I'm biased of course, so I > could have missed a Con or hyped a Pro :-).**** > > ** ** > > In other words, we're debating interface complexity (current spec) versus > implementation complexity (my suggestion). Both can hinder adoption of th= e > spec by different parties.**** > > ** ** > > Here's what we need to discuss - Do the Pros make the suggestion worth > adopting in spite of the Cons, or are the Cons so great that it's best to > leave the spec as it is?**** > > ** ** > > Keep in mind that a complex spec that only favours incumbent cloud > providers can cut both ways. It opens the door to a simpler interface > offered by a new generation of nimbler SPs that don't have the same legac= y > issues, and there could be an exodus of clients to these new SPs. SCIM > could end up being obsoleted very soon, because the API interface is very > complex and clumsy, as any new reader can attest. I was taken aback by th= e > complexity when I saw it, which is why I was prompted to suggest somethin= g > simpler.**** > > ** ** > > This is an issue where we need the opinions of many people, and they need > to state their affiliations. If most people weighing in belong to incumbe= nt > SPs and they vote in favour of interface complexity to avoid implementati= on > complexity, then it means the spec is not doing a good job of balancing t= he > interests of various groups. I think we should also poll client > organisations to see what they would want.**** > > ** ** > > (Gartner is trusted by enterprise clients to evaluate the capabilities of > vendors (SPs). I believe Gartner should take the lead in representing > client interests in this working group rather than those of incumbent > vendors, which is what it seems like to me. Correct me if I'm being unfai= r.) > **** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > ** ** > > On 11 August 2012 01:35, Diodati,Mark wrote:**= * > * > > Hi Ganesh,**** > > **** > > I am concerned about your second suggestion: **** > > =932. When dealing with multi-valued attributes of a resource (expressed = as > arrays in JSON), they must be converted from an array into a dictionary > with unique keys (UUIDs generated by the cloud provider when the attribut= e > is created). Without unique keys for every attribute value of a resource, > manipulating it will be clumsy and inelegant.=94**** > > **** > > One of the primary reasons that SPML failed was lack of adoption by > service providers due to its complexity. Very few target applications > implemented SPML. Most of the commercial provisioning systems had an SPML > interface (either v1 or v2), but not one of them was conformant to the SP= ML > standard because of complexity. If you are interested, I will forward you > the research documents that discuss these problems in detail. For SCIM to > be successful, it must be adopted by commercial target applications (i.e.= , > service providers). I am confident that a requirement for unique > identifiers with multi-valued attributes will preclude its adoption, > because it requires major changes to the service provider=92s existing > identity storage mechanisms. **** > > Mark**** > > **** > > **** > > **** > > *From:* Trey Drake [mailto:trey.drake@unboundid.com] > *Sent:* Friday, August 10, 2012 9:51 AM**** > > > *To:* Ganesh and Sashi Prasad**** > > *Cc:* scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt **** > > > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > ** ** > > **** > > Ganesh,**** > > **** > > I'll base my comments on your latest reply (below). **** > > **** > > The externalID is not part of the protocol. It is an *optional* attribut= e > within the *schema* specification. As for #2, the protocol spec works as > you describe if "arbitrary URI parameters" equate to resource attributes > (Allow generic search using 'GET /Users' and arbitrary URI parameters). > Please clarify your suggestion.**** > > **** > > I'm not tracking your coupling concern. The client can search and hence > retrieve resources on any attribute it chooses, externalId or otherwise. > Nothing mandates use of externalId. **** > > **** > > **** > > What do you mean by "candidate key"? Given **** > > **** > > On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad < > g.c.prasad@gmail.com> wrote:**** > > > I think scim gets its current simplicity from its single owner hub > spoke model implementing tight coupling. [...] IMHO loose coupling is a > much more complex solution.**** > > **** > > Phil,**** > > **** > > I'm a bit surprised that you're implying "tight coupling =3D=3D simple" a= nd > "loose coupling =3D=3D complex". That's contrary to my experience.**** > > **** > > When I say "loose coupling", I mean "no unnecessary dependencies". > Invariably, a reduction in dependencies leads to greater simplicity.**** > > **** > > Let's not confuse reduction of dependencies in the data model with a > hub-and-spokes architecture. They're entirely orthogonal aspects of the > solution.**** > > **** > > All that my suggestion involves is,**** > > **** > > 1. Take 'external ID' out of the protocol.**** > > 2. Allow generic search using 'GET /Users' and arbitrary URI parameters**= * > * > > **** > > No planned functionality is lost by this.**** > > **** > > 1. The client enterprise can still send its internal ID as part of the > resource body, inside some attribute defined by them (but not defined by > the protocol). Let's say they call it 'myID'.**** > > 2. The client enterprise can search for resource URIs using any attribute= , > including this internal ID**** > > 'GET /Users?myID=3Dbjensen'**** > > Since myID is a candidate key, the server will return exactly one URI, > which is the canonical URI for the resource**** > > https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646**** > > 3. The client can use this URI to perform all other operations as usual.*= *** > > **** > > So taking 'externalID' out of the protocol spec only does this:**** > > 1. It avoids enshrining tight coupling in the protocol (If clients want t= o tightly couple themselves to the cloud provider by sending their internal= IDs, they can do so. Suicide is OK, but the protocol should not be guilty = of assisted suicide. ;-)**** > > 2. It encourages loose coupling by nudging clients towards maintaining th= eir own internal-to-external identifier mappings.**** > > **** > > That's what I'd like to see. I don't believe this complicates the protoco= l. It simplifies it and it also lends itself to a loosely-coupled approach.= **** > > **** > > I'll address the multi-valued attribute suggestion separately.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > **** > > **** > > **** > > On 10 August 2012 07:53, Phil Hunt wrote:**** > > > > Phil**** > > > On 2012-08-09, at 14:14, Ganesh and Sashi Prasad > wrote:**** > > > storing this information in a mapping table outside of the SCIM spec > is a great way to enable this solution. Part of the key here is that SCI= M > is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains. > > I wasn't suggesting that the mapping table be part of the SCIM spec. I > provided that example to illustrate that splitting and merging identities > is a common requirement, and that decoupling local identifiers within a > domain from shared identifiers between domains was the best way to > facilitate it.**** > > **** > > I'm suggesting that the spec do less, not more.**** > > **** > > What the SCIM spec needs to do there is just refrain from introducing > tight coupling. I would like to see a single identifier exposed through t= he > API, with the implication (and perhaps the recommendation) that it be the > shared one. Allowing one domain to expose its internal identifier to the > other creates tight coupling and ensures that both domains need > simultaneously split or merge identities, which is not desirable. So I > recommend _taking out_ the "external id" field from the API. The spec > shouldn't encourage tight coupling. If clients want to pass in their > internal ids as part of the resource body, no one can stop them, and they > can always do a search on that attribute to retrieve the URI exactly as y= ou > visualise they will with the "external id", but let's not elevate an > anti-pattern to a recommendation by enshrining the "external id" as an > acceptable attribute.**** > > **** > > Am I making sense?**** > > **** > > I see what you are saying. I think scim gets its current simplicity from > its single owner hub spoke model implementing tight coupling. **** > > **** > > IMHO loose coupling is a much more complex solution. The reality is that > each end-point has value to contribute and thus the single-owner model wi= ll > eventually need to become multi-owner or multi-hub. **** > > **** > > That said i think the current model provides a practical starting point. = * > *** > > **** > > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. **** > > > Precisely. The spec has to strike the right balance. It would be > interesting to hear from the other members of the spec mailing list. You > know where I stand on this. It would be good to hear the spectrum of > opinions.**** > > **** > > Regards,**** > > Ganesh**** > > On 10 August 2012 00:28, Kelly Grizzle > wrote:**** > > Thanks Emmanuel. I had started writing up a similar response. As you > suggest, storing this information in a mapping table outside of the SCIM > spec is a great way to enable this solution. Part of the key here is tha= t > SCIM is just a piece of the architecture for this solution, and is only > responsible for the transport layer between domains.**** > > **** > > You could also model these ID mappings in the SCIM user as an extension > but would probably not want to expose these externally. Here is an examp= le > of how to model the end state of the false positive scenario (splitting a > user):**** > > **** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true |**** > > | a99a5feba839 | D2 | 7a87f27c1dd8 | > true |**** > > **** > > This could be represented as two SCIM users that contain information abou= t > the entities on other domains.**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "9caf78aac3d6",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "ff487230b3a0"**** > > }**** > > ]**** > > }**** > > }**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "a99a5feba839",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "7a87f27c1dd8"**** > > }**** > > ]**** > > }**** > > }**** > > **** > > In the second user, the linkedUsers attribute would be empty until the > split user was synced to domain 2.**** > > **** > > **** > > Similarly, the false negative use case (merging two users) looked like > this at the end:**** > > **** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | > true |**** > > | 9caf78aac3d6 | D2 | 41206cc97c8b | > false |**** > > **** > > This could be represented with the following SCIM user:**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0", > "urn:scim:schemas:extension:federation:1.0"],**** > > "id": "9caf78aac3d6",**** > > "userName": "John Smith",**** > > "urn:scim:schemas:extension:federation:1.0": {**** > > "linkedUsers": [**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "ff487230b3a0"**** > > },**** > > {**** > > "domain": "D2",**** > > "externalEntityId": "41206cc97c8b",**** > > "deletionRequired": true**** > > }**** > > ]**** > > }**** > > }**** > > **** > > **** > > Regarding unique identifiers for multi-valued attributes there is a > trade-off involved. On one hand this makes PATCH semantics easier. On t= he > other hand it puts extra burden on service providers. Since the inceptio= n > of SCIM, a key goal has been to foster adoption by service providers by > making things fit easily onto existing systems. IMO the value gained by > unique identifiers for multi-valued attributes is not worth the demands p= ut > on a service provider. I also think that vendors that have a > non-SCIM-compliant API will choose to keep things that way if the spec is > too hard for them to implement. In a green field environment we do have > the luxury of mandating a model to make certain operations more elegant. > However, we can=92t ignore legacy systems. **** > > **** > > --Kelly**** > > **** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Emmanuel Dreux > *Sent:* Thursday, August 09, 2012 3:18 AM > *To:* Ganesh and Sashi Prasad; Kelly Grizzle > *Cc:* scim@ietf.org > *Subject:* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > **** > > Hi Ganesh,**** > > **** > > Nothing prevents you in your SCIM implementation (client or server) to > generate a unique identifier for each synchronized object and maintain an > internal mapping table ( you would have to map group membership as well).= * > *** > > **** > > This is what we are doing with Active Directory sources or targets:**** > > As we didn=92t find an immutable uniqueID in AD systems (DN,samAccountNam= e, > UPN) are subject to change (even objectGuid can change if an AD domain is > migrated), we decided to generate and maintain an internal table of ids. > This fits your requirements as it hides internal ids.**** > > **** > > This was written in dotnet and we have started a project to rewrite our > SCIM stack in PHP and will give it to the Open Source community. This > implementation will have a parameter : AllocateIds versus UseExistingIDs.= * > *** > > This will give the choice of =93hiding=94 internalIDs or use them as uniq= ue ID. > **** > > **** > > You can also implement such feature without violating the SCIM specs, or > without asking to include it in the specs.**** > > **** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > **** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > > *Envoy=E9 :* jeudi 9 ao=FBt 2012 03:35 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org > *Objet :* Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > **** > > Hi Kelly,**** > > Thanks for your response. Let me first respond in brief to the two main > points you have made, and then elaborate on the first.**** > > 1. Why should domains not expose their internal identifiers to other > domains?**** > > a.**** > > We are designing a protocol for a federated system of domains, where all > domains are co-equal peers. (In physics too, N-body problems are much > harder than 2-body problems. :-) Therefore, assuming that there are only > two players in the interaction makes this tightly coupled in a number of > ways. We should rely on messaging and notification, with encapsulation of > domain-specific data.**** > > b. **** > > In any non-trivial data store, there will always be the ongoing need to > merge and split identities as and when =93false negatives=94 and =93false > positives=94 are discovered. A domain should be able to handle this inter= nal > housekeeping freely, only notifying other domains when convenient. Mappin= g > of internal identifiers to external ones and maintaining this mapping > internally allows this loosely-coupled housekeeping to take place. Sharin= g > internal identifiers (or otherwise outsourcing the mapping of internal to > external identifiers) forces housekeeping activities to be done in > lock-step across domains.**** > > c.**** > > Asynchronous interaction is not just a matter of a suitable wire protocol > which can be designed later. The data model plays a crucial role in > enabling or constraining such interaction. A tightly-coupled data model > will force the use of synchronous interactions, and the exposure of > internal identifiers is a key part of this tight coupling.**** > > 2. The difficulty of assigning unique identifiers to the individual value= s > of multi-valued attributes:**** > > a. **** > > I'm not belittling the effort involved in migrating legacy data stores to > such a model. However, in the larger historical context of cross-domain > identity management, we are really at the very early stages. If a > relatively new discipline and a brand new spec are held captive to legacy > considerations, we are losing an opportunity to provide a clean and elega= nt > model to subsequent users of the spec, and this will have repercussions > over many years or even decades.**** > > b. **** > > If incumbent cloud providers find it hard to immediately adopt the > dictionary model for existing multi-valued attributes, they can transitio= n > to this model by offering both =93SCIM-compliant=94 and =93non-SCIM-compl= iant=94 > APIs to their customers and encouraging new customers to adopt the > =93SCIM-compliant=94 API. Legacy customers can be supported using a > =93non-SCIM-compliant=94 API for an arbitrarily long period and gradually > migrated to the SCIM-compliant API. The logistics are not insurmountable, > and shouldn't prevent the adoption of a dictionary model for multi-valued > attributes.**** > > Elaboration of Point 1:**** > > When we consider federated identity across more than one domain, we have > to assume that domains are not necessarily master-slave in their > interaction. The most generic interaction model is peer-to-peer, where > entity lifecycle events within a domain are notified to other domains (wh= en > necessary) in an asynchronous manner (i.e., through messaging) and the > other domains are free to respond to these events in an appropriate manne= r > and at a time of their convenience.**** > > A key set of lifecycle events for an entity is the merging and splitting > of identity that is often required.**** > > The question =93Is this one entity?=94 can be answered either yes (positi= ve) > or no (negative). But sometimes, we can discover false positives and fals= e > negatives in our data stores.**** > > Consider a case where customers sign up online, and two customers who are > privacy-conscious enter fake IDs such as =93John Smith=94, and also use t= he > same date of birth (say, 1 Jan 1970) or similar attributes. The front-end > application may make an intelligent (but incorrect) guess that these two > persons are the same, and re-assign the same identifier to the second > person. This is a false positive. They appear to be the same entity, but > they're actually different. When the error is discovered, the identities > will need to be split, with a new identifier generated for one of them.**= * > * > > Consider the opposite case where a customer signs up through two differen= t > portals or in two different sessions, using the names =93JSmith=94 and = =93JohnS=94. > It is very likely that they will be treated as two different customers an= d > assigned two unique identifiers. This is a false negative. They appear to > be two entities, but are actually the same. At a later stage, when the > error is discovered, the identities will have to be merged, and one of th= e > identifiers will have to be dropped.**** > > These are not theoretical use cases. They form a significant proportion o= f > the user base in most large Web-facing applications. Let's see how these > can be managed in a federated way by mapping internal identifiers to > external ones and only exposing external identifiers to other domains.***= * > > a. False positives:**** > > Domain 1 has the following information about a customer in its data store= : > **** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > When requesting the provisioning of this entity in Domain 2, the followin= g > ID is returned by Domain 2: ff487230b3a0.**** > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifier:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > When the false positive is discovered and the entity is split, Domain 1 > creates a new internal identifier and now has the following entity > information.**** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > Internal ID: a99a5feba839**** > > Attributes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}**** > > This second entity with its own internal identifier is invisible to Domai= n > 2, and this is by design. Communication about the original entity takes > place as before by mapping =939caf78aac3d6=94 to =93ff487230b3a0=94 and v= ice-versa. > At some convenient time (importantly, this doesn't have to be at the time > the split happens), Domain 2 can be requested to provision a second entit= y, > and when it responds with an identifier of =937a87f27c1dd8=94, this can g= o into > the mapping table as a new record associated with the second entity's > internal identifier.**** > > The mapping table now contains the following entries:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | a99a5feba839 | D2 | 7a87f27c1dd8 | true |**** > > Domain 2 is not even aware that a split has happened, and the provisionin= g > that it does is not in lockstep with the split in identity that occurred = in > Domain 1.**** > > (What is the =93Primary flag=94 used for? We'll see when we cover the > treatment of false negatives.)**** > > b. False negatives:**** > > Domain 1 has the following information about what it thinks are two > distinct customers in its data store:**** > > Internal ID: 9caf78aac3d6**** > > Attributes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}**** > > Internal ID: 273d36e30d09**** > > Attributes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}**** > > When requesting the provisioning of these entities in Domain 2, the > following IDs are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.***= * > > Domain 1 then maintains the following in a mapping table and uses it for > translation when talking to Domain 2, taking care never to expose its > internal identifiers:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | 273d36e30d09 | D2 | 41206cc97c8b | true |**** > > When the false negative is discovered and the two entities are merged, > Domain 1 drops one of the internal identifiers and rationalises the name = of > the customer (say, to =93John Smith=94). Let's say it retains the first I= D > =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.**** > > The mapping table now looks like this:**** > > | Internal Entity ID | External Domain ID | External Entity ID | Primary > flag |**** > > | 9caf78aac3d6 | D2 | ff487230b3a0 | true |**** > > | 9caf78aac3d6 | D2 | 41206cc97c8b | false |**** > > Now two external identifiers map to the same internal one, so inbound > communication from Domain 2 can be unambi**** > > _______________________________________________ **** > > > 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**** > > ** ** > > ** ** > > ** ** > --00151747ba0628388a04c71847c7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

&= gt; Would it have to be stored on the account database of the service provi= der?

=A0

Y= es.


> If so, I believe that this is impracticable= in the core schema.=A0Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integrat= ion.


Why? That doesn't necessarily follow. Implementatio= n is independent of representation. We're talking about a change in rep= resentation to make the API cleaner.

As a simple e= xample, if an LDAP node is being used to hold a list of comma-separated ema= il addresses, it can just as easily store comma-separated name-value pairs.=

<= div>
Yes. I object. ExternalId i= s optional. There is no need for this major breaking change. IMHO. 

Phil

On 2012-08-11, at 10:18, Ganesh and Sashi Pras= ad <g.c.prasad@gmail.com> w= rote:

&g= t; And that's because?  I don't see any value to the behavior (ena= bling attribute searches on non-existent schema) you suggest. 

I wasn't suggesting there was value in it= . I was covering the possibility that the client could erroneously send URI p= arameters that are not valid attributes of the resource, and the only respon= se to such requests is a "400 Bad Request".

>  My question is why do you believe an SP ought to care about "candidate keys"= ?   Resources are uniquely identified exactly 1 way by the SP and that i= s by the SP minted id.  The Consumer can retrieve a resource by any att= ribute though only the id is guaranteed to be unique from the POV of the SP.=  The SCIM model is a *mapping* between the consumer and SP hence it is= not a prescription for how the Resource data is actually stored on either s= ide. 

I think we may actually be in violent agreement here! Yo= ur description exactly matches my recommendation of a data model that is loo= sely-coupled between client and SP. The SP should not care about "candidate k= eys", of course. But if one of the attributes of the resource happens to be a= client-internal key, then the _client_ knows that it is a candidate key, an= d that any search based on the candidate key will return at most one URI wit= h the "SP minted ID".

This is what I'd like to see in the SCIM spec. There is o= nly one key exposed _as a key_ between client and SP, and that is the "SP mi= nted ID". There is no _special_ attribute in the API called an "external ID"= . If the client wants to embed its internal identifier as an attribute withi= n the resource, it is free to do so. The SP will treat it as just another at= tribute and will not even bother to impose a uniqueness constraint on it.

> If externalId were dropped it wouldn't bother m= e a bit.  

Good.= Does anyone have an actual _objection_ to dropping the "externalID" field? A= s I said above, it doesn't prevent a client from sending such an attribute a= s an ordinary attribute and doing searches on it. Keeping the SP ignorant of= its status as a key within the client decouples the two parties to some ext= ent, so dropping the specially-named "externalID" is desirable.

Regards,
Ganesh

On 12 August 2012 01:59, Trey Drake <trey.drake@unboundid.com> wrote:

Trey,

> The externalID is not part of the protocol.  = ;It is an *optional* attribute within the *schema* specification.

I didn't realise SCIM w= as also specifying a User schema. Does this mean the User resource can only h= old certain attributes as defined by this schema? If so, that's going to be a= severe constraint, because client organisations are likely to require many s= pecialised User attributes depending on the nature of their business, and th= ey will expect to be able to store all of them, not just the subset defined b= y the SCIM spec. I hope the SCIM User schema is not trying to be just a repr= esentation of inetOrgPerson (the standard LDAP schema), because that could b= e severely limiting. Most organisations with their own LDAP end up extending= inetOrgPerson, and they will expect that they can do the same in the cloud.=

I recommend you read= the relevant specifications. The working group has accepted both a sch= ema and protocol draft as input to the effort. 

> As fo= r #2, the protocol spec works as you describe if "arbitrary URI parameters" e= quate to resource attributes 

Yes, that's what I meant, but in implementation, it may w= ork out to be looser than that. The client should be able to specify any arb= itrary attribute in the search parameters, even those that aren't attributes= of the resource. If an attribute is not defined, or if the attribute exists= but the value doesn't match any stored record, the SP will return no result= s. In the former case, it's a "400 Bad Request" and in the latter, it's a "4= 04 Not Found".
And that's because?  I don't see any valu= e to the behavior (enabling attribute searches on non-existent schema) you s= uggest. 


By "candidate key" (a data modelling term), I meant anot= her attribute that also uniquely identifies a single record, but is not the o= fficial "primary key", i.e., the main ID. In this case, a client's internal i= dentifier also uniquely identifies a record, but is not the ID used in the U= RI of RESTful operations.

I know what a candidate key is. &nbs= p;My question is why do you believe an SP ought to care about "candidate key= s"?   Resources are uniquely identified exactly 1 way by the SP and tha= t is by the SP minted id.  The Consumer can retrieve a resource by any a= ttribute though only the id is guaranteed to be unique from the POV of the S= P.  The SCIM model is a *mapping* between the consumer and SP hence it i= s not a prescription for how the Resource data is actually stored on either s= ide.
  

Look, this may seem to be splitting hairs since a determ= ined client may be able to store and search by their own internal ID in eith= er case (the current SCIM spec or my suggestion). The difference is philosop= hical. If the spec is showing how clients can store their internal IDs in th= e cloud by explicitly providing for such an attribute, that constitutes bad a= dvice, IMO. If it turns a blind eye to what they store and they store intern= al IDs anyway, they're constraining themselves but the spec comes out smelli= ng of roses because that's not "recommended practice".


If externalId we= re dropped it wouldn't bother me a bit.  
<= br>
Ganesh

On 11 August 2012 00:50, Trey Drake <trey.drake@unboundid.com>= wrote:
Ganesh,

I'll base my commen= ts on your latest reply (below).  

The externa= lID is not part of the protocol.  It is an *optional* attribute within t= he *schema* specification.  As for #2, the protocol spec works as you d= escribe if "arbitrary URI parameters" equate to resource attributes (Allow g= eneric search using 'GET /Users' and arbitrary URI parameters).  Please= clarify your suggestion.

I'm not tracking your coupling concern.  The client= can search and hence retrieve resources on any attribute it chooses, extern= alId or otherwise.  Nothing mandates use of externalId.   


What do you mean by "candidate key"?  Given&nb= sp;

On Fri, Aug 10, 2012 at 5:= 49 AM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote= :
>  I think scim gets its current simplicity from its single owner hub spoke mod= el implementing tight coupling. [...] IMHO loose coupling is a much mor= e complex solution.

Phil,

I'm a b= it surprised that you're implying "tight coupling =3D=3D simple" and "loose c= oupling =3D=3D complex". That's contrary to my experience.

When I say "loose coupling", I mean "no unnecessary depe= ndencies". Invariably, a reduction in dependencies leads to greater simplici= ty.

Let's not confuse reduction of dependencies in t= he data model with a hub-and-spokes architecture. They're entirely orthogona= l aspects of the solution.

All that my suggestion involves is,

=
1. Take 'external ID' out of the protocol.
2. Allow generic s= earch using 'GET /Users' and arbitrary URI parameters

No planned functionality is lost by this.

=
1. The client enterprise can still send its internal ID as part o= f the resource body, inside some attribute defined by them (but not defined b= y the protocol). Let's say they call it 'myID'.
2. The client enterprise can search for resource URIs using any attribu= te, including this internal ID
'GET /Users?myID=3Dbjensen'
Since myID is a candidate key, the server will return exactly one URI, wh= ich is the canonical URI for the resource
https://example.com/v1/Users/2819c2=
23-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other operatio=
ns as usual.

So taking 'externalID' out o=
f the protocol spec only does this:
1. It avoids enshrining tight coupling in the protocol (If c=
lients want to tightly couple themselves to the cloud provider by sending th=
eir internal IDs, they can do so. Suicide is OK, but the protocol should not=
 be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards m=
aintaining their own internal-to-external identifier mappings.

That's what I'd like to see=
. I don't believe this complicates the protocol. It simplifies it and it als=
o lends itself to a loosely-coupled approach.

I'll address the multi-valu=
ed attribute suggestion separately.

Regards,
Ganesh



On 10 August 2012 07:53, Phil Hunt <= span dir=3D"ltr"><phil.hunt@oracle.com> wrote:


Phil

On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com&= gt; wrote:

>  storing this information in a mapping table outside of the SCIM spec i= s a great way to enable this solution.  Part of the key here is that SC= IM is just a piece of the architecture for this solution, and is only respon= sible for the transport layer between domains. 

I wasn't suggesting that the mapping table be part of the SCIM spec. I p= rovided that example to illustrate that splitting and merging identities is a= common requirement, and that decoupling local identifiers within a domain f= rom shared identifiers between domains was the best way to facilitate it.
I'm suggesting that the spec do less, not more.

What the SCIM spec needs to do there is just refrain from introducing tight= coupling. I would like to see a single identifier exposed through the API, w= ith the implication (and perhaps the recommendation) that it be the shared o= ne. Allowing one domain to expose its internal identifier to the other creat= es tight coupling and ensures that both domains need simultaneously split or= merge identities, which is not desirable. So I recommend _taking out_ the "= external id" field from the API. The spec shouldn't encourage tight coupling= . If clients want to pass in their internal ids as part of the resource body= , no one can stop them, and they can always do a search on that attribute to= retrieve the URI exactly as you visualise they will with the "external id",= but let's not elevate an anti-pattern to a recommendation by enshrining the= "external id" as an acceptable attribute.

Am I making sense?

I see what you are saying. I think scim gets its current simplicity from i= ts single owner hub spoke model implementing tight coupling. 

IMHO loose coupling is a much more complex solution. The real= ity is that each end-point has value to contribute and thus the single-owner= model will eventually need to become multi-owner or multi-hub. 

That said i think the current model provides a practical= starting point. 

>  Regarding unique identifiers for multi-valued attributes there is a t= rade-off involved.  On one hand this makes PATCH semantics easier. = ; On the other hand it puts extra burden on service providers. <= /div>

Precisely. The spec has to strike the right balance. It would be in= teresting to hear from the other members of the spec mailing list. You know w= here I stand on this. It would be good to hear the spectrum of opinions.

Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sailpoin= t.com> wrote:

Thanks Emmanuel. = I had started writing up a similar response.  As you suggest, storing t= his information in a mapping table outside of the SCIM spec is a great way to enable this solution.  Part of the key here is that SCIM is jus= t a piece of the architecture for this solution, and is only responsible for= the transport layer between domains.

 

You could also model these ID mappings in the S= CIM user as an extension but would probably not want to expose these externa= lly.  Here is an example of how to model the end state of the false positive scenario (splitting a user):

 

| Internal Entity ID | External Domain ID | Ext= ernal Entity ID | Primary flag |

| 9caf78aac3d6       | D2  &nb= sp;            &= nbsp; | ff487230b3a0       | true  &= nbsp;      |

| a99a5feba839       | D2 =             &nbs= p;   | 7a87f27c1dd8       | true&nbs= p;        |

 

This could be represe= nted as two SCIM users that contain information about the entities on other d= omains.

 =

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

  &nbs= p; "linkedUsers": [

      {<= /span>

      &= nbsp; "domain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      }

    ]

  }

}

 

{

  "schemas": ["urn:scim:schemas:core:1.0", "urn:scim:schemas:ex= tension:federation:1.0"],

  "id": "a99a5feba839",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

  &nbs= p; "linkedUsers": [

      {<= /span>

      &= nbsp; "domain": "D2",

        "ext= ernalEntityId": "7a87f27c1dd8"

      }

    ]

  }

}

 

In the second user, the lin= kedUsers attribute would be empty until the split user was synced to domain 2= .

 =

 

Similarly, the false negati= ve use case (merging two users) looked like this at the end:

 

| Internal Entity ID | External Domain= ID | External Entity ID | Primary flag |

| 9caf78aac3d6     &nb= sp; | D2           &n= bsp;     | ff487230b3a0     &nb= sp; | true         |

| 9caf78aac3d6       | D2  &nb= sp;            &= nbsp; | 41206cc97c8b       | false  =       |

 

This could be represe= nted with the following SCIM user:

 

{

  "schemas": ["urn:scim:schemas:core:1.0",= "urn:scim:schemas:extension:federation:1.0"],

  "id": "9caf78aac3d6",

  "userName": "John Smith",

  "urn:scim:schemas:extension:federation:1= .0": {

  &nbs= p; "linkedUsers": [

      {<= /span>

      &= nbsp; "domain": "D2",

        "ext= ernalEntityId": "ff487230b3a0"

      },

      {<= /span>

      &= nbsp; "domain": "D2",

        "ext= ernalEntityId": "41206cc97c8b",

        "deletionRequired": true=

      }<= /span>

    ]

  }

}

 =

 

Regarding unique identifier= s for multi-valued attributes there is a trade-off involved.  On one ha= nd this makes PATCH semantics easier.  On the other hand it puts extra burden on service providers.  Since the inception of SCIM, a= key goal has been to foster adoption by service providers by making things f= it easily onto existing systems.  IMO the value gained by unique identi= fiers for multi-valued attributes is not worth the demands put on a service provider.  I also think that ve= ndors that have a non-SCIM-compliant API will choose to keep things that way= if the spec is too hard for them to implement.  In a green field envir= onment we do have the luxury of mandating a model to make certain operations more elegant.  However, we can=E2=80= =99t ignore legacy systems.

 

 =

From: scim-bounces@ietf.org= [mailto:scim= -bounces@ietf.org] On Behalf Of Emmanuel Dreux
Sent: Thursday, August 09, 2012 3:18 AM
To: Ganesh and Sashi Prasad; Kelly Grizzle
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement<= /u>

 

Hi Ganesh,

 

Nothing prevents you in your SCIM i= mplementation (client or server) to generate a unique identifier for each sy= nchronized object and maintain an internal mapping table ( you would have to map group membership as well).

 <= /span>

This is what we are doing w= ith Active Directory sources or targets:

As we didn=E2=80=99t find an immutable uniqueID in= AD systems (DN,samAccountName, UPN) are subject to change (even objectGuid c= an change if an AD domain is migrated), we decided to generate and maintain an internal table of ids. This fits you= r requirements as it hides internal ids.

 

This was written in dotnet a= nd we have started a project to rewrite our SCIM stack in PHP and will give i= t to the Open Source community. This implementation will have a parameter : AllocateIds versus UseExistingIDs.

This will give the c= hoice of =E2=80=9Chiding=E2=80=9D internalIDs or use them as unique ID.

 =

You can also implement s= uch feature without violating the SCIM specs, or without asking to include i= t in the specs.

 =

--

Regards,=

Emmanuel Dreux

http://www.cloudiway.com=

Tel: +33 4 26 78 17 58

Mobile: +33 6 47 81 26 70

skype: Emmanuel= .Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : jeudi 9 ao=C3=BBt 2012 03:35
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org
Objet : Re: [scim] SCIM Protocol - 3 suggestions for improvement=

 

Hi K= elly,

Thanks for your response. Let me first respond in brief to= the two main points you have made, and then elaborate on the first.<= u>

1.      Why should domains not expose t= heir internal identifiers to other domains?

a.

We are designing a protocol for a federated system of doma= ins, where all domains are co-equal peers. (In physics too, N-body problems a= re much harder than 2-body problems. :-) Therefore, assuming that there are o= nly two players in the interaction makes this tightly coupled in a number of ways. We should rely on messaging= and notification, with encapsulation of domain-specific data.=

b.

In any non-trivial data store, there will always be the on= going need to merge and split identities as and when =E2=80=9Cfalse negative= s=E2=80=9D and =E2=80=9Cfalse positives=E2=80=9D are discovered. A domain sh= ould be able to handle this internal housekeeping freely, only notifying other domains when convenient. Mapping of internal identifiers to= external ones and maintaining this mapping internally allows this loosely-c= oupled housekeeping to take place. Sharing internal identifiers (or otherwis= e outsourcing the mapping of internal to external identifiers) forces housekeeping activities to be done= in lock-step across domains.

c.

Asynchronous interaction is not just a matter of a suitabl= e wire protocol which can be designed later. The data model plays a crucial r= ole in enabling or constraining such interaction. A tightly-coupled data mod= el will force the use of synchronous interactions, and the exposure of internal identifiers is a key part of thi= s tight coupling.

2. The difficulty of assigning unique identifiers to the i= ndividual values of multi-valued attributes:

a.

I'm not belittling the effort involved in migrating legacy= data stores to such a model. However, in the larger historical context of c= ross-domain identity management, we are really at the very early stages. If a= relatively new discipline and a brand new spec are held captive to legacy considerations, we are losing a= n opportunity to provide a clean and elegant model to subsequent users of th= e spec, and this will have repercussions over many years or even decades.=

b.

If incumbent cloud providers find it hard to immediately a= dopt the dictionary model for existing multi-valued attributes, they can tra= nsition to this model by offering both =E2=80=9CSCIM-compliant=E2=80=9D and =E2= =80=9Cnon-SCIM-compliant=E2=80=9D APIs to their customers and encouraging new customers to adopt the =E2=80=9CSCIM-compliant=E2=80=9D API= . Legacy customers can be supported using a =E2=80=9Cnon-SCIM-compliant=E2=80= =9D API for an arbitrarily long period and gradually migrated to the SCIM-co= mpliant API. The logistics are not insurmountable, and shouldn't prevent the adoption of a dictionary model for multi-valued attributes.<= /u>

Elaboration of Point 1:

When we consider federated identity across more than one d= omain, we have to assume that domains are not necessarily master-slave in th= eir interaction. The most generic interaction model is peer-to-peer, where entity lifecycle events within a domain are no= tified to other domains (when necessary) in an asynchronous manner (i.e., th= rough messaging) and the other domains are free to respond to these events i= n an appropriate manner and at a time of their convenience.

A key set of lifecycle even= ts for an entity is the merging and splitting of identity that is often requ= ired.

The q= uestion =E2=80=9CIs this one entity?=E2=80=9D can be answered either yes (po= sitive) or no (negative). But sometimes, we can discover false positives and= false negatives in our data stores.

Consi= der a case where customers sign up online, and two customers who are privacy= -conscious enter fake IDs such as =E2=80=9CJohn Smith=E2=80=9D, and also use= the same date of birth (say, 1 Jan 1970) or similar attributes. The front-end application may make an intellig= ent (but incorrect) guess that these two persons are the same, and re-assign= the same identifier to the second person. This is a false positive. They ap= pear to be the same entity, but they're actually different. When the error is discovered, the identities wi= ll need to be split, with a new identifier generated for one of them.=

Consider the opposite case where a customer signs up throu= gh two different portals or in two different sessions, using the names =E2=80= =9CJSmith=E2=80=9D and =E2=80=9CJohnS=E2=80=9D. It is very likely that they will be treated as two different customers and assigned two unique ide= ntifiers. This is a false negative. They appear to be two entities, but are a= ctually the same. At a later stage, when the error is discovered, the identi= ties will have to be merged, and one of the identifiers will have to be dropped.

Thes= e are not theoretical use cases. They form a significant proportion of the u= ser base in most large Web-facing applications. Let's see how these can be m= anaged in a federated way by mapping internal identifiers to external ones and only exposing exte= rnal identifiers to other domains.

a. False positives:=

Domai= n 1 has the following information about a customer in its data store:=

Internal ID: 9caf78aac3d6

Attri= butes: {name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D= }

When requesting the provisioning of this entity in Doma= in 2, the following ID is returned by Domain 2: ff487230b3a0.<= /span>

Domai= n 1 then maintains the following in a mapping table and uses it for translat= ion when talking to Domain 2, taking care never to expose its internal ident= ifier:

| Internal Entity I= D | External Domain ID | External Entity ID | Primary flag |

| 9caf78aac3d6 | D2= | ff487230b3a0 | true |

When the false positive is discovered and the entity is sp= lit, Domain 1 creates a new internal identifier and now has the following en= tity information.

Internal ID: 9caf78aac3d6

Attributes: {= name: =E2=80=9CJohn Smith=E2=80=9D, dob: =E2=80=9C01-Jan-1970=E2=80=9D}

Internal ID: a99a5feba839


> As for #2, the protocol spec works = as you describe if "arbitrary URI parameters" equate to resource = attributes=A0

Yes, that's what I meant, but in implementation, it= may work out to be looser than that. The client should be able to specify = any arbitrary attribute in the search parameters, even those that aren'= t attributes of the resource. If an attribute is not defined, or if the att= ribute exists but the value doesn't match any stored record, the SP wil= l return no results. In the former case, it's a "400 Bad Request&q= uot; and in the latter, it's a "404 Not Found".

By "candidate key" (a data modelling term), I= meant another attribute that also uniquely identifies a single record, but= is not the official "primary key", i.e., the main ID. In this ca= se, a client's internal identifier also uniquely identifies a record, b= ut is not the ID used in the URI of RESTful operations.

Look, this may seem to be splitting hairs since a deter= mined client may be able to store and search by their own internal ID in ei= ther case (the current SCIM spec or my suggestion). The difference is philo= sophical. If the spec is showing how clients can store their internal IDs i= n the cloud by explicitly providing for such an attribute, that constitutes= bad advice, IMO. If it turns a blind eye to what they store and they store= internal IDs anyway, they're constraining themselves but the spec come= s out smelling of roses because that's not "recommended practice&q= uot;.

Ganesh

On 11 August 2= 012 00:50, Trey Drake <trey.drake@unboundid.com> wrot= e:
Ganesh,

I'll base my = comments on your latest reply (below). =A0

The ext= ernalID is not part of the protocol. =A0It is an *optional* attribute withi= n the *schema* specification. =A0As for #2, the protocol spec works as you = describe if "arbitrary URI parameters" equate to resource attribu= tes (Allow generic search using 'GET /Users' and arbitrary URI para= meters). =A0Please clarify your suggestion.

I'm not tracking your coupling concern. =A0The clie= nt can search and hence retrieve resources on any attribute it chooses, ext= ernalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0


What do you mean by "candidate key"= ? =A0Given=A0

On Fri, Aug 10, 2012 at 5:49 AM, Ganesh and Sashi Prasad <g.c.prasad= @gmail.com> wrote:
>=A0 I think scim gets its current simplicity from its single owner hub spoke mo= del implementing tight coupling. [...]=A0IMHO loose coupling is a much more= complex solution.

Phil,

I'= m a bit surprised that you're implying "tight coupling =3D=3D simp= le" and "loose coupling =3D=3D complex". That's contrary= to my experience.

When I say "loose coupling", I mean "no = unnecessary dependencies". Invariably, a reduction in dependencies lea= ds to greater simplicity.

Let's not confuse re= duction of dependencies in the data model with a hub-and-spokes architectur= e. They're entirely orthogonal aspects of the solution.

All that my suggestion involves is,

1. Take 'external ID' out of the protocol.
2. Allow= generic search using 'GET /Users' and arbitrary URI parameters

No planned functionality is lost by this.
1. The client enterprise can still send its internal ID as part= of the resource body, inside some attribute defined by them (but not defin= ed by the protocol). Let's say they call it 'myID'.
2. The client enterprise can search for resource URIs using any attrib= ute, including this internal ID
'GET /Users?myID=3Dbjensen= 9;
Since myID is a candidate key, the server will return exactly = one URI, which is the canonical URI for the resource
https://example.com/v1/Users/281=
9c223-7f76-453a-919d-413861904646
3. The client can use this URI to perform all other operat=
ions as usual.

So taking 'externalI=
D' out of the protocol spec only does this:
1. It avoids enshrining tight coupling in the protocol (If=
 clients want to tightly couple themselves to the cloud provider by sending=
 their internal IDs, they can do so. Suicide is OK, but the protocol should=
 not be guilty of assisted suicide. ;-)
2. It encourages loose coupling by nudging clients towards=
 maintaining their own internal-to-external identifier mappings.






That's what I'd =
like to see. I don't believe this complicates the protocol. It simplifi=
es it and it also lends itself to a loosely-coupled approach.







I'll address the mul=
ti-valued attribute suggestion separately.





Regards,




Ganesh




On 10 August 2012 07:53, Phil Hunt=
 <phil.hunt@oracle.com> wrote:





Phil

On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com<=
/a>> wrote:






>=A0
storing this information in a mapping table outside of the SCIM spe=
c is a great way to enable this solution.=A0 Part of the key here is that S=
CIM is just a piece of the architecture for this solution, and is only resp=
onsible for the transport layer between domains.=A0








I wasn't suggesting that the mapping table be part of the SCIM spec=
. I provided that example to illustrate that splitting and merging identiti=
es is a common requirement, and that decoupling local identifiers within a =
domain from shared identifiers between domains was the best way to facilita=
te it.








I'm suggesting that the spec do less, not more.
What the SCIM spec needs to do there is just refrain from introducing=
 tight coupling. I would like to see a single identifier exposed through th=
e API, with the implication (and perhaps the recommendation) that it be the=
 shared one. Allowing one domain to expose its internal identifier to the o=
ther creates tight coupling and ensures that both domains need simultaneous=
ly split or merge identities, which is not desirable. So I recommend _takin=
g out_ the "external id" field from the API. The spec shouldn'=
;t encourage tight coupling. If clients want to pass in their internal ids =
as part of the resource body, no one can stop them, and they can always do =
a search on that attribute to retrieve the URI exactly as you visualise the=
y will with the "external id", but let's not elevate an anti-=
pattern to a recommendation by enshrining the "external id" as an=
 acceptable attribute.









Am I making sense?

I see what you are saying. I think scim gets its current simplicit=
y from its single owner hub spoke model implementing tight coupling.=A0












That said i think the current model provides a practica=
l starting point.=A0

<=
/div>
>=A0
Regarding unique identifiers for multi-valued attributes there is a=
 trade-off involved.=A0 On one hand this makes PATCH semantics easier.=A0 O=
n the other hand it puts extra burden on service providers.=A0









Precisely. The spec has to strike the right balance. It would be i=
nteresting to hear from the other members of the spec mailing list. You kno=
w where I stand on this. It would be good to hear the spectrum of opinions.=










Regards,
Ganesh

On 10 August 2012 00:28, Kelly Grizzle <kelly.grizzle@sai=
lpoint.com> wrote:



















Thanks Emmanuel.=A0 I had=
 started writing up a similar response.=A0 As you suggest, storing this inf=
ormation in a mapping table outside of the SCIM spec is a great
 way to enable this solution.=A0 Part of the key here is that SCIM is just =
a piece of the architecture for this solution, and is only responsible for =
the transport layer between domains.


=A0<=
/p>

You could also model thes=
e ID mappings in the SCIM user as an extension but would probably not want =
to expose these externally.=A0 Here is an example of how to
 model the end state of the false positive scenario (splitting a user):<=
/u>


=A0<=
/p>

| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| a99a5feba839=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


=A0


This could be repre=
sented as two SCIM users that contain information about the entities on oth=
er domains.









=A0<=
/p>

{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=










=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0


{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=










=A0 "id": "a99a5feba839",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "7a87f27c1dd8"


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0<=
/p>

In the second user, the l=
inkedUsers attribute would be empty until the split user was synced to doma=
in 2.









=A0<=
/p>

=A0<=
/p>

Similarly, the false nega=
tive use case (merging two users) looked like this at the end:










=A0<=
/p>

| Internal Entity ID | External Domain ID | E=
xternal Entity ID | Primary flag |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=A0=A0=A0=A0=A0=
 | true=A0=A0=A0=A0=A0=A0=A0=A0 |


| 9caf78aac3d6=A0=A0=A0=A0=A0=A0 | D2=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=A0=A0=A0=A0=A0=
 | false=A0=A0=A0=A0=A0=A0=A0 |


=A0<=
/p>

This could be repre=
sented with the following SCIM user:


=A0<=
/p>

{


=A0 "schemas": ["urn:scim:sche=
mas:core:1.0", "urn:scim:schemas:extension:federation:1.0"],=










=A0 "id": "9caf78aac3d6",=



=A0 "userName": "John Smith&qu=
ot;,


=A0 "urn:scim:schemas:extension:federati=
on:1.0": {


=A0=A0=A0 "linkedUsers": [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "ff487230b3a0"


=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "domain": &qu=
ot;D2",


=A0=A0=A0=A0=A0=A0=A0 "externalEntityId&=
quot;: "41206cc97c8b",


=A0=A0=A0=A0=A0=A0=A0 "deletionRequired&=
quot;: true


=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}


=A0<=
/p>

=A0<=
/p>

Regarding unique identifi=
ers for multi-valued attributes there is a trade-off involved.=A0 On one ha=
nd this makes PATCH semantics easier.=A0 On the other hand it
 puts extra burden on service providers.=A0 Since the inception of SCIM, a =
key goal has been to foster adoption by service providers by making things =
fit easily onto existing systems.=A0 IMO the value gained by unique identif=
iers for multi-valued attributes is
 not worth the demands put on a service provider.=A0 I also think that vend=
ors that have a non-SCIM-compliant API will choose to keep things that way =
if the spec is too hard for them to implement.=A0 In a green field environm=
ent we do have the luxury of mandating
 a model to make certain operations more elegant.=A0 However, we can=92t ig=
nore legacy systems.



=A0<=
/p>

--Kelly


=A0<=
/p>





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

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=







=A0


Hi Ganesh,=



=A0=



Nothing prevents you in y=
our SCIM implementation (client or server) to generate a unique identifier =
for each synchronized object and maintain an internal mapping
 table ( you would have to map group membership as well).


=A0<=
/p>

This is what we are doing=
 with Active Directory sources or targets:


As we didn=92t find an im=
mutable uniqueID in AD systems (DN,samAccountName, UPN) are subject to chan=
ge (even objectGuid can change if an AD domain is migrated),
 we decided to generate and maintain an internal table of ids. This fits yo=
ur requirements as it hides internal ids.


=A0<=
/p>

This was written in dotne=
t and we have started a project to rewrite our SCIM stack in PHP and will g=
ive it to the Open Source community. This implementation
 will have a parameter : AllocateIds versus UseExistingIDs.


This will give the choice=
 of =93hiding=94 internalIDs or use them as unique ID.=










=A0<=
/p>

You can also implement su=
ch feature without violating the SCIM specs, or without asking to include i=
t in the specs.









=A0<=
/p>

--<=
/u>


Regards,


Emmanuel Dreu=
x


http://www.cloudiway.com









Tel: +33 4 26 78 17 58









Mobile: +33 6 47 81 26 70









skype: Emmanu=
el.Dreux


=A0=





De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement




=A0


Hi K=
elly,


Than=
ks for your response. Let me first respond in brief to the two main points =
you have made, and then elaborate on the first.



1.=A0=A0=A0=A0=A0
Why should domains not expose=
 their internal identifiers to other domains?



a.



We are designing a protocol for a federated system of dom=
ains, where all domains are co-equal peers. (In physics too, N-body problem=
s are much harder than 2-body problems. :-) Therefore, assuming that there =
are only two players in the interaction
 makes this tightly coupled in a number of ways. We should rely on messagin=
g and notification, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the o=
ngoing need to merge and split identities as and when =93false negatives=94=
 and =93false positives=94 are discovered. A domain should be able to handl=
e this internal housekeeping freely, only
 notifying other domains when convenient. Mapping of internal identifiers t=
o external ones and maintaining this mapping internally allows this loosely=
-coupled housekeeping to take place. Sharing internal identifiers (or other=
wise outsourcing the mapping of
 internal to external identifiers) forces housekeeping activities to be don=
e in lock-step across domains.



c.



Asynchronous interaction is not just a matter of a suitab=
le wire protocol which can be designed later. The data model plays a crucia=
l role in enabling or constraining such interaction. A tightly-coupled data=
 model will force the use of synchronous
 interactions, and the exposure of internal identifiers is a key part of th=
is tight coupling.



2. The difficulty of assigning unique identifiers to the =
individual values of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating l=
egacy data stores to such a model. However, in the larger historical contex=
t of cross-domain identity management, we are really at the very early stag=
es. If a relatively new discipline and
 a brand new spec are held captive to legacy considerations, we are losing =
an opportunity to provide a clean and elegant model to subsequent users of =
the spec, and this will have repercussions over many years or even decades.=











b. 



If incumbent cloud providers find it hard to immediately =
adopt the dictionary model for existing multi-valued attributes, they can t=
ransition to this model by offering both =93SCIM-compliant=94 and =93non-SC=
IM-compliant=94 APIs to their customers and
 encouraging new customers to adopt the =93SCIM-compliant=94 API. Legacy cu=
stomers can be supported using a =93non-SCIM-compliant=94 API for an arbitr=
arily long period and gradually migrated to the SCIM-compliant API. The log=
istics are not insurmountable, and shouldn't
 prevent the adoption of a dictionary model for multi-valued attributes.=



Elab=
oration of Point 1:


When=
 we consider federated identity across more than one domain, we have to ass=
ume that domains are not necessarily master-slave in their interaction. The=
 most generic interaction
 model is peer-to-peer, where entity lifecycle events within a domain are n=
otified to other domains (when necessary) in an asynchronous manner (i.e., =
through messaging) and the other domains are free to respond to these event=
s in an appropriate manner and at
 a time of their convenience.


A ke=
y set of lifecycle events for an entity is the merging and splitting of ide=
ntity that is often required.


The =
question =93Is this one entity?=94 can be answered either yes (positive) or=
 no (negative). But sometimes, we can discover false positives and false ne=
gatives in our data stores.









Cons=
ider a case where customers sign up online, and two customers who are priva=
cy-conscious enter fake IDs such as =93John Smith=94, and also use the same=
 date of birth (say, 1 Jan
 1970) or similar attributes. The front-end application may make an intelli=
gent (but incorrect) guess that these two persons are the same, and re-assi=
gn the same identifier to the second person. This is a false positive. They=
 appear to be the same entity, but
 they're actually different. When the error is discovered, the identiti=
es will need to be split, with a new identifier generated for one of them.<=
u>


Cons=
ider the opposite case where a customer signs up through two different port=
als or in two different sessions, using the names =93JSmith=94 and =93JohnS=
=94. It is very likely that
 they will be treated as two different customers and assigned two unique id=
entifiers. This is a false negative. They appear to be two entities, but ar=
e actually the same. At a later stage, when the error is discovered, the id=
entities will have to be merged,
 and one of the identifiers will have to be dropped.

Thes=
e are not theoretical use cases. They form a significant proportion of the =
user base in most large Web-facing applications. Let's see how these ca=
n be managed in a federated
 way by mapping internal identifiers to external ones and only exposing ext=
ernal identifiers to other domains.


a. F=
alse positives:


Doma=
in 1 has the following information about a customer in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


When=
 requesting the provisioning of this entity in Domain 2, the following ID i=
s returned by Domain 2: ff487230b3a0.


Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifier:









| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |









| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |

When=
 the false positive is discovered and the entity is split, Domain 1 creates=
 a new internal identifier and now has the following entity information.=










Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


Inte=
rnal ID: a99a5feba839


Attr=
ibutes: {name: =93John Smith=94, dob: =9301-Jan-1970=94}


This=
 second entity with its own internal identifier is invisible to Domain 2, a=
nd this is by design. Communication about the original entity takes place a=
s before by mapping
 =939caf78aac3d6=94 to =93ff487230b3a0=94 and vice-versa. At some convenien=
t time (importantly, this doesn't have to be at the time the split happ=
ens), Domain 2 can be requested to provision a second entity, and when it r=
esponds with an identifier of =937a87f27c1dd8=94,
 this can go into the mapping table as a new record associated with the sec=
ond entity's internal identifier.


The =
mapping table now contains the following entries:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |









| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |

| a99a5feba839 | =
D2 | 7a87f27c1dd8 | true |

Domain 2 is not even aware that a split has happened=
, and the provisioning that it does is not in lockstep with the split in id=
entity that occurred in
 Domain 1.


(Wha=
t is the =93Primary flag=94 used for? We'll see when we cover the treat=
ment of false negatives.)


b. F=
alse negatives:


Doma=
in 1 has the following information about what it thinks are two distinct cu=
stomers in its data store:


Inte=
rnal ID: 9caf78aac3d6


Attr=
ibutes: {name: =93JSmith=94, dob: =9301-Jan-1970=94}

Inte=
rnal ID: 273d36e30d09


Attr=
ibutes: {name: =93JohnS=94, dob: =9301-Jan-1970=94}

When=
 requesting the provisioning of these entities in Domain 2, the following I=
Ds are returned by Domain 2: ff487230b3a0 and 41206cc97c8b.









Doma=
in 1 then maintains the following in a mapping table and uses it for transl=
ation when talking to Domain 2, taking care never to expose its internal id=
entifiers:









| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |









| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |

| 273d36e30d09 | =
D2 | 41206cc97c8b | true |

When=
 the false negative is discovered and the two entities are merged, Domain 1=
 drops one of the internal identifiers and rationalises the name of the cus=
tomer (say, to =93John
 Smith=94). Let's say it retains the first ID =939caf78aac3d6=94 and dr=
ops the second =93273d36e30d09=94.


The =
mapping table now looks like this:


| Internal Entity=
 ID | External Domain ID | External Entity ID | Primary flag |









| 9caf78aac3d6 | =
D2 | ff487230b3a0 | true |

| 9caf78aac3d6 | =
D2 | 41206cc97c8b | false |

Now =
two external identifiers map to the same internal one, so inbound communica=
tion from Domain 2 can be unambiguously translated to the same entity inter=
nally. However, when
 going outwards, Domain 1 will have to look up the translation table to det=
ermine the =93primary=94 external ID for this entity in Domain 2, which was=
 decided to be =93ff487230b3a0=94. That's where the =93Primary flag=94 =
comes in. The second external ID =9341206cc97c8b=94
 is never used thereafter in outbound communication.

At s=
ome stage (importantly, not in lockstep with the identity merge), Domain 2 =
can be requested to delete the customer record identified by =9341206cc97c8=
b=94, and the second entry
 in the mapping table can be removed once this is acknowledged.


This=
 scheme will scale up to multiple domains, because the =93External Domain I=
D=94 column helps to keep track of which external ID is shared with which D=
omain. (Why don't we use
 just one external ID for an entity and share it with all external domains?=
 Tight coupling again. Just as OAuth allows an access token given to a thir=
d party to be invalidated without affecting the access of other third parti=
es, the use of separate external
 identifiers for different domains allows fine-grained control of identity =
federation.)


The =
scheme also allows the splitting of an entity into more than two entities, =
and the merging of more than two entities into a single one. (Any organisat=
ion with a web-facing
 application will tell you how many John Smiths there are who were born on =
1 Jan 1970!)


This=
 is a fairly long-winded explanation, but this is why we need to hide inter=
nal identifiers from other domains, and why mappings need to be managed int=
ernally in each domain.
 Such a data model also allows us to choose asynchronous protocols for prop=
agation of identity events, since there is no consistency requirement to up=
date multiple domains concurrently.


Rega=
rds,



Gane=
sh Prasad


=A0




On 9 August 2012 04:55, Kelly Griz=
zle <ke=
lly.grizzle@sailpoint.com> wrote:






Thanks for the feedback, =
Ganesh.=A0 I read through this and your InfoQ article (=
http://www.infoq.com/articles/scim-data-model-limitations)
 and have some thoughts.


=A0<=
/p>

>
The rest of the protocol does not meani=
ngfully use the enterprise client=92s identifier, the "external ID&quo=
t;









> at all, even thoug=
h it was ostensibly introduced to make things friendlier for the client.









=A0<=
/p>

The usage pattern for an =
external ID would be to search for a user by externalId and use the ID of
 the returned user in any desired operation.=A0 For example:<=
u>


=A0<=
/p>

GET /Users?filter=3Dexter=
nalId eq =93bjensen=94&attributes=3Did


=A0<=
/p>

{


=A0 =93totalResults=94: 1,


=A0 =93Resources=94: [

=A0=A0=A0 {


=A0=A0=A0 =A0=A0=93id=94: =932819c223-7f76-45=
3a-919d-413861904646=94


=A0=A0=A0 }


=A0 ]


}


=A0<=
/p>

Retrieve the ID from the =
response and use it.


=A0<=
/p>

DELETE /Users/2819c223-7f=
76-453a-919d-413861904646


=A0<=
/p>

This does introduce an ad=
ditional HTTP request if the client chooses not to store the server=92s id.=
=A0
 An issue was created to consider allowing operations to use the externalId=
 (http://code.google.com/p/scim/issues/detail?id=3D35),
 but I believe the general consensus has been to not include this in the sp=
ec.=A0 One main point of contention is that much of the rest of the spec (e=
g =96 group membership references, manager references, etc=85) require know=
ledge of the server=92s identifier.=A0 Continuing
 this discussion on the IETF list would be a good thing, though.<=
/u>


=A0<=
/p>

=A0<=
/p>

>
the cloud provider's ID and the ent=
erprise client's ID are both "Internal IDs" with respect to t=
heir domains









=A0<=
/p>

I think this comes down t=
o a nomenclature problem.=A0 The server=92s ID does not necessarily have to
 be the unique identifier that the underlying identity store uses, it just =
has to be stable and unique.=A0 In many cases, the underlying identity stor=
e will provide identifiers with these properties already (eg =96 a uuid) an=
d it can be used by the SCIM interface.=A0
 The =93externalId=94 is referring to the fact that the id is maintained ex=
ternal to the SCIM server.=A0 As long as the server=92s identifiers are sta=
ble and unique (which is mandated by the spec), I don=92t see a problem.









=A0<=
/p>

=A0<=
/p>

>
The secret is that=A0every value nee=
ds a key, and multi-valued attributes lack that. So our solution is qui=
te









> simple - turn ever=
y list or array (of values) into a dictionary (of key-value pairs) by provi=
ding
 each value


> with a unique and =
meaning-free identifier.


=A0<=
/p>

I agree that this would b=
e useful, especially in the PATCH operation.=A0 One reason that this wasn=
=92t
 included in the spec originally is that it can put undue burden on the ser=
vice provider.=A0 Many service providers are putting SCIM interfaces in fro=
nt of their existing identity stores (eg =96 directory servers, SaaS applic=
ation databases, etc=85).=A0 Many of these
 do not have a unique identifier for multi-valued attributes.=A0 By requiri=
ng this, a majority of the server providers would have to start maintaining=
 a unique key for each multi-valued attribute.=A0 I believe this would be a=
 roadblock for many implementers.









=A0<=
/p>

=A0<=
/p>

>
When the SCIM protocol uses PATCH, ther=
e are areas where it seems a bit clumsy.


=A0<=
/p>

I like the thoughts here.=
=A0 Your example reminds me of unified diffs (http://en.wikipedi=
a.org/wiki/Diff#Unified_format),
 which are commonly used with a patch program (pretty much the equivalent o=
f the PATCH verb). =A0However, the three proposals seem to largely hinge on=
 being able to uniquely address each element within an object.=A0 Without t=
hese it is not so easy to address each
 patch sub-operation (REPLACE, INCLUDE, etc=85) or provide a multi-status.<=
/span>




The 207 response would be interesting to consider for the bulk endpoint (http://www.simplecloud.info/specs/draft-sci=
m-api-00.html#bulk-resources),
 however.


=A0<=
/p>

=A0<=
/p>

>
There are other, non-data aspects of SC=
IM which may require review, such as its synchronous request-response









> interaction model,=
 which is a form of tight coupling and could prove to be a source of brittl=
eness.









=A0<=
/p>

I agree that we should ex=
plore optional asynchronous requests in 2.0.


=A0<=
/p>

Thanks again for your tho=
ughts.=A0 I hope you stay involved in the discussion as work on SCIM 2.0 go=
es
 forward.


=A0<=
/p>

--Kelly<=
/u>


=A0<=
/p>



From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Ganesh and Sashi Prasad

Sent: Wednesday, August 01, 2012 4:24 PM

To: scim@ietf.org=


Subject: [scim] SCIM Protocol - 3 suggestions for improvement=









=A0




(I posted this on the SCIM Google Group, and I was a=
dvised to subscribe to the mailing list and post it here instead, so here g=
oes.)






=A0






Hi,






=A0






My name is Ganesh Prasad, and my experience in Ident=
ity and Access Management is mainly through a 3-year project at an Australi=
an insurance company, an experience I have written
 about as a eBook on InfoQ (http://www.infoq.com/minibooks=
/Identity-Management-Shoestring).






=A0






I have been following the SCIM spec off and on, and =
based on my experience with a loosely-coupled architecture that I found to =
be successful, I have the following 3 suggestions
 to make.






=A0






1. The enterprise client and the cloud provider shou=
ld maintain their own internal IDs for a resource, which they should not re=
veal to each other. Both of them should map their
 internal IDs to a shared External ID, and this is the only ID that should =
be exposed through the API. The current specification's provision of an=
 id (which is the external ID and the only one to be transferred through th=
e API) and an "external ID" (which is
 the client's internal ID and should be hidden) is diametrically opposi=
te to this.






=A0






2. When dealing with multi-valued attributes of a re=
source (expressed as arrays in JSON), they must be converted from an array =
into a dictionary with unique keys (UUIDs generated
 by the cloud provider when the attribute is created). Without unique keys =
for every attribute value of a resource, manipulating it will be clumsy and=
 inelegant.






=A0






3. The PATCH command can be improved in 3 significan=
t ways:






3a. Leverage the fact (from 2 above) that every valu=
e has a key, to greatly simplify the API






3b. Use special verbs as nested operations of the PA=
TCH command to add, modify and delete attributes at any level=







3c. Use the WebDAV status code of "207 Multi-St=
atus" instead of "200 OK" as the response to a PATCH (or BUL=
K) command.






=A0






To elaborate,






=A0






1. Revealing private IDs externally is a form of tig=
ht coupling. A major requirement with Identity Management is to split (or m=
erge) identities when false positives (or false negatives)
 are detected, i.e., when a resource is discovered to be more than one, or =
when multiple resources are detected to be the same. If internal identifier=
s are revealed to external domains, such clean-ups become difficult, hence =
every domain that wants to expose
 references to a resource must map its internal ID to and external one crea=
ted for this explicit purpose, and only reveal this.






=A0






In the SCIM case, when an enterprise client POSTs a =
resource creation request, the cloud provider must generate its own interna=
l UUID as well as an external UUID, map them together,
 and only return the external UUID in the "Location:" header. The=
 enterprise client should map this external UUID to a newly-generated inter=
nal ID of its own. In case the resource already has an identifier within th=
e enterprise client's domain, then this is
 the internal ID that must be mapped to the external UUID returned through =
the POST response.






=A0






2. If a resource is to be created, and one of its at=
tributes is multi-valued, e.g.,






=A0






=A0 =A0 "email-addrs" :=A0





=A0 =A0 [






=A0 =A0 =A0 =A0 "john_smith@yahoo.com",





=A0 =A0 =A0 =A0 "john.smith@gmail.com",





=A0 =A0 =A0 =A0 "jsmith1970@hotmail.com"





<
________________________________=
_______________
scim mailing list
scim@ietf.org





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


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



mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf= =3Djohn.smith@gmail.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com

That's why I asked if there was an S= P representative on this working group who could explain what such a change= could mean for them. As of now, it looks like other people are presuming t= hat SPs will not be able to implement these changes easily and are rejectin= g them for that reason.

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <= span dir=3D"ltr"><edreux@cloudiway.com> wrote:

=F0=A0 addresses.3cbaaff8e84e.str= eet-number =3D "243"

=A0=

Where woul= d 3cbaaff8e84e come from? Would it have to be stored= on the account database of the service provider?

= =A0

If so, = I believe that this is impracticable in the core schema. Indeed it implies = that a service provider must extend the schema of his account repository (L= DAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This wo= uld be a show stopper. SCIM must be transparent, and must be able to be put= on top of an existing system to provide provisioning apis.

= =A0

Said di= fferently, SCIM must not be intrusive for existing systems and must not req= uire modifications to allow its integration.

Correct= me if I misunderstood your suggestion.

= =A0

--<= u>

Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=A0<= /p>

De=A0: Ganesh = and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

=A0

That's exactly the point. How do we "specif= y completely for uniqueness"?

=A0

In the example below, how are you proposing that the= following element be updated if we can't use positional indexes?

=A0

addresses[1].street-number =3D "243"

=A0

User object:

=A0

{

=A0 ...

=A0 addresses: [

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the value because it'= ;s the whole dictionary element:

=A0

{

=A0 "type" : "office",=

=A0 "street-number" : "213",<= /u>

=A0 "street-name" : "Main Street"= ;,

=A0 "suburb" : "Adelaide",

=A0 "postcode" : "5000",<= u>

=A0 "state" : "SA",

=A0 "country" : "Australia"

}

=A0

With my proposal, the "addresses" array ge= ts converted to a dictionary, and then we have a stable way of referencing = this element:

=A0

addresses.3cbaaff8e84e.street-number =3D "243&q= uot;

=A0

{

=A0 ...

=A0 addresses: {

=A0 =A0 "d6ea365462f5" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechanism for composite = attributes and another mechanism for simple attributes, I would suggest tha= t's actually more complex than adopting a single mechanism that works t= he same way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather t= han done by hand, and having two mechanisms (depending on whether the attri= bute is simple or composite) will complicate every script that has to be wr= itten.

=A0

There's a lot of talk about the "burden&quo= t; on the SPs, but I believe this is overblown. Is there any SP representat= ive in this WG who can tell us what this proposal will actually entail for = them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Ganesh,

=A0

This is exactly how PATCH works in SCIM = 1.0. =A0Multi-valued attributes that have a value sub-attribute can be remo= ved by specifying only the value since it is unique. =A0Multi-valued attributes that don't have a value sub-attribute (eg - address) have t= o specified completely for uniqueness. =A0As I have said before, I am very = opposed to adding a unique identifier to each element in a multi-valued col= lection due to the burden it will put on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in general PATCH can b= e made more intuitive without adding uids to each element. =A0The verbs tha= t you propose make sense. =A0There is also a JSON Patch informational draft in the IETF that is interesting -=A0http://tools.ietf= .org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Poin= ter draft which uses index-based addressing for multi-valued attributes. =A0I think that this is something that should= be looked at within the WG and I would be willing to lead this effort.<= /u>

=A0

I'm curious if anyone else in the WG= is in favor of unique identifiers for every multi-valued element.

=A0

--Kelly

=A0

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value itself to identif= y an element is that this method will only work for simple elements, not fo= r nested structures. i.e., if we had an array of dictionaries (e.g., we had= to record an array of addresses for each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creat= ing a unique key for each element scales better.

=A0

Regards,

Ganesh<= /p>

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> w= rote:

Ganesh,

=A0

Here's the sample that concerned me...=

The two operations differ significantly, and it'= s not very intuitive.=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute with an identifier = that matched that value or of identifiers that were additional unique keys.=

=A0

Given that multi-values must be each unique, I don't se= e the point of the extra indexing to support this. Just use the value as th= e item you wish to delete.

=A0

I agree, the delete value operation could be more explicit = and clear in general.

=A0

=A0

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad w= rote:



>=A0 For the multi-value example you gave you use= d the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don't believe any of= my examples ever used a value as the key.

=A0

Could you please show me which example you mean, and= which parts of it you believe to be the value?

=A0

Regards,

Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> w= rote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex indexing structure. Be= tter to just say delete a specific value.=A0

=A0

The spec already allows multiple values to have tags= like home, work, etc.

=A0

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

>=A0In your example you are conflating value with= an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where every attribute of th= e resource is a key-value pair. The key is a name or ID.

=A0

For non-repeating attributes (both simple and compos= ite), the key is the attribute name itself.=A0

=A0

Simple attribute:

=A0

Key: "dob"

Value: "01 Jan 1970"

=A0

For composite attributes, the key employs dot notati= on to specify the fully-qualified attribute name, e.g., "address.postc= ode".

=A0

Composite attribute:

=A0

Key: "address.street-number"=

Value: "10"

=A0

Key: "address.suburb"

Value: "East Camden"

=A0

For repeating (multi-valued) attributes, I'm sug= gesting that there be new keys for each individual value, otherwise they ar= e impossible to distinguish, and a positional index is inadequate. So we co= nvert the array into a dictionary and this then becomes a composite attribute using dot notation for the key.=

=A0

Multi-valued attribute:

=A0

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd9= 02"

=A0

So this allows us to apply uniform treatment to any = arbitrarily deep resource structure. We can refer to every leaf value with = a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous operations on these (= now) explicitly addressable attributes.

=A0

INCLUDE to a collection and specify only the value. = The key is generated and returned. The fully-qualified key is <collectio= n-name>.<newly-generated-ID> and the value is what was specified i= n the INCLUDE.

=A0

REPLACE a fully-qualified key with a new value. If t= he key doesn't exist, return a "404 Not Found".=

=A0

PLACE a value at the logical location implied by the= fully-qualified key. If there is already a key with that name, return a &q= uot;409 Conflict".

=A0

FORCE the fully-qualified key to hold the given valu= e, regardless of whether it existed before or not. Only errors possible are= "400 Bad Request" and "500 Internal Error".<= /u>

=A0

RETIRE an attribute or a collection given its fully-= qualified key. The implementation will determine whether the attribute will= disappear entirely or will exist holding a null value (the blank string &q= uot;" or the empty object {} ).

=A0

I'll explain in a separate post why we need oper= ation verbs like these that are independent of the HTTP verbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:=

If you have received this digest without all the ind= ividual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating value with an att= ribute id. I find that confusing.=A0

=A0

I agree though that operations in patch could be a l= ot more explicit.=A0

=A0

Eg explicitly deleting a value by saying delete or r= etire.=A0


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

=A0>=A0=A0I am concern= ed about your second suggestion:=A0

=A0

Let's discuss that now.

=A0

The trade-offs are very clear here.

=A0

Pros:

=A0

Pro 1. The API to manipulate resources becomes so mu= ch cleaner, consistent and intuitive when every individual attribute value = gets its own ID.

=A0

Here's how to delete a single member from a Grou= p, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "members": [
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 "displa=
y": "Babs Jensen",
=A0=A0=A0=A0=A0=A0=A0=A0 "value&=
quot;: "2819c223-7f76-453a-919d-413861904646"
=A0=A0=A0=A0=A0=A0=A0=A0 "operat=
ion": "delete"
=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0 ]

=A0=A0 }




Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "meta": {
=A0=A0=A0=A0=A0=A0 "attributes&q=
uot;: [
=A0=A0=A0=A0=A0=A0=A0=A0 "member=
s"
=A0=A0=A0=A0=A0=A0 ]
=A0=A0=A0=A0 }

=A0=A0 }




The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members"<= /p>

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism consistently to t= hree areas:

(a) Manipulating multi-valued attributes of a resour= ce

(b) Manipulating members of a group

(c) Performing bulk operations, where we simply use = HTTP verbs instead of the specialised (and semantically less ambiguous) ver= bs I suggested for attributes, the "key" becomes the URI, and the= "value" becomes the corresponding JSON object.

=A0

All of them return "207 Multi-Status" with= the "results" array holding individual status codes.

=A0

In the current spec, (a) and (b) are done similarly = but (c) is very different.

=A0

Pro 3: Adoption of the standard by clients is likely= to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud providers will prob= ably find this easier to implement because they have no legacy. They will p= robably use some form of NoSQL database and won't be constrained by the= limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers with existing data = stores in a directory format (where multi-valued attributes are stored as c= omma-separated values under a single attribute node) will find it difficult= to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinde= r adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons correctly? I'= m biased of course, so I could have missed a Con or hyped a Pro :-).=

=A0

In other words, we're debating interface complex= ity (current spec) versus implementation complexity (my suggestion). Both c= an hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss - Do the Pros mak= e the suggestion worth adopting in spite of the Cons, or are the Cons so gr= eat that it's best to leave the spec as it is?

=A0

Keep in mind that a complex spec that only favours i= ncumbent cloud providers can cut both ways. It opens the door to a simpler = interface offered by a new generation of nimbler SPs that don't have th= e same legacy issues, and there could be an exodus of clients to these new SPs. SCIM could end up being obsolete= d very soon, because the API interface is very complex and clumsy, as any n= ew reader can attest. I was taken aback by the complexity when I saw it, wh= ich is why I was prompted to suggest something simpler.

=A0

This is an issue where we need the opinions of many = people, and they need to state their affiliations. If most people weighing = in belong to incumbent SPs and they vote in favour of interface complexity = to avoid implementation complexity, then it means the spec is not doing a good job of balancing the interests = of various groups. I think we should also poll client organisations to see = what they would want.

=A0

(Gartner is trusted by enterprise clients to evaluat= e the capabilities of vendors (SPs). I believe Gartner should take the lead= in representing client interests in this working group rather than those o= f incumbent vendors, which is what it seems like to me. Correct me if I'm being unfair.)

=A0

Regards,

Ganesh

=A0

=A0

On 11 August 2012 01:35, Diodati,Mark <Mark.Diodati@gartner.co= m> wrote:

Hi Ganesh,=

=A0=

I am conce= rned about your second suggestion:

=932. When= dealing with multi-valued attributes of a resource (expressed as arrays in JSON), they must be converted from an array into a dictionary with unique = keys (UUIDs generated by the cloud provider when the attribute is created).= Without unique keys for every attribute value of a resource, manipulating = it will be clumsy and inelegant.=94

=A0=

One of the= primary reasons that SPML failed was lack of adoption by service providers due to its complexity. Very few target applications implemented SPML. Most= of the commercial provisioning systems had an SPML interface (either v1 or= v2), but not one of them was conformant to the SPML standard because of co= mplexity. If you are interested, I will forward you the research documents that discuss these problems in d= etail. For SCIM to be successful, it must be adopted by commercial target a= pplications (i.e., service providers). I am confident that a requirement fo= r unique identifiers with multi-valued attributes will preclude its adoption, because it requires major changes t= o the service provider=92s existing identity storage mechanisms.

Mark

=A0=

=A0=

=A0=

From: Trey Drake [mailto:trey.drake@unboundid.com]
Sent: Friday, August 10, 2012 9:51 AM=


To: Ganesh and Sashi Prasad

Cc: scim@ietf.org; Emmanuel Dreux; Kelly Grizzle; Phil Hunt <= /span>


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=

=A0

=A0

Ganesh,

=A0

I'll base my comments on yo= ur latest reply (below). =A0

=A0

The externalID is not part of t= he protocol. =A0It is an *optional* attribute within the *schema* specifica= tion. =A0As for #2, the protocol spec works as you describe if "arbitrary URI parameters" equate to resource attributes (All= ow generic search using 'GET /Users' and arbitrary URI parameters).= =A0Please clarify your suggestion.

=A0

I'm not tracking your coupl= ing concern. =A0The client can search and hence retrieve resources on any a= ttribute it chooses, externalId or otherwise. =A0Nothing mandates use of externalId. =A0=A0

=A0

=A0

What do you mean by "candi= date key"? =A0Given=A0

=A0

On Fri, Aug 10, 2012 at 5:49 AM= , Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0 I think scim gets its c= urrent simplicity from its single owner hub spoke model implementing tight = coupling. [...]=A0IMHO loose coupling is a much more complex solution.

=A0

Phil,

=A0

I'm a bit surprised that yo= u're implying "tight coupling =3D=3D simple" and "loose = coupling =3D=3D complex". That's contrary to my experience.=

=A0

When I say "loose coupling= ", I mean "no unnecessary dependencies". Invariably, a reduc= tion in dependencies leads to greater simplicity.

=A0

Let's not confuse reduction= of dependencies in the data model with a hub-and-spokes architecture. They= 're entirely orthogonal aspects of the solution.

=A0

All that my suggestion involves= is,

=A0

1. Take 'external ID' o= ut of the protocol.

2. Allow generic search using &= #39;GET /Users' and arbitrary URI parameters

=A0

No planned functionality is los= t by this.

=A0

1. The client enterprise can st= ill send its internal ID as part of the resource body, inside some attribut= e defined by them (but not defined by the protocol). Let's say they call it 'myID'.

2. The client enterprise can se= arch for resource URIs using any attribute, including this internal ID

'GET /Users?myID=3Dbjensen&= #39;

Since myID is a candidate key, = the server will return exactly one URI, which is the canonical URI for the = resource

https://example.com/v1/Users/2819c223-7f=
76-453a-919d-413861904646
3. The client can use this URI to perform all other operation=
s as usual.
=A0
So taking 'externalID' out of the protocol spec only =
does this:
1. It avoids enshrining tight coupling in the protocol (If cl=
ients want to tightly couple themselves to the cloud provider by sending th=
eir internal IDs, they can do so. Suicide is OK, but the protocol should no=
t be guilty of assisted suicide. ;-)<=
/u>
2. It encourages loose coupling by nudging clients towards ma=
intaining their own internal-to-external identifier mappings.
=A0
That's what I'd like to see. I don't believe this=
 complicates the protocol. It simplifies it and it also lends itself to a l=
oosely-coupled approach.



=A0


I'll address the multi-valued attribute suggestion separa=
tely.


=A0


Regards,

Ganesh






=A0


=A0


=A0




=A0






On 10 August 2012 07:53, Phil H=
unt <phil.hunt=
@oracle.com> wrote:










Phil








=


On 2012-08-09, at 14:14, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<=
/u>








>=A0
storing this information i=
n a mapping table outside of the SCIM spec is a great way to enable this so=
lution.=A0 Part of the key here is that SCIM is just a piece
 of the architecture for this solution, and is only responsible for the tra=
nsport layer between domains.=A0



I wasn't suggesting that the mapping table be part of the SCIM spec. I =
provided that example to illustrate that splitting and merging identities i=
s a common requirement, and that decoupling local identifiers within a doma=
in from shared identifiers between domains
 was the best way to facilitate it.






=A0








I'm suggesting that the spe=
c do less, not more.






=A0






What the SCIM spec needs to do =
there is just refrain from introducing tight coupling. I would like to see =
a single identifier exposed through the API, with the
 implication (and perhaps the recommendation) that it be the shared one. Al=
lowing one domain to expose its internal identifier to the other creates ti=
ght coupling and ensures that both domains need simultaneously split or mer=
ge identities, which is not desirable.
 So I recommend _taking out_ the "external id" field from the API=
. The spec shouldn't encourage tight coupling. If clients want to pass =
in their internal ids as part of the resource body, no one can stop them, a=
nd they can always do a search on that attribute
 to retrieve the URI exactly as you visualise they will with the "exte=
rnal id", but let's not elevate an anti-pattern to a recommendatio=
n by enshrining the "external id" as an acceptable attribute.<=
/u>










=A0








Am I making sense?












=A0








I see what you are saying. I th=
ink scim gets its current simplicity from its single owner hub spoke model =
implementing tight coupling.=A0






=A0








IMHO loose coupling is a much m=
ore complex solution. The reality is that each end-point has value to contr=
ibute and thus the single-owner model will eventually
 need to become multi-owner or multi-hub.=A0








=A0








=
That said i think the current model provides a practical starting point.=A0=













=A0








>=A0
Regarding unique identifie=
rs for multi-valued attributes there is a trade-off involved.=A0 On one han=
d this makes PATCH semantics easier.=A0 On the other hand it
 puts extra burden on service providers.=A0<=
/u>








Precisely. The spec has to strike the right balance. It would be interestin=
g to hear from the other members of the spec mailing list. You know where I=
 stand on this. It would be good to hear the spectrum of opinions.










=A0








Regards,





=
Ganesh




On 10 August 2012 00:28, Kelly =
Grizzle <kelly.grizzle@sailpoint.com> wrote:






Thanks Emm=
anuel.=A0 I had started writing up a similar response.=A0 As you suggest, s=
toring
 this information in a mapping table outside of the SCIM spec is a great wa=
y to enable this solution.=A0 Part of the key here is that SCIM is just a p=
iece of the architecture for this solution, and is only responsible for the=
 transport layer between domains.=







=A0=





You could =
also model these ID mappings in the SCIM user as an extension but would pro=
bably
 not want to expose these externally.=A0 Here is an example of how to model=
 the end state of the false positive scenario (splitting a user):






=A0=





| Internal Entity ID | Externa=
l Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6=A0=A0=A0=A0=A0=
=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=
=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |




| a99a5feba839=A0=A0=A0=A0=A0=
=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 7a87f27c1dd8=A0=
=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |






=A0






This could=
 be represented as two SCIM users that contain information about the entiti=
es
 on other domains.




=A0=





{<=
u>


=A0 "schemas": [&quo=
t;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federat=
ion:1.0"],




=A0 "id": "9caf=
78aac3d6",


=A0 "userName": &quo=
t;John Smith",


=A0 "urn:scim:schemas:ext=
ension:federation:1.0": {




=A0=A0=A0 "linkedUsers&qu=
ot;: [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "do=
main": "D2",


=A0=A0=A0=A0=A0=A0=A0 "ex=
ternalEntityId": "ff487230b3a0"<=
u>




=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}<=
u>




=A0




{<=
u>


=A0 "schemas": [&quo=
t;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federat=
ion:1.0"],




=A0 "id": "a99a=
5feba839",


=A0 "userName": &quo=
t;John Smith",


=A0 "urn:scim:schemas:ext=
ension:federation:1.0": {




=A0=A0=A0 "linkedUsers&qu=
ot;: [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "do=
main": "D2",


=A0=A0=A0=A0=A0=A0=A0 "ex=
ternalEntityId": "7a87f27c1dd8"<=
u>




=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}<=
u>




=A0=





In the sec=
ond user, the linkedUsers attribute would be empty until the split user was
 synced to domain 2.




=A0=







=A0=





Similarly,=
 the false negative use case (merging two users) looked like this at the en=
d:








=A0=





| Internal Entity ID | Externa=
l Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6=A0=A0=A0=A0=A0=
=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | ff487230b3a0=A0=
=A0=A0=A0=A0=A0 | true=A0=A0=A0=A0=A0=A0=A0=A0 |




| 9caf78aac3d6=A0=A0=A0=A0=A0=
=A0 | D2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 41206cc97c8b=A0=
=A0=A0=A0=A0=A0 | false=A0=A0=A0=A0=A0=A0=A0 |<=
u>






=A0=







This could=
 be represented with the following SCIM user:






=A0=





{<=
u>


=A0 "schemas": [&quo=
t;urn:scim:schemas:core:1.0", "urn:scim:schemas:extension:federat=
ion:1.0"],




=A0 "id": "9caf=
78aac3d6",


=A0 "userName": &quo=
t;John Smith",


=A0 "urn:scim:schemas:ext=
ension:federation:1.0": {




=A0=A0=A0 "linkedUsers&qu=
ot;: [


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "do=
main": "D2",


=A0=A0=A0=A0=A0=A0=A0 "ex=
ternalEntityId": "ff487230b3a0"<=
u>




=A0=A0=A0=A0=A0 },


=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0 "do=
main": "D2",


=A0=A0=A0=A0=A0=A0=A0 "ex=
ternalEntityId": "41206cc97c8b",=





=A0=A0=A0=A0=A0=A0=A0 "de=
letionRequired": true=



=A0=A0=A0=A0=A0 }


=A0=A0=A0 ]


=A0 }


}<=
u>




=A0=







=A0=





Regarding =
unique identifiers for multi-valued attributes there is a trade-off involve=
d.=A0
 On one hand this makes PATCH semantics easier.=A0 On the other hand it put=
s extra burden on service providers.=A0 Since the inception of SCIM, a key =
goal has been to foster adoption by service providers by making things fit =
easily onto existing systems.=A0 IMO the
 value gained by unique identifiers for multi-valued attributes is not wort=
h the demands put on a service provider.=A0 I also think that vendors that =
have a non-SCIM-compliant API will choose to keep things that way if the sp=
ec is too hard for them to implement.=A0
 In a green field environment we do have the luxury of mandating a model to=
 make certain operations more elegant.=A0 However, we can=92t ignore legacy=
 systems.





=A0=





--Kelly




=A0=









From:
scim-bounces@iet=
f.org [mailto:scim-bounces@ietf.org]
On Behalf Of Emmanuel Dreux

Sent: Thursday, August 09, 2012 3:18 AM

To: Ganesh and Sashi Prasad; Kelly Grizzle

Cc: scim@ietf.org=


Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement












=A0




Hi Ganesh,




=A0




Nothing pr=
events you in your SCIM implementation (client or server) to generate a uni=
que
 identifier for each synchronized object and maintain an internal mapping t=
able ( you would have to map group membership as well).




=A0=





This is wh=
at we are doing with Active Directory sources or targets:




As we didn=
=92t find an immutable uniqueID in AD systems (DN,samAccountName, UPN) are =
subject
 to change (even objectGuid can change if an AD domain is migrated), we dec=
ided to generate and maintain an internal table of ids. This fits your requ=
irements as it hides internal ids.






=A0=





This was w=
ritten in dotnet and we have started a project to rewrite our SCIM stack in
 PHP and will give it to the Open Source community. This implementation wil=
l have a parameter : AllocateIds versus UseExistingIDs.


This will =
give the choice of =93hiding=94 internalIDs or use them as unique ID.






=A0=





You can al=
so implement such feature without violating the SCIM specs, or without aski=
ng
 to include it in the specs.




=A0=





--


Regards,


Emmanuel Dreux


http://www.cloudiway.com




Tel:
+33 4 26 78=
 17 58


Mobile:
+33 6 47 81=
 26 70


skype: Emmanuel.Dreux




=A0






De=A0: Ganesh =
and Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9=A0: jeudi 9 ao=FBt 2012 03:35

=C0=A0: Kelly Grizzle

Cc=A0: scim@ietf.=
org

Objet=A0: Re: [scim] SCIM Protocol - 3 suggestions for improvement






=A0




Hi Kelly,


Thanks for your respon=
se. Let me first respond in brief to the two main points you have made, and=
 then elaborate on the first.





1.=A0=A0=A0=A0=A0 Why should domains=
 not expose their internal identifiers to other domains?



a.



We are designing a protocol for a federated system of domains, where all do=
mains are co-equal peers. (In physics too, N-body problems are much harder =
than 2-body problems. :-) Therefore, assuming that there are only two playe=
rs in the interaction makes this
 tightly coupled in a number of ways. We should rely on messaging and notif=
ication, with encapsulation of domain-specific data.



b. 



In any non-trivial data store, there will always be the ongoing need to mer=
ge and split identities as and when =93false negatives=94 and =93false posi=
tives=94 are discovered. A domain should be able to handle this internal ho=
usekeeping freely, only notifying other
 domains when convenient. Mapping of internal identifiers to external ones =
and maintaining this mapping internally allows this loosely-coupled houseke=
eping to take place. Sharing internal identifiers (or otherwise outsourcing=
 the mapping of internal to external
 identifiers) forces housekeeping activities to be done in lock-step across=
 domains.



c.



Asynchronous interaction is not just a matter of a suitable wire protocol w=
hich can be designed later. The data model plays a crucial role in enabling=
 or constraining such interaction. A tightly-coupled data model will force =
the use of synchronous interactions,
 and the exposure of internal identifiers is a key part of this tight coupl=
ing.



2. The difficulty of assigning unique identifiers to the individual values =
of multi-valued attributes:



a. 



I'm not belittling the effort involved in migrating legacy data stores =
to such a model. However, in the larger historical context of cross-domain =
identity management, we are really at the very early stages. If a relativel=
y new discipline and a brand new spec
 are held captive to legacy considerations, we are losing an opportunity to=
 provide a clean and elegant model to subsequent users of the spec, and thi=
s will have repercussions over many years or even decades.





b. 



If incumbent cloud providers find it hard to immediately adopt the dictiona=
ry model for existing multi-valued attributes, they can transition to this =
model by offering both =93SCIM-compliant=94 and =93non-SCIM-compliant=94 AP=
Is to their customers and encouraging new
 customers to adopt the =93SCIM-compliant=94 API. Legacy customers can be s=
upported using a =93non-SCIM-compliant=94 API for an arbitrarily long perio=
d and gradually migrated to the SCIM-compliant API. The logistics are not i=
nsurmountable, and shouldn't prevent the
 adoption of a dictionary model for multi-valued attributes.


Elaboration of Point 1=
:


When we consider feder=
ated identity across more than one domain, we have to assume that domains a=
re not necessarily master-slave in their interaction. The most generic inte=
raction model is peer-to-peer, where
 entity lifecycle events within a domain are notified to other domains (whe=
n necessary) in an asynchronous manner (i.e., through messaging) and the ot=
her domains are free to respond to these events in an appropriate manner an=
d at a time of their convenience.=





A key set of lifecycle=
 events for an entity is the merging and splitting of identity that is ofte=
n required.


The question =93Is thi=
s one entity?=94 can be answered either yes (positive) or no (negative). Bu=
t sometimes, we can discover false positives and false negatives in our dat=
a stores.




Consider a case where =
customers sign up online, and two customers who are privacy-conscious enter=
 fake IDs such as =93John Smith=94, and also use the same date of birth (sa=
y, 1 Jan 1970) or similar attributes.
 The front-end application may make an intelligent (but incorrect) guess th=
at these two persons are the same, and re-assign the same identifier to the=
 second person. This is a false positive. They appear to be the same entity=
, but they're actually different.
 When the error is discovered, the identities will need to be split, with a=
 new identifier generated for one of them.


Consider the opposite =
case where a customer signs up through two different portals or in two diff=
erent sessions, using the names =93JSmith=94 and =93JohnS=94. It is very li=
kely that they will be treated as two different
 customers and assigned two unique identifiers. This is a false negative. T=
hey appear to be two entities, but are actually the same. At a later stage,=
 when the error is discovered, the identities will have to be merged, and o=
ne of the identifiers will have
 to be dropped.


These are not theoreti=
cal use cases. They form a significant proportion of the user base in most =
large Web-facing applications. Let's see how these can be managed in a =
federated way by mapping internal identifiers
 to external ones and only exposing external identifiers to other domains.<=
span lang=3D"EN-US">


a. False positives:


Domain 1 has the follo=
wing information about a customer in its data store:


Internal ID: 9caf78aac=
3d6


Attributes: {name: =93=
John Smith=94, dob: =9301-Jan-1970=94}


When requesting the pr=
ovisioning of this entity in Domain 2, the following ID is returned by Doma=
in 2: ff487230b3a0.


Domain 1 then maintain=
s the following in a mapping table and uses it for translation when talking=
 to Domain 2, taking care never to expose its internal identifier:




| Internal Entity ID | Extern=
al Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff48723=
0b3a0 | true |


When the false positiv=
e is discovered and the entity is split, Domain 1 creates a new internal id=
entifier and now has the following entity information.=





Internal ID: 9caf78aac=
3d6


Attributes: {name: =93=
John Smith=94, dob: =9301-Jan-1970=94}


Internal ID: a99a5feba=
839


Attributes: {name: =93=
John Smith=94, dob: =9301-Jan-1970=94}


This second entity wit=
h its own internal identifier is invisible to Domain 2, and this is by desi=
gn. Communication about the original entity takes place as before by mappin=
g =939caf78aac3d6=94 to =93ff487230b3a0=94
 and vice-versa. At some convenient time (importantly, this doesn't hav=
e to be at the time the split happens), Domain 2 can be requested to provis=
ion a second entity, and when it responds with an identifier of =937a87f27c=
1dd8=94, this can go into the mapping table
 as a new record associated with the second entity's internal identifie=
r.


The mapping table now =
contains the following entries:

| Internal Entity ID | Extern=
al Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff48723=
0b3a0 | true |


| a99a5feba839 | D2 | 7a87f27=
c1dd8 | true |


Domain 2 is not even aware that a split has happened, and the pr=
ovisioning that it does is not in lockstep with the split in identity that =
occurred in Domain 1.




(What is the =93Primar=
y flag=94 used for? We'll see when we cover the treatment of false nega=
tives.)


b. False negatives:


Domain 1 has the follo=
wing information about what it thinks are two distinct customers in its dat=
a store:


Internal ID: 9caf78aac=
3d6


Attributes: {name: =93=
JSmith=94, dob: =9301-Jan-1970=94}


Internal ID: 273d36e30=
d09


Attributes: {name: =93=
JohnS=94, dob: =9301-Jan-1970=94}=



When requesting the pr=
ovisioning of these entities in Domain 2, the following IDs are returned by=
 Domain 2: ff487230b3a0 and 41206cc97c8b.




Domain 1 then maintain=
s the following in a mapping table and uses it for translation when talking=
 to Domain 2, taking care never to expose its internal identifiers:




| Internal Entity ID | Extern=
al Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff48723=
0b3a0 | true |


| 273d36e30d09 | D2 | 41206cc=
97c8b | true |


When the false negativ=
e is discovered and the two entities are merged, Domain 1 drops one of the =
internal identifiers and rationalises the name of the customer (say, to =93=
John Smith=94). Let's say it retains the
 first ID =939caf78aac3d6=94 and drops the second =93273d36e30d09=94.


The mapping table now =
looks like this:


| Internal Entity ID | Extern=
al Domain ID | External Entity ID | Primary flag |




| 9caf78aac3d6 | D2 | ff48723=
0b3a0 | true |


| 9caf78aac3d6 | D2 | 41206cc=
97c8b | false |


Now two external ident=
ifiers map to the same internal one, so inbound communication from Domain 2=
 can be unambi

_______________________________________________ <= /u>

=A0

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

=A0

=A0

=A0


--00151747ba0628388a04c71847c7-- From phil.hunt@oracle.com Sun Aug 12 17:13:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0AB21F8686 for ; Sun, 12 Aug 2012 17:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-y8-ImZS2F5 for ; Sun, 12 Aug 2012 17:13:44 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 07B6421F863F for ; Sun, 12 Aug 2012 17:13:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7D0DdgQ021805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Aug 2012 00:13:40 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7D0Dcx2017116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2012 00:13:38 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7D0Dc1Q010010; Sun, 12 Aug 2012 19:13:38 -0500 Received: from [25.65.153.73] (/74.198.150.201) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 12 Aug 2012 17:13:33 -0700 References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-653BBDC2-8350-4E22-BE62-52EF412A1029 Message-Id: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Sun, 12 Aug 2012 18:13:27 -0600 To: Ganesh and Sashi Prasad X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "scim@ietf.org" , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 00:13:47 -0000 --Apple-Mail-653BBDC2-8350-4E22-BE62-52EF412A1029 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I strongly object to anything that leads to a read before modify requirement= . Too complex and too chatty.=20 Phil On 2012-08-12, at 15:29, Ganesh and Sashi Prasad wrot= e: > > Would it have to be stored on the account database of the service provid= er? >=20 > =20 >=20 > Yes. >=20 >=20 >=20 > > If so, I believe that this is impracticable in the core schema. Indeed i= t implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D f= or SCIM integration. >=20 >=20 > Why? That doesn't necessarily follow. Implementation is independent of rep= resentation. We're talking about a change in representation to make the API c= leaner. >=20 > As a simple example, if an LDAP node is being used to hold a list of comma= -separated email addresses, it can just as easily store comma-separated name= -value pairs. >=20 > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com > can be changed to >=20 > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.sm= ith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >=20 > That's why I asked if there was an SP representative on this working group= who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement th= ese changes easily and are rejecting them for that reason. >=20 > Regards, > Ganesh >=20 > On 13 August 2012 04:29, Emmanuel Dreux wrote: > =C3=B0 addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 >=20 > Where would 3cbaaff8e84e come from? Would it have to be stored on the acco= unt database of the service provider? >=20 > =20 >=20 > If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposit= ory (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D for= SCIM integration. >=20 > This would be a show stopper. SCIM must be transparent, and must be able t= o be put on top of an existing system to provide provisioning apis. >=20 > =20 >=20 > Said differently, SCIM must not be intrusive for existing systems and must= not require modifications to allow its integration. >=20 > Correct me if I misunderstood your suggestion. >=20 > =20 >=20 > -- >=20 > Regards, >=20 > Emmanuel Dreux >=20 > http://www.cloudiway.com >=20 > Tel: +33 4 26 78 17 58 >=20 > Mobile: +33 6 47 81 26 70 >=20 > skype: Emmanuel.Dreux >=20 > =20 >=20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=C3=A9 : dimanche 12 ao=C3=BBt 2012 04:53 > =C3=80 : Kelly Grizzle > Cc : scim@ietf.org; Phil Hunt > Objet : Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > =20 >=20 > > Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness. =20 >=20 > =20 >=20 > That's exactly the point. How do we "specify completely for uniqueness"? >=20 > =20 >=20 > In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? >=20 > =20 >=20 > addresses[1].street-number =3D "243" >=20 > =20 >=20 > User object: >=20 > =20 >=20 > { >=20 > ... >=20 > addresses: [ >=20 > { >=20 > "type" : "home", >=20 > "street-number" : "35", >=20 > "street-name" : "High Road", >=20 > "suburb" : "East Camden", >=20 > "postcode" : "5346", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > }, >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > ] >=20 > } >=20 > =20 >=20 > It's impractical to use the value because it's the whole dictionary elemen= t: >=20 > =20 >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > =20 >=20 > With my proposal, the "addresses" array gets converted to a dictionary, an= d then we have a stable way of referencing this element: >=20 > =20 >=20 > addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 >=20 > { >=20 > ... >=20 > addresses: { >=20 > "d6ea365462f5" : >=20 > { >=20 > "type" : "home", >=20 > "street-number" : "35", >=20 > "street-name" : "High Road", >=20 > "suburb" : "East Camden", >=20 > "postcode" : "5346", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > }, >=20 > "3cbaaff8e84e" : >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > } >=20 > } >=20 > =20 >=20 > If you're proposing one mechanism for composite attributes and another mec= hanism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attributes= . Remember that a lot of the administration is probably going to be scripted= rather than done by hand, and having two mechanisms (depending on whether t= he attribute is simple or composite) will complicate every script that has t= o be written. >=20 > =20 >=20 > There's a lot of talk about the "burden" on the SPs, but I believe this is= overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 12 August 2012 11:53, Kelly Grizzle wrote= : >=20 > Ganesh, >=20 > =20 >=20 > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that= have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attribu= te (eg - address) have to specified completely for uniqueness. As I have sa= id before, I am very opposed to adding a unique identifier to each element i= n a multi-valued collection due to the burden it will put on SPs. Is it ele= gant? No. Is it functional? Yes. Will this non-elegance affect adoption?= My opinion is that adding unique keys to each element will have a much mor= e detrimental effect on adoption. >=20 > =20 >=20 > I do believe that in general PATCH can be made more intuitive without addi= ng uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http:= //tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JSON= Pointer draft which uses index-based addressing for multi-valued attributes= . I think that this is something that should be looked at within the WG and= I would be willing to lead this effort. >=20 > =20 >=20 > I'm curious if anyone else in the WG is in favor of unique identifiers for= every multi-valued element. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh an= d Sashi Prasad [g.c.prasad@gmail.com] > Sent: Saturday, August 11, 2012 10:50 AM > To: Phil Hunt > Cc: scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > Phil, >=20 > =20 >=20 > The reason we cannot use the value itself to identify an element is that t= his method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of a= ddresses for each customer, with each address element having sub-elements li= ke street number, street name, suburb, etc.), then it would be clumsy to sup= ply the entire value of the array element because it's itself a dictionary. C= reating a unique key for each element scales better. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > On 12 August 2012 01:12, Phil Hunt wrote: >=20 > Ganesh, >=20 > =20 >=20 > Here's the sample that concerned me... >=20 > The two operations differ significantly, and it's not very intuitive.=20 >=20 > With my suggestion, here's how to delete a single member from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members.2819c223-7f76-453a-919d-413861904646" >=20 > } >=20 > } >=20 > ] } >=20 > =20 >=20 > =20 >=20 > You gave other examples of an attribute with an identifier that matched th= at value or of identifiers that were additional unique keys. >=20 > =20 >=20 > Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to de= lete. >=20 > =20 >=20 > I agree, the delete value operation could be more explicit and clear in ge= neral. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >=20 >=20 >=20 >=20 > > For the multi-value example you gave you used the value as the attribut= e name key.=20 >=20 > =20 >=20 > Now I'm confused :-). I don't believe any of my examples ever used a value= as the key. >=20 > =20 >=20 > Could you please show me which example you mean, and which parts of it you= believe to be the value? >=20 > =20 >=20 > Regards, >=20 > Ganesh=20 >=20 > On 11 August 2012 13:59, Phil Hunt wrote: >=20 >=20 > For the multi-value example you gave you used the value as the attribute n= ame key.=20 >=20 > =20 >=20 > That means a lot more complex indexing structure. Better to just say delet= e a specific value.=20 >=20 > =20 >=20 > The spec already allows multiple values to have tags like home, work, etc.= >=20 > =20 >=20 > Phil >=20 >=20 > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad wr= ote: >=20 > > In your example you are conflating value with an attribute id.=20 >=20 > I don't believe so. >=20 > =20 >=20 > I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. >=20 > =20 >=20 > For non-repeating attributes (both simple and composite), the key is the a= ttribute name itself.=20 >=20 > =20 >=20 > Simple attribute: >=20 > =20 >=20 > Key: "dob" >=20 > Value: "01 Jan 1970" >=20 > =20 >=20 > For composite attributes, the key employs dot notation to specify the full= y-qualified attribute name, e.g., "address.postcode". >=20 > =20 >=20 > Composite attribute: >=20 > =20 >=20 > Key: "address.street-number" >=20 > Value: "10" >=20 > =20 >=20 > Key: "address.suburb" >=20 > Value: "East Camden" >=20 > =20 >=20 > For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish,= and a positional index is inadequate. So we convert the array into a dictio= nary and this then becomes a composite attribute using dot notation for the k= ey. >=20 > =20 >=20 > Multi-valued attribute: >=20 > =20 >=20 > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >=20 > Value: "john_smith@yahoo.com" >=20 > =20 >=20 > So this allows us to apply uniform treatment to any arbitrarily deep resou= rce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. >=20 > =20 >=20 > The verbs are just unambiguous operations on these (now) explicitly addres= sable attributes. >=20 > =20 >=20 > INCLUDE to a collection and specify only the value. The key is generated a= nd returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. >=20 > =20 >=20 > REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". >=20 > =20 >=20 > PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". >=20 > =20 >=20 > FORCE the fully-qualified key to hold the given value, regardless of wheth= er it existed before or not. Only errors possible are "400 Bad Request" and "= 500 Internal Error". >=20 > =20 >=20 > RETIRE an attribute or a collection given its fully-qualified key. The imp= lementation will determine whether the attribute will disappear entirely or w= ill exist holding a null value (the blank string "" or the empty object {} )= . >=20 > =20 >=20 > I'll explain in a separate post why we need operation verbs like these tha= t are independent of the HTTP verbs. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 11 August 2012 10:38, wrote: >=20 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >=20 >=20 > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux , Trey Drake , Kelly Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > Ganesh, >=20 > =20 >=20 > In your example you are conflating value with an attribute id. I find that= confusing.=20 >=20 > =20 >=20 > I agree though that operations in patch could be a lot more explicit.=20 >=20 > =20 >=20 > Eg explicitly deleting a value by saying delete or retire.=20 >=20 >=20 > Phil >=20 >=20 > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad wr= ote: >=20 > > I am concerned about your second suggestion:=20 >=20 > =20 >=20 > Let's discuss that now. >=20 > =20 >=20 > The trade-offs are very clear here. >=20 > =20 >=20 > Pros: >=20 > =20 >=20 > Pro 1. The API to manipulate resources becomes so much cleaner, consistent= and intuitive when every individual attribute value gets its own ID. >=20 > =20 >=20 > Here's how to delete a single member from a Group, as per the current spec= : >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current spe= c: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20 >=20 > With my suggestion, here's how to delete a single member from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members.2819c223-7f76-453a-919d-413861904646" >=20 > } >=20 > } >=20 > ] }=20 > Here's how I suggest deleting ALL members from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members" >=20 > } >=20 > } >=20 > ] } >=20 >=20 > I'm sure you'll agree that this is simpler, more consistent and more intui= tive to a reader. >=20 > =20 >=20 > Pro 2: We can apply this mechanism consistently to three areas: >=20 > (a) Manipulating multi-valued attributes of a resource >=20 > (b) Manipulating members of a group >=20 > (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attri= butes, the "key" becomes the URI, and the "value" becomes the corresponding J= SON object. >=20 > =20 >=20 > All of them return "207 Multi-Status" with the "results" array holding ind= ividual status codes. >=20 > =20 >=20 > In the current spec, (a) and (b) are done similarly but (c) is very differ= ent. >=20 > =20 >=20 > Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. >=20 > =20 >=20 > Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form of= NoSQL database and won't be constrained by the limitations of LDAP director= ies. >=20 > =20 >=20 > Cons: >=20 > =20 >=20 > Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values un= der a single attribute node) will find it difficult to migrate to this model= and store each attribute value as a sub-node with its own key. This will "h= inder adoption of the spec", which is what you fear. >=20 > =20 >=20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so I c= ould have missed a Con or hyped a Pro :-). >=20 > =20 >=20 > In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the sp= ec by different parties. >=20 > =20 >=20 > Here's what we need to discuss - Do the Pros make the suggestio --Apple-Mail-653BBDC2-8350-4E22-BE62-52EF412A1029 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I strongly object to anyth= ing that leads to a read before modify requirement. Too complex and too chat= ty. 

Phil

On 2012-08-12, at 15:29, Ganesh and Sash= i Prasad <g.c.prasad@gmail.com> wrote:

=
mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D<= a href=3D"mailto:john.smith@gmail.com">john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com
=

That's why I asked if there was an SP repr= esentative on this working group who could explain what such a change could m= ean for them. As of now, it looks like other people are presuming that SPs w= ill not be able to implement these changes easily and are rejecting them for= that reason.

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com> wrote:

=C3=B0<= span style=3D"font:7.0pt "Times New Roman"">  addresses.3cbaaff8e84e.stre= et-number =3D "243"

 = ;

Where would 3cbaaff8e84e come from? Would it have to be stored o= n the account database of the service provider?

&= nbsp;

If so, I= believe that this is impracticable in the core schema. Indeed it implies th= at a service provider must extend the schema of his account repository (LDAP= partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D for SCIM integration.

This wou= ld be a show stopper. SCIM must be transparent, and must be able to be put o= n top of an existing system to provide provisioning apis.

&= nbsp;

Said dif= ferently, SCIM must not be intrusive for existing systems and must not requi= re modifications to allow its integration.

Correct m= e if I misunderstood your suggestion.

&= nbsp;

--=

Regards,<= /u>

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78= 17 58

Mobile: +33 6 47= 81 26 70

skype: Emmanuel.Dreux

 =

De : Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=C3=A9 : dimanche 12 ao=C3=BBt 2012 04:53
=C3=80 : Kelly Grizzle
Cc : scim@iet= f.org; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue 24

 

>  Multi-valued attributes that don't have a value sub-attribute (eg - address)= have to specified completely for uniqueness.  

 

That's exactly the point. How do we "specify complete= ly for uniqueness"?

 

In the example below, how are you proposing that the f= ollowing element be updated if we can't use positional indexes?

 

addresses[1].street-number =3D "243"

 

User object:

 

{

  ...

  addresses: [

    {

      "type" : "home",

      "street-number" : "35",

      "street-name" : "High Road",<= /u>

      "suburb" : "East Camden",=

      "postcode" : "5346",

      "state" : "SA",

      "country" : "Australia"

    },

    {

      "type" : "office",=

      "street-number" : "213",<= u>

      "street-name" : "Main Street",

      "suburb" : "Adelaide",=

      "postcode" : "5000",

      "state" : "SA",

      "country" : "Australia"

    }

  ]

}

 

It's impractical to use the value because it's the wh= ole dictionary element:

 

{

  "type" : "office",

  "street-number" : "213",

  "street-name" : "Main Street",

  "suburb" : "Adelaide",

  "postcode" : "5000",

  "state" : "SA",

  "country" : "Australia"

}

 

With my proposal, the "addresses" array gets converte= d to a dictionary, and then we have a stable way of referencing this element= :

 

addresses.3cbaaff8e84e.street-number =3D "243"=

 

{

  ...

  addresses: {

    "d6ea365462f5" :

    {

      "type" : "home",

      "street-number" : "35",

      "street-name" : "High Road",<= /u>

      "suburb" : "East Camden",=

      "postcode" : "5346",

      "state" : "SA",

      "country" : "Australia"

    },

    "3cbaaff8e84e" :

    {

      "type" : "office",=

      "street-number" : "213",<= u>

      "street-name" : "Main Street",

      "suburb" : "Adelaide",=

      "postcode" : "5000",

      "state" : "SA",

      "country" : "Australia"

    }

  }

}

 

If you're proposing one mechanism for composite attri= butes and another mechanism for simple attributes, I would suggest that's ac= tually more complex than adopting a single mechanism that works the same way= for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather th= an done by hand, and having two mechanisms (depending on whether the attribu= te is simple or composite) will complicate every script that has to be writt= en.

 

There's a lot of talk about the "burden" on the SPs, b= ut I believe this is overblown. Is there any SP representative in this WG wh= o can tell us what this proposal will actually entail for them?

 

Regards,

Ganesh

 

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoi= nt.com> wrote:

Ganesh,

 

This is exactly how PATCH works in SCIM 1.= 0.  Multi-valued attributes that have a value sub-attribute can be remo= ved by specifying only the value since it is unique.  Multi-valued attributes that don't have a value sub-attribute (eg - address) have to spe= cified completely for uniqueness.  As I have said before, I am very opp= osed to adding a unique identifier to each element in a multi-valued collect= ion due to the burden it will put on SPs.  Is it elegant?  No.  Is it functional?  Yes. &= nbsp;Will this non-elegance affect adoption?  My opinion is that adding= unique keys to each element will have a much more detrimental effect on ado= ption.

 

I do believe that in general PATCH can be m= ade more intuitive without adding uids to each element.  The verbs that= you propose make sense.  There is also a JSON Patch informational draft in the IETF that is interesting - http://tools.iet= f.org/html/draft-ietf-appsawg-json-patch-02.  It relies on a JSON P= ointer draft which uses index-based addressing for multi-valued attributes.  I think that this is something that shou= ld be looked at within the WG and I would be willing to lead this effort.=

 

I'm curious if anyone else in the WG is in= favor of unique identifiers for every multi-valued element.

 

--Kelly

 

From: scim-bounces@ietf= .org [scim-bo= unces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org<= /a>
Subject: Re: [scim] scim Digest, Vol 8, Issue 24=

Phil,

 

The reason we cannot use the value itself to identify= an element is that this method will only work for simple elements, not for n= ested structures. i.e., if we had an array of dictionaries (e.g., we had to r= ecord an array of addresses for each customer, with each address element having sub-elements like street nu= mber, street name, suburb, etc.), then it would be clumsy to supply the enti= re value of the array element because it's itself a dictionary. Creating a u= nique key for each element scales better.

 

Regards,

Ganesh

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> wro= te:

Ganesh,

 

Here's the sample that concerned me...<= /p>

The two operations differ significantly, and it's not= very intuitive. 

With my suggestion, here's how to delete a single mem= ber from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: ap= plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413861904646"=

}

}

] }

 

 

You gave other examples of an attribute with an identifier th= at matched that value or of identifiers that were additional unique keys.

 

Given that multi-values must be each unique, I don't see the p= oint of the extra indexing to support this. Just use the value as the item y= ou wish to delete.

 

I agree, the delete value operation could be more explicit an= d clear in general.

 

Phil

 

@independentid

phil.hunt@oracle.com<= /u>

 

 

 

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wr= ote:



>  For the multi-value example you gave you u= sed the value as the attribute name key. 

 

Now I'm confused :-). I don't believe any of my examp= les ever used a value as the key.

 

Could you please show me which example you mean, and w= hich parts of it you believe to be the value?

 

Regards,

Ganesh =

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> wro= te:


For the multi-value example you gave you used the value as the attribute nam= e key. 

 

That means a lot more complex indexing structure. Bet= ter to just say delete a specific value. 

 

The spec already allows multiple values to have tags l= ike home, work, etc.

 

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> In your example you are conflating value wi= th an attribute id. 

I don't believe so.

 

I'm adopting a model where every attribute of the res= ource is a key-value pair. The key is a name or ID.

 

For non-repeating attributes (both simple and composi= te), the key is the attribute name itself. 

 

Simple attribute:

 

Key: "dob"

Value: "01 Jan 1970"

 

For composite attributes, the key employs dot notatio= n to specify the fully-qualified attribute name, e.g., "address.postcode".

 

Composite attribute:

 

Key: "address.street-number"

Value: "10"

 

Key: "address.suburb"

Value: "East Camden"

 

For repeating (multi-valued) attributes, I'm suggesti= ng that there be new keys for each individual value, otherwise they are impo= ssible to distinguish, and a positional index is inadequate. So we convert t= he array into a dictionary and this then becomes a composite attribute using dot notation for the key.<= /u>

 

Multi-valued attribute:

 

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"=

 

So this allows us to apply uniform treatment to any a= rbitrarily deep resource structure. We can refer to every leaf value with a k= ey that is the fully-qualified name using dot notation.

 

The verbs are just unambiguous operations on these (n= ow) explicitly addressable attributes.

 

INCLUDE to a collection and specify only the value. T= he key is generated and returned. The fully-qualified key is <collection-= name>.<newly-generated-ID> and the value is what was specified in t= he INCLUDE.

 

REPLACE a fully-qualified key with a new value. If th= e key doesn't exist, return a "404 Not Found".

 

PLACE a value at the logical location implied by the f= ully-qualified key. If there is already a key with that name, return a "409 C= onflict".

 

FORCE the fully-qualified key to hold the given value= , regardless of whether it existed before or not. Only errors possible are "= 400 Bad Request" and "500 Internal Error".

 

RETIRE an attribute or a collection given its fully-q= ualified key. The implementation will determine whether the attribute will d= isappear entirely or will exist holding a null value (the blank string "" or= the empty object {} ).

 

I'll explain in a separate post why we need operation= verbs like these that are independent of the HTTP verbs.

 

Regards,

Ganesh

 

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:

If you have received this digest without all the indi= vidual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

htt= ps://www.ietf.org/mailman/listinfo/scim

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt= )


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <edreux@cloudiway.com>= , Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement

Ganesh,

 

In your example you are conflating value with an attr= ibute id. I find that confusing. 

 

I agree though that operations in patch could be a lo= t more explicit. 

 

Eg explicitly deleting a value by saying delete or re= tire. 


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

 >  I am c= oncerned about your second suggestion: 

 

Let's discuss that now.

 

The trade-offs are very clear here.

=

 

Pros:

 

Pro 1. The API to manipulate resources becomes so muc= h cleaner, consistent and intuitive when every individual attribute value ge= ts its own ID.

 

Here's how to delete a single member from a Group, as= per the current spec:

 

   PATCH /Groups/acbf3ae7-84=
63-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json<=
u>
   Authorization: Bearer h48=
0djs93hd8
   ETag: W/"a330bc54f0671c9"=

 
   {

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


     "members": [<=
u>


       {=



      &n=
bsp;  "display": "Babs Jensen",


      &n=
bsp;  "value": "2819c223-7f76-453a-919d-413861904646"


      &n=
bsp;  "operation": "delete"


       }=



     ]


   }



Here's how to delete ALL members from a group according to the current spec:=

 

   PATCH /Groups/acbf3ae7-84=
63-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: application/json<=
u>
   Authorization: Bearer h48=
0djs93hd8
   ETag: W/"a330bc54f0671c9"=

 
   {

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


     "meta": {<=
/u>


       "=
attributes": [


      &n=
bsp;  "members"


       ]=



     }


   }



The two operations differ significantly, and it's not very intuitive. <=
u>

With my suggestion, here's how to delete a single mem= ber from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: ap= plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413861904646"=

}

}

] }
Here's how I suggest deleting ALL members from a group:

 

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: ap= plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=

"operations" : [

{

"RETIRE" : {

"key" : "members"

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and more intuiti= ve to a reader.

 

Pro 2: We can apply this mechanism consistently to th= ree areas:

(a) Manipulating multi-valued attributes of a resourc= e

(b) Manipulating members of a group

=

(c) Performing bulk operations, where we simply use H= TTP verbs instead of the specialised (and semantically less ambiguous) verbs= I suggested for attributes, the "key" becomes the URI, and the "value" beco= mes the corresponding JSON object.

 

All of them return "207 Multi-Status" with the "resul= ts" array holding individual status codes.

 

In the current spec, (a) and (b) are done similarly b= ut (c) is very different.

 

Pro 3: Adoption of the standard by clients is likely t= o be higher because it's simpler for them.

 

Pro 4: New (not incumbent) cloud providers will proba= bly find this easier to implement because they have no legacy. They will pro= bably use some form of NoSQL database and won't be constrained by the limita= tions of LDAP directories.

 

Cons:

 

Con 1: Incumbent cloud providers with existing data s= tores in a directory format (where multi-valued attributes are stored as com= ma-separated values under a single attribute node) will find it difficult to= migrate to this model and store each attribute value as a sub-node with its own key. This will "hinder adop= tion of the spec", which is what you fear.

 

Have I summed up the Pros and Cons correctly? I'm bia= sed of course, so I could have missed a Con or hyped a Pro :-).

 

In other words, we're debating interface complexity (= current spec) versus implementation complexity (my suggestion). Both can hin= der adoption of the spec by different parties.

 

Here's what we need to discuss - Do the Pros make the= suggestio

<= /div>
<= /div>
= --Apple-Mail-653BBDC2-8350-4E22-BE62-52EF412A1029-- From melinda.shore@gmail.com Sun Aug 12 17:53:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA23621F8533 for ; Sun, 12 Aug 2012 17:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJEuLFHQPAMv for ; Sun, 12 Aug 2012 17:53:22 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EE21F8522 for ; Sun, 12 Aug 2012 17:53:22 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so6266242pbb.31 for ; Sun, 12 Aug 2012 17:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/4adUWbQqgwsbzKB6DYKuer83Bgjb9daGYOYrAiSosw=; b=Fd+OKjN474uDpMIvRt0zVu+sBysEeu9CkX6UHRgnGZWSB8XMJsm1O0kdbpqzWbGFYx nvkla05aD5U5MqMuNVx0wBt7SnBX4iOb5W+k48LLQydcT3ySWmGpQseYJHgFUHLPRZbU el7mUsMxh55UUvUY6ZozdqpYqBYtM7i6xA98cSItX5iJstcBJU4eBAA2VPL2gvcgW1nc hBu9TXc4X48kNOlfOZpcBBrjSumSyHwYuvuZSVoi7idu451+M3oveI1Gltg8ITiaKc+T bRuEl+rsy1R3SmYNadn4IMJkYUk2g/0Q3FGZE2kTarmRyXADASiq+XL7oOcw5ZjOeFw5 9jYg== Received: by 10.68.129.164 with SMTP id nx4mr15333723pbb.28.1344819202257; Sun, 12 Aug 2012 17:53:22 -0700 (PDT) Received: from spandex.local (66-230-81-165-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.165]) by mx.google.com with ESMTPS id gf3sm4217445pbc.74.2012.08.12.17.53.20 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Aug 2012 17:53:21 -0700 (PDT) Message-ID: <50284FFF.20909@gmail.com> Date: Sun, 12 Aug 2012 16:53:19 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> In-Reply-To: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 00:53:23 -0000 On 8/12/12 4:13 PM, Phil Hunt wrote: > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. This strikes me as rather an important point. It might be more productive to think about error messaging in this context. Melinda From wmills@yahoo-inc.com Sun Aug 12 19:28:35 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253D21F8674 for ; Sun, 12 Aug 2012 19:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.493 X-Spam-Level: X-Spam-Status: No, score=-17.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0URrzQ6x9yN for ; Sun, 12 Aug 2012 19:28:34 -0700 (PDT) Received: from nm34.bullet.mail.bf1.yahoo.com (nm34.bullet.mail.bf1.yahoo.com [72.30.238.192]) by ietfa.amsl.com (Postfix) with ESMTP id 9038321F856D for ; Sun, 12 Aug 2012 19:28:33 -0700 (PDT) Received: from [98.139.212.151] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2012 02:28:32 -0000 Received: from [98.139.215.252] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 13 Aug 2012 02:28:32 -0000 Received: from [127.0.0.1] by omp1065.mail.bf1.yahoo.com with NNFMP; 13 Aug 2012 02:28:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 404593.25966.bm@omp1065.mail.bf1.yahoo.com Received: (qmail 76040 invoked by uid 60001); 13 Aug 2012 02:28:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1344824911; bh=yf15+GiH9MTdI61NVgksIOjoM8ggNEnJx0vH8DNqbxY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=C9E3OxFdUFKjU2qc1BgBYEC8TeopLYx+fkPbc7AJUWFp62LQ29btZ4yZjdSTPlHw8p+GG3+N/V2LIeNc1WOaBLVgL32vaU+au6POiOU4j66Luo391DD0KYYwja4389VbM8+0cGL1iGEvi1cGUekxr/54xEYTV+JN3qW5bDEaUIQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MeUZnw1Mw/K4qa8+O2hiCRGEzJ9NHCTtw1N+Ztalg8HFtHJ3fY4KF0aNWTHqkBGap2v/NsFjaj06kDiB+575JIfhxqB/7bRk/ZvkhoNTwsQ8xYFXkqn+q8jlnHNGHrNq2hig+Mo3iyW+pWmy8xN4oEkDUUILk7+9bwL/NAQAGhs=; X-YMail-OSG: 4YPh_b8VM1msnDHYNeDLeAYf9n72Gzt50s_OYaMTMImqsac yl9K0R400.h_y4mX6QNerRRD2DM394tTC_NkqdEVt1_2VxXbemXa01c7m.vB 8xJI.GK6Sxk65GNAgDAe4xpZj47y0GEdqfMlljlnGlUQO22GSo48Va7qGeZx Cc4QXBBeNTfPPQg0PSL5ylLmOWSyN7gqMrH4d5BP38z.iVHNxmhkGCX8sYaw 4VzRrg5qCTkCu412PWoBXiaUY_3j4S3AbCXh_SX9v69t2Zk7dT1aGQEJi6C0 ZYJDk8DdlapKX4KWOwQjBYAtWtDsmlqh8al5OPnhMvygpAAxG7rPsINf_qiP sgKBZmCIAGu29bjdbNngsiT9Oe7BU0Ia4yD272f1ZQdGVRzKWHaZSJUr6dWv Cm7zB_bpA.3APZPE.uC6CkfPw3TuHlK1e97rd4MLP4aI5OA-- Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Sun, 12 Aug 2012 19:28:31 PDT X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.121.416 References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <50284FFF.20909@gmail.com> Message-ID: <1344824911.70371.YahooMailNeo@web31805.mail.mud.yahoo.com> Date: Sun, 12 Aug 2012 19:28:31 -0700 (PDT) From: William Mills To: Melinda Shore , "scim@ietf.org" In-Reply-To: <50284FFF.20909@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-551393103-1098192591-1344824911=:70371" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 02:28:35 -0000 ---551393103-1098192591-1344824911=:70371 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Test and set perhaps, but read before write implies locking...=A0 which you= don't wanna go there.=0A=0A=0A=0A=0A=0A>________________________________= =0A> From: Melinda Shore =0A>To: scim@ietf.org =0A= >Sent: Sunday, August 12, 2012 5:53 PM=0A>Subject: Re: [scim] scim Digest, = Vol 8, Issue 24=0A> =0A>On 8/12/12 4:13 PM, Phil Hunt wrote:=0A>> I strongl= y object to anything that leads to a read before modify=0A>> requirement. T= oo complex and too chatty.=0A>=0A>This strikes me as rather an important po= int.=A0 It might be more=0A>productive to think about error messaging in th= is context.=0A>=0A>Melinda=0A>=0A>=0A>_____________________________________= __________=0A>scim mailing list=0A>scim@ietf.org=0A>https://www.ietf.org/ma= ilman/listinfo/scim=0A>=0A>=0A> ---551393103-1098192591-1344824911=:70371 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Test and set perh= aps, but read before write implies locking...  which you don't wanna g= o there.


From: Melinda Shore <melinda.shore@gmail.com>
= To: scim@ietf.org
Sent: Sunday, August 12, 201= 2 5:53 PM
Subject: Re:= [scim] scim Digest, Vol 8, Issue 24

=0AOn 8/12/12 4:13 PM, Phil= Hunt wrote:
> I strongly object to anything that leads to a read bef= ore modify
> requirement. Too complex and too chatty.

This str= ikes me as rather an important point.  It might be more
productive = to think about error messaging in this context.

Melinda


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


---551393103-1098192591-1344824911=:70371-- From g.c.prasad@gmail.com Sun Aug 12 20:55:20 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6AB21F86A8 for ; Sun, 12 Aug 2012 20:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.257 X-Spam-Level: X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-5z6tmvDgeT for ; Sun, 12 Aug 2012 20:55:17 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8C21F8698 for ; Sun, 12 Aug 2012 20:55:16 -0700 (PDT) Received: by bkty7 with SMTP id y7so1416901bkt.31 for ; Sun, 12 Aug 2012 20:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zub+biMXvoVL/HfKHsPKUIbrPk+H7YB/VCTHyE8ENAs=; b=1DquzS4s6sbXZ/FOOYpk61wRLCeak4RsXtCoG8c0hqYckSteOkG0sFaJh7NCpDMFIZ aQdr9jECXTckL4qmyISRKcDqpDpPTUFtOrVwxaYYo0tskOZ0A5pSkwCc7nbvXSXLjpYL rzAN/rbGtEcgBae+TCMFBLV97QtwL5tleOwdWgTyRcu142i4QBWhd3m+0fKWdA8biTdi R9HMYCVJIiICoW98tqXzVlA5MNVf6+5rWeD3RjT9CPr+8YAem5oU7B0h4SE76o7n7E5k sOcJWOqUKN6ARJCFCUB0iSC46Ddv3jsCEZ4aaG+u3I64b4P/T9gHpviBx87SHaVB20Eo QhLg== Received: by 10.204.152.19 with SMTP id e19mr3642920bkw.8.1344830115552; Sun, 12 Aug 2012 20:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Sun, 12 Aug 2012 20:54:55 -0700 (PDT) In-Reply-To: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> From: Ganesh and Sashi Prasad Date: Mon, 13 Aug 2012 13:54:55 +1000 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=0015175d0406521f1404c71da928 Cc: "scim@ietf.org" , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 03:55:20 -0000 --0015175d0406521f1404c71da928 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > I strongly object to anything that leads to a read before modify requirement. Too complex and too chatty. Sorry Phil, but you're contradicting yourself here. There seems to be an awful lot of matching (i.e., reading) going on in the spec as it stands, with if-then clauses to do one thing or another if the match either succeeds or fails. This is a complex, chatty protocol right now! Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. For a spec that is supposed to be about simplicity, the above description is anything but simple. I know you guys have worked hard on this and I don't mean to disparage those efforts, but think about how the above passage would appear to a new reader (i.e., a novice to the spec, not a technology novice). There is something fundamentally broken, and it is this: multi-valued attributes without a unique identifier per value. If you don't fix that, you won't get simplicity. We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously commented back in 2005, "Unfortunately, some of the emerging protocols which also intend to represent and transfer personal identity information have perhaps taken a step backwards by not even considering these issues, perhaps sweeping them under the rug in the guise of simplicity, XMLification, or "fix in the next version", which only postpone finding interoperable solutions to allowing applications to express the identity entries they want to express." SCIM is exactly one of these "emerging protocols" Wahl talks about, and what I see now strikes me as "sweeping these issues under the rug in the guise of simplicity". Apologies for the bluntness. My take is that SPs are _already_ struggling to manage multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specification that made operations easier at the cost of a re-engineered schema. That calls for some thought leadership from this working group. Regards, Ganesh On 13 August 2012 10:13, Phil Hunt wrote: > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Phil > > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote: > > > Would it have to be stored on the account database of the service > provider?**** > > ** ** > > Yes. > > > > If so, I believe that this is impracticable in the core schema. Indeed > it implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration. > > Why? That doesn't necessarily follow. Implementation is independent of > representation. We're talking about a change in representation to make th= e > API cleaner. > > As a simple example, if an LDAP node is being used to hold a list of > comma-separated email addresses, it can just as easily store > comma-separated name-value pairs. > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com > > can be changed to > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com > > That's why I asked if there was an SP representative on this working grou= p > who could explain what such a change could mean for them. As of now, it > looks like other people are presuming that SPs will not be able to > implement these changes easily and are rejecting them for that reason. > > Regards, > Ganesh > > On 13 August 2012 04:29, Emmanuel Dreux wrote: > >> **=F0 **addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> ** ** >> >> Where would 3cbaaff8e84e come from? Would it have to be stored on the >> account database of the service provider?**** >> >> ** ** >> >> If so, I believe that this is impracticable in the core schema. Indeed i= t >> implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM >> integration.**** >> >> This would be a show stopper. SCIM must be transparent, and must be able >> to be put on top of an existing system to provide provisioning apis.**** >> >> ** ** >> >> Said differently, SCIM must not be intrusive for existing systems and >> must not require modifications to allow its integration.**** >> >> Correct me if I misunderstood your suggestion.**** >> >> ** ** >> >> --**** >> >> Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> ** ** >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org; Phil Hunt >> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> ** ** >> >> > Multi-valued attributes that don't have a value sub-attribute (eg - >> address) have to specified completely for uniqueness. **** >> >> ** ** >> >> That's exactly the point. How do we "specify completely for uniqueness"?= * >> *** >> >> ** ** >> >> In the example below, how are you proposing that the following element b= e >> updated if we can't use positional indexes?**** >> >> ** ** >> >> addresses[1].street-number =3D "243"**** >> >> ** ** >> >> User object:**** >> >> ** ** >> >> {**** >> >> ...**** >> >> addresses: [**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> ]**** >> >> }**** >> >> ** ** >> >> It's impractical to use the value because it's the whole dictionary >> element:**** >> >> ** ** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> ** ** >> >> With my proposal, the "addresses" array gets converted to a dictionary, >> and then we have a stable way of referencing this element:**** >> >> ** ** >> >> addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> ** ** >> >> {**** >> >> ...**** >> >> addresses: {**** >> >> "d6ea365462f5" :**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> "3cbaaff8e84e" :**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> }**** >> >> }**** >> >> ** ** >> >> If you're proposing one mechanism for composite attributes and another >> mechanism for simple attributes, I would suggest that's actually more >> complex than adopting a single mechanism that works the same way for _al= l_ >> attributes. Remember that a lot of the administration is probably going = to >> be scripted rather than done by hand, and having two mechanisms (dependi= ng >> on whether the attribute is simple or composite) will complicate every >> script that has to be written.**** >> >> ** ** >> >> There's a lot of talk about the "burden" on the SPs, but I believe this >> is overblown. Is there any SP representative in this WG who can tell us >> what this proposal will actually entail for them?**** >> >> ** ** >> >> Regards,**** >> >> Ganesh**** >> >> ** ** >> >> On 12 August 2012 11:53, Kelly Grizzle >> wrote:**** >> >> Ganesh,**** >> >> ** ** >> >> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >> that have a value sub-attribute can be removed by specifying only the va= lue >> since it is unique. Multi-valued attributes that don't have a value >> sub-attribute (eg - address) have to specified completely for uniqueness= . >> As I have said before, I am very opposed to adding a unique identifier = to >> each element in a multi-valued collection due to the burden it will put = on >> SPs. Is it elegant? No. Is it functional? Yes. Will this non-elegan= ce >> affect adoption? My opinion is that adding unique keys to each element >> will have a much more detrimental effect on adoption.**** >> >> ** ** >> >> I do believe that in general PATCH can be made more intuitive without >> adding uids to each element. The verbs that you propose make sense. Th= ere >> is also a JSON Patch informational draft in the IETF that is interesting= - >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >> on a JSON Pointer draft which uses index-based addressing for multi-valu= ed >> attributes. I think that this is something that should be looked at wit= hin >> the WG and I would be willing to lead this effort.**** >> >> ** ** >> >> I'm curious if anyone else in the WG is in favor of unique identifiers >> for every multi-valued element.**** >> >> ** ** >> >> --Kelly**** >> >> ** ** >> ------------------------------ >> >> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >> *Sent:* Saturday, August 11, 2012 10:50 AM >> *To:* Phil Hunt >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> Phil, **** >> >> ** ** >> >> The reason we cannot use the value itself to identify an element is that >> this method will only work for simple elements, not for nested structure= s. >> i.e., if we had an array of dictionaries (e.g., we had to record an arra= y >> of addresses for each customer, with each address element having >> sub-elements like street number, street name, suburb, etc.), then it wou= ld >> be clumsy to supply the entire value of the array element because it's >> itself a dictionary. Creating a unique key for each element scales bette= r. >> **** >> >> ** ** >> >> Regards,**** >> >> Ganesh**** >> >> On 12 August 2012 01:12, Phil Hunt wrote:**** >> >> Ganesh, **** >> >> ** ** >> >> Here's the sample that concerned me...**** >> >> The two operations differ significantly, and it's not very intuitive. *= * >> ** >> >> With my suggestion, here's how to delete a single member from a group:**= * >> * >> >> ** ** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> ** ** >> >> ** ** >> >> You gave other examples of an attribute with an identifier that matched >> that value or of identifiers that were additional unique keys.**** >> >> ** ** >> >> Given that multi-values must be each unique, I don't see the point of th= e >> extra indexing to support this. Just use the value as the item you wish = to >> delete.**** >> >> ** ** >> >> I agree, the delete value operation could be more explicit and clear in >> general.**** >> >> ** ** >> >> Phil**** >> >> ** ** >> >> @independentid**** >> >> www.independentid.com**** >> >> phil.hunt@oracle.com**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** >> >> >> >> **** >> >> > For the multi-value example you gave you used the value as the >> attribute name key. **** >> >> ** ** >> >> Now I'm confused :-). I don't believe any of my examples ever used a >> value as the key.**** >> >> ** ** >> >> Could you please show me which example you mean, and which parts of it >> you believe to be the value?**** >> >> ** ** >> >> Regards,**** >> >> Ganesh **** >> >> On 11 August 2012 13:59, Phil Hunt wrote:**** >> >> >> For the multi-value example you gave you used the value as the attribute >> name key. **** >> >> ** ** >> >> That means a lot more complex indexing structure. Better to just say >> delete a specific value. **** >> >> ** ** >> >> The spec already allows multiple values to have tags like home, work, et= c. >> **** >> >> ** ** >> >> Phil**** >> >> >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >> wrote:**** >> >> > In your example you are conflating value with an attribute id. >> >> I don't believe so. **** >> >> ** ** >> >> I'm adopting a model where every attribute of the resource is a key-valu= e >> pair. The key is a name or ID.**** >> >> ** ** >> >> For non-repeating attributes (both simple and composite), the key is the >> attribute name itself. **** >> >> ** ** >> >> Simple attribute:**** >> >> ** ** >> >> Key: "dob"**** >> >> Value: "01 Jan 1970"**** >> >> ** ** >> >> For composite attributes, the key employs dot notation to specify the >> fully-qualified attribute name, e.g., "address.postcode".**** >> >> ** ** >> >> Composite attribute:**** >> >> ** ** >> >> Key: "address.street-number"**** >> >> Value: "10"**** >> >> ** ** >> >> Key: "address.suburb"**** >> >> Value: "East Camden"**** >> >> ** ** >> >> For repeating (multi-valued) attributes, I'm suggesting that there be ne= w >> keys for each individual value, otherwise they are impossible to >> distinguish, and a positional index is inadequate. So we convert the arr= ay >> into a dictionary and this then becomes a composite attribute using dot >> notation for the key.**** >> >> ** ** >> >> Multi-valued attribute:**** >> >> ** ** >> >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** >> >> Value: "john_smith@yahoo.com"**** >> >> ** ** >> >> So this allows us to apply uniform treatment to any arbitrarily deep >> resource structure. We can refer to every leaf value with a key that is = the >> fully-qualified name using dot notation.**** >> >> ** ** >> >> The verbs are just unambiguous operations on these (now) explicitly >> addressable attributes.**** >> >> ** ** >> >> INCLUDE to a collection and specify only the value. The key is generated >> and returned. The fully-qualified key is >> . and the value is what was specifi= ed >> in the INCLUDE.**** >> >> ** ** >> >> REPLACE a fully-qualified key with a new value. If the key doesn't exist= , >> return a "404 Not Found".**** >> >> ** ** >> >> PLACE a value at the logical location implied by the fully-qualified key= . >> If there is already a key with that name, return a "409 Conflict".**** >> >> ** ** >> >> FORCE the fully-qualified key to hold the given value, regardless of >> whether it existed before or not. Only errors possible are "400 Bad >> Request" and "500 Internal Error".**** >> >> ** ** >> >> RETIRE an attribute or a collection given its fully-qualified key. The >> implementation will determine whether the attribute will disappear entir= ely >> or will exist holding a null value (the blank string "" or the empty obj= ect >> {} ).**** >> >> ** ** >> >> I'll explain in a separate post why we need operation verbs like these >> that are independent of the HTTP verbs.**** >> >> ** ** >> >> Regards,**** >> >> Ganesh**** >> >> ** ** >> >> On 11 August 2012 10:38, wrote:**** >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/scim >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send scim mailing list submissions to >> scim@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >> >> You can reach the person managing the list at >> scim-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >> >> Today's Topics: >> >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >> >> >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux < >> edreux@cloudiway.com>, Trey Drake , Kelly >> Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> Ganesh,**** >> >> ** ** >> >> In your example you are conflating value with an attribute id. I find >> that confusing. **** >> >> ** ** >> >> I agree though that operations in patch could be a lot more explicit. **= * >> * >> >> ** ** >> >> Eg explicitly deleting a value by saying delete or retire. **** >> >> >> Phil**** >> >> >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >> wrote:**** >> >> > I am concerned about your second suggestion: **** >> >> ** ** >> >> Let's discuss that now.**** >> >> ** ** >> >> The trade-offs are very clear here.**** >> >> ** ** >> >> Pros:**** >> >> ** ** >> >> Pro 1. The API to manipulate resources becomes so much cleaner, >> consistent and intuitive when every individual attribute value gets its = own >> ID.**** >> >> ** ** >> >> Here's how to delete a single member from a Group, as per the current >> spec:**** >> >> ** ** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "members": [**** >> >> {**** >> >> "display": "Babs Jensen",**** >> >> "value": "2819c223-7f76-453a-919d-413861904646"**** >> >> "operation": "delete"**** >> >> }**** >> >> ]**** >> >> }**** >> >> >> Here's how to delete ALL members from a group according to the current >> spec:**** >> >> ** ** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> ** ** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "meta": {**** >> >> "attributes": [**** >> >> "members"**** >> >> ]**** >> >> }**** >> >> }**** >> >> >> The two operations differ significantly, and it's not very intuitive. **= * >> * >> >> With my suggestion, here's how to delete a single member from a group:**= * >> * >> >> ** ** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } >> Here's how I suggest deleting ALL members from a group:**** >> >> ** ** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> >> I'm sure you'll agree that this is simpler, more consistent and more >> intuitive to a reader.**** >> >> ** ** >> >> Pro 2: We can apply this mechanism consistently to three areas:**** >> >> (a) Manipulating multi-valued attributes of a resource**** >> >> (b) Manipulating members of a group**** >> >> (c) Performing bulk operations, where we simply use HTTP verbs instead o= f >> the specialised (and semantically less ambiguous) verbs I suggested for >> attributes, the "key" becomes the URI, and the "value" becomes the >> corresponding JSON object.**** >> >> ** ** >> >> All of them return "207 Multi-Status" with the "results" array holding >> individual status codes.**** >> >> ** ** >> >> In the current spec, (a) and (b) are done similarly but (c) is very >> different.**** >> >> ** ** >> >> Pro 3: Adoption of the standard by clients is likely to be higher becaus= e >> it's simpler for them.**** >> >> ** ** >> >> Pro 4: New (not incumbent) cloud providers will probably find this easie= r >> to implement because they have no legacy. They will probably use some fo= rm >> of NoSQL database and won't be constrained by the limitations of LDAP >> directories.**** >> >> ** ** >> >> Cons:**** >> >> ** ** >> >> Con 1: Incumbent cloud providers with existing data stores in a director= y >> format (where multi-valued attributes are stored as comma-separated valu= es >> under a single attribute node) will find it difficult to migrate to this >> model and store each attribute value as a sub-node with its own key. Thi= s >> will "hinder adoption of the spec", which is what you fear.**** >> >> ** ** >> >> Have I summed up the Pros and Cons correctly? I'm biased of course, so I >> could have missed a Con or hyped a Pro :-).**** >> >> ** ** >> >> In other words, we're debating interface complexity (current spec) versu= s >> implementation complexity (my suggestion). Both can hinder adoption of t= he >> spec by different parties.**** >> >> ** ** >> >> Here's what we need to discuss - Do the Pros make the suggestio >> >> --0015175d0406521f1404c71da928 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0I strongly object to anything that leads to a read before modify req= uirement. Too complex and too chatty.

Sorry Phil, but you're con= tradicting yourself here.=A0There seems to be an awful lot of matching (i.e= ., reading) going on in the spec as it stands, with if-then clauses to do o= ne thing or another if the match either succeeds or fails. This is a comple= x, chatty protocol right now!

   Multi-valued attributes:  An attribute value in the =
PATCH request
      body is added to the value collection if the value does not exist
      and merged if a matching value is present.  Values are matched by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute; e.g., addresses, or do not have unique
      value Sub-Attributes cannot be matched and must instead be deleted
      then added.  Specific values can be removed from a Resource by
      adding an "operation" Sub-Attribute with the value "de=
lete" to the
      attribute in the PATCH request body.  As with adding/updating
      attribute value collections, the value to delete is determined by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute or that have a non-unique value Sub-
      Attribute are matched by comparing all Sub-Attribute values from
      the PATCH request body to the Sub-Attribute values of the
      Resource.  A delete operation is ignored if the attribute's name
      is in the meta.attributes list.  If the requested value to delete
      does not match a unique value on the Resource the server MAY
      return a HTTP 400 error.

For a spec that is supposed to be about sim= plicity, the above description is anything but simple. I know you guys have= worked hard on this and I don't mean to disparage those efforts, but t= hink about how the above passage would appear to a new reader (i.e., a novi= ce to the spec, not a technology novice).

There is something fundamentally broken, and it is this= : multi-valued attributes without a unique identifier per value. If you don= 't fix that, you won't get simplicity.

We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously c= ommented back in 2005,

"existing mechanisms are c= lumsy. They would be grateful for a specification that made operations = easier at the cost of a re-engineered schema. That calls for some thought l= eadership from this working group.

Regards,
Ganesh

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:
I strongly obj= ect to anything that leads to a read before modify requirement. Too complex= and too chatty.=A0

Phil

On 2012-08-12, = at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=

> Would it have to be stored on the accoun= t database of the service provider?

=A0=

Y= es.


> If so, I believe that this is impracticable= in the core schema.=A0Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integrat= ion.


Why? That doesn't necessarily follow. Implementatio= n is independent of representation. We're talking about a change in rep= resentation to make the API cleaner.

As a simple e= xample, if an LDAP node is being used to hold a list of comma-separated ema= il addresses, it can just as easily store comma-separated name-value pairs.=

<= div>
mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com

That's why I asked if there was an S= P representative on this working group who could explain what such a change= could mean for them. As of now, it looks like other people are presuming t= hat SPs will not be able to implement these changes easily and are rejectin= g them for that reason.

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <= span dir=3D"ltr"><edreux@cloudiway.com> wrote:

=F0=A0 addresses.3cbaaff8e84e.str= eet-number =3D "243"

=A0=

Where woul= d 3cbaaff8e84e come from? Would it have to be stored= on the account database of the service provider?

= =A0

If so, = I believe that this is impracticable in the core schema. Indeed it implies = that a service provider must extend the schema of his account repository (L= DAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This wo= uld be a show stopper. SCIM must be transparent, and must be able to be put= on top of an existing system to provide provisioning apis.

= =A0

Said di= fferently, SCIM must not be intrusive for existing systems and must not req= uire modifications to allow its integration.

Correct= me if I misunderstood your suggestion.

= =A0

--<= u>

Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=A0<= /p>

De=A0: Ganesh = and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

=A0

That's exactly the point. How do we "specif= y completely for uniqueness"?

=A0

In the example below, how are you proposing that the= following element be updated if we can't use positional indexes?

=A0

addresses[1].street-number =3D "243"

=A0

User object:

=A0

{

=A0 ...

=A0 addresses: [

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the value because it'= ;s the whole dictionary element:

=A0

{

=A0 "type" : "office",=

=A0 "street-number" : "213",<= /u>

=A0 "street-name" : "Main Street"= ;,

=A0 "suburb" : "Adelaide",

=A0 "postcode" : "5000",<= u>

=A0 "state" : "SA",

=A0 "country" : "Australia"

}

=A0

With my proposal, the "addresses" array ge= ts converted to a dictionary, and then we have a stable way of referencing = this element:

=A0

addresses.3cbaaff8e84e.street-number =3D "243&q= uot;

=A0

{

=A0 ...

=A0 addresses: {

=A0 =A0 "d6ea365462f5" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechanism for composite = attributes and another mechanism for simple attributes, I would suggest tha= t's actually more complex than adopting a single mechanism that works t= he same way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather t= han done by hand, and having two mechanisms (depending on whether the attri= bute is simple or composite) will complicate every script that has to be wr= itten.

=A0

There's a lot of talk about the "burden&quo= t; on the SPs, but I believe this is overblown. Is there any SP representat= ive in this WG who can tell us what this proposal will actually entail for = them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Ganesh,

=A0

This is exactly how PATCH works in SCIM = 1.0. =A0Multi-valued attributes that have a value sub-attribute can be remo= ved by specifying only the value since it is unique. =A0Multi-valued attributes that don't have a value sub-attribute (eg - address) have t= o specified completely for uniqueness. =A0As I have said before, I am very = opposed to adding a unique identifier to each element in a multi-valued col= lection due to the burden it will put on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in general PATCH can b= e made more intuitive without adding uids to each element. =A0The verbs tha= t you propose make sense. =A0There is also a JSON Patch informational draft in the IETF that is interesting -=A0http://tools.ietf= .org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Poin= ter draft which uses index-based addressing for multi-valued attributes. =A0I think that this is something that should= be looked at within the WG and I would be willing to lead this effort.<= /u>

=A0

I'm curious if anyone else in the WG= is in favor of unique identifiers for every multi-valued element.

=A0

--Kelly

=A0

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value itself to identif= y an element is that this method will only work for simple elements, not fo= r nested structures. i.e., if we had an array of dictionaries (e.g., we had= to record an array of addresses for each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creat= ing a unique key for each element scales better.

=A0

Regards,

Ganesh<= /p>

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> w= rote:

Ganesh,

=A0

Here's the sample that concerned me...=

The two operations differ significantly, and it'= s not very intuitive.=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute with an identifier = that matched that value or of identifiers that were additional unique keys.=

=A0

Given that multi-values must be each unique, I don't se= e the point of the extra indexing to support this. Just use the value as th= e item you wish to delete.

=A0

I agree, the delete value operation could be more explicit = and clear in general.

=A0

=A0

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad w= rote:



>=A0 For the multi-value example you gave you use= d the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don't believe any of= my examples ever used a value as the key.

=A0

Could you please show me which example you mean, and= which parts of it you believe to be the value?

=A0

Regards,

Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> w= rote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex indexing structure. Be= tter to just say delete a specific value.=A0

=A0

The spec already allows multiple values to have tags= like home, work, etc.

=A0

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

>=A0In your example you are conflating value with= an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where every attribute of th= e resource is a key-value pair. The key is a name or ID.

=A0

For non-repeating attributes (both simple and compos= ite), the key is the attribute name itself.=A0

=A0

Simple attribute:

=A0

Key: "dob"

Value: "01 Jan 1970"

=A0

For composite attributes, the key employs dot notati= on to specify the fully-qualified attribute name, e.g., "address.postc= ode".

=A0

Composite attribute:

=A0

Key: "address.street-number"=

Value: "10"

=A0

Key: "address.suburb"

Value: "East Camden"

=A0

For repeating (multi-valued) attributes, I'm sug= gesting that there be new keys for each individual value, otherwise they ar= e impossible to distinguish, and a positional index is inadequate. So we co= nvert the array into a dictionary and this then becomes a composite attribute using dot notation for the key.=

=A0

Multi-valued attribute:

=A0

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd9= 02"

=A0

So this allows us to apply uniform treatment to any = arbitrarily deep resource structure. We can refer to every leaf value with = a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous operations on these (= now) explicitly addressable attributes.

=A0

INCLUDE to a collection and specify only the value. = The key is generated and returned. The fully-qualified key is <collectio= n-name>.<newly-generated-ID> and the value is what was specified i= n the INCLUDE.

=A0

REPLACE a fully-qualified key with a new value. If t= he key doesn't exist, return a "404 Not Found".=

=A0

PLACE a value at the logical location implied by the= fully-qualified key. If there is already a key with that name, return a &q= uot;409 Conflict".

=A0

FORCE the fully-qualified key to hold the given valu= e, regardless of whether it existed before or not. Only errors possible are= "400 Bad Request" and "500 Internal Error".<= /u>

=A0

RETIRE an attribute or a collection given its fully-= qualified key. The implementation will determine whether the attribute will= disappear entirely or will exist holding a null value (the blank string &q= uot;" or the empty object {} ).

=A0

I'll explain in a separate post why we need oper= ation verbs like these that are independent of the HTTP verbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:=

If you have received this digest without all the ind= ividual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating value with an att= ribute id. I find that confusing.=A0

=A0

I agree though that operations in patch could be a l= ot more explicit.=A0

=A0

Eg explicitly deleting a value by saying delete or r= etire.=A0


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

=A0>=A0=A0I am concern= ed about your second suggestion:=A0

=A0

Let's discuss that now.

=A0

The trade-offs are very clear here.

=A0

Pros:

=A0

Pro 1. The API to manipulate resources becomes so mu= ch cleaner, consistent and intuitive when every individual attribute value = gets its own ID.

=A0

Here's how to delete a single member from a Grou= p, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "members": [
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 "displa=
y": "Babs Jensen",
=A0=A0=A0=A0=A0=A0=A0=A0 "value&=
quot;: "2819c223-7f76-453a-919d-413861904646"
=A0=A0=A0=A0=A0=A0=A0=A0 "operat=
ion": "delete"
=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0 ]

=A0=A0 }




Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "meta": {
=A0=A0=A0=A0=A0=A0 "attributes&q=
uot;: [
=A0=A0=A0=A0=A0=A0=A0=A0 "member=
s"
=A0=A0=A0=A0=A0=A0 ]
=A0=A0=A0=A0 }

=A0=A0 }




The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members"<= /p>

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism consistently to t= hree areas:

(a) Manipulating multi-valued attributes of a resour= ce

(b) Manipulating members of a group

(c) Performing bulk operations, where we simply use = HTTP verbs instead of the specialised (and semantically less ambiguous) ver= bs I suggested for attributes, the "key" becomes the URI, and the= "value" becomes the corresponding JSON object.

=A0

All of them return "207 Multi-Status" with= the "results" array holding individual status codes.

=A0

In the current spec, (a) and (b) are done similarly = but (c) is very different.

=A0

Pro 3: Adoption of the standard by clients is likely= to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud providers will prob= ably find this easier to implement because they have no legacy. They will p= robably use some form of NoSQL database and won't be constrained by the= limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers with existing data = stores in a directory format (where multi-valued attributes are stored as c= omma-separated values under a single attribute node) will find it difficult= to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinde= r adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons correctly? I'= m biased of course, so I could have missed a Con or hyped a Pro :-).=

=A0

In other words, we're debating interface complex= ity (current spec) versus implementation complexity (my suggestion). Both c= an hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss - Do the Pros mak= e the suggestio

<= /div>

--0015175d0406521f1404c71da928-- From melinda.shore@gmail.com Sun Aug 12 21:06:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5621F84F9 for ; Sun, 12 Aug 2012 21:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Xx+SmDXYo42 for ; Sun, 12 Aug 2012 21:06:03 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABE221F84F6 for ; Sun, 12 Aug 2012 21:06:03 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so6521204pbb.31 for ; Sun, 12 Aug 2012 21:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Sblw6QlEjXedS0DPJgnRvPVptSLToYcr9uhBKA3Di+E=; b=MVYctGLyXLr3NDYjo0WRYibposKPTsyCi+GvPP7P5TWOQk471ODJxKdFncd4Uvobg/ n5S8jqXiTB92E366qBrdXp/DfHhnyEV+Ke+O1lGXUvXZDEgl77rwoccFIiE0HbdhRZ5Q HfrW3A/QqY7+BIB+UDwM13LUe8Wgpr/8fz14tjXoE+pu2vjjZ4OplAZmrZYz4UKnLzAj F9dy60OSEAK0tYEm638gCZiVOZBLQGg/sNeGZXWDfSAwaY1k+XFOb+5MdVlWSJsuMEDZ O1ilBFDtqWzOE2sNvMjCKYAoCQVGF4AXiudCFY6M+PoC4DfP3iXCLb9HcKZkdnoZZKkX EwFA== Received: by 10.68.197.70 with SMTP id is6mr16030197pbc.64.1344830762993; Sun, 12 Aug 2012 21:06:02 -0700 (PDT) Received: from spandex.local (66-230-81-165-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.165]) by mx.google.com with ESMTPS id y11sm2632902pbv.66.2012.08.12.21.06.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Aug 2012 21:06:02 -0700 (PDT) Message-ID: <50287D28.8060607@gmail.com> Date: Sun, 12 Aug 2012 20:06:00 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 04:06:03 -0000 On 8/12/12 7:54 PM, Ganesh and Sashi Prasad wrote: > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now! ?? Not really. Try putting together a state machine diagram for the current spec and a state machine diagram for what you're proposing. The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. Melinda From g.c.prasad@gmail.com Sun Aug 12 23:35:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ED621F84F5 for ; Sun, 12 Aug 2012 23:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQiMsm35zUuT for ; Sun, 12 Aug 2012 23:35:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B58BA21F8495 for ; Sun, 12 Aug 2012 23:35:40 -0700 (PDT) Received: by bkty7 with SMTP id y7so1448106bkt.31 for ; Sun, 12 Aug 2012 23:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kNnx0BeLIxG1O3ghBoS3+9NPaShDqtMyYNfye/Um+bI=; b=SLw0pmpX3TOJq/zx1Mb8R94Vq9bHSiY+ZaYp4tEAmJeLp5bBYzTRUpKKpXOSxt45DG Nw4AvxJ73qjmQOFYP/BG5yBnM2VbNqh6FcH4Qs+LaFGEwLmUHqh92tY8wGes0vQ/hF0f N+8kT+0ERyD9BuBt7RGhWxZrXgMM8eGBuTisgiKYqk7oamJvstLP1W+PdyZZjC1zmbAt cQc1ASwA3CF7H9q9TPEMaPfO3kzYNg1du6MM7dKNTiL8n+ZJ4YKvIWUQuzL357ykbRVn CZomsnjBYM/BwQYnW4KT+jka3Id5Lhg0guzuhnTmK3YycetDbUuyhsIAcHel8boG/2/Q AAZw== Received: by 10.204.130.211 with SMTP id u19mr3659687bks.24.1344839739603; Sun, 12 Aug 2012 23:35:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Sun, 12 Aug 2012 23:35:19 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> From: Ganesh and Sashi Prasad Date: Mon, 13 Aug 2012 16:35:19 +1000 Message-ID: To: Phil Hunt , Melinda Shore Content-Type: multipart/alternative; boundary=0015173fe602f57aec04c71fe633 Cc: "scim@ietf.org" , Kelly Grizzle , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 06:35:44 -0000 --0015173fe602f57aec04c71fe633 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Responding to extract of Melinda Shore's mail from digest: The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. It depends on how it's implemented. I'm confident we can have the best of both - simple API with low-overhead implementation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've been hearing so far)? After all, no one has challenged the claim that this proposal drastically simplifies the API for the client, so it would appear to be worth doing. I'm sure there's more than enough intellectual horsepower in this working group to pull this off if we put our minds to it. Regards, Ganesh On 13 August 2012 13:54, Ganesh and Sashi Prasad wrot= e: > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now! > > Multi-valued attributes: An attribute value in the PATCH request > body is added to the value collection if the value does not exist > and merged if a matching value is present. Values are matched by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute; e.g., addresses, or do not have unique > value Sub-Attributes cannot be matched and must instead be deleted > then added. Specific values can be removed from a Resource by > adding an "operation" Sub-Attribute with the value "delete" to the > attribute in the PATCH request body. As with adding/updating > attribute value collections, the value to delete is determined by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute or that have a non-unique value Sub- > Attribute are matched by comparing all Sub-Attribute values from > the PATCH request body to the Sub-Attribute values of the > Resource. A delete operation is ignored if the attribute's name > is in the meta.attributes list. If the requested value to delete > does not match a unique value on the Resource the server MAY > return a HTTP 400 error. > > > For a spec that is supposed to be about simplicity, the above description > is anything but simple. I know you guys have worked hard on this and I > don't mean to disparage those efforts, but think about how the above > passage would appear to a new reader (i.e., a novice to the spec, not a > technology novice). > > There is something fundamentally broken, and it is this: multi-valued > attributes without a unique identifier per value. If you don't fix that, > you won't get simplicity. > > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl f= amously > commented back > in 2005, > > "Unfortunately, some of the emerging protocols which also intend to > represent and transfer personal identity information have perhaps taken a > step backwards by not even considering these issues, perhaps sweeping the= m > under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt > version", which only postpone finding interoperable solutions to allowing > applications to express the identity entries they want to express." > > SCIM is exactly one of these "emerging protocols" Wahl talks about, and > what I see now strikes me as "sweeping these issues under the rug in the > guise of simplicity". Apologies for the bluntness. > > My take is that SPs are _already_ struggling to manage multi-valued > attributes, and existing mechanisms are clumsy. > They would be grateful for a specification that made operations easier at > the cost of a re-engineered schema. That calls for some thought leadershi= p > from this working group. > > Regards, > Ganesh > > > On 13 August 2012 10:13, Phil Hunt wrote: > >> I strongly object to anything that leads to a read before modify >> requirement. Too complex and too chatty. >> >> Phil >> >> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad >> wrote: >> >> > Would it have to be stored on the account database of the service >> provider?**** >> >> ** ** >> >> Yes. >> >> >> > If so, I believe that this is impracticable in the core schema. Indeed >> it implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM >> integration. >> >> Why? That doesn't necessarily follow. Implementation is independent of >> representation. We're talking about a change in representation to make t= he >> API cleaner. >> >> As a simple example, if an LDAP node is being used to hold a list of >> comma-separated email addresses, it can just as easily store >> comma-separated name-value pairs. >> >> mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com >> >> can be changed to >> >> mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D >> john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >> >> That's why I asked if there was an SP representative on this working >> group who could explain what such a change could mean for them. As of no= w, >> it looks like other people are presuming that SPs will not be able to >> implement these changes easily and are rejecting them for that reason. >> >> Regards, >> Ganesh >> >> On 13 August 2012 04:29, Emmanuel Dreux wrote: >> >>> **=F0 **addresses.3cbaaff8e84e.street-number =3D "243"**** >>> >>> ** ** >>> >>> Where would 3cbaaff8e84e come from? Would it have to be stored on the >>> account database of the service provider?**** >>> >>> ** ** >>> >>> If so, I believe that this is impracticable in the core schema. Indeed >>> it implies that a service provider must extend the schema of his accoun= t >>> repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM >>> integration.**** >>> >>> This would be a show stopper. SCIM must be transparent, and must be abl= e >>> to be put on top of an existing system to provide provisioning apis.***= * >>> >>> ** ** >>> >>> Said differently, SCIM must not be intrusive for existing systems and >>> must not require modifications to allow its integration.**** >>> >>> Correct me if I misunderstood your suggestion.**** >>> >>> ** ** >>> >>> --**** >>> >>> Regards,**** >>> >>> Emmanuel Dreux**** >>> >>> http://www.cloudiway.com**** >>> >>> Tel: +33 4 26 78 17 58**** >>> >>> Mobile: +33 6 47 81 26 70**** >>> >>> skype: Emmanuel.Dreux**** >>> >>> ** ** >>> >>> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >>> *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 >>> *=C0 :* Kelly Grizzle >>> *Cc :* scim@ietf.org; Phil Hunt >>> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** >>> >>> ** ** >>> >>> > Multi-valued attributes that don't have a value sub-attribute (eg - >>> address) have to specified completely for uniqueness. **** >>> >>> ** ** >>> >>> That's exactly the point. How do we "specify completely for uniqueness"= ? >>> **** >>> >>> ** ** >>> >>> In the example below, how are you proposing that the following element >>> be updated if we can't use positional indexes?**** >>> >>> ** ** >>> >>> addresses[1].street-number =3D "243"**** >>> >>> ** ** >>> >>> User object:**** >>> >>> ** ** >>> >>> {**** >>> >>> ...**** >>> >>> addresses: [**** >>> >>> {**** >>> >>> "type" : "home",**** >>> >>> "street-number" : "35",**** >>> >>> "street-name" : "High Road",**** >>> >>> "suburb" : "East Camden",**** >>> >>> "postcode" : "5346",**** >>> >>> "state" : "SA",**** >>> >>> "country" : "Australia"**** >>> >>> },**** >>> >>> {**** >>> >>> "type" : "office",**** >>> >>> "street-number" : "213",**** >>> >>> "street-name" : "Main Street",**** >>> >>> "suburb" : "Adelaide",**** >>> >>> "postcode" : "5000",**** >>> >>> "state" : "SA",**** >>> >>> "country" : "Australia"**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> ** ** >>> >>> It's impractical to use the value because it's the whole dictionary >>> element:**** >>> >>> ** ** >>> >>> {**** >>> >>> "type" : "office",**** >>> >>> "street-number" : "213",**** >>> >>> "street-name" : "Main Street",**** >>> >>> "suburb" : "Adelaide",**** >>> >>> "postcode" : "5000",**** >>> >>> "state" : "SA",**** >>> >>> "country" : "Australia"**** >>> >>> }**** >>> >>> ** ** >>> >>> With my proposal, the "addresses" array gets converted to a dictionary, >>> and then we have a stable way of referencing this element:**** >>> >>> ** ** >>> >>> addresses.3cbaaff8e84e.street-number =3D "243"**** >>> >>> ** ** >>> >>> {**** >>> >>> ...**** >>> >>> addresses: {**** >>> >>> "d6ea365462f5" :**** >>> >>> {**** >>> >>> "type" : "home",**** >>> >>> "street-number" : "35",**** >>> >>> "street-name" : "High Road",**** >>> >>> "suburb" : "East Camden",**** >>> >>> "postcode" : "5346",**** >>> >>> "state" : "SA",**** >>> >>> "country" : "Australia"**** >>> >>> },**** >>> >>> "3cbaaff8e84e" :**** >>> >>> {**** >>> >>> "type" : "office",**** >>> >>> "street-number" : "213",**** >>> >>> "street-name" : "Main Street",**** >>> >>> "suburb" : "Adelaide",**** >>> >>> "postcode" : "5000",**** >>> >>> "state" : "SA",**** >>> >>> "country" : "Australia"**** >>> >>> }**** >>> >>> }**** >>> >>> }**** >>> >>> ** ** >>> >>> If you're proposing one mechanism for composite attributes and another >>> mechanism for simple attributes, I would suggest that's actually more >>> complex than adopting a single mechanism that works the same way for _a= ll_ >>> attributes. Remember that a lot of the administration is probably going= to >>> be scripted rather than done by hand, and having two mechanisms (depend= ing >>> on whether the attribute is simple or composite) will complicate every >>> script that has to be written.**** >>> >>> ** ** >>> >>> There's a lot of talk about the "burden" on the SPs, but I believe this >>> is overblown. Is there any SP representative in this WG who can tell us >>> what this proposal will actually entail for them?**** >>> >>> ** ** >>> >>> Regards,**** >>> >>> Ganesh**** >>> >>> ** ** >>> >>> On 12 August 2012 11:53, Kelly Grizzle >>> wrote:**** >>> >>> Ganesh,**** >>> >>> ** ** >>> >>> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >>> that have a value sub-attribute can be removed by specifying only the v= alue >>> since it is unique. Multi-valued attributes that don't have a value >>> sub-attribute (eg - address) have to specified completely for uniquenes= s. >>> As I have said before, I am very opposed to adding a unique identifier= to >>> each element in a multi-valued collection due to the burden it will put= on >>> SPs. Is it elegant? No. Is it functional? Yes. Will this non-elega= nce >>> affect adoption? My opinion is that adding unique keys to each element >>> will have a much more detrimental effect on adoption.**** >>> >>> ** ** >>> >>> I do believe that in general PATCH can be made more intuitive without >>> adding uids to each element. The verbs that you propose make sense. T= here >>> is also a JSON Patch informational draft in the IETF that is interestin= g - >>> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >>> on a JSON Pointer draft which uses index-based addressing for multi-val= ued >>> attributes. I think that this is something that should be looked at wi= thin >>> the WG and I would be willing to lead this effort.**** >>> >>> ** ** >>> >>> I'm curious if anyone else in the WG is in favor of unique identifiers >>> for every multi-valued element.**** >>> >>> ** ** >>> >>> --Kelly**** >>> >>> ** ** >>> ------------------------------ >>> >>> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >>> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >>> *Sent:* Saturday, August 11, 2012 10:50 AM >>> *To:* Phil Hunt >>> *Cc:* scim@ietf.org >>> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >>> >>> Phil, **** >>> >>> ** ** >>> >>> The reason we cannot use the value itself to identify an element is tha= t >>> this method will only work for simple elements, not for nested structur= es. >>> i.e., if we had an array of dictionaries (e.g., we had to record an arr= ay >>> of addresses for each customer, with each address element having >>> sub-elements like street number, street name, suburb, etc.), then it wo= uld >>> be clumsy to supply the entire value of the array element because it's >>> itself a dictionary. Creating a unique key for each element scales bett= er. >>> **** >>> >>> ** ** >>> >>> Regards,**** >>> >>> Ganesh**** >>> >>> On 12 August 2012 01:12, Phil Hunt wrote:**** >>> >>> Ganesh, **** >>> >>> ** ** >>> >>> Here's the sample that concerned me...**** >>> >>> The two operations differ significantly, and it's not very intuitive. = * >>> *** >>> >>> With my suggestion, here's how to delete a single member from a group:*= * >>> ** >>> >>> ** ** >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" {**** >>> >>> "operations" : [**** >>> >>> {**** >>> >>> "RETIRE" : {**** >>> >>> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >>> >>> }**** >>> >>> }**** >>> >>> ] } **** >>> >>> ** ** >>> >>> ** ** >>> >>> You gave other examples of an attribute with an identifier that matched >>> that value or of identifiers that were additional unique keys.**** >>> >>> ** ** >>> >>> Given that multi-values must be each unique, I don't see the point of >>> the extra indexing to support this. Just use the value as the item you = wish >>> to delete.**** >>> >>> ** ** >>> >>> I agree, the delete value operation could be more explicit and clear in >>> general.**** >>> >>> ** ** >>> >>> Phil**** >>> >>> ** ** >>> >>> @independentid**** >>> >>> www.independentid.com**** >>> >>> phil.hunt@oracle.com**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** >>> >>> >>> >>> **** >>> >>> > For the multi-value example you gave you used the value as the >>> attribute name key. **** >>> >>> ** ** >>> >>> Now I'm confused :-). I don't believe any of my examples ever used a >>> value as the key.**** >>> >>> ** ** >>> >>> Could you please show me which example you mean, and which parts of it >>> you believe to be the value?**** >>> >>> ** ** >>> >>> Regards,**** >>> >>> Ganesh **** >>> >>> On 11 August 2012 13:59, Phil Hunt wrote:**** >>> >>> >>> For the multi-value example you gave you used the value as the attribut= e >>> name key. **** >>> >>> ** ** >>> >>> That means a lot more complex indexing structure. Better to just say >>> delete a specific value. **** >>> >>> ** ** >>> >>> The spec already allows multiple values to have tags like home, work, >>> etc.**** >>> >>> ** ** >>> >>> Phil**** >>> >>> >>> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >>> wrote:**** >>> >>> > In your example you are conflating value with an attribute id. >>> >>> I don't believe so. **** >>> >>> ** ** >>> >>> I'm adopting a model where every attribute of the resource is a >>> key-value pair. The key is a name or ID.**** >>> >>> ** ** >>> >>> For non-repeating attributes (both simple and composite), the key is th= e >>> attribute name itself. **** >>> >>> ** ** >>> >>> Simple attribute:**** >>> >>> ** ** >>> >>> Key: "dob"**** >>> >>> Value: "01 Jan 1970"**** >>> >>> ** ** >>> >>> For composite attributes, the key employs dot notation to specify the >>> fully-qualified attribute name, e.g., "address.postcode".**** >>> >>> ** ** >>> >>> Composite attribute:**** >>> >>> ** ** >>> >>> Key: "address.street-number"**** >>> >>> Value: "10"**** >>> >>> ** ** >>> >>> Key: "address.suburb"**** >>> >>> Value: "East Camden"**** >>> >>> ** ** >>> >>> For repeating (multi-valued) attributes, I'm suggesting that there be >>> new keys for each individual value, otherwise they are impossible to >>> distinguish, and a positional index is inadequate. So we convert the ar= ray >>> into a dictionary and this then becomes a composite attribute using dot >>> notation for the key.**** >>> >>> ** ** >>> >>> Multi-valued attribute:**** >>> >>> ** ** >>> >>> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** >>> >>> Value: "john_smith@yahoo.com"**** >>> >>> ** ** >>> >>> So this allows us to apply uniform treatment to any arbitrarily deep >>> resource structure. We can refer to every leaf value with a key that is= the >>> fully-qualified name using dot notation.**** >>> >>> ** ** >>> >>> The verbs are just unambiguous operations on these (now) explicitly >>> addressable attributes.**** >>> >>> ** ** >>> >>> INCLUDE to a collection and specify only the value. The key is generate= d >>> and returned. The fully-qualified key is >>> . and the value is what was specif= ied >>> in the INCLUDE.**** >>> >>> ** ** >>> >>> REPLACE a fully-qualified key with a new value. If the key doesn't >>> exist, return a "404 Not Found".**** >>> >>> ** ** >>> >>> PLACE a value at the logical location implied by the fully-qualified >>> key. If there is already a key with that name, return a "409 Conflict".= * >>> *** >>> >>> ** ** >>> >>> FORCE the fully-qualified key to hold the given value, regardless of >>> whether it existed before or not. Only errors possible are "400 Bad >>> Request" and "500 Internal Error".**** >>> >>> ** ** >>> >>> RETIRE an attribute or a collection given its fully-qualified key. The >>> implementation will determine whether the attribute will disappear enti= rely >>> or will exist holding a null value (the blank string "" or the empty ob= ject >>> {} ).**** >>> >>> ** ** >>> >>> I'll explain in a separate post why we need operation verbs like these >>> that are independent of the HTTP verbs.**** >>> >>> ** ** >>> >>> Regards,**** >>> >>> Ganesh**** >>> >>> ** ** >>> >>> On 11 August 2012 10:38, wrote:**** >>> >>> If you have received this digest without all the individual message >>> attachments you will need to update your digest options in your list >>> subscription. To do so, go to >>> >>> https://www.ietf.org/mailman/listinfo/scim >>> >>> Click the 'Unsubscribe or edit options' button, log in, and set "Get >>> MIME or Plain Text Digests?" to MIME. You can set this option >>> globally for all the list digests you receive at this point. >>> >>> >>> >>> Send scim mailing list submissions to >>> scim@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/scim >>> or, via email, send a message with subject or body 'help' to >>> scim-request@ietf.org >>> >>> You can reach the person managing the list at >>> scim-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of scim digest..." >>> >>> Today's Topics: >>> >>> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>> >>> >>> ---------- Forwarded message ---------- >>> From: Phil Hunt >>> To: Ganesh and Sashi Prasad >>> Cc: "Diodati, Mark" , Emmanuel Dreux < >>> edreux@cloudiway.com>, Trey Drake , Kelly >>> Grizzle , "scim@ietf.org" >>> Date: Fri, 10 Aug 2012 17:36:54 -0700 >>> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >>> >>> Ganesh,**** >>> >>> ** ** >>> >>> In your example you are conflating value with an attribute id. I find >>> that confusing. **** >>> >>> ** ** >>> >>> I agree though that operations in patch could be a lot more explicit. *= * >>> ** >>> >>> ** ** >>> >>> Eg explicitly deleting a value by saying delete or retire. **** >>> >>> >>> Phil**** >>> >>> >>> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >>> wrote:**** >>> >>> > I am concerned about your second suggestion: **** >>> >>> ** ** >>> >>> Let's discuss that now.**** >>> >>> ** ** >>> >>> The trade-offs are very clear here.**** >>> >>> ** ** >>> >>> Pros:**** >>> >>> ** ** >>> >>> Pro 1. The API to manipulate resources becomes so much cleaner, >>> consistent and intuitive when every individual attribute value gets its= own >>> ID.**** >>> >>> ** ** >>> >>> Here's how to delete a single member from a Group, as per the current >>> spec:**** >>> >>> ** ** >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >>> >>> Host: example.com**** >>> >>> Accept: application/json**** >>> >>> Authorization: Bearer h480djs93hd8**** >>> >>> ETag: W/"a330bc54f0671c9"**** >>> >>> ** ** >>> >>> {**** >>> >>> "schemas": ["urn:scim:schemas:core:1.0"],**** >>> >>> "members": [**** >>> >>> {**** >>> >>> "display": "Babs Jensen",**** >>> >>> "value": "2819c223-7f76-453a-919d-413861904646"**** >>> >>> "operation": "delete"**** >>> >>> }**** >>> >>> ]**** >>> >>> }**** >>> >>> >>> Here's how to delete ALL members from a group according to the current >>> spec:**** >>> >>> ** ** >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >>> >>> Host: example.com**** >>> >>> Accept: application/json**** >>> >>> Authorization: Bearer h480djs93hd8**** >>> >>> ETag: W/"a330bc54f0671c9"**** >>> >>> ** ** >>> >>> {**** >>> >>> "schemas": ["urn:scim:schemas:core:1.0"],**** >>> >>> "meta": {**** >>> >>> "attributes": [**** >>> >>> "members"**** >>> >>> ]**** >>> >>> }**** >>> >>> }**** >>> >>> >>> The two operations differ significantly, and it's not very intuitive. *= * >>> ** >>> >>> With my suggestion, here's how to delete a single member from a group:*= * >>> ** >>> >>> ** ** >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" {**** >>> >>> "operations" : [**** >>> >>> {**** >>> >>> "RETIRE" : {**** >>> >>> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >>> >>> }**** >>> >>> }**** >>> >>> ] } >>> Here's how I suggest deleting ALL members from a group:**** >>> >>> ** ** >>> >>> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcc= ept: application/json Authorization: Bearer h480djs93hd8 ETag: >>> W/"a330bc54f0671c9" {**** >>> >>> "operations" : [**** >>> >>> {**** >>> >>> "RETIRE" : {**** >>> >>> "key" : "members"**** >>> >>> }**** >>> >>> }**** >>> >>> ] } **** >>> >>> >>> I'm sure you'll agree that this is simpler, more consistent and more >>> intuitive to a reader.**** >>> >>> ** ** >>> >>> Pro 2: We can apply this mechanism consistently to three areas:**** >>> >>> (a) Manipulating multi-valued attributes of a resource**** >>> >>> (b) Manipulating members of a group**** >>> >>> (c) Performing bulk operations, where we simply use HTTP verbs instead >>> of the specialised (and semantically less ambiguous) verbs I suggested = for >>> attributes, the "key" becomes the URI, and the "value" becomes the >>> corresponding JSON object.**** >>> >>> ** ** >>> >>> All of them return "207 Multi-Status" with the "results" array holding >>> individual status codes.**** >>> >>> ** ** >>> >>> In the current spec, (a) and (b) are done similarly but (c) is very >>> different.**** >>> >>> ** ** >>> >>> Pro 3: Adoption of the standard by clients is likely to be higher >>> because it's simpler for them.**** >>> >>> ** ** >>> >>> Pro 4: New (not incumbent) cloud providers will probably find this >>> easier to implement because they have no legacy. They will probably use >>> some form of NoSQL database and won't be constrained by the limitations= of >>> LDAP directories.**** >>> >>> ** ** >>> >>> Cons:**** >>> >>> ** ** >>> >>> Con 1: Incumbent cloud providers with existing data stores in a >>> directory format (where multi-valued attributes are stored as >>> comma-separated values under a single attribute node) will find it >>> difficult to migrate to this model and store each attribute value as a >>> sub-node with its own key. This will "hinder adoption of the spec", whi= ch >>> is what you fear.**** >>> >>> ** ** >>> >>> Have I summed up the Pros and Cons correctly? I'm biased of course, so = I >>> could have missed a Con or hyped a Pro :-).**** >>> >>> ** ** >>> >>> In other words, we're debating interface complexity (current spec) >>> versus implementation complexity (my suggestion). Both can hinder adopt= ion >>> of the spec by different parties.**** >>> >>> ** ** >>> >>> Here's what we need to discuss - Do the Pros make the suggestio >>> >>> > --0015173fe602f57aec04c71fe633 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Responding to extract of Melinda Shore's mail from digest:
--0015173fe602f57aec04c71fe633-- From kelly.grizzle@sailpoint.com Mon Aug 13 07:27:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C0521F8751 for ; Mon, 13 Aug 2012 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.414 X-Spam-Level: X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAZQp+8Dfsme for ; Mon, 13 Aug 2012 07:27:35 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id B66C321F8702 for ; Mon, 13 Aug 2012 07:27:34 -0700 (PDT) Received: from mail226-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Aug 2012 14:27:33 +0000 Received: from mail226-va3 (localhost [127.0.0.1]) by mail226-va3-R.bigfish.com (Postfix) with ESMTP id 4581D900360; Mon, 13 Aug 2012 14:27:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -95 X-BigFish: PS-95(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85dh1432I1418Iac5W9d9Rzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail226-va3: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail226-va3 (localhost.localdomain [127.0.0.1]) by mail226-va3 (MessageSwitch) id 1344868050270956_10504; Mon, 13 Aug 2012 14:27:30 +0000 (UTC) Received: from VA3EHSMHS016.bigfish.com (unknown [10.7.14.242]) by mail226-va3.bigfish.com (Postfix) with ESMTP id 3D88A780045; Mon, 13 Aug 2012 14:27:30 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by VA3EHSMHS016.bigfish.com (10.7.99.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Aug 2012 14:27:29 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0175.005; Mon, 13 Aug 2012 14:27:26 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad , Phil Hunt , Melinda Shore Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PrysoINrXz30exI2CcM9WIa5dT/IGAgABLt4CAAHBZgIAACouAgACi+YWAABY3AIABBZAAgAAyWwCAAC3NgIAAPeCAgAAs0YCAAHzV0A== Date: Mon, 13 Aug 2012 14:27:25 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330259C2BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:27:48 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330259C2BY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > After all, no one has challenged the claim that this proposal drastically= simplifies the API for the client I agree that your proposal makes PATCH semantics simpler and more elegant. > ... so it would appear to be worth doing. I strongly disagree here. This statements assumes that simplicity of the c= lient API is the only factor that should be considered with the spec. Emmanuel's example is from a real-world service provider that would not be = able to implement the spec easily with a uid per element. He is working on= a SCIM interface that will help facilitate data exchange between multiple = Active Directory servers. Your solution was to change the data model from = this: mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com to this: mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com I do not know of a single organization that would change their Active Direc= tory data model to fit this. For one thing, it would be a huge data migrat= ion effort (likely across other domain controllers, etc...) to assign these= unique identifiers. This also assumes that SCIM is the only reader/writer= of this data, which will almost never be the case. If the data model requ= ires uids for every element, then every piece of non-SCIM code that writes = data into the directory will have to follow this. Additionally, there are = *many* tools and applications (eg - address books) that rely on a certain = data model in Active Directory, and this would cause them to break. IMO th= is same argument holds true for most service providers. PATCH is an optional part of the spec. It was primarily introduced to make= modifying resources with large multi-valued lists more efficient. It does= not need to solve every problem (eg - modifying sub-elements in nested arr= ays). Adding uids to every multi-valued element does not strike the right = balance between the needs of the client and the needs of the service provid= er. --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 1:35 AM To: Phil Hunt; Melinda Shore Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Responding to extract of Melinda Shore's mail from digest: The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. It depends on how it's implemented. I'm confident we can have the best of b= oth - simple API with low-overhead implementation. Can we brainstorm HOW th= is proposal can be implemented rather than WHY it can't be implemented (whi= ch is mostly what I've been hearing so far)? After all, no one has challeng= ed the claim that this proposal drastically simplifies the API for the clie= nt, so it would appear to be worth doing. I'm sure there's more than enough= intellectual horsepower in this working group to pull this off if we put o= ur minds to it. Regards, Ganesh On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote: > I strongly object to anything that leads to a read before modify requirem= ent. Too complex and too chatty. Sorry Phil, but you're contradicting yourself here. There seems to be an aw= ful lot of matching (i.e., reading) going on in the spec as it stands, with= if-then clauses to do one thing or another if the match either succeeds or= fails. This is a complex, chatty protocol right now! Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. For a spec that is supposed to be about simplicity, the above description i= s anything but simple. I know you guys have worked hard on this and I don't= mean to disparage those efforts, but think about how the above passage wou= ld appear to a new reader (i.e., a novice to the spec, not a technology nov= ice). There is something fundamentally broken, and it is this: multi-valued attri= butes without a unique identifier per value. If you don't fix that, you won= 't get simplicity. We know LDAP trees are broken for multi-valued attributes. As Mark Wahl fam= ously commented ba= ck in 2005, "Unfortunately, some of the emerging protocols which also intend to represe= nt and transfer personal identity information have perhaps taken a step bac= kwards by not even considering these issues, perhaps sweeping them under th= e rug in the guise of simplicity, XMLification, or "fix in the next version= ", which only postpone finding interoperable solutions to allowing applicat= ions to express the identity entries they want to express." SCIM is exactly one of these "emerging protocols" Wahl talks about, and wha= t I see now strikes me as "sweeping these issues under the rug in the guise= of simplicity". Apologies for the bluntness. My take is that SPs are _already_ struggling to manage multi-valued attribu= tes, and existing mechanisms are clumsy. They would be grateful f= or a specification that made operations easier at the cost of a re-engineer= ed schema. That calls for some thought leadership from this working group. Regards, Ganesh On 13 August 2012 10:13, Phil Hunt > wrote: I strongly object to anything that leads to a read before modify requiremen= t. Too complex and too chatty. Phil On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote: > Would it have to be stored on the account database of the service provide= r? Yes. > If so, I believe that this is impracticable in the core schema. Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. Why? That doesn't necessarily follow. Implementation is independent of repr= esentation. We're talking about a change in representation to make the API = cleaner. As a simple example, if an LDAP node is being used to hold a list of comma-= separated email addresses, it can just as easily store comma-separated name= -value pairs. mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com can be changed to mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com That's why I asked if there was an SP representative on this working group = who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement t= hese changes easily and are rejecting them for that reason. Regards, Ganesh On 13 August 2012 04:29, Emmanuel Dreux > wrote: =3D> addresses.3cbaaff8e84e.street-number =3D "243" Where would 3cbaaff8e84e come from? Would it have to be stored on the accou= nt database of the service provider? If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposi= tory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. This would be a show stopper. SCIM must be transparent, and must be able to= be put on top of an existing system to provide provisioning apis. Said differently, SCIM must not be intrusive for existing systems and must = not require modifications to allow its integration. Correct me if I misunderstood your suggestion. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 =C0 : Kelly Grizzle Cc : scim@ietf.org; Phil Hunt Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestio --_000_56C3C758F9D6534CA3778EAA1E0C3437330259C2BY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> After all, no one has challenged the claim that= this proposal drastically simplifies the API for the client

 <= /p>

I agree that your proposa= l makes PATCH semantics simpler and more elegant.

 <= /p>

 <= /p>

> … so it would appear to be worth doing.  <= /p>

I strongly disagree here.=   This statements assumes that simplicity of the client API is the onl= y factor that should be considered with the spec.

 <= /p>

Emmanuel’s example = is from a real-world service provider that would not be able to implement t= he spec easily with a uid per element.  He is working on a SCIM interface that will help facilitate data exchange between multiple Active = Directory servers.  Your solution was to change the data model from th= is:

 <= /p> 

m=
ail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com

 <=
/p>

to this:


 <=
/p>

mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com<=
/o:p>


 <=
/p>

I do not know of a single=
 organization that would change their Active Directory data model to fit th=
is.  For one thing, it would be a huge data migration effort
 (likely across other domain controllers, etc…) to assign these uniqu=
e identifiers.  This also assumes that SCIM is the only reader/writer =
of this data, which will almost never be the case.  If the data model =
requires uids for every element, then every piece
 of non-SCIM code that writes data into the directory will have to follow t=
his.  Additionally, there are *many* tools and applications &nb=
sp;(eg – address books) that rely on a certain data model in Active D=
irectory, and this would cause them to break.  IMO
 this same argument holds true for most service providers.


 <=
/p>

 <=
/p>

PATCH is an optional part=
 of the spec.  It was primarily introduced to make modifying resources=
 with large multi-valued lists more efficient.  It does not need
 to solve every problem (eg – modifying sub-elements in nested arrays=
).  Adding uids to every multi-valued element does not strike the righ=
t balance between the needs of the client and the needs of the service prov=
ider.


 <=
/p>

--Kelly=



 <=
/p>



From: Ganesh a=
nd Sashi Prasad [mailto:g.c.prasad@gmail.com]


Sent: Monday, August 13, 2012 1:35 AM

To: Phil Hunt; Melinda Shore

Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org

Subject: Re: [scim] scim Digest, Vol 8, Issue 24



 


Responding to extract of Melinda Shore's mail from d=
igest:




 






The issue being ra=
ised here isn't endpoint logic, but


network traffic, and I'm pretty sure it's not very helpful to


respond to the observation that your model requires more

messages with a complaint about what you seem to think is a=



complex algorithm for attribute processing.




 






It depends on how it's implemented. I'm confident we=
 can have the best of both - simple API with low-overhead implementation. C=
an we brainstorm HOW this proposal can be implemented rather than WHY it ca=
n't be implemented (which is mostly
 what I've been hearing so far)? After all, no one has challenged the claim=
 that this proposal drastically simplifies the API for the client, so it wo=
uld appear to be worth doing. I'm sure there's more than enough intell=
ectual horsepower in this working group
 to pull this off if we put our minds to it.






 






Regards,






Ganesh




 




On 13 August 2012 13:54, Ganesh and Sashi Prasad <=
;g.c.prasad@gmail=
.com> wrote:




> I strongly =
object to anything that leads to a read before modify requirement. Too comp=
lex and too chatty.




Sorry Phil, but you're contradicting yourself here.&=
nbsp;There seems to be an awful lot of matching (i.e., reading) going on in=
 the spec as it stands, with if-then clauses to do one thing or another if =
the match either succeeds or fails. This
 is a complex, chatty protocol right now!




 






   Multi-valued attributes:=
  An attribute value in the PATCH request


      body i=
s added to the value collection if the value does not exist


      and me=
rged if a matching value is present.  Values are matched by=



      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not<=
/span>


      have a=
 value Sub-Attribute; e.g., addresses, or do not have unique


      value =
Sub-Attributes cannot be matched and must instead be deleted


      then a=
dded.  Specific values can be removed from a Resource by


      adding=
 an "operation" Sub-Attribute with the value "delete" t=
o the


      attrib=
ute in the PATCH request body.  As with adding/updating


      attrib=
ute value collections, the value to delete is determined by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not<=
/span>


      have a=
 value Sub-Attribute or that have a non-unique value Sub-=



      Attrib=
ute are matched by comparing all Sub-Attribute values from


      the PA=
TCH request body to the Sub-Attribute values of the


      Resour=
ce.  A delete operation is ignored if the attribute's name<=
/span>


      is in =
the meta.attributes list.  If the requested value to delete=



      does n=
ot match a unique value on the Resource the server MAY

      return=
 a HTTP 400 error.






 






For a spec that is supposed to be about simplicity, =
the above description is anything but simple. I know you guys have worked h=
ard on this and I don't mean to disparage those efforts, but think about ho=
w the above passage would appear to
 a new reader (i.e., a novice to the spec, not a technology novice).






 






There is something fundamentally broken, and it is t=
his: multi-valued attributes without a unique identifier per value. If you =
don't fix that, you won't get simplicity.






 






We know LDAP trees are broken for multi-valued attri=
butes. As Mark Wahl

famously commented back in 2005,






 






"Unfortunately, some of the emergi=
ng protocols which also intend to represent and transfer personal identity =
information have perhaps taken a step backwards by not even considering
 these issues, perhaps sweeping them under the rug in the guise of simplici=
ty, XMLification, or "fix in the next version", which only postpo=
ne finding interoperable solutions to allowing applications to express the =
identity entries they want to express."






 






SCIM is exactly one of these "emerging protocol=
s" Wahl talks about, and what I see now strikes me as "sweeping t=
hese issues under the rug in the guise of simplicity". Apologies for t=
he bluntness.






 






My take is that SPs are _already_ struggling to mana=
ge multi-valued attributes, and

existing mechanisms are clumsy. They would be grateful for a specificat=
ion that made operations easier at the cost of a re-engineered schema. That=
 calls for some thought leadership from this working group.






 






Regards,






Ganesh






 




On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> w=
rote:






I strongly object to anything that leads to a read b=
efore modify requirement. Too complex and too chatty. 



Phil












On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








> Would it have to be stored on t=
he account database of the service provider?


 


Yes.


 


> If so, I believe that this is i=
mpracticable in the core schema. Indeed it implies that a service prov=
ider must extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.




 






Why? That doesn't necessarily follow. Implementation=
 is independent of representation. We're talking about a change in represen=
tation to make the API cleaner.






 






As a simple example, if an LDAP node is being used t=
o hold a list of comma-separated email addresses, it can just as easily sto=
re comma-separated name-value pairs.






 







 






mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=
=3Djohn.smith@gma=
il.com, 7a6d1de664e1=3Djsmith1970@hotmail.com






 




That's why I asked if there was an SP representative on th=
is working group who could explain what such a change could mean for them. =
As of now, it looks like other people are presuming that
 SPs will not be able to implement these changes easily and are rejecting t=
hem for that reason.




 






Regards,






Ganesh






 




On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com=
> wrote:






=F0  
addresses.3cbaaff8e84e.street-number =3D "243"<=
o:p>


 


Where would
3cbaaff8e84e come from? Would it have to be stored on the account database of th=
e service provider?


 =



If so, I believe that this is imprac=
ticable in the core schema. Indeed it implies that a service provider must =
extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.


This would be a show stopper. SCIM m=
ust be transparent, and must be able to be put on top of an existing system=
 to provide provisioning apis.

 =



Said differently, SCIM must not be i=
ntrusive for existing systems and must not require modifications to allow i=
ts integration.


Correct me if I misunderstood your s=
uggestion.


 =



--<=
/span>


Regards,<=
/o:p>


Emmanuel Dreux


http://www.cloudiway.com


Tel:
+33 4 2=
6 78 17 58


Mobile:
+33 6 4=
7 81 26 70


skype: Emmanuel.Dreux


 




De : Ganesh and
 Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9 : dimanche 12 ao=FBt 2012 04:53

=C0 : Kelly Grizzle

Cc : scim@ie=
tf.org; Phil Hunt

Objet : Re: [scim] scim Digest, Vol 8, Issue 24




 


> 
Multi-valued attributes that d=
on't have a value sub-attribute (eg - address) have to specified completely=
 for uniqueness.  




 






That's exactly the point. How do we "specif=
y completely for uniqueness"?






 






In the example below, how are you proposing that=
 the following element be updated if we can't use positional indexes?<=
/o:p>






 






addresses[1].street-number =3D "243"






 






User object:






 








{






  ...






  addresses: [






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  ]






}






 






It's impractical to use the value because it's t=
he whole dictionary element:






 








{






  "type" : "office",






  "street-number" : "213&quo=
t;,






  "street-name" : "Main Stre=
et",






  "suburb" : "Adelaide"=
,






  "postcode" : "5000",<=
o:p>






  "state" : "SA",<=
/o:p>






  "country" : "Australia&quo=
t;






}








 






With my proposal, the "addresses" arra=
y gets converted to a dictionary, and then we have a stable way of referenc=
ing this element:






 








addresses.3cbaaff8e84e.street-number =3D "2=
43"




 








{






  ...






  addresses: {






    "d6ea365462f5" :






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    "3cbaaff8e84e" :






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  }






}






 






If you're proposing one mechanism for composite =
attributes and another mechanism for simple attributes, I would suggest tha=
t's actually more complex than adopting
 a single mechanism that works the same way for _all_ attributes. Remember =
that a lot of the administration is probably going to be scripted rather th=
an done by hand, and having two mechanisms (depending on whether the attrib=
ute is simple or composite) will
 complicate every script that has to be written.








 






There's a lot of talk about the "burden&quo=
t; on the SPs, but I believe this is overblown. Is there any SP representat=
ive in this WG who can tell us what this proposal
 will actually entail for them?






 






Regards,






Ganesh




 




On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@s=
ailpoint.com> wrote:








Ganesh,






 =







This is exactly how PATCH works in SCIM 1.=
0.  Multi-valued attributes that have a value sub-attribute
 can be removed by specifying only the value since it is unique.  Mult=
i-valued attributes that don't have a value sub-attribute (eg - address) ha=
ve to specified completely for uniqueness.  As I have said before, I a=
m very opposed to adding a unique identifier
 to each element in a multi-valued collection due to the burden it will put=
 on SPs.  Is it elegant?  No.  Is it functional?  Yes. =
 Will this non-elegance affect adoption?  My opinion is that addi=
ng unique keys to each element will have a much more detrimental
 effect on adoption.






 =







I do believe that in general PATCH can be =
made more intuitive without adding uids to each element.  The
 verbs that you propose make sense.  There is also a JSON Patch inform=
ational draft in the IETF that is interesting - http://=
tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.
  It relies on a JSON Pointer draft which uses index-based addressing =
for multi-valued attributes.  I think that this is something that shou=
ld be looked at within the WG and I would be willing to lead this effort.






 =







I'm curious if anyone else in the WG is in=
 favor of unique identifiers for every multi-valued element.






 =







--Kelly




 =













From:
scim-bounces@iet=
f.org [scim-=
bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]

Sent: Saturday, August 11, 2012 10:50 AM

To: Phil Hunt

Cc: scim@ietf.org=


Subject: Re: [scim] scim Digest, Vol 8, Issue 24










Phil,





 






The reason we cannot use the value itself to ide=
ntify an element is that this method will only work for simple elements, no=
t for nested structures. i.e., if we had
 an array of dictionaries (e.g., we had to record an array of addresses for=
 each customer, with each address element having sub-elements like street n=
umber, street name, suburb, etc.), then it would be clumsy to supply the en=
tire value of the array element
 because it's itself a dictionary. Creating a unique key for each element s=
cales better.






 






Regards,






Ganesh




On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com=
> wrote:




Ganesh,





 






Here's the sample that concerned me...












The two operations differ significantly, and it'=
s not very intuitive. 






With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }











 








 








You gave other examples of an attribute with an identifier th=
at matched that value or of identifiers that were
 additional unique keys.






 






Given that multi-values must be each unique, I don't see the =
point of the extra indexing to support this. Just
 use the value as the item you wish to delete.






 






I agree, the delete value operation could be more explicit an=
d clear in general.






 


















Phil=







 






@independentid<=
o:p>











phil.hunt@oracle.com




 




 








 






On 2012-08-11, at 2:30 AM, Ganesh and Sashi Pras=
ad wrote:




 


>  For the multi-value example you gave =
you used the value as the attribute name key. 





 






Now I'm confused :-). I don't believe any of my =
examples ever used a value as the key.






 






Could you please show me which example you mean,=
 and which parts of it you believe to be the value?






 






Regards,






Ganesh 




On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com=
> wrote:








For the multi-value example you gave you used the value as the attribute na=
me key. 






 






That means a lot more complex indexing structure=
. Better to just say delete a specific value. 






 






The spec already allows multiple values to have =
tags like home, work, etc.






 






Phil












On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
















> In your example you are conflating val=
ue with an attribute id. 



I don't believe so. 




 






I'm adopting a model where every attribute of th=
e resource is a key-value pair. The key is a name or ID.<=
/p>





 






For non-repeating attributes (both simple and co=
mposite), the key is the attribute name itself. 






 








Simple attribute:






 






Key: "dob"






Value: "01 Jan 1970"=







 








For composite attributes, the key employs dot no=
tation to specify the fully-qualified attribute name, e.g., "address.p=
ostcode".






 






Composite attribute:






 






Key: "address.street-number"






Value: "10"






 






Key: "address.suburb"






Value: "East Camden"=







 






For repeating (multi-valued) attributes, I'm sug=
gesting that there be new keys for each individual value, otherwise they ar=
e impossible to distinguish, and a positional
 index is inadequate. So we convert the array into a dictionary and this th=
en becomes a composite attribute using dot notation for the key.=







 






Multi-valued attribute:






 






Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea=
3bd902"







 






So this allows us to apply uniform treatment to =
any arbitrarily deep resource structure. We can refer to every leaf value w=
ith a key that is the fully-qualified
 name using dot notation.






 






The verbs are just unambiguous operations on the=
se (now) explicitly addressable attributes.






 






INCLUDE to a collection and specify only the val=
ue. The key is generated and returned. The fully-qualified key is <colle=
ction-name>.<newly-generated-ID> and the
 value is what was specified in the INCLUDE.






 






REPLACE a fully-qualified key with a new value. =
If the key doesn't exist, return a "404 Not Found".






 






PLACE a value at the logical location implied by=
 the fully-qualified key. If there is already a key with that name, return =
a "409 Conflict".






 






FORCE the fully-qualified key to hold the given =
value, regardless of whether it existed before or not. Only errors possible=
 are "400 Bad Request" and "500 Internal
 Error".






 






RETIRE an attribute or a collection given its fu=
lly-qualified key. The implementation will determine whether the attribute =
will disappear entirely or will exist
 holding a null value (the blank string "" or the empty object {}=
 ).






 






I'll explain in a separate post why we need oper=
ation verbs like these that are independent of the HTTP verbs.






 






Regards,






Ganesh






 




On 11 August 2012 10:38, <scim-request@ietf.org> wrote=
:


If you have received this digest without all the=
 individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



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



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







Send scim mailing list submissions to

        scim@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

        https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to

        scim-request@ietf.org



You can reach the person managing the list at

        scim-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of scim digest..."



Today's Topics:



   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun=
t)





---------- Forwarded message ----------

From: Phil Hunt <phil.hunt@oracle.com>

To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>

Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux =
<edreux@cloudi=
way.com>, Trey Drake <trey.drake@unboundid.com>,
 Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>

Date: Fri, 10 Aug 2012 17:36:54 -0700

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement=









Ganesh,






 






In your example you are conflating value with an=
 attribute id. I find that confusing. 






 






I agree though that operations in patch could be=
 a lot more explicit. 






 






Eg explicitly deleting a value by saying delete =
or retire. 








Phil








On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








 >  I am concerned about your second suggestion: 





 






Let's discuss that now.






 






The trade-offs are very clear here.






 






Pros:






 






Pro 1. The API to manipulate resources becomes s=
o much cleaner, consistent and intuitive when every individual attribute va=
lue gets its own ID.






 






Here's how to delete a single member from a Grou=
p, as per the current spec:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce<=
/span>


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 


   {


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


     =
"members": [


    &=
nbsp;  {


    &=
nbsp;    "display": "Babs Jensen",


    &=
nbsp;    "value": "2819c223-7f76-453a-919d-41=
3861904646"


    &=
nbsp;    "operation": "delete"


    &=
nbsp;  }


     =
]


   }




Here's how to delete ALL members from a group according to the current spec=
:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce<=
/span>


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 


   {


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


     =
"meta": {


    &=
nbsp;  "attributes": [


    &=
nbsp;    "members"


    &=
nbsp;  ]


     =
}


   }




The two operations differ significantly, and it's not very intuitive. =







With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }


Here's how I suggest deleting ALL members from a group:





 








PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members"






}






}






] }







I'm sure you'll agree that this is simpler, more consistent and more intuit=
ive to a reader.






 






Pro 2: We can apply this mechanism consistently =
to three areas:






(a) Manipulating multi-valued attributes of a re=
source






(b) Manipulating members of a group






(c) Performing bulk operations, where we simply =
use HTTP verbs instead of the specialised (and semantically less ambiguous)=
 verbs I suggested for attributes, the
 "key" becomes the URI, and the "value" becomes the cor=
responding JSON object.






 






All of them return "207 Multi-Status" =
with the "results" array holding individual status codes.






 






In the current spec, (a) and (b) are done simila=
rly but (c) is very different.






 






Pro 3: Adoption of the standard by clients is li=
kely to be higher because it's simpler for them.






 






Pro 4: New (not incumbent) cloud providers will =
probably find this easier to implement because they have no legacy. They wi=
ll probably use some form of NoSQL database
 and won't be constrained by the limitations of LDAP directories.






 






Cons:






 






Con 1: Incumbent cloud providers with existing d=
ata stores in a directory format (where multi-valued attributes are stored =
as comma-separated values under a single
 attribute node) will find it difficult to migrate to this model and store =
each attribute value as a sub-node with its own key. This will "hinder=
 adoption of the spec", which is what you fear.






 






Have I summed up the Pros and Cons correctly? I'=
m biased of course, so I could have missed a Con or hyped a Pro :-).




 




In other words, we're debating interface complex=
ity (current spec) versus implementation complexity (my suggestion). Both c=
an hinder adoption of the spec by different
 parties.






 






Here's what we need to discuss - Do the Pros mak=
e the suggestio
















































































 










 
--_000_56C3C758F9D6534CA3778EAA1E0C3437330259C2BY2PRD0410MB354_-- From g.c.prasad@gmail.com Mon Aug 13 07:56:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBE321F8699 for ; Mon, 13 Aug 2012 07:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.255 X-Spam-Level: X-Spam-Status: No, score=-3.255 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeGZwuMMdn6Q for ; Mon, 13 Aug 2012 07:56:49 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 302E921F871A for ; Mon, 13 Aug 2012 07:56:48 -0700 (PDT) Received: by bkty7 with SMTP id y7so1654152bkt.31 for ; Mon, 13 Aug 2012 07:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ijpzTh769AJMZl27uLB/gHpprW3moETwJt+8auEltGI=; b=zgiCiAZ/yTSHqIxIclt5CFDYq/4KDRe5by43/X88xsJm7J+S9HxS1N7bQVML6+vHmh MwNH5F/G9LDe2X2aWRcemf0rTyFxI1DNci7b/N47N31+upkHAYDJt0pSao5YSABT87O+ Hn+NFP1tE7O7uD6ucnnqvrwFYl9h0RINgRh4nms5MpvL5/aziho8g+vGe86GFEHpTsx2 LsZy6oOOvmEKC8K1l7ABKA/bY9ac4NamTDQZvXAhV0izVmrKMMG0nLdTpZHgusA74Z8b kJ5DdlODPVGiygOXFjgDQS3fBP5y+/EdgNuWBwAGGrqrYJtCmcL2FneXHfjXxhkEsSPt V+/g== Received: by 10.204.129.208 with SMTP id p16mr4291116bks.129.1344869806936; Mon, 13 Aug 2012 07:56:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Mon, 13 Aug 2012 07:56:26 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Tue, 14 Aug 2012 00:56:26 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=00151747ba061c929504c726e7c4 Cc: Emmanuel Dreux , Melinda Shore , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 14:56:52 -0000 --00151747ba061c929504c726e7c4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That was one suggestion. Another way could be container nodes with their own "dn"s. If one suggestion won't work, tell me another way to make it work. I'm waiting to hear a constructive suggestion that can square an elegant API with the implementation constraints that come from having to store multi-valued attributes in LDAP directories. I've heard enough of WHY this won't work. For a change, tell me HOW it can be made to work. Everyone now knows what the proposal means in terms of the API, and implementors understand the constraints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in the room" here, surely we should be able to crack this. Regards, Ganesh P.S. I'm rapidly reaching my own conclusions about what is to be done: http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nold= ap.html On 14 August 2012 00:27, Kelly Grizzle wrote: > > After all, no one has challenged the claim that this proposal > drastically simplifies the API for the client**** > > ** ** > > I agree that your proposal makes PATCH semantics simpler and more elegant= . > **** > > ** ** > > ** ** > > > =85 so it would appear to be worth doing. **** > > ** ** > > I strongly disagree here. This statements assumes that simplicity of the > client API is the only factor that should be considered with the spec.***= * > > ** ** > > Emmanuel=92s example is from a real-world service provider that would not= be > able to implement the spec easily with a uid per element. He is working = on > a SCIM interface that will help facilitate data exchange between multiple > Active Directory servers. Your solution was to change the data model fro= m > this:**** > > ** ** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > ** ** > > to this:**** > > ** ** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > ** ** > > I do not know of a single organization that would change their Active > Directory data model to fit this. For one thing, it would be a huge data > migration effort (likely across other domain controllers, etc=85) to assi= gn > these unique identifiers. This also assumes that SCIM is the only > reader/writer of this data, which will almost never be the case. If the > data model requires uids for every element, then every piece of non-SCIM > code that writes data into the directory will have to follow this. > Additionally, there are **many** tools and applications (eg =96 address > books) that rely on a certain data model in Active Directory, and this > would cause them to break. IMO this same argument holds true for most > service providers.**** > > ** ** > > ** ** > > PATCH is an optional part of the spec. It was primarily introduced to > make modifying resources with large multi-valued lists more efficient. I= t > does not need to solve every problem (eg =96 modifying sub-elements in ne= sted > arrays). Adding uids to every multi-valued element does not strike the > right balance between the needs of the client and the needs of the servic= e > provider.**** > > ** ** > > --Kelly**** > > ** ** > > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 1:35 AM > *To:* Phil Hunt; Melinda Shore > *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > ** ** > > Responding to extract of Melinda Shore's mail from digest:**** > > ** ** > > The issue being raised here isn't endpoint logic, but**** > > network traffic, and I'm pretty sure it's not very helpful to**** > > respond to the observation that your model requires more**** > > messages with a complaint about what you seem to think is a**** > > complex algorithm for attribute processing.**** > > ** ** > > It depends on how it's implemented. I'm confident we can have the best of > both - simple API with low-overhead implementation. Can we brainstorm HOW > this proposal can be implemented rather than WHY it can't be implemented > (which is mostly what I've been hearing so far)? After all, no one has > challenged the claim that this proposal drastically simplifies the API fo= r > the client, so it would appear to be worth doing. I'm sure there's more > than enough intellectual horsepower in this working group to pull this of= f > if we put our minds to it.**** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote:**** > > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty.**** > > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now!**** > > ** ** > > Multi-valued attributes: An attribute value in the PATCH request**** > > body is added to the value collection if the value does not exist**= ** > > and merged if a matching value is present. Values are matched by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute; e.g., addresses, or do not have unique*= *** > > value Sub-Attributes cannot be matched and must instead be deleted*= *** > > then added. Specific values can be removed from a Resource by**** > > adding an "operation" Sub-Attribute with the value "delete" to the*= *** > > attribute in the PATCH request body. As with adding/updating**** > > attribute value collections, the value to delete is determined by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute or that have a non-unique value Sub-**** > > Attribute are matched by comparing all Sub-Attribute values from***= * > > the PATCH request body to the Sub-Attribute values of the**** > > Resource. A delete operation is ignored if the attribute's name***= * > > is in the meta.attributes list. If the requested value to delete**= ** > > does not match a unique value on the Resource the server MAY**** > > return a HTTP 400 error.**** > > ** ** > > For a spec that is supposed to be about simplicity, the above description > is anything but simple. I know you guys have worked hard on this and I > don't mean to disparage those efforts, but think about how the above > passage would appear to a new reader (i.e., a novice to the spec, not a > technology novice).**** > > ** ** > > There is something fundamentally broken, and it is this: multi-valued > attributes without a unique identifier per value. If you don't fix that, > you won't get simplicity.**** > > ** ** > > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl f= amously > commented back > in 2005,**** > > ** ** > > "Unfortunately, some of the emerging protocols which also intend to > represent and transfer personal identity information have perhaps taken a > step backwards by not even considering these issues, perhaps sweeping the= m > under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt > version", which only postpone finding interoperable solutions to allowing > applications to express the identity entries they want to express."**** > > ** ** > > SCIM is exactly one of these "emerging protocols" Wahl talks about, and > what I see now strikes me as "sweeping these issues under the rug in the > guise of simplicity". Apologies for the bluntness.**** > > ** ** > > My take is that SPs are _already_ struggling to manage multi-valued > attributes, and existing mechanisms are clumsy. > They would be grateful for a specification that made operations easier at > the cost of a re-engineered schema. That calls for some thought leadershi= p > from this working group.**** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > On 13 August 2012 10:13, Phil Hunt wrote:**** > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Phil**** > > > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote:**** > > > Would it have to be stored on the account database of the service > provider?**** > > **** > > Yes.**** > > ** ** > > > If so, I believe that this is impracticable in the core schema. Indeed > it implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > ** ** > > Why? That doesn't necessarily follow. Implementation is independent of > representation. We're talking about a change in representation to make th= e > API cleaner.**** > > ** ** > > As a simple example, if an LDAP node is being used to hold a list of > comma-separated email addresses, it can just as easily store > comma-separated name-value pairs.**** > > ** ** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > can be changed to**** > > ** ** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > ** ** > > That's why I asked if there was an SP representative on this working grou= p > who could explain what such a change could mean for them. As of now, it > looks like other people are presuming that SPs will not be able to > implement these changes easily and are rejecting them for that reason.***= * > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > On 13 August 2012 04:29, Emmanuel Dreux wrote:**** > > =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > Where would 3cbaaff8e84e come from? Would it have to be stored on the > account database of the service provider?**** > > **** > > If so, I believe that this is impracticable in the core schema. Indeed it > implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > This would be a show stopper. SCIM must be transparent, and must be able > to be put on top of an existing system to provide provisioning apis.**** > > **** > > Said differently, SCIM must not be intrusive for existing systems and mus= t > not require modifications to allow its integration.**** > > Correct me if I misunderstood your suggestion.**** > > **** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > **** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org; Phil Hunt > *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. **** > > **** > > That's exactly the point. How do we "specify completely for uniqueness"?*= * > ** > > **** > > In the example below, how are you proposing that the following element be > updated if we can't use positional indexes?**** > > **** > > addresses[1].street-number =3D "243"**** > > **** > > User object:**** > > **** > > {**** > > ...**** > > addresses: [**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > ]**** > > }**** > > **** > > It's impractical to use the value because it's the whole dictionary > element:**** > > **** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > **** > > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element:**** > > **** > > addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > {**** > > ...**** > > addresses: {**** > > "d6ea365462f5" :**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > "3cbaaff8e84e" :**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > }**** > > }**** > > **** > > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written.**** > > **** > > There's a lot of talk about the "burden" on the SPs, but I believe this i= s > overblown. Is there any SP representative in this WG who can tell us what > this proposal will actually entail for them?**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 12 August 2012 11:53, Kelly Grizzle > wrote:**** > > Ganesh,**** > > **** > > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t > have a value sub-attribute can be removed by specifying only the value > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption.**** > > **** > > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort.**** > > **** > > I'm curious if anyone else in the WG is in favor of unique identifiers fo= r > every multi-valued element.**** > > **** > > --Kelly**** > > **** > ------------------------------ > > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > Phil, **** > > **** > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > **** > > **** > > Regards,**** > > Ganesh**** > > On 12 August 2012 01:12, Phil Hunt wrote:**** > > Ganesh, **** > > **** > > Here's the sample that concerned me...**** > > The two operations differ significantly, and it's not very intuitive. **= * > * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } **** > > **** > > **** > > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys.**** > > **** > > Given that multi-values must be each unique, I don't see the point of the > extra indexing to support this. Just use the value as the item you wish t= o > delete.**** > > **** > > I agree, the delete value operation could be more explicit and clear in > general.**** > > **** > > Phil**** > > **** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > **** > > **** > > **** > > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** > > ** ** > > > For the multi-value example you gave you used the value as the > attribute name key. **** > > **** > > Now I'm confused :-). I don't believe any of my examples ever used a valu= e > as the key.**** > > **** > > Could you please show me which example you mean, and which parts of it yo= u > believe to be the value?**** > > **** > > Regards,**** > > Ganesh **** > > On 11 August 2012 13:59, Phil Hunt wrote:**** > > > For the multi-value example you gave you used the value as the attribute > name key. **** > > **** > > That means a lot more complex indexing structure. Better to just say > delete a specific value. **** > > **** > > The spec already allows multiple values to have tags like home, work, etc= . > **** > > **** > > Phil**** > > > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote:**** > > > In your example you are conflating value with an attribute id. > > I don't believe so. **** > > **** > > I'm adopting a model where every attribute of the resource is a key-value > pair. The key is a name or ID.**** > > **** > > For non-repeating attributes (both simple and composite), the key is the > attribute name itself. **** > > **** > > Simple attribute:**** > > **** > > Key: "dob"**** > > Value: "01 Jan 1970"**** > > **** > > For composite attributes, the key employs dot notation to specify the > fully-qualified attribute name, e.g., "address.postcode".**** > > **** > > Composite attribute:**** > > **** > > Key: "address.street-number"**** > > Value: "10"**** > > **** > > Key: "address.suburb"**** > > Value: "East Camden"**** > > **** > > For repeating (multi-valued) attributes, I'm suggesting that there be new > keys for each individual value, otherwise they are impossible to > distinguish, and a positional index is inadequate. So we convert the arra= y > into a dictionary and this then becomes a composite attribute using dot > notation for the key.**** > > **** > > Multi-valued attribute:**** > > **** > > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** > > Value: "john_smith@yahoo.com"**** > > **** > > So this allows us to apply uniform treatment to any arbitrarily deep > resource structure. We can refer to every leaf value with a key that is t= he > fully-qualified name using dot notation.**** > > **** > > The verbs are just unambiguous operations on these (now) explicitly > addressable attributes.**** > > **** > > INCLUDE to a collection and specify only the value. The key is generated > and returned. The fully-qualified key is > . and the value is what was specifie= d > in the INCLUDE.**** > > **** > > REPLACE a fully-qualified key with a new value. If the key doesn't exist, > return a "404 Not Found".**** > > **** > > PLACE a value at the logical location implied by the fully-qualified key. > If there is already a key with that name, return a "409 Conflict".**** > > **** > > FORCE the fully-qualified key to hold the given value, regardless of > whether it existed before or not. Only errors possible are "400 Bad > Request" and "500 Internal Error".**** > > **** > > RETIRE an attribute or a collection given its fully-qualified key. The > implementation will determine whether the attribute will disappear entire= ly > or will exist holding a null value (the blank string "" or the empty obje= ct > {} ).**** > > **** > > I'll explain in a separate post why we need operation verbs like these > that are independent of the HTTP verbs.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 11 August 2012 10:38, wrote:**** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) > > > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux < > edreux@cloudiway.com>, Trey Drake , Kelly > Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > Ganesh,**** > > **** > > In your example you are conflating value with an attribute id. I find tha= t > confusing. **** > > **** > > I agree though that operations in patch could be a lot more explicit. ***= * > > **** > > Eg explicitly deleting a value by saying delete or retire. **** > > > Phil**** > > > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote:**** > > > I am concerned about your second suggestion: **** > > **** > > Let's discuss that now.**** > > **** > > The trade-offs are very clear here.**** > > **** > > Pros:**** > > **** > > Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t > and intuitive when every individual attribute value gets its own ID.**** > > **** > > Here's how to delete a single member from a Group, as per the current spe= c: > **** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "members": [**** > > {**** > > "display": "Babs Jensen",**** > > "value": "2819c223-7f76-453a-919d-413861904646"**** > > "operation": "delete"**** > > }**** > > ]**** > > }**** > > > Here's how to delete ALL members from a group according to the current > spec:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "meta": {**** > > "attributes": [**** > > "members"**** > > ]**** > > }**** > > }**** > > > The two operations differ significantly, and it's not very intuitive. ***= * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } > Here's how I suggest deleting ALL members from a group:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members"**** > > }**** > > }**** > > ] } **** > > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader.**** > > **** > > Pro 2: We can apply this mechanism consistently to three areas:**** > > (a) Manipulating multi-valued attributes of a resource**** > > (b) Manipulating members of a group**** > > (c) Performing bulk operations, where we simply use HTTP verbs instead of > the specialised (and semantically less ambiguous) verbs I suggested for > attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object.**** > > **** > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes.**** > > **** > > In the current spec, (a) and (b) are done similarly but (c) is very > different.**** > > **** > > Pro 3: Adoption of the standard by clients is likely to be higher because > it's simpler for them.**** > > **** > > Pro 4: New (not incumbent) cloud providers will probably find this easier > to implement because they have no legacy. They will probably use some for= m > of NoSQL database and won't be constrained by the limitations of LDAP > directories.**** > > **** > > Cons:**** > > **** > > Con 1: Incumbent cloud providers with existing data stores in a directory > format (where multi-valued attributes are stored as comma-separated value= s > under a single attribute node) will find it difficult to migrate to this > model and store each attribute value as a sub-node with its own key. This > will "hinder adoption of the spec", which is what you fear.**** > > **** > > Have I summed up the Pros and Cons correctly? I'm biased of course, so I > could have missed a Con or hyped a Pro :-).**** > > **** > > In other words, we're debating interface complexity (current spec) versus > implementation complexity (my suggestion). Both can hinder adoption of th= e > spec by different parties.**** > > **** > > Here's what we need to discuss - Do the Pros make the suggestio**** > > ** ** > > ** ** > --00151747ba061c929504c726e7c4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That was one suggestion. Another way could be container nodes with their ow= n "dn"s. If one suggestion won't work, tell me another way to= make it work. I'm waiting to hear a constructive suggestion that can s= quare an elegant API with the implementation constraints that come from hav= ing to store multi-valued attributes in LDAP directories.

I've heard enough of WHY this won't work. For a chan= ge, tell me HOW it can be made to work. Everyone now knows what the proposa= l means in terms of the API, and implementors understand the constraints of= legacy data stores, so put the two together to propose a solution. C'm= on, we have the "smartest guys in the room" here, surely we shoul= d be able to crack this.

Regards,
Ganesh

P.S.= I'm rapidly reaching my own conclusions about what is to be done:


On 14 August 2012 00:27, Kelly Griz= zle <kelly.grizzle@sailpoint.com> wrote:

> After all, no one has challenged the claim that= this proposal drastically simplifies the API for the client<= /p>

=A0<= /p>

I agree that your p= roposal makes PATCH semantics simpler and more elegant.

=A0<= /p>

=A0<= /p>

> =85 so it would appear to be worth doing.=A0<= u>

=A0<= /p>

I strongly disagree= here.=A0 This statements assumes that simplicity of the client API is the = only factor that should be considered with the spec.

=A0<= /p>

Emmanuel=92s example is f= rom a real-world service provider that would not be able to implement the s= pec easily with a uid per element.=A0 He is working on a SCIM interface that will help facilitate data exchange between multiple Active = Directory servers.=A0 Your solution was to change the data model from this:=

=A0<= /p> 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

=A0<= /p>

to this:

=A0<= /p>

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0<= /p>

I do not know of a single= organization that would change their Active Directory data model to fit th= is.=A0 For one thing, it would be a huge data migration effort (likely across other domain controllers, etc=85) to assign these unique id= entifiers.=A0 This also assumes that SCIM is the only reader/writer of this= data, which will almost never be the case.=A0 If the data model requires u= ids for every element, then every piece of non-SCIM code that writes data into the directory will have to follow t= his.=A0 Additionally, there are *many* tools and applications =A0(eg= =96 address books) that rely on a certain data model in Active Directory, = and this would cause them to break.=A0 IMO this same argument holds true for most service providers.

=A0<= /p>

=A0<= /p>

PATCH is an optional part= of the spec. =A0It was primarily introduced to make modifying resources wi= th large multi-valued lists more efficient.=A0 It does not need to solve every problem (eg =96 modifying sub-elements in nested arrays).= =A0 Adding uids to every multi-valued element does not strike the right bal= ance between the needs of the client and the needs of the service provider.=

=A0<= /p>

--Kelly

=A0<= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24
=

=A0

Responding to extract of Melinda Shore's mail fr= om digest:

=A0

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to<=
u>
respond to the observation that your model requires more=

messages with a complaint about what you seem to think is a<=
/u>
complex algorithm for attribute processing.

=A0

It depends on how it's implemented. I'm conf= ident we can have the best of both - simple API with low-overhead implement= ation. Can we brainstorm HOW this proposal can be implemented rather than W= HY it can't be implemented (which is mostly what I've been hearing so far)? After all, no one has challenged the c= laim that this proposal drastically simplifies the API for the client, so i= t would appear to be worth doing.=A0I'm sure there's more than enou= gh intellectual horsepower in this working group to pull this off if we put our minds to it.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 13:54, Ganesh and Sashi Prasad <= ;g.c.prasad@gmail= .com> wrote:

>=A0I strongly obj= ect to anything that leads to a read before modify requirement. Too complex= and too chatty.

Sorry Phil, but you're contradicting yourself he= re.=A0There seems to be an awful lot of matching (i.e., reading) going on i= n the spec as it stands, with if-then clauses to do one thing or another if= the match either succeeds or fails. This is a complex, chatty protocol right now!

=A0

=A0=A0 Multi-valued attributes:=A0 An=
 attribute value in the PATCH request
=A0=A0=A0=A0=A0 body is added to the =
value collection if the value does not exist
=A0=A0=A0=A0=A0 and merged if a match=
ing value is present.=A0 Values are matched by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute; e.g., addresses, or do not have unique
=A0=A0=A0=A0=A0 value Sub-Attributes =
cannot be matched and must instead be deleted
=A0=A0=A0=A0=A0 then added.=A0 Specif=
ic values can be removed from a Resource by
=A0=A0=A0=A0=A0 adding an "opera=
tion" Sub-Attribute with the value "delete" to the=

=A0=A0=A0=A0=A0 attribute in the PATC=
H request body.=A0 As with adding/updating
=A0=A0=A0=A0=A0 attribute value colle=
ctions, the value to delete is determined by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute or that have a non-unique value Sub-
=A0=A0=A0=A0=A0 Attribute are matched=
 by comparing all Sub-Attribute values from
=A0=A0=A0=A0=A0 the PATCH request bod=
y to the Sub-Attribute values of the
=A0=A0=A0=A0=A0 Resource.=A0 A delete=
 operation is ignored if the attribute's name

=A0=A0=A0=A0=A0 is in the meta.attrib=
utes list.=A0 If the requested value to delete


=A0=A0=A0=A0=A0 does not match a uniq=
ue value on the Resource the server MAY


=A0=A0=A0=A0=A0 return a HTTP 400 err=
or.

=A0

For a spec that is supposed to be about simplicity, = the above description is anything but simple. I know you guys have worked h= ard on this and I don't mean to disparage those efforts, but think abou= t how the above passage would appear to a new reader (i.e., a novice to the spec, not a technology novice).=

=A0

There is something fundamentally broken, and it is t= his: multi-valued attributes without a unique identifier per value. If you = don't fix that, you won't get simplicity.

=A0

We know LDAP trees are broken for multi-valued attri= butes. As Mark Wahl famously commented back in 2005,

=A0

"Unfortunately, some of the emergi= ng protocols which also intend to represent and transfer personal identity = information have perhaps taken a step backwards by not even considering these issues, perhaps sweeping them under the rug in the guise of simplici= ty, XMLification, or "fix in the next version", which only postpo= ne finding interoperable solutions to allowing applications to express the = identity entries they want to express."

=A0

SCIM is exactly one of these "emerging protocol= s" Wahl talks about, and what I see now strikes me as "sweeping t= hese issues under the rug in the guise of simplicity". Apologies for t= he bluntness.

=A0

My take is that SPs are _already_ struggling to mana= ge multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specificat= ion that made operations easier at the cost of a re-engineered schema. That= calls for some thought leadership from this working group.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> w= rote:

I strongly object to anything that leads to a read b= efore modify requirement. Too complex and too chatty.=A0

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

> Would it have to = be stored on the account database of the service provider?=

=A0

Yes.<= /u>

=A0

> If so, I believe = that this is impracticable in the core schema.=A0Indeed it implies that a s= ervice provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

=A0

Why? That doesn't necessarily follow. Implementa= tion is independent of representation. We're talking about a change in = representation to make the API cleaner.

=A0

As a simple example, if an LDAP node is being used t= o hold a list of comma-separated email addresses, it can just as easily sto= re comma-separated name-value pairs.

=A0

=A0

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0

That's why I asked if there was an SP representative o= n this working group who could explain what such a change could mean for th= em. As of now, it looks like other people are presuming that SPs will not be able to implement these changes easily and are rejecting t= hem for that reason.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

=F0=A0 addresses.3cbaaff8e84e.street-number =3D "243"<= u>

=A0

Where would 3cbaaff8e84e come from? Would it have to be stored on the account database of th= e service provider?

=A0

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a service = provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This would be a show s= topper. SCIM must be transparent, and must be able to be put on top of an e= xisting system to provide provisioning apis.

=A0

Said differently, SCIM= must not be intrusive for existing systems and must not require modificati= ons to allow its integration.=

Correct me if I misund= erstood your suggestion.

=A0

--

Regards,

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78= 17 58

Mobile: +33 6 47 81= 26 70

skype: Emmanu= el.Dreux

=A0

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that d= on't have a value sub-attribute (eg - address) have to specified comple= tely for uniqueness.=A0=A0

=A0

That's exactly the point. How = do we "specify completely for uniqueness"?

=A0

In the example below, how are you = proposing that the following element be updated if we can't use positio= nal indexes?

=A0

addresses[1].street-number =3D &qu= ot;243"

=A0

User object:<= /p>

=A0

{

=A0 ...

=A0 addresses: [

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the va= lue because it's the whole dictionary element:

=A0

{

=A0 "type" : "offic= e",

=A0 "street-number" : &q= uot;213",

=A0 "street-name" : &quo= t;Main Street",

=A0 "suburb" : "Ade= laide",

=A0 "postcode" : "5= 000",

=A0 "state" : "SA&q= uot;,

=A0 "country" : "Au= stralia"

}

=A0

With my proposal, the "addres= ses" array gets converted to a dictionary, and then we have a stable w= ay of referencing this element:

=A0

addresses.3cbaaff8e84e.street-numb= er =3D "243"

=A0

{

=A0 ...

=A0 addresses: {

=A0 =A0 "d6ea365462f5" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechan= ism for composite attributes and another mechanism for simple attributes, I= would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember = that a lot of the administration is probably going to be scripted rather th= an done by hand, and having two mechanisms (depending on whether the attrib= ute is simple or composite) will complicate every script that has to be written.

=A0

There's a lot of talk about th= e "burden" on the SPs, but I believe this is overblown. Is there = any SP representative in this WG who can tell us what this proposal will actually entail for them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Gri= zzle <k= elly.grizzle@sailpoint.com> wrote:

Ganesh,

=A0=

This is exactly how PATCH wo= rks in SCIM 1.0. =A0Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. =A0Multi-v= alued attributes that don't have a value sub-attribute (eg - address) h= ave to specified completely for uniqueness. =A0As I have said before, I am = very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will put= on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0=

I do believe that in general= PATCH can be made more intuitive without adding uids to each element. =A0T= he verbs that you propose make sense. =A0There is also a JSON Patch informati= onal draft in the IETF that is interesting -=A0http://tools.= ietf.org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= span lang=3D"FR">

=A0=

I'm curious if anyone el= se in the WG is in favor of unique identifiers for every multi-valued eleme= nt.

=A0=

--Kelly

=A0=

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value= itself to identify an element is that this method will only work for simpl= e elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for= each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creating a unique key for each eleme= nt scales better.

=A0

Regards,

Gan= esh

On 12 August 2012 01:12, Phil Hunt= <phil.hunt@or= acle.com> wrote:

Ganesh,

=A0

Here's the sample that concern= ed me...

The two operations differ signific= antly, and it's not very intuitive.=A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{=

"RETIRE" : {=

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}=

}=

] }

=A0

=A0

You gave other examples of an attribute with an= identifier that matched that value or of identifiers that were additional unique keys.

=A0

Given that multi-values must be each unique, I = don't see the point of the extra indexing to support this. Just use the value as the item you wish to delete.<= /u>

=A0

I agree, the delete value operation could be mo= re explicit and clear in general.

=A0

=A0

=A0=

=A0

On 2012-08-11, at 2:30 AM, Ganesh = and Sashi Prasad wrote:

= =A0

>=A0 For the multi-value exampl= e you gave you used the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don= 9;t believe any of my examples ever used a value as the key.<= /span>

=A0

Could you please show me which exa= mple you mean, and which parts of it you believe to be the value?=

=A0

Regards,

Gan= esh=A0

On 11 August 2012 13:59, Phil Hunt= <phil.hunt@or= acle.com> wrote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex inde= xing structure. Better to just say delete a specific value.=A0

=A0

The spec already allows multiple v= alues to have tags like home, work, etc.

=A0=

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

>=A0In your example you are con= flating value with an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where eve= ry attribute of the resource is a key-value pair. The key is a name or ID.<= u>

=A0

For non-repeating attributes (both= simple and composite), the key is the attribute name itself.=A0<= /u>

=A0

Simple attribute:

=A0

Key: "dob"=

Value: "01 Jan 1970"<= /u>

=A0

For composite attributes, the key = employs dot notation to specify the fully-qualified attribute name, e.g., &= quot;address.postcode".

=A0

Composite attribute:=

=A0

Key: "address.street-number&q= uot;

Value: "10"

=A0

Key: "address.suburb"=

Value: "East Camden"<= /u>

=A0

For repeating (multi-valued) attri= butes, I'm suggesting that there be new keys for each individual value,= otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this th= en becomes a composite attribute using dot notation for the key.<= /u>

=A0

Multi-valued attribute:<= /u>

=A0

Key: "emails.7dfcb444-74d8-4f= 17-aa66-daf9ea3bd902"

Value: "john_smith@yahoo.com"<= u>

=A0

So this allows us to apply uniform= treatment to any arbitrarily deep resource structure. We can refer to ever= y leaf value with a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous ope= rations on these (now) explicitly addressable attributes.

=A0

INCLUDE to a collection and specif= y only the value. The key is generated and returned. The fully-qualified ke= y is <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

=A0

REPLACE a fully-qualified key with= a new value. If the key doesn't exist, return a "404 Not Found&qu= ot;.

=A0

PLACE a value at the logical locat= ion implied by the fully-qualified key. If there is already a key with that= name, return a "409 Conflict".

=A0

FORCE the fully-qualified key to h= old the given value, regardless of whether it existed before or not. Only e= rrors possible are "400 Bad Request" and "500 Internal Error".

=A0

RETIRE an attribute or a collectio= n given its fully-qualified key. The implementation will determine whether = the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {}= ).

=A0

I'll explain in a separate pos= t why we need operation verbs like these that are independent of the HTTP v= erbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org= > wrote:

If you have received this digest w= ithout all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating= value with an attribute id. I find that confusing.=A0=

=A0

I agree though that operations in = patch could be a lot more explicit.=A0

=A0

Eg explicitly deleting a value by = saying delete or retire.=A0


Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

=A0>=A0=A0I am concerned about your second suggestion:=A0

=A0

Let's discuss that now.=

=A0

The trade-offs are very clear here= .

=A0

Pros:

=A0

Pro 1. The API to manipulate resou= rces becomes so much cleaner, consistent and intuitive when every individua= l attribute value gets its own ID.

=A0

Here's how to delete a single = member from a Group, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: applicatio=
n/json
=A0=A0 Authorization: Bea=
rer h480djs93hd8
=A0=A0 ETag: W/"a330=
bc54f0671c9"
=A0
=A0=A0 {
=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],<=
u>
=A0=A0=A0=A0 "member=
s": [
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 =
"display": "Babs Jensen",
=A0=A0=A0=A0=A0=A0=A0=A0 =
"value": "2819c223-7f76-453a-919d-413861904646"<=
span lang=3D"FR">
=A0=A0=A0=A0=A0=A0=A0=A0 =
"operation": "delete"
=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0 ]
=A0=A0 }


Here's how to delete ALL members from a group according to the current = spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: applicatio=
n/json
=A0=A0 Authorization: Bea=
rer h480djs93hd8
=A0=A0 ETag: W/"a330=
bc54f0671c9"
=A0
=A0=A0 {
=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],<=
u>
=A0=A0=A0=A0 "meta&q=
uot;: {
=A0=A0=A0=A0=A0=A0 "=
attributes": [
=A0=A0=A0=A0=A0=A0=A0=A0 =
"members"
=A0=A0=A0=A0=A0=A0 ]
=A0=A0=A0=A0 }
=A0=A0 }


The two operations differ significantly, and it's not very intuitive.= =A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{=

"RETIRE" : {=

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}=

}=

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{=

"RETIRE" : {=

"key" : "members"

}=

}=

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism= consistently to three areas:

(a) Manipulating multi-valued attr= ibutes of a resource

(b) Manipulating members of a grou= p

(c) Performing bulk operations, wh= ere we simply use HTTP verbs instead of the specialised (and semantically l= ess ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the cor= responding JSON object.

=A0

All of them return "207 Multi= -Status" with the "results" array holding individual status = codes.

=A0

In the current spec, (a) and (b) a= re done similarly but (c) is very different.

=A0

Pro 3: Adoption of the standard by= clients is likely to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud p= roviders will probably find this easier to implement because they have no l= egacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers w= ith existing data stores in a directory format (where multi-valued attribut= es are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store = each attribute value as a sub-node with its own key. This will "hinder= adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons= correctly? I'm biased of course, so I could have missed a Con or hyped= a Pro :-).

=A0

In other words, we're debating= interface complexity (current spec) versus implementation complexity (my s= uggestion). Both can hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss= - Do the Pros make the suggestio

=A0

=A0


--00151747ba061c929504c726e7c4-- From kelly.grizzle@sailpoint.com Mon Aug 13 08:54:59 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B118C21F872D for ; Mon, 13 Aug 2012 08:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[AWL=1.362, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3JUhCYzUF4K for ; Mon, 13 Aug 2012 08:54:46 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDF321F8704 for ; Mon, 13 Aug 2012 08:54:45 -0700 (PDT) Received: from mail251-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 Aug 2012 15:54:44 +0000 Received: from mail251-tx2 (localhost [127.0.0.1]) by mail251-tx2-R.bigfish.com (Postfix) with ESMTP id 5C0141D0006A; Mon, 13 Aug 2012 15:54:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -95 X-BigFish: PS-95(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85dh1432I1418Iac5W9d9Rzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail251-tx2: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail251-tx2 (localhost.localdomain [127.0.0.1]) by mail251-tx2 (MessageSwitch) id 13448732802678_21272; Mon, 13 Aug 2012 15:54:40 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.239]) by mail251-tx2.bigfish.com (Postfix) with ESMTP id F08027400B9; Mon, 13 Aug 2012 15:54:39 +0000 (UTC) Received: from BY2PRD0410HT001.namprd04.prod.outlook.com (157.56.236.85) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 Aug 2012 15:54:39 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.142]) by BY2PRD0410HT001.namprd04.prod.outlook.com ([10.255.83.36]) with mapi id 14.16.0175.005; Mon, 13 Aug 2012 15:54:39 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PrysoINrXz30exI2CcM9WIa5dT/IGAgABLt4CAAHBZgIAACouAgACi+YWAABY3AIABBZAAgAAyWwCAAC3NgIAAPeCAgAAs0YCAAHzV0IAADy0AgAAF2KA= Date: Mon, 13 Aug 2012 15:54:39 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C343733025AEABY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: Emmanuel Dreux , Melinda Shore , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 15:55:00 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C343733025AEABY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are really two implementation options for a uid per element - either = store the uids in the native underlying data store or have some secondary d= ata store that maps elements to their uids. The third option is to hope th= at a service provider has a NoLDAP data store or its equivalent. None of t= hese are practical for rapid and wide-spread adoption. > put the two together to propose a solution. As I said before, I am completely on board with cleaning up the PATCH seman= tics (eg - the inconsistency between meta.attributes and operation=3Ddelete= , etc...). Your suggestion of using different verbs is a good option to co= nsider. This cannot be based on a uid per element, though. It seems as th= ough you have admitted this in your conclusion - "As for LDAP and SCIM, I g= uess the best TLA is RIP." --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 9:56 AM To: Kelly Grizzle Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 That was one suggestion. Another way could be container nodes with their ow= n "dn"s. If one suggestion won't work, tell me another way to make it work.= I'm waiting to hear a constructive suggestion that can square an elegant A= PI with the implementation constraints that come from having to store multi= -valued attributes in LDAP directories. I've heard enough of WHY this won't work. For a change, tell me HOW it can = be made to work. Everyone now knows what the proposal means in terms of the= API, and implementors understand the constraints of legacy data stores, so= put the two together to propose a solution. C'mon, we have the "smartest g= uys in the room" here, surely we should be able to crack this. Regards, Ganesh P.S. I'm rapidly reaching my own conclusions about what is to be done: http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nold= ap.html On 14 August 2012 00:27, Kelly Grizzle > wrote: > After all, no one has challenged the claim that this proposal drastically= simplifies the API for the client I agree that your proposal makes PATCH semantics simpler and more elegant. > ... so it would appear to be worth doing. I strongly disagree here. This statements assumes that simplicity of the c= lient API is the only factor that should be considered with the spec. Emmanuel's example is from a real-world service provider that would not be = able to implement the spec easily with a uid per element. He is working on= a SCIM interface that will help facilitate data exchange between multiple = Active Directory servers. Your solution was to change the data model from = this: mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com to this: mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com I do not know of a single organization that would change their Active Direc= tory data model to fit this. For one thing, it would be a huge data migrat= ion effort (likely across other domain controllers, etc...) to assign these= unique identifiers. This also assumes that SCIM is the only reader/writer= of this data, which will almost never be the case. If the data model requ= ires uids for every element, then every piece of non-SCIM code that writes = data into the directory will have to follow this. Additionally, there are = *many* tools and applications (eg - address books) that rely on a certain = data model in Active Directory, and this would cause them to break. IMO th= is same argument holds true for most service providers. PATCH is an optional part of the spec. It was primarily introduced to make= modifying resources with large multi-valued lists more efficient. It does= not need to solve every problem (eg - modifying sub-elements in nested arr= ays). Adding uids to every multi-valued element does not strike the right = balance between the needs of the client and the needs of the service provid= er. --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 1:35 AM To: Phil Hunt; Melinda Shore Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Responding to extract of Melinda Shore's mail from digest: The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. It depends on how it's implemented. I'm confident we can have the best of b= oth - simple API with low-overhead implementation. Can we brainstorm HOW th= is proposal can be implemented rather than WHY it can't be implemented (whi= ch is mostly what I've been hearing so far)? After all, no one has challeng= ed the claim that this proposal drastically simplifies the API for the clie= nt, so it would appear to be worth doing. I'm sure there's more than enough= intellectual horsepower in this working group to pull this off if we put o= ur minds to it. Regards, Ganesh On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote: > I strongly object to anything that leads to a read before modify requirem= ent. Too complex and too chatty. Sorry Phil, but you're contradicting yourself here. There seems to be an aw= ful lot of matching (i.e., reading) going on in the spec as it stands, with= if-then clauses to do one thing or another if the match either succeeds or= fails. This is a complex, chatty protocol right now! Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. For a spec that is supposed to be about simplicity, the above description i= s anything but simple. I know you guys have worked hard on this and I don't= mean to disparage those efforts, but think about how the above passage wou= ld appear to a new reader (i.e., a novice to the spec, not a technology nov= ice). There is something fundamentally broken, and it is this: multi-valued attri= butes without a unique identifier per value. If you don't fix that, you won= 't get simplicity. We know LDAP trees are broken for multi-valued attributes. As Mark Wahl fam= ously commented ba= ck in 2005, "Unfortunately, some of the emerging protocols which also intend to represe= nt and transfer personal identity information have perhaps taken a step bac= kwards by not even considering these issues, perhaps sweeping them under th= e rug in the guise of simplicity, XMLification, or "fix in the next version= ", which only postpone finding interoperable solutions to allowing applicat= ions to express the identity entries they want to express." SCIM is exactly one of these "emerging protocols" Wahl talks about, and wha= t I see now strikes me as "sweeping these issues under the rug in the guise= of simplicity". Apologies for the bluntness. My take is that SPs are _already_ struggling to manage multi-valued attribu= tes, and existing mechanisms are clumsy. They would be grateful f= or a specification that made operations easier at the cost of a re-engineer= ed schema. That calls for some thought leadership from this working group. Regards, Ganesh On 13 August 2012 10:13, Phil Hunt > wrote: I strongly object to anything that leads to a read before modify requiremen= t. Too complex and too chatty. Phil On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote: > Would it have to be stored on the account database of the service provide= r? Yes. > If so, I believe that this is impracticable in the core schema. Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. Why? That doesn't necessarily follow. Implementation is independent of repr= esentation. We're talking about a change in representation to make the API = cleaner. As a simple example, if an LDAP node is being used to hold a list of comma-= separated email addresses, it can just as easily store comma-separated name= -value pairs. mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com can be changed to mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com That's why I asked if there was an SP representative on this working group = who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement t= hese changes easily and are rejecting them for that reason. Regards, Ganesh On 13 August 2012 04:29, Emmanuel Dreux > wrote: =3D> addresses.3cbaaff8e84e.street-number =3D "243" Where would 3cbaaff8e84e come from? Would it have to be stored on the accou= nt database of the service provider? If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposi= tory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. This would be a show stopper. SCIM must be transparent, and must be able to= be put on top of an existing system to provide provisioning apis. Said differently, SCIM must not be intrusive for existing systems and must = not require modifications to allow its integration. Correct me if I misunderstood your suggestion. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 =C0 : Kelly Grizzle Cc : scim@ietf.org; Phil Hunt Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestio --_000_56C3C758F9D6534CA3778EAA1E0C343733025AEABY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

There are really two impl= ementation options for a uid per element – either store the uids in t= he native underlying data store or have some secondary data store that maps elements to their uids.  The third option is to hope that a= service provider has a NoLDAP data store or its equivalent.  None of = these are practical for rapid and wide-spread adoption.

 <= /p>

> put the two together to propose a solution. <= /p>

As I said before, I am co= mpletely on board with cleaning up the PATCH semantics (eg – the inco= nsistency between meta.attributes and operation=3Ddelete, etc…). = ; Your suggestion of using different verbs is a good option to consider.&nbs= p; This cannot be based on a uid per element, though.  It seems as tho= ugh you have admitted this in your conclusion – “As for LDAP an= d SCIM, I guess the best TLA is RIP.”

 <= /p>

--Kelly=

 <= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

That was one suggestion. Another way could be contai= ner nodes with their own "dn"s. If one suggestion won't work, tel= l me another way to make it work. I'm waiting to hear a constructive sugges= tion that can square an elegant API with the implementation constraints that come from having to store multi-valued att= ributes in LDAP directories.

 

I've heard enough of WHY this won't work. For a chan= ge, tell me HOW it can be made to work. Everyone now knows what the proposa= l means in terms of the API, and implementors understand the constraints of= legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in = the room" here, surely we should be able to crack this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions about w= hat is to be done:

 

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

> After all, no one has challenged the claim that this proposal= drastically simplifies the API for the client

 

I agree that your proposal makes PATCH = semantics simpler and more elegant.

 

 

> … so it would appear to be worth doing. 

 

I strongly disagree here.  This st= atements assumes that simplicity of the client API is the only factor that should be considered with the spec.

 

Emmanuel’s example is from a real= -world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interfac= e that will help facilitate data exchange between multiple Active Directory= servers.  Your solution was to change the data model from this:

 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, = ;7a6d1de664e1=3Djsmith1970@hotmail.com

 

I do not know of a single organization = that would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likel= y across other domain controllers, etc…) to assign these unique ident= ifiers.  This also assumes that SCIM is the only reader/writer of this= data, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this. = Additionally, there are *many* tools and applications  (eg = 211; address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO t= his same argument holds true for most service providers.<= /p>

 

 

PATCH is an optional part of the spec. =  It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve e= very problem (eg – modifying sub-elements in nested arrays).  Ad= ding uids to every multi-valued element does not strike the right balance b= etween the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasa= d [mailto:g.c.pra= sad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Responding to extract of Melinda Shore's mail from digest:

 

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more

messages with a complaint about what you seem to think is a=



complex algorithm for attribute processing.




 






It depends on how it's implemented. I'm confident we can have the =
best of both - simple API with low-overhead implementation. Can we brainsto=
rm HOW this proposal can be implemented
 rather than WHY it can't be implemented (which is mostly what I've been he=
aring so far)? After all, no one has challenged the claim that this proposa=
l drastically simplifies the API for the client, so it would appear to be w=
orth doing. I'm sure there's more
 than enough intellectual horsepower in this working group to pull this off=
 if we put our minds to it.






 






Regards,






Ganesh




 




On 13 August 2012 13:54, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> w=
rote:




> I strongly object to anything that leads to a read before modi=
fy requirement. Too complex and too chatty.




Sorry Phil, but you're contradicting yourself here. There see=
ms to be an awful lot of matching (i.e., reading) going on in the spec as i=
t stands, with if-then clauses to do one
 thing or another if the match either succeeds or fails. This is a complex,=
 chatty protocol right now!




 






   Multi-valued attributes:=
  An attribute value in the PATCH request


      body i=
s added to the value collection if the value does not exist


      and me=
rged if a matching value is present.  Values are matched by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute; e.g., addresses, or do not have unique


      value =
Sub-Attributes cannot be matched and must instead be deleted


      then a=
dded.  Specific values can be removed from a Resource by


      adding=
 an "operation" Sub-Attribute with the value "delete" t=
o the


      attrib=
ute in the PATCH request body.  As with adding/updating


      attrib=
ute value collections, the value to delete is determined by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute or that have a non-unique value Sub-=



      Attrib=
ute are matched by comparing all Sub-Attribute values from


      the PA=
TCH request body to the Sub-Attribute values of the


      Resour=
ce.  A delete operation is ignored if the attribute's name=



      is in =
the meta.attributes list.  If the requested value to delete


      does n=
ot match a unique value on the Resource the server MAY

      return=
 a HTTP 400 error.






 






For a spec that is supposed to be about simplicity, the above desc=
ription is anything but simple. I know you guys have worked hard on this an=
d I don't mean to disparage those efforts,
 but think about how the above passage would appear to a new reader (i.e., =
a novice to the spec, not a technology novice).






 






There is something fundamentally broken, and it is this: multi-val=
ued attributes without a unique identifier per value. If you don't fix that=
, you won't get simplicity.






 






We know LDAP trees are broken for multi-valued attributes. As Mark=
 Wahl

famously commented back in 2005,






 






"Unfortunately, some of the emerging protocols w=
hich also intend to represent and transfer personal identity information
 have perhaps taken a step backwards by not even considering these issues, =
perhaps sweeping them under the rug in the guise of simplicity, XMLificatio=
n, or "fix in the next version", which only postpone finding inte=
roperable solutions to allowing applications
 to express the identity entries they want to express."






 






SCIM is exactly one of these "emerging protocols" Wahl t=
alks about, and what I see now strikes me as "sweeping these issues un=
der the rug in the guise of simplicity". Apologies
 for the bluntness.






 






My take is that SPs are _already_ struggling to manage multi-value=
d attributes, and

existing mechanisms are clumsy. They would be grateful for a specificat=
ion that made operations easier at the cost of a re-engineered schema. That=
 calls for some thought leadership from this working group.






 






Regards,






Ganesh






 




On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:






I strongly object to anything that leads to a read before modify r=
equirement. Too complex and too chatty. =




Phil












On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








> Would it have to be stored on t=
he account database of the service provider?


 


Yes.


 


> If so, I believe that this is i=
mpracticable in the core schema. Indeed it implies that a service prov=
ider must extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.




 






Why? That doesn't necessarily follow. Implementation is independen=
t of representation. We're talking about a change in representation to make=
 the API cleaner.






 






As a simple example, if an LDAP node is being used to hold a list =
of comma-separated email addresses, it can just as easily store comma-separ=
ated name-value pairs.






 







 






mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, =
;7a6d1de664e1=3Djsmith1970@hotmail.com






 




That's why I asked if there was an SP representative on this working gro=
up who could explain what such a change could mean for them.
 As of now, it looks like other people are presuming that SPs will not be a=
ble to implement these changes easily and are rejecting them for that reaso=
n.




 






Regards,






Ganesh






 




On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com> wrote:






=F0  
addresses.3cbaaff8e84e.street-number =3D "243"


 


Where would
3cbaaff8e84e come from? Would it have to be stored on the account database of th=
e service provider?


 


If so, I believe that this is imprac=
ticable in the core schema. Indeed it implies that a service provider must =
extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.


This would be a show stopper. SCIM m=
ust be transparent, and must be able to be put on top of an existing system=
 to provide provisioning apis.


 


Said differently, SCIM must not be i=
ntrusive for existing systems and must not require modifications to allow i=
ts integration.


Correct me if I misunderstood your s=
uggestion.


 


--


Regards,


Emmanuel Dreux<=
/o:p>


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

Tel:
+33 4 2=
6 78 17 58


Mobile:
+33 6 4=
7 81 26 70


skype: Emmanuel.Dreux


 



De : Ganesh and
 Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9 : dimanche 12 ao=FBt 2012 04:53

=C0 : Kelly Grizzle

Cc : scim@ie=
tf.org; Phil Hunt

Objet : Re: [scim] scim Digest, Vol 8, Issue 24




 


> 
Multi-valued attributes that d=
on't have a value sub-attribute (eg - address) have to specified completely=
 for uniqueness.  




 






That's exactly the point. How do we "specif=
y completely for uniqueness"?






 






In the example below, how are you proposing that=
 the following element be updated if we can't use positional indexes?






 






addresses[1].street-number =3D "243"






 






User object:






 








{






  ...






  addresses: [






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  ]






}






 






It's impractical to use the value because it's t=
he whole dictionary element:






 








{






  "type" : "office",






  "street-number" : "213&quo=
t;,






  "street-name" : "Main Stre=
et",






  "suburb" : "Adelaide"=
,






  "postcode" : "5000",<=
/span>






  "state" : "SA",






  "country" : "Australia&quo=
t;






}








 






With my proposal, the "addresses" arra=
y gets converted to a dictionary, and then we have a stable way of referenc=
ing this element:






 








addresses.3cbaaff8e84e.street-number =3D "2=
43"




 








{






  ...






  addresses: {






    "d6ea365462f5" :<=
o:p>






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    "3cbaaff8e84e" :<=
o:p>






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  }






}






 






If you're proposing one mechanism for composite =
attributes and another mechanism for simple attributes, I would suggest tha=
t's actually more complex than adopting
 a single mechanism that works the same way for _all_ attributes. Remember =
that a lot of the administration is probably going to be scripted rather th=
an done by hand, and having two mechanisms (depending on whether the attrib=
ute is simple or composite) will
 complicate every script that has to be written.








 






There's a lot of talk about the "burden&quo=
t; on the SPs, but I believe this is overblown. Is there any SP representat=
ive in this WG who can tell us what this proposal
 will actually entail for them?






 






Regards,






Ganesh




 




On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@s=
ailpoint.com> wrote:








Ganesh,






 






This is exactly how PATCH works in SCIM 1.=
0.  Multi-valued attributes that have a value sub-attribute
 can be removed by specifying only the value since it is unique.  Mult=
i-valued attributes that don't have a value sub-attribute (eg - address) ha=
ve to specified completely for uniqueness.  As I have said before, I a=
m very opposed to adding a unique identifier
 to each element in a multi-valued collection due to the burden it will put=
 on SPs.  Is it elegant?  No.  Is it functional?  Yes. =
 Will this non-elegance affect adoption?  My opinion is that addi=
ng unique keys to each element will have a much more detrimental
 effect on adoption.






 






I do believe that in general PATCH can be =
made more intuitive without adding uids to each element.  The
 verbs that you propose make sense.  There is also a JSON Patch inform=
ational draft in the IETF that is interesting - http://=
tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.
  It relies on a JSON Pointer draft which uses index-based addressing =
for multi-valued attributes.  I think that this is something that shou=
ld be looked at within the WG and I would be willing to lead this effort.






 






I'm curious if anyone else in the WG is in=
 favor of unique identifiers for every multi-valued element.






 






--Kelly




 












From:
scim-bounces@iet=
f.org [scim-=
bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]

Sent: Saturday, August 11, 2012 10:50 AM

To: Phil Hunt

Cc: scim@ietf.org=


Subject: Re: [scim] scim Digest, Vol 8, Issue 24









Phil,





 






The reason we cannot use the value itself to ide=
ntify an element is that this method will only work for simple elements, no=
t for nested structures. i.e., if we had
 an array of dictionaries (e.g., we had to record an array of addresses for=
 each customer, with each address element having sub-elements like street n=
umber, street name, suburb, etc.), then it would be clumsy to supply the en=
tire value of the array element
 because it's itself a dictionary. Creating a unique key for each element s=
cales better.






 






Regards,






Ganesh




On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com=
> wrote:




Ganesh,





 






Here's the sample that concerned me...












The two operations differ significantly, and it'=
s not very intuitive. 






With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }











 








 








You gave other examples of an attribute with an identifier th=
at matched that value or of identifiers that were
 additional unique keys.






 






Given that multi-values must be each unique, I don't see the =
point of the extra indexing to support this. Just
 use the value as the item you wish to delete.






 






I agree, the delete value operation could be more explicit an=
d clear in general.






 









 




 








 






On 2012-08-11, at 2:30 AM, Ganesh and Sashi Pras=
ad wrote:




 


>  For the multi-value example you gave =
you used the value as the attribute name key. 





 






Now I'm confused :-). I don't believe any of my =
examples ever used a value as the key.






 






Could you please show me which example you mean,=
 and which parts of it you believe to be the value?






 






Regards,






Ganesh 




On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com=
> wrote:








For the multi-value example you gave you used the value as the attribute na=
me key. 






 






That means a lot more complex indexing structure=
. Better to just say delete a specific value. 






 






The spec already allows multiple values to have =
tags like home, work, etc.






 =







Phil











On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
















> In your example you are conflating val=
ue with an attribute id. 



I don't believe so. 




 






I'm adopting a model where every attribute of th=
e resource is a key-value pair. The key is a name or ID.<=
/p>





 






For non-repeating attributes (both simple and co=
mposite), the key is the attribute name itself. 






 








Simple attribute:






 






Key: "dob"






Value: "01 Jan 1970"=







 








For composite attributes, the key employs dot no=
tation to specify the fully-qualified attribute name, e.g., "address.p=
ostcode".






 






Composite attribute:






 






Key: "address.street-number"






Value: "10"






 






Key: "address.suburb"






Value: "East Camden"=







 






For repeating (multi-valued) attributes, I'm sug=
gesting that there be new keys for each individual value, otherwise they ar=
e impossible to distinguish, and a positional
 index is inadequate. So we convert the array into a dictionary and this th=
en becomes a composite attribute using dot notation for the key.






 






Multi-valued attribute:






 






Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea=
3bd902"







 






So this allows us to apply uniform treatment to =
any arbitrarily deep resource structure. We can refer to every leaf value w=
ith a key that is the fully-qualified
 name using dot notation.






 






The verbs are just unambiguous operations on the=
se (now) explicitly addressable attributes.






 






INCLUDE to a collection and specify only the val=
ue. The key is generated and returned. The fully-qualified key is <colle=
ction-name>.<newly-generated-ID> and the
 value is what was specified in the INCLUDE.






 






REPLACE a fully-qualified key with a new value. =
If the key doesn't exist, return a "404 Not Found".






 






PLACE a value at the logical location implied by=
 the fully-qualified key. If there is already a key with that name, return =
a "409 Conflict".






 






FORCE the fully-qualified key to hold the given =
value, regardless of whether it existed before or not. Only errors possible=
 are "400 Bad Request" and "500 Internal
 Error".






 






RETIRE an attribute or a collection given its fu=
lly-qualified key. The implementation will determine whether the attribute =
will disappear entirely or will exist
 holding a null value (the blank string "" or the empty object {}=
 ).






 






I'll explain in a separate post why we need oper=
ation verbs like these that are independent of the HTTP verbs.<=
/o:p>






 






Regards,






Ganesh






 




On 11 August 2012 10:38, <scim-request@ietf.org> wrote=
:


If you have received this digest without all the=
 individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



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



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







Send scim mailing list submissions to

        scim@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

        https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to

        scim-request@ietf.org



You can reach the person managing the list at

        scim-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of scim digest..."



Today's Topics:



   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun=
t)





---------- Forwarded message ----------

From: Phil Hunt <phil.hunt@oracle.com>

To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>

Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux =
<edreux@cloudi=
way.com>, Trey Drake <trey.drake@unboundid.com>,
 Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>

Date: Fri, 10 Aug 2012 17:36:54 -0700

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








Ganesh,






 






In your example you are conflating value with an=
 attribute id. I find that confusing. 






 






I agree though that operations in patch could be=
 a lot more explicit. 






 






Eg explicitly deleting a value by saying delete =
or retire. 








Phil








On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








 >  I am concerned about your second suggestion: 





 






Let's discuss that now.






 






The trade-offs are very clear here.<=
/o:p>






 






Pros:






 






Pro 1. The API to manipulate resources becomes s=
o much cleaner, consistent and intuitive when every individual attribute va=
lue gets its own ID.






 






Here's how to delete a single member from a Grou=
p, as per the current spec:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"members": [


    &=
nbsp;  {


    &=
nbsp;    "display": "Babs Jensen",


    &=
nbsp;    "value": "2819c223-7f76-453a-919d-41=
3861904646"


    &=
nbsp;    "operation": "delete"


    &=
nbsp;  }


     =
]


   }




Here's how to delete ALL members from a group according to the current spec=
:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"meta": {


    &=
nbsp;  "attributes": [


    &=
nbsp;    "members"


    &=
nbsp;  ]


     =
}


   }




The two operations differ significantly, and it's not very intuitive. =







With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }


Here's how I suggest deleting ALL members from a group:





 








PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members"






}






}






] }







I'm sure you'll agree that this is simpler, more consistent and more intuit=
ive to a reader.






 






Pro 2: We can apply this mechanism consistently =
to three areas:






(a) Manipulating multi-valued attributes of a re=
source






(b) Manipulating members of a group<=
/o:p>






(c) Performing bulk operations, where we simply =
use HTTP verbs instead of the specialised (and semantically less ambiguous)=
 verbs I suggested for attributes, the
 "key" becomes the URI, and the "value" becomes the cor=
responding JSON object.






 






All of them return "207 Multi-Status" =
with the "results" array holding individual status codes.<=
o:p>






 






In the current spec, (a) and (b) are done simila=
rly but (c) is very different.






 






Pro 3: Adoption of the standard by clients is li=
kely to be higher because it's simpler for them.






 






Pro 4: New (not incumbent) cloud providers will =
probably find this easier to implement because they have no legacy. They wi=
ll probably use some form of NoSQL database
 and won't be constrained by the limitations of LDAP directories.






 






Cons:






 






Con 1: Incumbent cloud providers with existing d=
ata stores in a directory format (where multi-valued attributes are stored =
as comma-separated values under a single
 attribute node) will find it difficult to migrate to this model and store =
each attribute value as a sub-node with its own key. This will "hinder=
 adoption of the spec", which is what you fear.






 






Have I summed up the Pros and Cons correctly? I'=
m biased of course, so I could have missed a Con or hyped a Pro :-).=





 




In other words, we're debating interface complex=
ity (current spec) versus implementation complexity (my suggestion). Both c=
an hinder adoption of the spec by different
 parties.






 






Here's what we need to discuss - Do the Pros mak=
e the suggestio
















































































 










 

 

--_000_56C3C758F9D6534CA3778EAA1E0C343733025AEABY2PRD0410MB354_-- From charliemortimore@gmail.com Mon Aug 13 09:26:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF7521F84EA for ; Mon, 13 Aug 2012 09:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhjsyZF+bu-3 for ; Mon, 13 Aug 2012 09:25:59 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A306921F84E7 for ; Mon, 13 Aug 2012 09:25:58 -0700 (PDT) Received: by qadz3 with SMTP id z3so1169524qad.10 for ; Mon, 13 Aug 2012 09:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=FHcYzx4Tsy2DTVbgdiTRkxdroh1GTYjWO22fxQ2VCC8=; b=OhqAE+vrbejJPB/Y2eNzB44w8dwzELmIsonpybg3nERAhPt7pZ7ePh0H3z/u7FeUqR xoE04rZUZYRHxDSrdWeNWgUp9TPVSsrtKgahXL+u5R65jFdoviLtgyS01XPwXKDIiczT Hw9EkpC2gpgQqRR24Z0noH64XQVPgDZiTUBQpf5y9rWNKRsziGkk5Xz5exMma4sFiz/c qZC8UX54Nzj77S8GkHJSA91rCQei0QjCjaQcEUQfe5rXWQTdVOscrYfpO6nAiKY7QKqd lL2itJxX9r05JThcb29vo7Ygvlr9h0ondpUeOTbcMB6Y3ZbY1rfD2mr7N/CfmtdhrDvI 5Pcw== Received: by 10.224.28.7 with SMTP id k7mr26347588qac.56.1344875157972; Mon, 13 Aug 2012 09:25:57 -0700 (PDT) Received: from [192.168.1.114] (c-24-131-236-45.hsd1.pa.comcast.net. [24.131.236.45]) by mx.google.com with ESMTPS id dg10sm98696qab.12.2012.08.13.09.25.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 09:25:57 -0700 (PDT) References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-771690FD-1A57-4A8D-B1E7-0BD429BFF746 Message-Id: <8A16EFDB-9B79-43E2-8990-4F4098CF13C3@gmail.com> X-Mailer: iPhone Mail (9B179) From: Charliemortimore Date: Mon, 13 Aug 2012 12:25:53 -0400 To: Kelly Grizzle Cc: "scim@ietf.org" , Ganesh and Sashi Prasad , Melinda Shore , Phil Hunt , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:26:02 -0000 --Apple-Mail-771690FD-1A57-4A8D-B1E7-0BD429BFF746 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Speaking as a large adopting service provider, we wouldn't be able to absorb= a uniqueid per attribute scheme. That said, in practice our patch support= works fine without this On Aug 13, 2012, at 11:54 AM, Kelly Grizzle wr= ote: > There are really two implementation options for a uid per element =E2=80=93= either store the uids in the native underlying data store or have some seco= ndary data store that maps elements to their uids. The third option is to h= ope that a service provider has a NoLDAP data store or its equivalent. None= of these are practical for rapid and wide-spread adoption. > =20 > > put the two together to propose a solution. > =20 > As I said before, I am completely on board with cleaning up the PATCH sema= ntics (eg =E2=80=93 the inconsistency between meta.attributes and operation=3D= delete, etc=E2=80=A6). Your suggestion of using different verbs is a good o= ption to consider. This cannot be based on a uid per element, though. It s= eems as though you have admitted this in your conclusion =E2=80=93 =E2=80=9C= As for LDAP and SCIM, I guess the best TLA is RIP.=E2=80=9D > =20 > --Kelly > =20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 9:56 AM > To: Kelly Grizzle > Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > That was one suggestion. Another way could be container nodes with their o= wn "dn"s. If one suggestion won't work, tell me another way to make it work.= I'm waiting to hear a constructive suggestion that can square an elegant AP= I with the implementation constraints that come from having to store multi-v= alued attributes in LDAP directories. > =20 > I've heard enough of WHY this won't work. For a change, tell me HOW it can= be made to work. Everyone now knows what the proposal means in terms of the= API, and implementors understand the constraints of legacy data stores, so p= ut the two together to propose a solution. C'mon, we have the "smartest guys= in the room" here, surely we should be able to crack this. > =20 > Regards, > Ganesh > =20 > P.S. I'm rapidly reaching my own conclusions about what is to be done: > http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nol= dap.html=20 > =20 >=20 > On 14 August 2012 00:27, Kelly Grizzle wrote= : > > After all, no one has challenged the claim that this proposal drasticall= y simplifies the API for the client > =20 > I agree that your proposal makes PATCH semantics simpler and more elegant.= > =20 > =20 > > =E2=80=A6 so it would appear to be worth doing.=20 > =20 > I strongly disagree here. This statements assumes that simplicity of the c= lient API is the only factor that should be considered with the spec. > =20 > Emmanuel=E2=80=99s example is from a real-world service provider that woul= d not be able to implement the spec easily with a uid per element. He is wo= rking on a SCIM interface that will help facilitate data exchange between mu= ltiple Active Directory servers. Your solution was to change the data model= from this: > =20 > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com > =20 > to this: > =20 > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.sm= ith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com > =20 > I do not know of a single organization that would change their Active Dire= ctory data model to fit this. For one thing, it would be a huge data migrat= ion effort (likely across other domain controllers, etc=E2=80=A6) to assign t= hese unique identifiers. This also assumes that SCIM is the only reader/wri= ter of this data, which will almost never be the case. If the data model re= quires uids for every element, then every piece of non-SCIM code that writes= data into the directory will have to follow this. Additionally, there are *= many* tools and applications (eg =E2=80=93 address books) that rely on a ce= rtain data model in Active Directory, and this would cause them to break. I= MO this same argument holds true for most service providers. > =20 > =20 > PATCH is an optional part of the spec. It was primarily introduced to mak= e modifying resources with large multi-valued lists more efficient. It does= not need to solve every problem (eg =E2=80=93 modifying sub-elements in nes= ted arrays). Adding uids to every multi-valued element does not strike the r= ight balance between the needs of the client and the needs of the service pr= ovider. > =20 > --Kelly > =20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 1:35 AM > To: Phil Hunt; Melinda Shore > Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > Responding to extract of Melinda Shore's mail from digest: > =20 > The issue being raised here isn't endpoint logic, but > network traffic, and I'm pretty sure it's not very helpful to > respond to the observation that your model requires more > messages with a complaint about what you seem to think is a > complex algorithm for attribute processing. > =20 > It depends on how it's implemented. I'm confident we can have the best of b= oth - simple API with low-overhead implementation. Can we brainstorm HOW thi= s proposal can be implemented rather than WHY it can't be implemented (which= is mostly what I've been hearing so far)? After all, no one has challenged t= he claim that this proposal drastically simplifies the API for the client, s= o it would appear to be worth doing. I'm sure there's more than enough intel= lectual horsepower in this working group to pull this off if we put our mind= s to it. > =20 > Regards, > Ganesh > =20 > On 13 August 2012 13:54, Ganesh and Sashi Prasad wr= ote: > > I strongly object to anything that leads to a read before modify require= ment. Too complex and too chatty. >=20 > Sorry Phil, but you're contradicting yourself here. There seems to be an a= wful lot of matching (i.e., reading) going on in the spec as it stands, with= if-then clauses to do one thing or another if the match either succeeds or f= ails. This is a complex, chatty protocol right now! > =20 > Multi-valued attributes: An attribute value in the PATCH request > body is added to the value collection if the value does not exist > and merged if a matching value is present. Values are matched by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute; e.g., addresses, or do not have unique > value Sub-Attributes cannot be matched and must instead be deleted > then added. Specific values can be removed from a Resource by > adding an "operation" Sub-Attribute with the value "delete" to the > attribute in the PATCH request body. As with adding/updating > attribute value collections, the value to delete is determined by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute or that have a non-unique value Sub- > Attribute are matched by comparing all Sub-Attribute values from > the PATCH request body to the Sub-Attribute values of the > Resource. A delete operation is ignored if the attribute's name > is in the meta.attributes list. If the requested value to delete > does not match a unique value on the Resource the server MAY > return a HTTP 400 error. > =20 > For a spec that is supposed to be about simplicity, the above description i= s anything but simple. I know you guys have worked hard on this and I don't m= ean to disparage those efforts, but think about how the above passage would a= ppear to a new reader (i.e., a novice to the spec, not a technology novice).= > =20 > There is something fundamentally broken, and it is this: multi-valued attr= ibutes without a unique identifier per value. If you don't fix that, you won= 't get simplicity. > =20 > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl fa= mously commented back in 2005, > =20 > "Unfortunately, some of the emerging protocols which also intend to repres= ent and transfer personal identity information have perhaps taken a step bac= kwards by not even considering these issues, perhaps sweeping them under the= rug in the guise of simplicity, XMLification, or "fix in the next version",= which only postpone finding interoperable solutions to allowing application= s to express the identity entries they want to express." > =20 > SCIM is exactly one of these "emerging protocols" Wahl talks about, and wh= at I see now strikes me as "sweeping these issues under the rug in the guise= of simplicity". Apologies for the bluntness. > =20 > My take is that SPs are _already_ struggling to manage multi-valued attrib= utes, and existing mechanisms are clumsy. They would be grateful for a speci= fication that made operations easier at the cost of a re-engineered schema. T= hat calls for some thought leadership from this working group. > =20 > Regards, > Ganesh > =20 >=20 > On 13 August 2012 10:13, Phil Hunt wrote: > I strongly object to anything that leads to a read before modify requireme= nt. Too complex and too chatty.=20 >=20 > Phil >=20 > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad wr= ote: >=20 > > Would it have to be stored on the account database of the service provid= er? > =20 > Yes. > =20 > > If so, I believe that this is impracticable in the core schema. Indeed i= t implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D f= or SCIM integration. > =20 > Why? That doesn't necessarily follow. Implementation is independent of rep= resentation. We're talking about a change in representation to make the API c= leaner. > =20 > As a simple example, if an LDAP node is being used to hold a list of comma= -separated email addresses, it can just as easily store comma-separated name= -value pairs. > =20 > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com > can be changed to > =20 > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.sm= ith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com > =20 > That's why I asked if there was an SP representative on this working group= who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement th= ese changes easily and are rejecting them for that reason. > =20 > Regards, > Ganesh > =20 > On 13 August 2012 04:29, Emmanuel Dreux wrote: > =C3=B0 addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 > Where would 3cbaaff8e84e come from? Would it have to be stored on the acco= unt database of the service provider? > =20 > If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposit= ory (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D for= SCIM integration. > This would be a show stopper. SCIM must be transparent, and must be able t= o be put on top of an existing system to provide provisioning apis. > =20 > Said differently, SCIM must not be intrusive for existing systems and must= not require modifications to allow its integration. > Correct me if I misunderstood your suggestion. > =20 > -- > Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux > =20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=C3=A9 : dimanche 12 ao=C3=BBt 2012 04:53 > =C3=80 : Kelly Grizzle > Cc : scim@ietf.org; Phil Hunt > Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > > Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness. =20 > =20 > That's exactly the point. How do we "specify completely for uniqueness"? > =20 > In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? > =20 > addresses[1].street-number =3D "243" > =20 > User object: > =20 > { > ... > addresses: [ > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > ] > } > =20 > It's impractical to use the value because it's the whole dictionary elemen= t: > =20 > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > =20 > With my proposal, the "addresses" array gets converted to a dictionary, an= d then we have a stable way of referencing this element: > =20 > addresses.3cbaaff8e84e.street-number =3D "243" > =20 > { > ... > addresses: { > "d6ea365462f5" : > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > "3cbaaff8e84e" : > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > } > } > =20 > If you're proposing one mechanism for composite attributes and another mec= hanism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attributes= . Remember that a lot of the administration is probably going to be scripted= rather than done by hand, and having two mechanisms (depending on whether t= he attribute is simple or composite) will complicate every script that has t= o be written. > =20 > There's a lot of talk about the "burden" on the SPs, but I believe this is= overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? > =20 > Regards, > Ganesh > =20 > On 12 August 2012 11:53, Kelly Grizzle wrote= : > Ganesh, > =20 > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that= have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attribu= te (eg - address) have to specified completely for uniqueness. As I have sa= id before, I am very opposed to adding a unique identifier to each element i= n a multi-valued collection due to the burden it will put on SPs. Is it ele= gant? No. Is it functional? Yes. Will this non-elegance affect adoption?= My opinion is that adding unique keys to each element will have a much mor= e detrimental effect on adoption. > =20 > I do believe that in general PATCH can be made more intuitive without addi= ng uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http:= //tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JSON= Pointer draft which uses index-based addressing for multi-valued attributes= . I think that this is something that should be looked at within the WG and= I would be willing to lead this effort. > =20 > I'm curious if anyone else in the WG is in favor of unique identifiers for= every multi-valued element. > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh an= d Sashi Prasad [g.c.prasad@gmail.com] > Sent: Saturday, August 11, 2012 10:50 AM > To: Phil Hunt > Cc: scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > Phil, > =20 > The reason we cannot use the value itself to identify an element is that t= his method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of a= ddresses for each customer, with each address element having sub-elements li= ke street number, street name, suburb, etc.), then it would be clumsy to sup= ply the entire value of the array element because it's itself a dictionary. C= reating a unique key for each element scales better. > =20 > Regards, > Ganesh >=20 > On 12 August 2012 01:12, Phil Hunt wrote: > Ganesh, > =20 > Here's the sample that concerned me... > The two operations differ significantly, and it's not very intuitive.=20 > With my suggestion, here's how to delete a single member from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] } > =20 > =20 > You gave other examples of an attribute with an identifier that matched th= at value or of identifiers that were additional unique keys. > =20 > Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to de= lete. > =20 > I agree, the delete value operation could be more explicit and clear in ge= neral. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 > =20 >=20 > =20 > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > =20 >=20 > > For the multi-value example you gave you used the value as the attribut= e name key.=20 > =20 > Now I'm confused :-). I don't believe any of my examples ever used a value= as the key. > =20 > Could you please show me which example you mean, and which parts of it you= believe to be the value? > =20 > Regards, > Ganesh=20 >=20 > On 11 August 2012 13:59, Phil Hunt wrote: >=20 > For the multi-value example you gave you used the value as the attribute n= ame key.=20 > =20 > That means a lot more complex indexing structure. Better to just say delet= e a specific value.=20 > =20 > The spec already allows multiple values to have tags like home, work, etc.= > =20 > Phil >=20 > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad wr= ote: >=20 > > In your example you are conflating value with an attribute id.=20 >=20 > I don't believe so. > =20 > I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. > =20 > For non-repeating attributes (both simple and composite), the key is the a= ttribute name itself.=20 > =20 > Simple attribute: > =20 > Key: "dob" > Value: "01 Jan 1970" > =20 > For composite attributes, the key employs dot notation to specify the full= y-qualified attribute name, e.g., "address.postcode". > =20 > Composite attribute: > =20 > Key: "address.street-number" > Value: "10" > =20 > Key: "address.suburb" > Value: "East Camden" > =20 > For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish,= and a positional index is inadequate. So we convert the array into a dictio= nary and this then becomes a composite attribute using dot notation for the k= ey. > =20 > Multi-valued attribute: > =20 > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" > Value: "john_smith@yahoo.com" > =20 > So this allows us to apply uniform treatment to any arbitrarily deep resou= rce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. > =20 > The verbs are just unambiguous operations on these (now) explicitly addres= sable attributes. > =20 > INCLUDE to a collection and specify only the value. The key is generated a= nd returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. > =20 > REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". > =20 > PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". > =20 > FORCE the fully-qualified key to hold the given value, regardless of wheth= er it existed before or not. Only errors possible are "400 Bad Request" and "= 500 Internal Error". > =20 > RETIRE an attribute or a collection given its fully-qualified key. The imp= lementation will determine whether the attribute will disappear entirely or w= ill exist holding a null value (the blank string "" or the empty object {} )= . > =20 > I'll explain in a separate post why we need operation verbs like these tha= t are independent of the HTTP verbs. > =20 > Regards, > Ganesh > =20 > On 11 August 2012 10:38, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >=20 >=20 > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux , Trey Drake , Kelly Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > Ganesh, > =20 > In your example you are conflating value with an attribute id. I find that= confusing.=20 > =20 > I agree though that operations in patch could be a lot more explicit.=20 > =20 > Eg explicitly deleting a value by saying delete or retire.=20 >=20 > Phil >=20 > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad wr= ote: >=20 > > I am concerned about your second suggestion:=20 > =20 > Let's discuss that now. > =20 > The trade-offs are very clear here. > =20 > Pros: > =20 > Pro 1. The API to manipulate resources becomes so much cleaner, consistent= and intuitive when every individual attribute value gets its own ID. > =20 > Here's how to delete a single member from a Group, as per the current spec= : > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current spe= c: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20 > With my suggestion, here's how to delete a single member from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] }=20 > Here's how I suggest deleting ALL members from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accep= t: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f067= 1c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] } >=20 > I'm sure you'll agree that this is simpler, more consistent and more intui= tive to a reader. > =20 > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attri= butes, the "key" becomes the URI, and the "value" becomes the corresponding J= SON object. > =20 > All of them return "207 Multi-Status" with the "results" array holding ind= ividual status codes. > =20 > In the current spec, (a) and (b) are done similarly but (c) is very differ= ent. > =20 > Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. > =20 > Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form of= NoSQL database and won't be constrained by the limitations of LDAP director= ies. > =20 > Cons: > =20 > Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values un= der a single attribute node) will find it difficult to migrate to this model= and store each attribute value as a sub-node with its own key. This will "h= inder adoption of the spec", which is what you fear. > =20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so I c= ould have missed a Con or hyped a Pro :-). > =20 > In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the sp= ec by different parties. > =20 > Here's what we need to discuss - Do the Pros make the suggestio > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-771690FD-1A57-4A8D-B1E7-0BD429BFF746 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Speaking as a large adopti= ng service provider, we wouldn't be able to absorb a uniqueid per attribute s= cheme.   That said, in practice our patch support works fine without th= is

On Aug 13, 2012, at 11:54 AM, Kelly Grizzle <kelly.grizzle@sailpoint.com> w= rote:

There are really two implem= entation options for a uid per element =E2=80=93 either store the uids in th= e native underlying data store or have some secondary data store that maps elements to their uids.  The third option is to hope that a s= ervice provider has a NoLDAP data store or its equivalent.  None of the= se are practical for rapid and wide-spread adoption.

 

> put the two together to propose a solution.=

 

As I said before, I am comp= letely on board with cleaning up the PATCH semantics (eg =E2=80=93 the incon= sistency between meta.attributes and operation=3Ddelete, etc=E2=80=A6). = ; Your suggestion of using different verbs is a good option to consider. = ; This cannot be based on a uid per element, though.  It seems as thoug= h you have admitted this in your conclusion =E2=80=93 =E2=80=9CAs for LDAP a= nd SCIM, I guess the best TLA is RIP.=E2=80=9D

 

--Kelly

 

From: Ganesh and S= ashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

That was one suggestion. Another way could be contain= er nodes with their own "dn"s. If one suggestion won't work, tell me another= way to make it work. I'm waiting to hear a constructive suggestion that can= square an elegant API with the implementation constraints that come from having to store multi-valued attr= ibutes in LDAP directories.

 

I've heard enough of WHY this won't work. For a chang= e, tell me HOW it can be made to work. Everyone now knows what the proposal m= eans in terms of the API, and implementors understand the constraints of leg= acy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in the ro= om" here, surely we should be able to crack this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions about wh= at is to be done:

 

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sailpoi= nt.com> wrote:

> After all, no one has challenged the claim that this proposal d= rastically simplifies the API for the client

 

I agree that your proposal makes PATCH sem= antics simpler and more elegant.

 

 

> =E2=80=A6 so it would appear to be worth doing. 

 

I strongly disagree here.  This state= ments assumes that simplicity of the client API is the only factor that should be considered with the spec.

 

Emmanuel=E2=80=99s example is from a real-= world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interface= that will help facilitate data exchange between multiple Active Directory s= ervers.  Your solution was to change the data model from this:

 

ma=
il: john_smith@yah=
oo.com, john.s=
mith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d= 1de664e1=3Djsmit= h1970@hotmail.com

 

I do not know of a single organization tha= t would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likely= across other domain controllers, etc=E2=80=A6) to assign these unique ident= ifiers.  This also assumes that SCIM is the only reader/writer of this d= ata, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SCI= M code that writes data into the directory will have to follow this.  A= dditionally, there are *many* tools and applications  (eg =E2=80= =93 address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO th= is same argument holds true for most service providers.

 

 

PATCH is an optional part of the spec. &nb= sp;It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve ev= ery problem (eg =E2=80=93 modifying sub-elements in nested arrays).  Ad= ding uids to every multi-valued element does not strike the right balance be= tween the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasad [m= ailto:g.c.prasad@g= mail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Responding to extract of Melinda Shore's mail from digest:

 

The issue being rai=
sed here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more

messages with a complaint about what you seem to think is a<=
/pre>

complex algorithm for attribute processing.




 






It depends on how it's implemented. I'm confident we can have the be=
st of both - simple API with low-overhead implementation. Can we brainstorm H=
OW this proposal can be implemented
 rather than WHY it can't be implemented (which is mostly what I've been hea=
ring so far)? After all, no one has challenged the claim that this proposal d=
rastically simplifies the API for the client, so it would appear to be worth=
 doing. I'm sure there's more
 than enough intellectual horsepower in this working group to pull this off i=
f we put our minds to it.






 






Regards,






Ganesh




 




On 13 August 2012 13:54, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrot=
e:




> I strongly object to anything that leads to a read before modify=
 requirement. Too complex and too chatty.




Sorry Phil, but you're contradicting yourself here. There seems=
 to be an awful lot of matching (i.e., reading) going on in the spec as it s=
tands, with if-then clauses to do one
 thing or another if the match either succeeds or fails. This is a complex, c=
hatty protocol right now!




 






   Multi-valued attributes:&=
nbsp; An attribute value in the PATCH request


      body is=
 added to the value collection if the value does not exist=



      and mer=
ged if a matching value is present.  Values are matched by<=
/o:p>


      compari=
ng the value Sub-Attribute from the PATCH request body to<=
/pre>

      the val=
ue Sub-Attribute of the Resource.  Attributes that do not


      have a v=
alue Sub-Attribute; e.g., addresses, or do not have unique=



      value S=
ub-Attributes cannot be matched and must instead be deleted


      then ad=
ded.  Specific values can be removed from a Resource by


      adding a=
n "operation" Sub-Attribute with the value "delete" to the=



      attribu=
te in the PATCH request body.  As with adding/updating


      attribu=
te value collections, the value to delete is determined by=



      compari=
ng the value Sub-Attribute from the PATCH request body to<=
/pre>

      the val=
ue Sub-Attribute of the Resource.  Attributes that do not


      have a v=
alue Sub-Attribute or that have a non-unique value Sub-

      Attribu=
te are matched by comparing all Sub-Attribute values from<=
/pre>

      the PAT=
CH request body to the Sub-Attribute values of the


      Resourc=
e.  A delete operation is ignored if the attribute's name


      is in t=
he meta.attributes list.  If the requested value to delete<=
/o:p>


      does no=
t match a unique value on the Resource the server MAY

      return a=
 HTTP 400 error.






 






For a spec that is supposed to be about simplicity, the above descri=
ption is anything but simple. I know you guys have worked hard on this and I=
 don't mean to disparage those efforts,
 but think about how the above passage would appear to a new reader (i.e., a=
 novice to the spec, not a technology novice).






 






There is something fundamentally broken, and it is this: multi-value=
d attributes without a unique identifier per value. If you don't fix that, y=
ou won't get simplicity.






 






We know LDAP trees are broken for multi-valued attributes. As Mark W=
ahl

famously commented back in 2005,






 






"Unfortunately, some of the emerging protocols which als=
o intend to represent and transfer personal identity information
 have perhaps taken a step backwards by not even considering these issues, p=
erhaps sweeping them under the rug in the guise of simplicity, XMLification,=
 or "fix in the next version", which only postpone finding interoperable sol=
utions to allowing applications
 to express the identity entries they want to express."





 






SCIM is exactly one of these "emerging protocols" Wahl talks about, a=
nd what I see now strikes me as "sweeping these issues under the rug in the g=
uise of simplicity". Apologies
 for the bluntness.






 






My take is that SPs are _already_ struggling to manage multi-valued a=
ttributes, and

existing mechanisms are clumsy. They would be grateful for a specificati=
on that made operations easier at the cost of a re-engineered schema. That c=
alls for some thought leadership from this working group.






 






Regards,






Ganesh






 




On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:<=
/p>





I strongly object to anything that leads to a read before modify req=
uirement. Too complex and too chatty. 


Phil












On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<=
/o:p>








> Would it have to be stored on the=
 account database of the service provider?


 


Yes.


 


> If so, I believe that this is imp=
racticable in the core schema. Indeed it implies that a service provide=
r must extend the schema of his account repository
 (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D for SC=
IM integration.




 






Why? That doesn't necessarily follow. Implementation is independent o=
f representation. We're talking about a change in representation to make the=
 API cleaner.






 






As a simple example, if an LDAP node is being used to hold a list of=
 comma-separated email addresses, it can just as easily store comma-separate=
d name-value pairs.






 







 






mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d=
1de664e1=3Djsmit=
h1970@hotmail.com






 




That's why I asked if there was an SP representative on this working group w=
ho could explain what such a change could mean for them.
 As of now, it looks like other people are presuming that SPs will not be ab=
le to implement these changes easily and are rejecting them for that reason.=





 






Regards,






Ganesh






 




On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com> wrote:






=C3=B0  
addresses.3cbaaff8e84e.street-number =3D "243"


 


Where would
3cbaaff8e84e come from? Would it have to be stored on the account database of the s=
ervice provider?


 


If so, I believe that this is impracti=
cable in the core schema. Indeed it implies that a service provider must ext=
end the schema of his account repository
 (LDAP partition, SQL db, =E2=80=A6) and =E2=80=9Cprepare it=E2=80=9D for SC=
IM integration.


This would be a show stopper. SCIM mus=
t be transparent, and must be able to be put on top of an existing system to=
 provide provisioning apis.


 


Said differently, SCIM must not be int=
rusive for existing systems and must not require modifications to allow its i=
ntegration.


Correct me if I misunderstood your sug=
gestion.


 


--


Regards,


Emmanuel Dreux


http://www.cloudiway.com


Tel:
+33 4 26 78 1=
7 58


Mobile:
+33 6 47 81 2=
6 70


skype: Emmanuel.Dreux


 




De : Ganesh and
 Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=C3=A9 : dimanche 12 ao=C3=BBt 2012 04:53

=C3=80 : Kelly Grizzle

Cc : scim@iet=
f.org; Phil Hunt

Objet : Re: [scim] scim Digest, Vol 8, Issue 24




 


> 
Multi-valued attributes that don=
't have a value sub-attribute (eg - address) have to specified completely fo=
r uniqueness.  




 






That's exactly the point. How do we "specify compl=
etely for uniqueness"?






 






In the example below, how are you proposing that t=
he following element be updated if we can't use positional indexes?






 






addresses[1].street-number =3D "243"






 






User object:






 








{






  ...






  addresses: [






    {






      "type" : "home",<=
/o:p>






      "street-number" : "35",






      "street-name" : "High Road",<=
/span>






      "suburb" : "East Camden",






      "postcode" : "5346",






      "state" : "SA",






      "country" : "Australia"






    },






    {






      "type" : "office",






      "street-number" : "213",






      "street-name" : "Main Street"=
,






      "suburb" : "Adelaide",=







      "postcode" : "5000",






      "state" : "SA",






      "country" : "Australia"






    }






  ]






}






 






It's impractical to use the value because it's the=
 whole dictionary element:






 








{






  "type" : "office",






  "street-number" : "213",<=
/p>





  "street-name" : "Main Street",<=
/o:p>






  "suburb" : "Adelaide",





  "postcode" : "5000",






  "state" : "SA",






  "country" : "Australia"





}








 






With my proposal, the "addresses" array gets conve=
rted to a dictionary, and then we have a stable way of referencing this elem=
ent:






 








addresses.3cbaaff8e84e.street-number =3D "243"




 








{






  ...






  addresses: {






    "d6ea365462f5" :





    {






      "type" : "home",<=
/o:p>






      "street-number" : "35",






      "street-name" : "High Road",<=
/span>






      "suburb" : "East Camden",






      "postcode" : "5346",






      "state" : "SA",






      "country" : "Australia"






    },






    "3cbaaff8e84e" :





    {






      "type" : "office",






      "street-number" : "213",






      "street-name" : "Main Street"=
,






      "suburb" : "Adelaide",=







      "postcode" : "5000",






      "state" : "SA",






      "country" : "Australia"






    }






  }






}






 






If you're proposing one mechanism for composite at=
tributes and another mechanism for simple attributes, I would suggest that's=
 actually more complex than adopting
 a single mechanism that works the same way for _all_ attributes. Remember t=
hat a lot of the administration is probably going to be scripted rather than=
 done by hand, and having two mechanisms (depending on whether the attribute=
 is simple or composite) will
 complicate every script that has to be written.








 






There's a lot of talk about the "burden" on the SP=
s, but I believe this is overblown. Is there any SP representative in this W=
G who can tell us what this proposal
 will actually entail for them?






 






Regards,






Ganesh




 




On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sail=
point.com> wrote:








Ganesh,






 






This is exactly how PATCH works in SCIM 1.0. &=
nbsp;Multi-valued attributes that have a value sub-attribute
 can be removed by specifying only the value since it is unique.  Multi=
-valued attributes that don't have a value sub-attribute (eg - address) have=
 to specified completely for uniqueness.  As I have said before, I am v=
ery opposed to adding a unique identifier
 to each element in a multi-valued collection due to the burden it will put o=
n SPs.  Is it elegant?  No.  Is it functional?  Yes. &nb=
sp;Will this non-elegance affect adoption?  My opinion is that adding u=
nique keys to each element will have a much more detrimental
 effect on adoption.






 






I do believe that in general PATCH can be mad=
e more intuitive without adding uids to each element.  The
 verbs that you propose make sense.  There is also a JSON Patch informa=
tional draft in the IETF that is interesting - http://too=
ls.ietf.org/html/draft-ietf-appsawg-json-patch-02.
  It relies on a JSON Pointer draft which uses index-based addressing f=
or multi-valued attributes.  I think that this is something that should=
 be looked at within the WG and I would be willing to lead this effort.






 






I'm curious if anyone else in the WG is in fa=
vor of unique identifiers for every multi-valued element.<=
/p>





 






--Kelly




 












From:
scim-bounces@ietf=
.org [scim-bo=
unces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]

Sent: Saturday, August 11, 2012 10:50 AM

To: Phil Hunt

Cc: scim@ietf.org<=
/a>

Subject: Re: [scim] scim Digest, Vol 8, Issue 24









Phil,





 






The reason we cannot use the value itself to ident=
ify an element is that this method will only work for simple elements, not f=
or nested structures. i.e., if we had
 an array of dictionaries (e.g., we had to record an array of addresses for e=
ach customer, with each address element having sub-elements like street numb=
er, street name, suburb, etc.), then it would be clumsy to supply the entire=
 value of the array element
 because it's itself a dictionary. Creating a unique key for each element sc=
ales better.






 






Regards,






Ganesh




On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> w=
rote:




Ganesh,





 






Here's the sample that concerned me...=













The two operations differ significantly, and it's n=
ot very intuitive. 






With my suggestion, here's how to delete a single m=
ember from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: ap=
plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=







"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-413861904646"






}






}






] }











 








 








You gave other examples of an attribute with an identifier that m=
atched that value or of identifiers that were
 additional unique keys.






 






Given that multi-values must be each unique, I don't see the poi=
nt of the extra indexing to support this. Just
 use the value as the item you wish to delete.






 






I agree, the delete value operation could be more explicit and c=
lear in general.






 









 




 








 






On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad=
 wrote:




 


>  For the multi-value example you gave yo=
u used the value as the attribute name key. 





 






Now I'm confused :-). I don't believe any of my ex=
amples ever used a value as the key.






 






Could you please show me which example you mean, a=
nd which parts of it you believe to be the value?






 






Regards,






Ganesh 




On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> w=
rote:








For the multi-value example you gave you used the value as the attribute nam=
e key. 






 






That means a lot more complex indexing structure. B=
etter to just say delete a specific value. 






 






The spec already allows multiple values to have ta=
gs like home, work, etc.






 





Phil
=












On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
















> In your example you are conflating value=
 with an attribute id. 



I don't believe so. 




 






I'm adopting a model where every attribute of the r=
esource is a key-value pair. The key is a name or ID.






 






For non-repeating attributes (both simple and comp=
osite), the key is the attribute name itself. 






 








Simple attribute:






 






Key: "dob"






Value: "01 Jan 1970"






 








For composite attributes, the key employs dot nota=
tion to specify the fully-qualified attribute name, e.g., "address.postcode"=
.






 






Composite attribute:






 






Key: "address.street-number"
=






Value: "10"






 






Key: "address.suburb"






Value: "East Camden"






 






For repeating (multi-valued) attributes, I'm sugge=
sting that there be new keys for each individual value, otherwise they are i=
mpossible to distinguish, and a positional
 index is inadequate. So we convert the array into a dictionary and this the=
n becomes a composite attribute using dot notation for the key.<=
/o:p>






 






Multi-valued attribute:






 






Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"=








 






So this allows us to apply uniform treatment to an=
y arbitrarily deep resource structure. We can refer to every leaf value with=
 a key that is the fully-qualified
 name using dot notation.






 






The verbs are just unambiguous operations on these=
 (now) explicitly addressable attributes.






 






INCLUDE to a collection and specify only the value=
. The key is generated and returned. The fully-qualified key is <collecti=
on-name>.<newly-generated-ID> and the
 value is what was specified in the INCLUDE.






 






REPLACE a fully-qualified key with a new value. If=
 the key doesn't exist, return a "404 Not Found".






 






PLACE a value at the logical location implied by t=
he fully-qualified key. If there is already a key with that name, return a "=
409 Conflict".






 






FORCE the fully-qualified key to hold the given va=
lue, regardless of whether it existed before or not. Only errors possible ar=
e "400 Bad Request" and "500 Internal
 Error".






 






RETIRE an attribute or a collection given its full=
y-qualified key. The implementation will determine whether the attribute wil=
l disappear entirely or will exist
 holding a null value (the blank string "" or the empty object {} ).<=
o:p>






 






I'll explain in a separate post why we need operat=
ion verbs like these that are independent of the HTTP verbs.






 






Regards,






Ganesh






 




On 11 August 2012 10:38, <scim-request@ietf.org> wrote:


If you have received this digest without all the i=
ndividual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



htt=
ps://www.ietf.org/mailman/listinfo/scim



Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.







Send scim mailing list submissions to

        scim@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

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

or, via email, send a message with subject or body 'help' to

        scim-request@ietf.org



You can reach the person managing the list at

        scim-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of scim digest..."



Today's Topics:



   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt=
)





---------- Forwarded message ----------

From: Phil Hunt <phil.hunt@oracle.com>

To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>

Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <edreux@cloudiway.com>=
, Trey Drake <trey.drake@unboundid.com>,
 Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>

Date: Fri, 10 Aug 2012 17:36:54 -0700

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








Ganesh,






 






In your example you are conflating value with an a=
ttribute id. I find that confusing. 






 






I agree though that operations in patch could be a=
 lot more explicit. 






 






Eg explicitly deleting a value by saying delete or=
 retire. 








Phil








On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








 >  I am concerned about your second suggestion: 





 






Let's discuss that now.






 






The trade-offs are very clear here.






 






Pros:






 






Pro 1. The API to manipulate resources becomes so m=
uch cleaner, consistent and intuitive when every individual attribute value g=
ets its own ID.






 






Here's how to delete a single member from a Group,=
 as per the current spec:






 






   PATCH /Groups=
/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com=



   Accept: appli=
cation/json


   Authorization=
: Bearer h480djs93hd8


   ETag: W/"a330=
bc54f0671c9"


 

   {=



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


     "=
members": [


    &n=
bsp;  {


    &n=
bsp;    "display": "Babs Jensen",


    &n=
bsp;    "value": "2819c223-7f76-453a-919d-413861904646"


    &n=
bsp;    "operation": "delete"


    &n=
bsp;  }


     ]=



   }=





Here's how to delete ALL members from a group according to the current spec:=







 






   PATCH /Groups=
/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com=



   Accept: appli=
cation/json


   Authorization=
: Bearer h480djs93hd8


   ETag: W/"a330=
bc54f0671c9"


 

   {=



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


     "=
meta": {


    &n=
bsp;  "attributes": [


    &n=
bsp;    "members"


    &n=
bsp;  ]


     }=



   }=





The two operations differ significantly, and it's not very intuitive. <=
/span>






With my suggestion, here's how to delete a single m=
ember from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: ap=
plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=







"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-413861904646"






}






}






] }


Here's how I suggest deleting ALL members from a group:





 








PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: ap=
plication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" {=







"operations" : [






{






"RETIRE" : {






"key" : "members"






}






}






] }







I'm sure you'll agree that this is simpler, more consistent and more intuiti=
ve to a reader.






 






Pro 2: We can apply this mechanism consistently to=
 three areas:






(a) Manipulating multi-valued attributes of a reso=
urce






(b) Manipulating members of a group






(c) Performing bulk operations, where we simply us=
e HTTP verbs instead of the specialised (and semantically less ambiguous) ve=
rbs I suggested for attributes, the
 "key" becomes the URI, and the "value" becomes the corresponding JSON objec=
t.






 






All of them return "207 Multi-Status" with the "re=
sults" array holding individual status codes.






 






In the current spec, (a) and (b) are done similarl=
y but (c) is very different.






 






Pro 3: Adoption of the standard by clients is like=
ly to be higher because it's simpler for them.






 






Pro 4: New (not incumbent) cloud providers will pr=
obably find this easier to implement because they have no legacy. They will p=
robably use some form of NoSQL database
 and won't be constrained by the limitations of LDAP directories.






 






Cons:






 






Con 1: Incumbent cloud providers with existing dat=
a stores in a directory format (where multi-valued attributes are stored as c=
omma-separated values under a single
 attribute node) will find it difficult to migrate to this model and store e=
ach attribute value as a sub-node with its own key. This will "hinder adopti=
on of the spec", which is what you fear.






 






Have I summed up the Pros and Cons correctly? I'm b=
iased of course, so I could have missed a Con or hyped a Pro :-).




 




In other words, we're debating interface complexit=
y (current spec) versus implementation complexity (my suggestion). Both can h=
inder adoption of the spec by different
 parties.






 






Here's what we need to discuss - Do the Pros make t=
he suggestio
















































































 










 

 

____________________= ___________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman= /listinfo/scim
= --Apple-Mail-771690FD-1A57-4A8D-B1E7-0BD429BFF746-- From Chris.Phillips@canarie.ca Mon Aug 13 10:45:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049AB21F8717 for ; Mon, 13 Aug 2012 10:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, NO_RELAYS=-0.001, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrZZ3NinwN5c for ; Mon, 13 Aug 2012 10:45:08 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 627A021F8714 for ; Mon, 13 Aug 2012 10:45:07 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Mon, 13 Aug 2012 13:45:06 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Mon, 13 Aug 2012 13:45:02 -0400 Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: Ac15e1+NSxm2KIE0Tb6E8knoWR9Zyg== Message-ID: In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC4E982CBA4A5chrisphillipscanarieca_" MIME-Version: 1.0 Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:45:21 -0000 --_000_CC4E982CBA4A5chrisphillipscanarieca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S2VsbHkgRydzIGNvbW1lbnRzIGJlc3QgbWF0Y2ggbXkgb3BpbmlvbiBhcyB3ZWxsICAtLUkgdG9v IGRpc2FncmVlIHdpdGggdGhlIHByb3Bvc2VkIGNoYW5nZXMgYnkgR2FuZXNoIGFzIHRoZXkgYWRk IHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkuDQoNClRoZSBleGFtcGxlIGJlbG93IGJyZWFrcyBwcmFj dGljYWxseSBhbnkgTERBUCBkaXJlY3RvcnkgYmFja2luZyBhIG1haWxzdG9yZSBhbmQgd291bGQg Zm9yY2UgYW4gaW1wbGVtZW50b3Igb2YgU0NJTSB0byBnaG9zdCB0aGVpciBkYXRhIHNvbWVob3cg dG8gc3VwcG9ydCB0aGUgY2hhbmdlcyBHYW5lc2ggcHJvcG9zZXMuIFNvbWV0aGluZyB0aGF0IGNl cnRhaW5seSB3b3VsZCBtYWtlIHBlb3BsZSBhdm9pZCB1c2luZyBTQ0lNIGF0IGFsbC4NCg0KR2l2 ZW4gdGhhdCB5b3UgaGF2ZSBhIG51bWJlciBvZiB0aG91Z2h0cyBhYm91dCB3aGF0IGNvdWxkIGJl IGNoYW5nZWQgaW4gU0NJTSxMZWlmJ3MgcmVjb21tZW5kYXRpb24gdG8gIGNyYWZ0IHRoZW0gaW4g YW4gSW50ZXJuZXQgRHJhZnQgbWF5IGJlIGEgYmV0dGVyIHdheSB0byBjb252ZXkgeW91ciB0aG91 Z2h0cy4NCg0KQ2hyaXMuDQoNCg0KDQoNCkZyb206IEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4NCkRh dGU6IE1vbmRheSwgMTMgQXVndXN0LCAyMDEyIDEwOjI3IEFNDQpUbzogR2FuZXNoIGFuZCBTYXNo aSBQcmFzYWQgPGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNv bT4+LCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbT4+LCBNZWxpbmRhIFNob3JlIDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbTxtYWlsdG86 bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+Pg0KQ2M6ICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2lt QGlldGYub3JnPiIgPHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+PiwgRW1tYW51 ZWwgRHJldXggPGVkcmV1eEBjbG91ZGl3YXkuY29tPG1haWx0bzplZHJldXhAY2xvdWRpd2F5LmNv bT4+DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwgSXNzdWUgMjQNCg0K PiBBZnRlciBhbGwsIG5vIG9uZSBoYXMgY2hhbGxlbmdlZCB0aGUgY2xhaW0gdGhhdCB0aGlzIHBy b3Bvc2FsIGRyYXN0aWNhbGx5IHNpbXBsaWZpZXMgdGhlIEFQSSBmb3IgdGhlIGNsaWVudA0KDQpJ IGFncmVlIHRoYXQgeW91ciBwcm9wb3NhbCBtYWtlcyBQQVRDSCBzZW1hbnRpY3Mgc2ltcGxlciBh bmQgbW9yZSBlbGVnYW50Lg0KDQoNCj4g4oCmIHNvIGl0IHdvdWxkIGFwcGVhciB0byBiZSB3b3J0 aCBkb2luZy4NCg0KSSBzdHJvbmdseSBkaXNhZ3JlZSBoZXJlLiAgVGhpcyBzdGF0ZW1lbnRzIGFz c3VtZXMgdGhhdCBzaW1wbGljaXR5IG9mIHRoZSBjbGllbnQgQVBJIGlzIHRoZSBvbmx5IGZhY3Rv ciB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHdpdGggdGhlIHNwZWMuDQoNCkVtbWFudWVs4oCZ cyBleGFtcGxlIGlzIGZyb20gYSByZWFsLXdvcmxkIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCB3b3Vs ZCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlIHNwZWMgZWFzaWx5IHdpdGggYSB1aWQgcGVy IGVsZW1lbnQuICBIZSBpcyB3b3JraW5nIG9uIGEgU0NJTSBpbnRlcmZhY2UgdGhhdCB3aWxsIGhl bHAgZmFjaWxpdGF0ZSBkYXRhIGV4Y2hhbmdlIGJldHdlZW4gbXVsdGlwbGUgQWN0aXZlIERpcmVj dG9yeSBzZXJ2ZXJzLiAgWW91ciBzb2x1dGlvbiB3YXMgdG8gY2hhbmdlIHRoZSBkYXRhIG1vZGVs IGZyb20gdGhpczoNCg0KDQptYWlsOiBqb2huX3NtaXRoQHlhaG9vLmNvbTxtYWlsdG86am9obl9z bWl0aEB5YWhvby5jb20+LCBqb2huLnNtaXRoQGdtYWlsLmNvbTxtYWlsdG86am9obi5zbWl0aEBn bWFpbC5jb20+LCBqc21pdGgxOTcwQGhvdG1haWwuY29tPG1haWx0bzpqc21pdGgxOTcwQGhvdG1h aWwuY29tPg0KDQp0byB0aGlzOg0KDQptYWlsOiBhYTY2LWRhZjllYTNiZDkwMj1qb2huX3NtaXRo QHlhaG9vLmNvbTxtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20+LDljZGEtODY0NmMzMDg1YmJm PWpvaG4uc21pdGhAZ21haWwuY29tPG1haWx0bzpqb2huLnNtaXRoQGdtYWlsLmNvbT4sIDdhNmQx ZGU2NjRlMT1qc21pdGgxOTcwQGhvdG1haWwuY29tPG1haWx0bzpqc21pdGgxOTcwQGhvdG1haWwu Y29tPg0KDQpJIGRvIG5vdCBrbm93IG9mIGEgc2luZ2xlIG9yZ2FuaXphdGlvbiB0aGF0IHdvdWxk IGNoYW5nZSB0aGVpciBBY3RpdmUgRGlyZWN0b3J5IGRhdGEgbW9kZWwgdG8gZml0IHRoaXMuICBG b3Igb25lIHRoaW5nLCBpdCB3b3VsZCBiZSBhIGh1Z2UgZGF0YSBtaWdyYXRpb24gZWZmb3J0IChs aWtlbHkgYWNyb3NzIG90aGVyIGRvbWFpbiBjb250cm9sbGVycywgZXRj4oCmKSB0byBhc3NpZ24g dGhlc2UgdW5pcXVlIGlkZW50aWZpZXJzLiAgVGhpcyBhbHNvIGFzc3VtZXMgdGhhdCBTQ0lNIGlz IHRoZSBvbmx5IHJlYWRlci93cml0ZXIgb2YgdGhpcyBkYXRhLCB3aGljaCB3aWxsIGFsbW9zdCBu ZXZlciBiZSB0aGUgY2FzZS4gIElmIHRoZSBkYXRhIG1vZGVsIHJlcXVpcmVzIHVpZHMgZm9yIGV2 ZXJ5IGVsZW1lbnQsIHRoZW4gZXZlcnkgcGllY2Ugb2Ygbm9uLVNDSU0gY29kZSB0aGF0IHdyaXRl cyBkYXRhIGludG8gdGhlIGRpcmVjdG9yeSB3aWxsIGhhdmUgdG8gZm9sbG93IHRoaXMuICBBZGRp dGlvbmFsbHksIHRoZXJlIGFyZSAqbWFueSogdG9vbHMgYW5kIGFwcGxpY2F0aW9ucyAgKGVnIOKA kyBhZGRyZXNzIGJvb2tzKSB0aGF0IHJlbHkgb24gYSBjZXJ0YWluIGRhdGEgbW9kZWwgaW4gQWN0 aXZlIERpcmVjdG9yeSwgYW5kIHRoaXMgd291bGQgY2F1c2UgdGhlbSB0byBicmVhay4gIElNTyB0 aGlzIHNhbWUgYXJndW1lbnQgaG9sZHMgdHJ1ZSBmb3IgbW9zdCBzZXJ2aWNlIHByb3ZpZGVycy4N Cg0KDQpQQVRDSCBpcyBhbiBvcHRpb25hbCBwYXJ0IG9mIHRoZSBzcGVjLiAgSXQgd2FzIHByaW1h cmlseSBpbnRyb2R1Y2VkIHRvIG1ha2UgbW9kaWZ5aW5nIHJlc291cmNlcyB3aXRoIGxhcmdlIG11 bHRpLXZhbHVlZCBsaXN0cyBtb3JlIGVmZmljaWVudC4gIEl0IGRvZXMgbm90IG5lZWQgdG8gc29s dmUgZXZlcnkgcHJvYmxlbSAoZWcg4oCTIG1vZGlmeWluZyBzdWItZWxlbWVudHMgaW4gbmVzdGVk IGFycmF5cykuICBBZGRpbmcgdWlkcyB0byBldmVyeSBtdWx0aS12YWx1ZWQgZWxlbWVudCBkb2Vz IG5vdCBzdHJpa2UgdGhlIHJpZ2h0IGJhbGFuY2UgYmV0d2VlbiB0aGUgbmVlZHMgb2YgdGhlIGNs aWVudCBhbmQgdGhlIG5lZWRzIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyLg0KDQotLUtlbGx5DQoN CkZyb206IEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIFttYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5j b21dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAxOjM1IEFNDQpUbzogUGhpbCBIdW50 OyBNZWxpbmRhIFNob3JlDQpDYzogRW1tYW51ZWwgRHJldXg7IEtlbGx5IEdyaXp6bGU7IHNjaW1A aWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0g RGlnZXN0LCBWb2wgOCwgSXNzdWUgMjQNCg0KUmVzcG9uZGluZyB0byBleHRyYWN0IG9mIE1lbGlu ZGEgU2hvcmUncyBtYWlsIGZyb20gZGlnZXN0Og0KDQoNClRoZSBpc3N1ZSBiZWluZyByYWlzZWQg aGVyZSBpc24ndCBlbmRwb2ludCBsb2dpYywgYnV0DQoNCm5ldHdvcmsgdHJhZmZpYywgYW5kIEkn bSBwcmV0dHkgc3VyZSBpdCdzIG5vdCB2ZXJ5IGhlbHBmdWwgdG8NCg0KcmVzcG9uZCB0byB0aGUg b2JzZXJ2YXRpb24gdGhhdCB5b3VyIG1vZGVsIHJlcXVpcmVzIG1vcmUNCg0KbWVzc2FnZXMgd2l0 aCBhIGNvbXBsYWludCBhYm91dCB3aGF0IHlvdSBzZWVtIHRvIHRoaW5rIGlzIGENCg0KY29tcGxl eCBhbGdvcml0aG0gZm9yIGF0dHJpYnV0ZSBwcm9jZXNzaW5nLg0KDQpJdCBkZXBlbmRzIG9uIGhv dyBpdCdzIGltcGxlbWVudGVkLiBJJ20gY29uZmlkZW50IHdlIGNhbiBoYXZlIHRoZSBiZXN0IG9m IGJvdGggLSBzaW1wbGUgQVBJIHdpdGggbG93LW92ZXJoZWFkIGltcGxlbWVudGF0aW9uLiBDYW4g d2UgYnJhaW5zdG9ybSBIT1cgdGhpcyBwcm9wb3NhbCBjYW4gYmUgaW1wbGVtZW50ZWQgcmF0aGVy IHRoYW4gV0hZIGl0IGNhbid0IGJlIGltcGxlbWVudGVkICh3aGljaCBpcyBtb3N0bHkgd2hhdCBJ J3ZlIGJlZW4gaGVhcmluZyBzbyBmYXIpPyBBZnRlciBhbGwsIG5vIG9uZSBoYXMgY2hhbGxlbmdl ZCB0aGUgY2xhaW0gdGhhdCB0aGlzIHByb3Bvc2FsIGRyYXN0aWNhbGx5IHNpbXBsaWZpZXMgdGhl IEFQSSBmb3IgdGhlIGNsaWVudCwgc28gaXQgd291bGQgYXBwZWFyIHRvIGJlIHdvcnRoIGRvaW5n LiBJJ20gc3VyZSB0aGVyZSdzIG1vcmUgdGhhbiBlbm91Z2ggaW50ZWxsZWN0dWFsIGhvcnNlcG93 ZXIgaW4gdGhpcyB3b3JraW5nIGdyb3VwIHRvIHB1bGwgdGhpcyBvZmYgaWYgd2UgcHV0IG91ciBt aW5kcyB0byBpdC4NCg0KUmVnYXJkcywNCkdhbmVzaA0KDQpPbiAxMyBBdWd1c3QgMjAxMiAxMzo1 NCwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgPGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpn LmMucHJhc2FkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBJIHN0cm9uZ2x5IG9iamVjdCB0byBhbnl0 aGluZyB0aGF0IGxlYWRzIHRvIGEgcmVhZCBiZWZvcmUgbW9kaWZ5IHJlcXVpcmVtZW50LiBUb28g Y29tcGxleCBhbmQgdG9vIGNoYXR0eS4NClNvcnJ5IFBoaWwsIGJ1dCB5b3UncmUgY29udHJhZGlj dGluZyB5b3Vyc2VsZiBoZXJlLiBUaGVyZSBzZWVtcyB0byBiZSBhbiBhd2Z1bCBsb3Qgb2YgbWF0 Y2hpbmcgKGkuZS4sIHJlYWRpbmcpIGdvaW5nIG9uIGluIHRoZSBzcGVjIGFzIGl0IHN0YW5kcywg d2l0aCBpZi10aGVuIGNsYXVzZXMgdG8gZG8gb25lIHRoaW5nIG9yIGFub3RoZXIgaWYgdGhlIG1h dGNoIGVpdGhlciBzdWNjZWVkcyBvciBmYWlscy4gVGhpcyBpcyBhIGNvbXBsZXgsIGNoYXR0eSBw cm90b2NvbCByaWdodCBub3chDQoNCg0KICAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXM6ICBBbiBh dHRyaWJ1dGUgdmFsdWUgaW4gdGhlIFBBVENIIHJlcXVlc3QNCg0KICAgICAgYm9keSBpcyBhZGRl ZCB0byB0aGUgdmFsdWUgY29sbGVjdGlvbiBpZiB0aGUgdmFsdWUgZG9lcyBub3QgZXhpc3QNCg0K ICAgICAgYW5kIG1lcmdlZCBpZiBhIG1hdGNoaW5nIHZhbHVlIGlzIHByZXNlbnQuICBWYWx1ZXMg YXJlIG1hdGNoZWQgYnkNCg0KICAgICAgY29tcGFyaW5nIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRl IGZyb20gdGhlIFBBVENIIHJlcXVlc3QgYm9keSB0bw0KDQogICAgICB0aGUgdmFsdWUgU3ViLUF0 dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuICBBdHRyaWJ1dGVzIHRoYXQgZG8gbm90DQoNCiAgICAg IGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlOyBlLmcuLCBhZGRyZXNzZXMsIG9yIGRvIG5vdCBo YXZlIHVuaXF1ZQ0KDQogICAgICB2YWx1ZSBTdWItQXR0cmlidXRlcyBjYW5ub3QgYmUgbWF0Y2hl ZCBhbmQgbXVzdCBpbnN0ZWFkIGJlIGRlbGV0ZWQNCg0KICAgICAgdGhlbiBhZGRlZC4gIFNwZWNp ZmljIHZhbHVlcyBjYW4gYmUgcmVtb3ZlZCBmcm9tIGEgUmVzb3VyY2UgYnkNCg0KICAgICAgYWRk aW5nIGFuICJvcGVyYXRpb24iIFN1Yi1BdHRyaWJ1dGUgd2l0aCB0aGUgdmFsdWUgImRlbGV0ZSIg dG8gdGhlDQoNCiAgICAgIGF0dHJpYnV0ZSBpbiB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5LiAgQXMg d2l0aCBhZGRpbmcvdXBkYXRpbmcNCg0KICAgICAgYXR0cmlidXRlIHZhbHVlIGNvbGxlY3Rpb25z LCB0aGUgdmFsdWUgdG8gZGVsZXRlIGlzIGRldGVybWluZWQgYnkNCg0KICAgICAgY29tcGFyaW5n IHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIGZyb20gdGhlIFBBVENIIHJlcXVlc3QgYm9keSB0bw0K DQogICAgICB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuICBBdHRyaWJ1 dGVzIHRoYXQgZG8gbm90DQoNCiAgICAgIGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlIG9yIHRo YXQgaGF2ZSBhIG5vbi11bmlxdWUgdmFsdWUgU3ViLQ0KDQogICAgICBBdHRyaWJ1dGUgYXJlIG1h dGNoZWQgYnkgY29tcGFyaW5nIGFsbCBTdWItQXR0cmlidXRlIHZhbHVlcyBmcm9tDQoNCiAgICAg IHRoZSBQQVRDSCByZXF1ZXN0IGJvZHkgdG8gdGhlIFN1Yi1BdHRyaWJ1dGUgdmFsdWVzIG9mIHRo ZQ0KDQogICAgICBSZXNvdXJjZS4gIEEgZGVsZXRlIG9wZXJhdGlvbiBpcyBpZ25vcmVkIGlmIHRo ZSBhdHRyaWJ1dGUncyBuYW1lDQoNCiAgICAgIGlzIGluIHRoZSBtZXRhLmF0dHJpYnV0ZXMgbGlz dC4gIElmIHRoZSByZXF1ZXN0ZWQgdmFsdWUgdG8gZGVsZXRlDQoNCiAgICAgIGRvZXMgbm90IG1h dGNoIGEgdW5pcXVlIHZhbHVlIG9uIHRoZSBSZXNvdXJjZSB0aGUgc2VydmVyIE1BWQ0KDQogICAg ICByZXR1cm4gYSBIVFRQIDQwMCBlcnJvci4NCg0KRm9yIGEgc3BlYyB0aGF0IGlzIHN1cHBvc2Vk IHRvIGJlIGFib3V0IHNpbXBsaWNpdHksIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiBpcyBhbnl0aGlu ZyBidXQgc2ltcGxlLiBJIGtub3cgeW91IGd1eXMgaGF2ZSB3b3JrZWQgaGFyZCBvbiB0aGlzIGFu ZCBJIGRvbid0IG1lYW4gdG8gZGlzcGFyYWdlIHRob3NlIGVmZm9ydHMsIGJ1dCB0aGluayBhYm91 dCBob3cgdGhlIGFib3ZlIHBhc3NhZ2Ugd291bGQgYXBwZWFyIHRvIGEgbmV3IHJlYWRlciAoaS5l LiwgYSBub3ZpY2UgdG8gdGhlIHNwZWMsIG5vdCBhIHRlY2hub2xvZ3kgbm92aWNlKS4NCg0KVGhl cmUgaXMgc29tZXRoaW5nIGZ1bmRhbWVudGFsbHkgYnJva2VuLCBhbmQgaXQgaXMgdGhpczogbXVs dGktdmFsdWVkIGF0dHJpYnV0ZXMgd2l0aG91dCBhIHVuaXF1ZSBpZGVudGlmaWVyIHBlciB2YWx1 ZS4gSWYgeW91IGRvbid0IGZpeCB0aGF0LCB5b3Ugd29uJ3QgZ2V0IHNpbXBsaWNpdHkuDQoNCldl IGtub3cgTERBUCB0cmVlcyBhcmUgYnJva2VuIGZvciBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcy4g QXMgTWFyayBXYWhsIGZhbW91c2x5IGNvbW1lbnRlZDxodHRwOi8vd3d3LmxkYXAuY29tLzEvY29t bWVudGFyeS93YWhsLzIwMDUwNjE3XzAxLnNodG1sPiBiYWNrIGluIDIwMDUsDQoNCiJVbmZvcnR1 bmF0ZWx5LCBzb21lIG9mIHRoZSBlbWVyZ2luZyBwcm90b2NvbHMgd2hpY2ggYWxzbyBpbnRlbmQg dG8gcmVwcmVzZW50IGFuZCB0cmFuc2ZlciBwZXJzb25hbCBpZGVudGl0eSBpbmZvcm1hdGlvbiBo YXZlIHBlcmhhcHMgdGFrZW4gYSBzdGVwIGJhY2t3YXJkcyBieSBub3QgZXZlbiBjb25zaWRlcmlu ZyB0aGVzZSBpc3N1ZXMsIHBlcmhhcHMgc3dlZXBpbmcgdGhlbSB1bmRlciB0aGUgcnVnIGluIHRo ZSBndWlzZSBvZiBzaW1wbGljaXR5LCBYTUxpZmljYXRpb24sIG9yICJmaXggaW4gdGhlIG5leHQg dmVyc2lvbiIsIHdoaWNoIG9ubHkgcG9zdHBvbmUgZmluZGluZyBpbnRlcm9wZXJhYmxlIHNvbHV0 aW9ucyB0byBhbGxvd2luZyBhcHBsaWNhdGlvbnMgdG8gZXhwcmVzcyB0aGUgaWRlbnRpdHkgZW50 cmllcyB0aGV5IHdhbnQgdG8gZXhwcmVzcy4iDQoNClNDSU0gaXMgZXhhY3RseSBvbmUgb2YgdGhl c2UgImVtZXJnaW5nIHByb3RvY29scyIgV2FobCB0YWxrcyBhYm91dCwgYW5kIHdoYXQgSSBzZWUg bm93IHN0cmlrZXMgbWUgYXMgInN3ZWVwaW5nIHRoZXNlIGlzc3VlcyB1bmRlciB0aGUgcnVnIGlu IHRoZSBndWlzZSBvZiBzaW1wbGljaXR5Ii4gQXBvbG9naWVzIGZvciB0aGUgYmx1bnRuZXNzLg0K DQpNeSB0YWtlIGlzIHRoYXQgU1BzIGFyZSBfYWxyZWFkeV8gc3RydWdnbGluZyB0byBtYW5hZ2Ug bXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMsIGFuZCBleGlzdGluZyBtZWNoYW5pc21zIGFyZSBjbHVt c3k8aHR0cDovL2ZmMTk1OS53b3JkcHJlc3MuY29tLzIwMTEvMDcvMjgvcmVwbGFjZS1hLXZhbHVl LW9mLWEtbXVsdGktdmFsdWVkLWF0dHJpYnV0ZS8+LiBUaGV5IHdvdWxkIGJlIGdyYXRlZnVsIGZv ciBhIHNwZWNpZmljYXRpb24gdGhhdCBtYWRlIG9wZXJhdGlvbnMgZWFzaWVyIGF0IHRoZSBjb3N0 IG9mIGEgcmUtZW5naW5lZXJlZCBzY2hlbWEuIFRoYXQgY2FsbHMgZm9yIHNvbWUgdGhvdWdodCBs ZWFkZXJzaGlwIGZyb20gdGhpcyB3b3JraW5nIGdyb3VwLg0KDQpSZWdhcmRzLA0KR2FuZXNoDQoN Ck9uIDEzIEF1Z3VzdCAyMDEyIDEwOjEzLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29t PG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KSSBzdHJvbmdseSBvYmplY3Qg dG8gYW55dGhpbmcgdGhhdCBsZWFkcyB0byBhIHJlYWQgYmVmb3JlIG1vZGlmeSByZXF1aXJlbWVu dC4gVG9vIGNvbXBsZXggYW5kIHRvbyBjaGF0dHkuDQoNClBoaWwNCg0KT24gMjAxMi0wOC0xMiwg YXQgMTU6MjksIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIDxnLmMucHJhc2FkQGdtYWlsLmNvbTxt YWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+PiB3cm90ZToNCj4gV291bGQgaXQgaGF2ZSB0byBi ZSBzdG9yZWQgb24gdGhlIGFjY291bnQgZGF0YWJhc2Ugb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXI/ DQoNClllcy4NCg0KPiBJZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbXByYWN0aWNhYmxl IGluIHRoZSBjb3JlIHNjaGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhhdCBhIHNlcnZpY2UgcHJv dmlkZXIgbXVzdCBleHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCByZXBvc2l0b3J5IChM REFQIHBhcnRpdGlvbiwgU1FMIGRiLCDigKYpIGFuZCDigJxwcmVwYXJlIGl04oCdIGZvciBTQ0lN IGludGVncmF0aW9uLg0KDQpXaHk/IFRoYXQgZG9lc24ndCBuZWNlc3NhcmlseSBmb2xsb3cuIElt cGxlbWVudGF0aW9uIGlzIGluZGVwZW5kZW50IG9mIHJlcHJlc2VudGF0aW9uLiBXZSdyZSB0YWxr aW5nIGFib3V0IGEgY2hhbmdlIGluIHJlcHJlc2VudGF0aW9uIHRvIG1ha2UgdGhlIEFQSSBjbGVh bmVyLg0KDQpBcyBhIHNpbXBsZSBleGFtcGxlLCBpZiBhbiBMREFQIG5vZGUgaXMgYmVpbmcgdXNl ZCB0byBob2xkIGEgbGlzdCBvZiBjb21tYS1zZXBhcmF0ZWQgZW1haWwgYWRkcmVzc2VzLCBpdCBj YW4ganVzdCBhcyBlYXNpbHkgc3RvcmUgY29tbWEtc2VwYXJhdGVkIG5hbWUtdmFsdWUgcGFpcnMu DQoNCg0KbWFpbDogam9obl9zbWl0aEB5YWhvby5jb208bWFpbHRvOmpvaG5fc21pdGhAeWFob28u Y29tPiwgam9obi5zbWl0aEBnbWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tPiwg anNtaXRoMTk3MEBob3RtYWlsLmNvbTxtYWlsdG86anNtaXRoMTk3MEBob3RtYWlsLmNvbT4NCmNh biBiZSBjaGFuZ2VkIHRvDQoNCm1haWw6IGFhNjYtZGFmOWVhM2JkOTAyPWpvaG5fc21pdGhAeWFo b28uY29tPG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sOWNkYS04NjQ2YzMwODViYmY9am9o bi5zbWl0aEBnbWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tPiwgN2E2ZDFkZTY2 NGUxPWpzbWl0aDE5NzBAaG90bWFpbC5jb208bWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20+ DQoNClRoYXQncyB3aHkgSSBhc2tlZCBpZiB0aGVyZSB3YXMgYW4gU1AgcmVwcmVzZW50YXRpdmUg b24gdGhpcyB3b3JraW5nIGdyb3VwIHdobyBjb3VsZCBleHBsYWluIHdoYXQgc3VjaCBhIGNoYW5n ZSBjb3VsZCBtZWFuIGZvciB0aGVtLiBBcyBvZiBub3csIGl0IGxvb2tzIGxpa2Ugb3RoZXIgcGVv cGxlIGFyZSBwcmVzdW1pbmcgdGhhdCBTUHMgd2lsbCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQg dGhlc2UgY2hhbmdlcyBlYXNpbHkgYW5kIGFyZSByZWplY3RpbmcgdGhlbSBmb3IgdGhhdCByZWFz b24uDQoNClJlZ2FyZHMsDQpHYW5lc2gNCg0KT24gMTMgQXVndXN0IDIwMTIgMDQ6MjksIEVtbWFu dWVsIERyZXV4IDxlZHJldXhAY2xvdWRpd2F5LmNvbTxtYWlsdG86ZWRyZXV4QGNsb3VkaXdheS5j b20+PiB3cm90ZToNCg0KPT4gIGFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9 ICIyNDMiDQoNCldoZXJlIHdvdWxkIDNjYmFhZmY4ZTg0ZSBjb21lIGZyb20/IFdvdWxkIGl0IGhh dmUgdG8gYmUgc3RvcmVkIG9uIHRoZSBhY2NvdW50IGRhdGFiYXNlIG9mIHRoZSBzZXJ2aWNlIHBy b3ZpZGVyPw0KDQpJZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbXByYWN0aWNhYmxlIGlu IHRoZSBjb3JlIHNjaGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhhdCBhIHNlcnZpY2UgcHJvdmlk ZXIgbXVzdCBleHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCByZXBvc2l0b3J5IChMREFQ IHBhcnRpdGlvbiwgU1FMIGRiLCDigKYpIGFuZCDigJxwcmVwYXJlIGl04oCdIGZvciBTQ0lNIGlu dGVncmF0aW9uLg0KVGhpcyB3b3VsZCBiZSBhIHNob3cgc3RvcHBlci4gU0NJTSBtdXN0IGJlIHRy YW5zcGFyZW50LCBhbmQgbXVzdCBiZSBhYmxlIHRvIGJlIHB1dCBvbiB0b3Agb2YgYW4gZXhpc3Rp bmcgc3lzdGVtIHRvIHByb3ZpZGUgcHJvdmlzaW9uaW5nIGFwaXMuDQoNClNhaWQgZGlmZmVyZW50 bHksIFNDSU0gbXVzdCBub3QgYmUgaW50cnVzaXZlIGZvciBleGlzdGluZyBzeXN0ZW1zIGFuZCBt dXN0IG5vdCByZXF1aXJlIG1vZGlmaWNhdGlvbnMgdG8gYWxsb3cgaXRzIGludGVncmF0aW9uLg0K Q29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBzdWdnZXN0aW9uLg0KDQotLQ0KUmVn YXJkcywNCkVtbWFudWVsIERyZXV4DQpodHRwOi8vd3d3LmNsb3VkaXdheS5jb20NClRlbDogKzMz IDQgMjYgNzggMTcgNTg8dGVsOiUyQjMzJTIwNCUyMDI2JTIwNzglMjAxNyUyMDU4Pg0KTW9iaWxl OiArMzMgNiA0NyA4MSAyNiA3MDx0ZWw6JTJCMzMlMjA2JTIwNDclMjA4MSUyMDI2JTIwNzA+DQpz a3lwZTogRW1tYW51ZWwuRHJldXgNCg0KRGUgOiBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCBbbWFp bHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbT5dDQpF bnZvecOpIDogZGltYW5jaGUgMTIgYW/Du3QgMjAxMiAwNDo1Mw0Kw4AgOiBLZWxseSBHcml6emxl DQpDYyA6IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+OyBQaGlsIEh1bnQNCk9i amV0IDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0DQoNCj4gIE11bHRp LXZhbHVlZCBhdHRyaWJ1dGVzIHRoYXQgZG9uJ3QgaGF2ZSBhIHZhbHVlIHN1Yi1hdHRyaWJ1dGUg KGVnIC0gYWRkcmVzcykgaGF2ZSB0byBzcGVjaWZpZWQgY29tcGxldGVseSBmb3IgdW5pcXVlbmVz cy4NCg0KVGhhdCdzIGV4YWN0bHkgdGhlIHBvaW50LiBIb3cgZG8gd2UgInNwZWNpZnkgY29tcGxl dGVseSBmb3IgdW5pcXVlbmVzcyI/DQoNCkluIHRoZSBleGFtcGxlIGJlbG93LCBob3cgYXJlIHlv dSBwcm9wb3NpbmcgdGhhdCB0aGUgZm9sbG93aW5nIGVsZW1lbnQgYmUgdXBkYXRlZCBpZiB3ZSBj YW4ndCB1c2UgcG9zaXRpb25hbCBpbmRleGVzPw0KDQphZGRyZXNzZXNbMV0uc3RyZWV0LW51bWJl ciA9ICIyNDMiDQoNClVzZXIgb2JqZWN0Og0KDQp7DQogIC4uLg0KICBhZGRyZXNzZXM6IFsNCiAg ICB7DQogICAgICAidHlwZSIgOiAiaG9tZSIsDQogICAgICAic3RyZWV0LW51bWJlciIgOiAiMzUi LA0KICAgICAgInN0cmVldC1uYW1lIiA6ICJIaWdoIFJvYWQiLA0KICAgICAgInN1YnVyYiIgOiAi RWFzdCBDYW1kZW4iLA0KICAgICAgInBvc3Rjb2RlIiA6ICI1MzQ2IiwNCiAgICAgICJzdGF0ZSIg OiAiU0EiLA0KICAgICAgImNvdW50cnkiIDogIkF1c3RyYWxpYSINCiAgICB9LA0KICAgIHsNCiAg ICAgICJ0eXBlIiA6ICJvZmZpY2UiLA0KICAgICAgInN0cmVldC1udW1iZXIiIDogIjIxMyIsDQog ICAgICAic3RyZWV0LW5hbWUiIDogIk1haW4gU3RyZWV0IiwNCiAgICAgICJzdWJ1cmIiIDogIkFk ZWxhaWRlIiwNCiAgICAgICJwb3N0Y29kZSIgOiAiNTAwMCIsDQogICAgICAic3RhdGUiIDogIlNB IiwNCiAgICAgICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiDQogICAgfQ0KICBdDQp9DQoNCkl0J3Mg aW1wcmFjdGljYWwgdG8gdXNlIHRoZSB2YWx1ZSBiZWNhdXNlIGl0J3MgdGhlIHdob2xlIGRpY3Rp b25hcnkgZWxlbWVudDoNCg0Kew0KICAidHlwZSIgOiAib2ZmaWNlIiwNCiAgInN0cmVldC1udW1i ZXIiIDogIjIxMyIsDQogICJzdHJlZXQtbmFtZSIgOiAiTWFpbiBTdHJlZXQiLA0KICAic3VidXJi IiA6ICJBZGVsYWlkZSIsDQogICJwb3N0Y29kZSIgOiAiNTAwMCIsDQogICJzdGF0ZSIgOiAiU0Ei LA0KICAiY291bnRyeSIgOiAiQXVzdHJhbGlhIg0KfQ0KDQpXaXRoIG15IHByb3Bvc2FsLCB0aGUg ImFkZHJlc3NlcyIgYXJyYXkgZ2V0cyBjb252ZXJ0ZWQgdG8gYSBkaWN0aW9uYXJ5LCBhbmQgdGhl biB3ZSBoYXZlIGEgc3RhYmxlIHdheSBvZiByZWZlcmVuY2luZyB0aGlzIGVsZW1lbnQ6DQoNCmFk ZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9ICIyNDMiDQoNCnsNCiAgLi4uDQog IGFkZHJlc3Nlczogew0KICAgICJkNmVhMzY1NDYyZjUiIDoNCiAgICB7DQogICAgICAidHlwZSIg OiAiaG9tZSIsDQogICAgICAic3RyZWV0LW51bWJlciIgOiAiMzUiLA0KICAgICAgInN0cmVldC1u YW1lIiA6ICJIaWdoIFJvYWQiLA0KICAgICAgInN1YnVyYiIgOiAiRWFzdCBDYW1kZW4iLA0KICAg ICAgInBvc3Rjb2RlIiA6ICI1MzQ2IiwNCiAgICAgICJzdGF0ZSIgOiAiU0EiLA0KICAgICAgImNv dW50cnkiIDogIkF1c3RyYWxpYSINCiAgICB9LA0KICAgICIzY2JhYWZmOGU4NGUiIDoNCiAgICB7 DQogICAgICAidHlwZSIgOiAib2ZmaWNlIiwNCiAgICAgICJzdHJlZXQtbnVtYmVyIiA6ICIyMTMi LA0KICAgICAgInN0cmVldC1uYW1lIiA6ICJNYWluIFN0cmVldCIsDQogICAgICAic3VidXJiIiA6 ICJBZGVsYWlkZSIsDQogICAgICAicG9zdGNvZGUiIDogIjUwMDAiLA0KICAgICAgInN0YXRlIiA6 ICJTQSIsDQogICAgICAiY291bnRyeSIgOiAiQXVzdHJhbGlhIg0KICAgIH0NCiAgfQ0KfQ0KDQpJ ZiB5b3UncmUgcHJvcG9zaW5nIG9uZSBtZWNoYW5pc20gZm9yIGNvbXBvc2l0ZSBhdHRyaWJ1dGVz IGFuZCBhbm90aGVyIG1lY2hhbmlzbSBmb3Igc2ltcGxlIGF0dHJpYnV0ZXMsIEkgd291bGQgc3Vn Z2VzdCB0aGF0J3MgYWN0dWFsbHkgbW9yZSBjb21wbGV4IHRoYW4gYWRvcHRpbmcgYSBzaW5nbGUg bWVjaGFuaXNtIHRoYXQgd29ya3MgdGhlIHNhbWUgd2F5IGZvciBfYWxsXyBhdHRyaWJ1dGVzLiBS ZW1lbWJlciB0aGF0IGEgbG90IG9mIHRoZSBhZG1pbmlzdHJhdGlvbiBpcyBwcm9iYWJseSBnb2lu ZyB0byBiZSBzY3JpcHRlZCByYXRoZXIgdGhhbiBkb25lIGJ5IGhhbmQsIGFuZCBoYXZpbmcgdHdv IG1lY2hhbmlzbXMgKGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSBhdHRyaWJ1dGUgaXMgc2ltcGxl IG9yIGNvbXBvc2l0ZSkgd2lsbCBjb21wbGljYXRlIGV2ZXJ5IHNjcmlwdCB0aGF0IGhhcyB0byBi ZSB3cml0dGVuLg0KDQpUaGVyZSdzIGEgbG90IG9mIHRhbGsgYWJvdXQgdGhlICJidXJkZW4iIG9u IHRoZSBTUHMsIGJ1dCBJIGJlbGlldmUgdGhpcyBpcyBvdmVyYmxvd24uIElzIHRoZXJlIGFueSBT UCByZXByZXNlbnRhdGl2ZSBpbiB0aGlzIFdHIHdobyBjYW4gdGVsbCB1cyB3aGF0IHRoaXMgcHJv cG9zYWwgd2lsbCBhY3R1YWxseSBlbnRhaWwgZm9yIHRoZW0/DQoNClJlZ2FyZHMsDQpHYW5lc2gN Cg0KT24gMTIgQXVndXN0IDIwMTIgMTE6NTMsIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVA c2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6 DQpHYW5lc2gsDQoNClRoaXMgaXMgZXhhY3RseSBob3cgUEFUQ0ggd29ya3MgaW4gU0NJTSAxLjAu ICBNdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB0aGF0IGhhdmUgYSB2YWx1ZSBzdWItYXR0cmlidXRl IGNhbiBiZSByZW1vdmVkIGJ5IHNwZWNpZnlpbmcgb25seSB0aGUgdmFsdWUgc2luY2UgaXQgaXMg dW5pcXVlLiAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBkb24ndCBoYXZlIGEgdmFsdWUg c3ViLWF0dHJpYnV0ZSAoZWcgLSBhZGRyZXNzKSBoYXZlIHRvIHNwZWNpZmllZCBjb21wbGV0ZWx5 IGZvciB1bmlxdWVuZXNzLiAgQXMgSSBoYXZlIHNhaWQgYmVmb3JlLCBJIGFtIHZlcnkgb3Bwb3Nl ZCB0byBhZGRpbmcgYSB1bmlxdWUgaWRlbnRpZmllciB0byBlYWNoIGVsZW1lbnQgaW4gYSBtdWx0 aS12YWx1ZWQgY29sbGVjdGlvbiBkdWUgdG8gdGhlIGJ1cmRlbiBpdCB3aWxsIHB1dCBvbiBTUHMu ICBJcyBpdCBlbGVnYW50PyAgTm8uICBJcyBpdCBmdW5jdGlvbmFsPyAgWWVzLiAgV2lsbCB0aGlz IG5vbi1lbGVnYW5jZSBhZmZlY3QgYWRvcHRpb24/ICBNeSBvcGluaW9uIGlzIHRoYXQgYWRkaW5n IHVuaXF1ZSBrZXlzIHRvIGVhY2ggZWxlbWVudCB3aWxsIGhhdmUgYSBtdWNoIG1vcmUgZGV0cmlt ZW50YWwgZWZmZWN0IG9uIGFkb3B0aW9uLg0KDQpJIGRvIGJlbGlldmUgdGhhdCBpbiBnZW5lcmFs IFBBVENIIGNhbiBiZSBtYWRlIG1vcmUgaW50dWl0aXZlIHdpdGhvdXQgYWRkaW5nIHVpZHMgdG8g ZWFjaCBlbGVtZW50LiAgVGhlIHZlcmJzIHRoYXQgeW91IHByb3Bvc2UgbWFrZSBzZW5zZS4gIFRo ZXJlIGlzIGFsc28gYSBKU09OIFBhdGNoIGluZm9ybWF0aW9uYWwgZHJhZnQgaW4gdGhlIElFVEYg dGhhdCBpcyBpbnRlcmVzdGluZyAtIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtYXBwc2F3Zy1qc29uLXBhdGNoLTAyLiAgSXQgcmVsaWVzIG9uIGEgSlNPTiBQb2ludGVyIGRy YWZ0IHdoaWNoIHVzZXMgaW5kZXgtYmFzZWQgYWRkcmVzc2luZyBmb3IgbXVsdGktdmFsdWVkIGF0 dHJpYnV0ZXMuICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgYmUg bG9va2VkIGF0IHdpdGhpbiB0aGUgV0cgYW5kIEkgd291bGQgYmUgd2lsbGluZyB0byBsZWFkIHRo aXMgZWZmb3J0Lg0KDQpJJ20gY3VyaW91cyBpZiBhbnlvbmUgZWxzZSBpbiB0aGUgV0cgaXMgaW4g ZmF2b3Igb2YgdW5pcXVlIGlkZW50aWZpZXJzIGZvciBldmVyeSBtdWx0aS12YWx1ZWQgZWxlbWVu dC4NCg0KLS1LZWxseQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTpz Y2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZz4gW3NjaW0t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnPl0gb24gYmVoYWxm IG9mIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIFtnLmMucHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86 Zy5jLnByYXNhZEBnbWFpbC5jb20+XQ0KU2VudDogU2F0dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAx MDo1MCBBTQ0KVG86IFBoaWwgSHVudA0KQ2M6IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwgSXNzdWUgMjQN ClBoaWwsDQoNClRoZSByZWFzb24gd2UgY2Fubm90IHVzZSB0aGUgdmFsdWUgaXRzZWxmIHRvIGlk ZW50aWZ5IGFuIGVsZW1lbnQgaXMgdGhhdCB0aGlzIG1ldGhvZCB3aWxsIG9ubHkgd29yayBmb3Ig c2ltcGxlIGVsZW1lbnRzLCBub3QgZm9yIG5lc3RlZCBzdHJ1Y3R1cmVzLiBpLmUuLCBpZiB3ZSBo YWQgYW4gYXJyYXkgb2YgZGljdGlvbmFyaWVzIChlLmcuLCB3ZSBoYWQgdG8gcmVjb3JkIGFuIGFy cmF5IG9mIGFkZHJlc3NlcyBmb3IgZWFjaCBjdXN0b21lciwgd2l0aCBlYWNoIGFkZHJlc3MgZWxl bWVudCBoYXZpbmcgc3ViLWVsZW1lbnRzIGxpa2Ugc3RyZWV0IG51bWJlciwgc3RyZWV0IG5hbWUs IHN1YnVyYiwgZXRjLiksIHRoZW4gaXQgd291bGQgYmUgY2x1bXN5IHRvIHN1cHBseSB0aGUgZW50 aXJlIHZhbHVlIG9mIHRoZSBhcnJheSBlbGVtZW50IGJlY2F1c2UgaXQncyBpdHNlbGYgYSBkaWN0 aW9uYXJ5LiBDcmVhdGluZyBhIHVuaXF1ZSBrZXkgZm9yIGVhY2ggZWxlbWVudCBzY2FsZXMgYmV0 dGVyLg0KDQpSZWdhcmRzLA0KR2FuZXNoDQpPbiAxMiBBdWd1c3QgMjAxMiAwMToxMiwgUGhpbCBI dW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3 cm90ZToNCkdhbmVzaCwNCg0KSGVyZSdzIHRoZSBzYW1wbGUgdGhhdCBjb25jZXJuZWQgbWUuLi4N ClRoZSB0d28gb3BlcmF0aW9ucyBkaWZmZXIgc2lnbmlmaWNhbnRseSwgYW5kIGl0J3Mgbm90IHZl cnkgaW50dWl0aXZlLg0KV2l0aCBteSBzdWdnZXN0aW9uLCBoZXJlJ3MgaG93IHRvIGRlbGV0ZSBh IHNpbmdsZSBtZW1iZXIgZnJvbSBhIGdyb3VwOg0KDQpQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0 NjMtNDY5Mi1iNGZkLTliNGRhM2Y5MDhjZSBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBs ZS5jb20vPiBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24gQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0 ODBkanM5M2hkOCBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzkiIHsNCiJvcGVyYXRpb25zIiA6IFsN CnsNCiJSRVRJUkUiIDogew0KImtleSIgOiAibWVtYmVycy4yODE5YzIyMy03Zjc2LTQ1M2EtOTE5 ZC00MTM4NjE5MDQ2NDYiDQp9DQp9DQpdIH0NCg0KDQpZb3UgZ2F2ZSBvdGhlciBleGFtcGxlcyBv ZiBhbiBhdHRyaWJ1dGUgd2l0aCBhbiBpZGVudGlmaWVyIHRoYXQgbWF0Y2hlZCB0aGF0IHZhbHVl IG9yIG9mIGlkZW50aWZpZXJzIHRoYXQgd2VyZSBhZGRpdGlvbmFsIHVuaXF1ZSBrZXlzLg0KDQpH aXZlbiB0aGF0IG11bHRpLXZhbHVlcyBtdXN0IGJlIGVhY2ggdW5pcXVlLCBJIGRvbid0IHNlZSB0 aGUgcG9pbnQgb2YgdGhlIGV4dHJhIGluZGV4aW5nIHRvIHN1cHBvcnQgdGhpcy4gSnVzdCB1c2Ug dGhlIHZhbHVlIGFzIHRoZSBpdGVtIHlvdSB3aXNoIHRvIGRlbGV0ZS4NCg0KSSBhZ3JlZSwgdGhl IGRlbGV0ZSB2YWx1ZSBvcGVyYXRpb24gY291bGQgYmUgbW9yZSBleHBsaWNpdCBhbmQgY2xlYXIg aW4gZ2VuZXJhbC4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50aWQu Y29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxt YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQpPbiAyMDEyLTA4LTExLCBhdCAyOjMw IEFNLCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCB3cm90ZToNCg0KPiAgRm9yIHRoZSBtdWx0aS12 YWx1ZSBleGFtcGxlIHlvdSBnYXZlIHlvdSB1c2VkIHRoZSB2YWx1ZSBhcyB0aGUgYXR0cmlidXRl IG5hbWUga2V5Lg0KDQpOb3cgSSdtIGNvbmZ1c2VkIDotKS4gSSBkb24ndCBiZWxpZXZlIGFueSBv ZiBteSBleGFtcGxlcyBldmVyIHVzZWQgYSB2YWx1ZSBhcyB0aGUga2V5Lg0KDQpDb3VsZCB5b3Ug cGxlYXNlIHNob3cgbWUgd2hpY2ggZXhhbXBsZSB5b3UgbWVhbiwgYW5kIHdoaWNoIHBhcnRzIG9m IGl0IHlvdSBiZWxpZXZlIHRvIGJlIHRoZSB2YWx1ZT8NCg0KUmVnYXJkcywNCkdhbmVzaA0KT24g MTEgQXVndXN0IDIwMTIgMTM6NTksIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkZvciB0aGUgbXVsdGktdmFsdWUg ZXhhbXBsZSB5b3UgZ2F2ZSB5b3UgdXNlZCB0aGUgdmFsdWUgYXMgdGhlIGF0dHJpYnV0ZSBuYW1l IGtleS4NCg0KVGhhdCBtZWFucyBhIGxvdCBtb3JlIGNvbXBsZXggaW5kZXhpbmcgc3RydWN0dXJl LiBCZXR0ZXIgdG8ganVzdCBzYXkgZGVsZXRlIGEgc3BlY2lmaWMgdmFsdWUuDQoNClRoZSBzcGVj IGFscmVhZHkgYWxsb3dzIG11bHRpcGxlIHZhbHVlcyB0byBoYXZlIHRhZ3MgbGlrZSBob21lLCB3 b3JrLCBldGMuDQoNClBoaWwNCg0KT24gMjAxMi0wOC0xMCwgYXQgMjE6NDUsIEdhbmVzaCBhbmQg U2FzaGkgUHJhc2FkIDxnLmMucHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFp bC5jb20+PiB3cm90ZToNCj4gSW4geW91ciBleGFtcGxlIHlvdSBhcmUgY29uZmxhdGluZyB2YWx1 ZSB3aXRoIGFuIGF0dHJpYnV0ZSBpZC4NCg0KSSBkb24ndCBiZWxpZXZlIHNvLg0KDQpJJ20gYWRv cHRpbmcgYSBtb2RlbCB3aGVyZSBldmVyeSBhdHRyaWJ1dGUgb2YgdGhlIHJlc291cmNlIGlzIGEg a2V5LXZhbHVlIHBhaXIuIFRoZSBrZXkgaXMgYSBuYW1lIG9yIElELg0KDQpGb3Igbm9uLXJlcGVh dGluZyBhdHRyaWJ1dGVzIChib3RoIHNpbXBsZSBhbmQgY29tcG9zaXRlKSwgdGhlIGtleSBpcyB0 aGUgYXR0cmlidXRlIG5hbWUgaXRzZWxmLg0KDQpTaW1wbGUgYXR0cmlidXRlOg0KDQpLZXk6ICJk b2IiDQpWYWx1ZTogIjAxIEphbiAxOTcwIg0KDQpGb3IgY29tcG9zaXRlIGF0dHJpYnV0ZXMsIHRo ZSBrZXkgZW1wbG95cyBkb3Qgbm90YXRpb24gdG8gc3BlY2lmeSB0aGUgZnVsbHktcXVhbGlmaWVk IGF0dHJpYnV0ZSBuYW1lLCBlLmcuLCAiYWRkcmVzcy5wb3N0Y29kZSIuDQoNCkNvbXBvc2l0ZSBh dHRyaWJ1dGU6DQoNCktleTogImFkZHJlc3Muc3RyZWV0LW51bWJlciINClZhbHVlOiAiMTAiDQoN CktleTogImFkZHJlc3Muc3VidXJiIg0KVmFsdWU6ICJFYXN0IENhbWRlbiINCg0KRm9yIHJlcGVh dGluZyAobXVsdGktdmFsdWVkKSBhdHRyaWJ1dGVzLCBJJ20gc3VnZ2VzdGluZyB0aGF0IHRoZXJl IGJlIG5ldyBrZXlzIGZvciBlYWNoIGluZGl2aWR1YWwgdmFsdWUsIG90aGVyd2lzZSB0aGV5IGFy ZSBpbXBvc3NpYmxlIHRvIGRpc3Rpbmd1aXNoLCBhbmQgYSBwb3NpdGlvbmFsIGluZGV4IGlzIGlu YWRlcXVhdGUuIFNvIHdlIGNvbnZlcnQgdGhlIGFycmF5IGludG8gYSBkaWN0aW9uYXJ5IGFuZCB0 aGlzIHRoZW4gYmVjb21lcyBhIGNvbXBvc2l0ZSBhdHRyaWJ1dGUgdXNpbmcgZG90IG5vdGF0aW9u IGZvciB0aGUga2V5Lg0KDQpNdWx0aS12YWx1ZWQgYXR0cmlidXRlOg0KDQpLZXk6ICJlbWFpbHMu N2RmY2I0NDQtNzRkOC00ZjE3LWFhNjYtZGFmOWVhM2JkOTAyIg0KVmFsdWU6ICJqb2huX3NtaXRo QHlhaG9vLmNvbTxtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20+Ig0KDQpTbyB0aGlzIGFsbG93 cyB1cyB0byBhcHBseSB1bmlmb3JtIHRyZWF0bWVudCB0byBhbnkgYXJiaXRyYXJpbHkgZGVlcCBy ZXNvdXJjZSBzdHJ1Y3R1cmUuIFdlIGNhbiByZWZlciB0byBldmVyeSBsZWFmIHZhbHVlIHdpdGgg YSBrZXkgdGhhdCBpcyB0aGUgZnVsbHktcXVhbGlmaWVkIG5hbWUgdXNpbmcgZG90IG5vdGF0aW9u Lg0KDQpUaGUgdmVyYnMgYXJlIGp1c3QgdW5hbWJpZ3VvdXMgb3BlcmF0aW9ucyBvbiB0aGVzZSAo bm93KSBleHBsaWNpdGx5IGFkZHJlc3NhYmxlIGF0dHJpYnV0ZXMuDQoNCklOQ0xVREUgdG8gYSBj b2xsZWN0aW9uIGFuZCBzcGVjaWZ5IG9ubHkgdGhlIHZhbHVlLiBUaGUga2V5IGlzIGdlbmVyYXRl ZCBhbmQgcmV0dXJuZWQuIFRoZSBmdWxseS1xdWFsaWZpZWQga2V5IGlzIDxjb2xsZWN0aW9uLW5h bWU+LjxuZXdseS1nZW5lcmF0ZWQtSUQ+IGFuZCB0aGUgdmFsdWUgaXMgd2hhdCB3YXMgc3BlY2lm aWVkIGluIHRoZSBJTkNMVURFLg0KDQpSRVBMQUNFIGEgZnVsbHktcXVhbGlmaWVkIGtleSB3aXRo IGEgbmV3IHZhbHVlLiBJZiB0aGUga2V5IGRvZXNuJ3QgZXhpc3QsIHJldHVybiBhICI0MDQgTm90 IEZvdW5kIi4NCg0KUExBQ0UgYSB2YWx1ZSBhdCB0aGUgbG9naWNhbCBsb2NhdGlvbiBpbXBsaWVk IGJ5IHRoZSBmdWxseS1xdWFsaWZpZWQga2V5LiBJZiB0aGVyZSBpcyBhbHJlYWR5IGEga2V5IHdp dGggdGhhdCBuYW1lLCByZXR1cm4gYSAiNDA5IENvbmZsaWN0Ii4NCg0KRk9SQ0UgdGhlIGZ1bGx5 LXF1YWxpZmllZCBrZXkgdG8gaG9sZCB0aGUgZ2l2ZW4gdmFsdWUsIHJlZ2FyZGxlc3Mgb2Ygd2hl dGhlciBpdCBleGlzdGVkIGJlZm9yZSBvciBub3QuIE9ubHkgZXJyb3JzIHBvc3NpYmxlIGFyZSAi NDAwIEJhZCBSZXF1ZXN0IiBhbmQgIjUwMCBJbnRlcm5hbCBFcnJvciIuDQoNClJFVElSRSBhbiBh dHRyaWJ1dGUgb3IgYSBjb2xsZWN0aW9uIGdpdmVuIGl0cyBmdWxseS1xdWFsaWZpZWQga2V5LiBU aGUgaW1wbGVtZW50YXRpb24gd2lsbCBkZXRlcm1pbmUgd2hldGhlciB0aGUgYXR0cmlidXRlIHdp bGwgZGlzYXBwZWFyIGVudGlyZWx5IG9yIHdpbGwgZXhpc3QgaG9sZGluZyBhIG51bGwgdmFsdWUg KHRoZSBibGFuayBzdHJpbmcgIiIgb3IgdGhlIGVtcHR5IG9iamVjdCB7fSApLg0KDQpJJ2xsIGV4 cGxhaW4gaW4gYSBzZXBhcmF0ZSBwb3N0IHdoeSB3ZSBuZWVkIG9wZXJhdGlvbiB2ZXJicyBsaWtl IHRoZXNlIHRoYXQgYXJlIGluZGVwZW5kZW50IG9mIHRoZSBIVFRQIHZlcmJzLg0KDQpSZWdhcmRz LA0KR2FuZXNoDQoNCk9uIDExIEF1Z3VzdCAyMDEyIDEwOjM4LCA8c2NpbS1yZXF1ZXN0QGlldGYu b3JnPG1haWx0bzpzY2ltLXJlcXVlc3RAaWV0Zi5vcmc+PiB3cm90ZToNCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UNCmF0 dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4g eW91ciBsaXN0DQpzdWJzY3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCkNsaWNrIHRoZSAnVW5zdWJzY3JpYmUg b3IgZWRpdCBvcHRpb25zJyBidXR0b24sIGxvZyBpbiwgYW5kIHNldCAiR2V0DQpNSU1FIG9yIFBs YWluIFRleHQgRGlnZXN0cz8iIHRvIE1JTUUuICBZb3UgY2FuIHNldCB0aGlzIG9wdGlvbg0KZ2xv YmFsbHkgZm9yIGFsbCB0aGUgbGlzdCBkaWdlc3RzIHlvdSByZWNlaXZlIGF0IHRoaXMgcG9pbnQu DQoNCg0KDQpTZW5kIHNjaW0gbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQogICAgICAgIHNj aW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQoNClRvIHN1YnNjcmliZSBvciB1bnN1 YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KICAgICAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCm9yLCB2aWEgZW1haWwsIHNlbmQgYSBt ZXNzYWdlIHdpdGggc3ViamVjdCBvciBib2R5ICdoZWxwJyB0bw0KICAgICAgICBzY2ltLXJlcXVl c3RAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tcmVxdWVzdEBpZXRmLm9yZz4NCg0KWW91IGNhbiByZWFj aCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0DQogICAgICAgIHNjaW0tb3duZXJAaWV0 Zi5vcmc8bWFpbHRvOnNjaW0tb3duZXJAaWV0Zi5vcmc+DQoNCldoZW4gcmVwbHlpbmcsIHBsZWFz ZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMNCnRoYW4gIlJl OiBDb250ZW50cyBvZiBzY2ltIGRpZ2VzdC4uLiINCg0KVG9kYXkncyBUb3BpY3M6DQoNCiAgIDEu IFJlOiBTQ0lNIFByb3RvY29sIC0gMyBzdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQgKFBoaWwg SHVudCkNCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0NCkZyb206 IFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tPj4NClRvOiBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCA8Zy5jLnByYXNhZEBnbWFpbC5jb208 bWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPj4NCkNjOiAiRGlvZGF0aSwgTWFyayIgPE1hcmsu RGlvZGF0aUBnYXJ0bmVyLmNvbTxtYWlsdG86TWFyay5EaW9kYXRpQGdhcnRuZXIuY29tPj4sIEVt bWFudWVsIERyZXV4IDxlZHJldXhAY2xvdWRpd2F5LmNvbTxtYWlsdG86ZWRyZXV4QGNsb3VkaXdh eS5jb20+PiwgVHJleSBEcmFrZSA8dHJleS5kcmFrZUB1bmJvdW5kaWQuY29tPG1haWx0bzp0cmV5 LmRyYWtlQHVuYm91bmRpZC5jb20+PiwgS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3JpenpsZUBzYWls cG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+PiwgInNjaW1AaWV0 Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+IiA8c2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBp ZXRmLm9yZz4+DQpEYXRlOiBGcmksIDEwIEF1ZyAyMDEyIDE3OjM2OjU0IC0wNzAwDQpTdWJqZWN0 OiBSZTogW3NjaW1dIFNDSU0gUHJvdG9jb2wgLSAzIHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVu dA0KR2FuZXNoLA0KDQpJbiB5b3VyIGV4YW1wbGUgeW91IGFyZSBjb25mbGF0aW5nIHZhbHVlIHdp dGggYW4gYXR0cmlidXRlIGlkLiBJIGZpbmQgdGhhdCBjb25mdXNpbmcuDQoNCkkgYWdyZWUgdGhv dWdoIHRoYXQgb3BlcmF0aW9ucyBpbiBwYXRjaCBjb3VsZCBiZSBhIGxvdCBtb3JlIGV4cGxpY2l0 Lg0KDQpFZyBleHBsaWNpdGx5IGRlbGV0aW5nIGEgdmFsdWUgYnkgc2F5aW5nIGRlbGV0ZSBvciBy ZXRpcmUuDQoNClBoaWwNCg0KT24gMjAxMi0wOC0xMCwgYXQgMTY6MTksIEdhbmVzaCBhbmQgU2Fz aGkgUHJhc2FkIDxnLmMucHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5j b20+PiB3cm90ZToNCiA+ICBJIGFtIGNvbmNlcm5lZCBhYm91dCB5b3VyIHNlY29uZCBzdWdnZXN0 aW9uOg0KDQpMZXQncyBkaXNjdXNzIHRoYXQgbm93Lg0KDQpUaGUgdHJhZGUtb2ZmcyBhcmUgdmVy eSBjbGVhciBoZXJlLg0KDQpQcm9zOg0KDQpQcm8gMS4gVGhlIEFQSSB0byBtYW5pcHVsYXRlIHJl c291cmNlcyBiZWNvbWVzIHNvIG11Y2ggY2xlYW5lciwgY29uc2lzdGVudCBhbmQgaW50dWl0aXZl IHdoZW4gZXZlcnkgaW5kaXZpZHVhbCBhdHRyaWJ1dGUgdmFsdWUgZ2V0cyBpdHMgb3duIElELg0K DQpIZXJlJ3MgaG93IHRvIGRlbGV0ZSBhIHNpbmdsZSBtZW1iZXIgZnJvbSBhIEdyb3VwLCBhcyBw ZXIgdGhlIGN1cnJlbnQgc3BlYzoNCg0KDQogICBQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMt NDY5Mi1iNGZkLTliNGRhM2Y5MDhjZQ0KDQogICBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhh bXBsZS5jb20vPg0KDQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24NCg0KICAgQXV0aG9yaXph dGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOA0KDQogICBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzki DQoNCg0KDQogICB7DQoNCiAgICAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZTox LjAiXSwNCg0KICAgICAibWVtYmVycyI6IFsNCg0KICAgICAgIHsNCg0KICAgICAgICAgImRpc3Bs YXkiOiAiQmFicyBKZW5zZW4iLA0KDQogICAgICAgICAidmFsdWUiOiAiMjgxOWMyMjMtN2Y3Ni00 NTNhLTkxOWQtNDEzODYxOTA0NjQ2Ig0KDQogICAgICAgICAib3BlcmF0aW9uIjogImRlbGV0ZSIN Cg0KICAgICAgIH0NCg0KICAgICBdDQoNCiAgIH0NCg0KSGVyZSdzIGhvdyB0byBkZWxldGUgQUxM IG1lbWJlcnMgZnJvbSBhIGdyb3VwIGFjY29yZGluZyB0byB0aGUgY3VycmVudCBzcGVjOg0KDQoN CiAgIFBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlDQoN CiAgIEhvc3Q6IGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+DQoNCiAgIEFjY2VwdDog YXBwbGljYXRpb24vanNvbg0KDQogICBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4 DQoNCiAgIEVUYWc6IFcvImEzMzBiYzU0ZjA2NzFjOSINCg0KDQoNCiAgIHsNCg0KICAgICAic2No ZW1hcyI6IFsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJdLA0KDQogICAgICJtZXRhIjogew0K DQogICAgICAgImF0dHJpYnV0ZXMiOiBbDQoNCiAgICAgICAgICJtZW1iZXJzIg0KDQogICAgICAg XQ0KDQogICAgIH0NCg0KICAgfQ0KDQpUaGUgdHdvIG9wZXJhdGlvbnMgZGlmZmVyIHNpZ25pZmlj YW50bHksIGFuZCBpdCdzIG5vdCB2ZXJ5IGludHVpdGl2ZS4NCldpdGggbXkgc3VnZ2VzdGlvbiwg aGVyZSdzIGhvdyB0byBkZWxldGUgYSBzaW5nbGUgbWVtYmVyIGZyb20gYSBncm91cDoNCg0KUEFU Q0ggL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4Y2UgSG9zdDogZXhh bXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tLz4gQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uIEF1 dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDggRVRhZzogVy8iYTMzMGJjNTRmMDY3MWM5 IiB7DQoib3BlcmF0aW9ucyIgOiBbDQp7DQoiUkVUSVJFIiA6IHsNCiJrZXkiIDogIm1lbWJlcnMu MjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2Ig0KfQ0KfQ0KXSB9DQpIZXJlJ3Mg aG93IEkgc3VnZ2VzdCBkZWxldGluZyBBTEwgbWVtYmVycyBmcm9tIGEgZ3JvdXA6DQoNClBBVENI IC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlIEhvc3Q6IGV4YW1w bGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+IEFjY2VwdDogYXBwbGljYXRpb24vanNvbiBBdXRo b3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4IEVUYWc6IFcvImEzMzBiYzU0ZjA2NzFjOSIg ew0KIm9wZXJhdGlvbnMiIDogWw0Kew0KIlJFVElSRSIgOiB7DQoia2V5IiA6ICJtZW1iZXJzIg0K fQ0KfQ0KXSB9DQoNCkknbSBzdXJlIHlvdSdsbCBhZ3JlZSB0aGF0IHRoaXMgaXMgc2ltcGxlciwg bW9yZSBjb25zaXN0ZW50IGFuZCBtb3JlIGludHVpdGl2ZSB0byBhIHJlYWRlci4NCg0KUHJvIDI6 IFdlIGNhbiBhcHBseSB0aGlzIG1lY2hhbmlzbSBjb25zaXN0ZW50bHkgdG8gdGhyZWUgYXJlYXM6 DQooYSkgTWFuaXB1bGF0aW5nIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIG9mIGEgcmVzb3VyY2UN CihiKSBNYW5pcHVsYXRpbmcgbWVtYmVycyBvZiBhIGdyb3VwDQooYykgUGVyZm9ybWluZyBidWxr IG9wZXJhdGlvbnMsIHdoZXJlIHdlIHNpbXBseSB1c2UgSFRUUCB2ZXJicyBpbnN0ZWFkIG9mIHRo ZSBzcGVjaWFsaXNlZCAoYW5kIHNlbWFudGljYWxseSBsZXNzIGFtYmlndW91cykgdmVyYnMgSSBz dWdnZXN0ZWQgZm9yIGF0dHJpYnV0ZXMsIHRoZSAia2V5IiBiZWNvbWVzIHRoZSBVUkksIGFuZCB0 aGUgInZhbHVlIiBiZWNvbWVzIHRoZSBjb3JyZXNwb25kaW5nIEpTT04gb2JqZWN0Lg0KDQpBbGwg b2YgdGhlbSByZXR1cm4gIjIwNyBNdWx0aS1TdGF0dXMiIHdpdGggdGhlICJyZXN1bHRzIiBhcnJh eSBob2xkaW5nIGluZGl2aWR1YWwgc3RhdHVzIGNvZGVzLg0KDQpJbiB0aGUgY3VycmVudCBzcGVj LCAoYSkgYW5kIChiKSBhcmUgZG9uZSBzaW1pbGFybHkgYnV0IChjKSBpcyB2ZXJ5IGRpZmZlcmVu dC4NCg0KUHJvIDM6IEFkb3B0aW9uIG9mIHRoZSBzdGFuZGFyZCBieSBjbGllbnRzIGlzIGxpa2Vs eSB0byBiZSBoaWdoZXIgYmVjYXVzZSBpdCdzIHNpbXBsZXIgZm9yIHRoZW0uDQoNClBybyA0OiBO ZXcgKG5vdCBpbmN1bWJlbnQpIGNsb3VkIHByb3ZpZGVycyB3aWxsIHByb2JhYmx5IGZpbmQgdGhp cyBlYXNpZXIgdG8gaW1wbGVtZW50IGJlY2F1c2UgdGhleSBoYXZlIG5vIGxlZ2FjeS4gVGhleSB3 aWxsIHByb2JhYmx5IHVzZSBzb21lIGZvcm0gb2YgTm9TUUwgZGF0YWJhc2UgYW5kIHdvbid0IGJl IGNvbnN0cmFpbmVkIGJ5IHRoZSBsaW1pdGF0aW9ucyBvZiBMREFQIGRpcmVjdG9yaWVzLg0KDQpD b25zOg0KDQpDb24gMTogSW5jdW1iZW50IGNsb3VkIHByb3ZpZGVycyB3aXRoIGV4aXN0aW5nIGRh dGEgc3RvcmVzIGluIGEgZGlyZWN0b3J5IGZvcm1hdCAod2hlcmUgbXVsdGktdmFsdWVkIGF0dHJp YnV0ZXMgYXJlIHN0b3JlZCBhcyBjb21tYS1zZXBhcmF0ZWQgdmFsdWVzIHVuZGVyIGEgc2luZ2xl IGF0dHJpYnV0ZSBub2RlKSB3aWxsIGZpbmQgaXQgZGlmZmljdWx0IHRvIG1pZ3JhdGUgdG8gdGhp cyBtb2RlbCBhbmQgc3RvcmUgZWFjaCBhdHRyaWJ1dGUgdmFsdWUgYXMgYSBzdWItbm9kZSB3aXRo IGl0cyBvd24ga2V5LiBUaGlzIHdpbGwgImhpbmRlciBhZG9wdGlvbiBvZiB0aGUgc3BlYyIsIHdo aWNoIGlzIHdoYXQgeW91IGZlYXIuDQoNCkhhdmUgSSBzdW1tZWQgdXAgdGhlIFByb3MgYW5kIENv bnMgY29ycmVjdGx5PyBJJ20gYmlhc2VkIG9mIGNvdXJzZSwgc28gSSBjb3VsZCBoYXZlIG1pc3Nl ZCBhIENvbiBvciBoeXBlZCBhIFBybyA6LSkuDQoNCkluIG90aGVyIHdvcmRzLCB3ZSdyZSBkZWJh dGluZyBpbnRlcmZhY2UgY29tcGxleGl0eSAoY3VycmVudCBzcGVjKSB2ZXJzdXMgaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eSAobXkgc3VnZ2VzdGlvbikuIEJvdGggY2FuIGhpbmRlciBhZG9wdGlv biBvZiB0aGUgc3BlYyBieSBkaWZmZXJlbnQgcGFydGllcy4NCg0KSGVyZSdzIHdoYXQgd2UgbmVl ZCB0byBkaXNjdXNzIC0gRG8gdGhlIFByb3MgbWFrZSB0aGUgc3VnZ2VzdGlvDQoNCg0K --_000_CC4E982CBA4A5chrisphillipscanarieca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48ZGl2PktlbGx5IEcncyBjb21tZW50cyBiZXN0IG1hdGNo IG15IG9waW5pb24gYXMgd2VsbCAmbmJzcDstLUkgdG9vIGRpc2FncmVlIHdpdGggdGhlIHByb3Bv c2VkIGNoYW5nZXMgYnkgR2FuZXNoIGFzIHRoZXkgYWRkIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHku PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgZXhhbXBsZSBiZWxvdyBicmVha3MgcHJhY3Rp Y2FsbHkgYW55IExEQVAgZGlyZWN0b3J5IGJhY2tpbmcgYSBtYWlsc3RvcmUgYW5kIHdvdWxkIGZv cmNlIGFuIGltcGxlbWVudG9yIG9mIFNDSU0gdG8gZ2hvc3QgdGhlaXIgZGF0YSBzb21laG93IHRv IHN1cHBvcnQgdGhlIGNoYW5nZXMgR2FuZXNoIHByb3Bvc2VzLiBTb21ldGhpbmcgdGhhdCBjZXJ0 YWlubHkgd291bGQgbWFrZSBwZW9wbGUgYXZvaWQgdXNpbmcgU0NJTSBhdCBhbGwuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5HaXZlbiB0aGF0IHlvdSBoYXZlIGEgbnVtYmVyIG9mIHRob3VnaHRz IGFib3V0IHdoYXQgY291bGQgYmUgY2hhbmdlZCBpbiBTQ0lNLExlaWYncyByZWNvbW1lbmRhdGlv biB0byAmbmJzcDtjcmFmdCB0aGVtIGluIGFuIEludGVybmV0IERyYWZ0IG1heSBiZSBhIGJldHRl ciB3YXkgdG8gY29udmV5IHlvdXIgdGhvdWdodHMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5D aHJpcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNv bG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1 bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1S SUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkZyb206IDwvc3Bhbj4gS2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5 LmdyaXp6bGVAc2FpbHBvaW50LmNvbSI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZn dDs8YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj4gTW9uZGF5 LCAxMyBBdWd1c3QsIDIwMTIgMTA6MjcgQU08YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlRvOiA8L3NwYW4+IEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJtYWls dG86Zy5jLnByYXNhZEBnbWFpbC5jb20iPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDssIFBo aWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7LCBNZWxpbmRhIFNob3JlICZsdDs8YSBocmVmPSJtYWlsdG86 bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20iPm1lbGluZGEuc2hvcmVAZ21haWwuY29tPC9hPiZndDs8 YnI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+ICI8YSBocmVmPSJt YWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWls dG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7LCBFbW1hbnVlbCBEcmV1eCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmVkcmV1eEBjbG91ZGl3YXkuY29tIj5lZHJldXhAY2xvdWRpd2F5 LmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8 L3NwYW4+IFJlOiBbc2NpbV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAyNDxicj48L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1s IiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5z Onc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6 Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPSJHZW5lcmF0 b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48IS0tW2lm ICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHti ZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQj Vk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFb ZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEg NiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+PGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFmdGVyIGFsbCwgbm8g b25lIGhhcyBjaGFsbGVuZ2VkIHRoZSBjbGFpbSB0aGF0IHRoaXMgcHJvcG9zYWwgZHJhc3RpY2Fs bHkgc2ltcGxpZmllcyB0aGUgQVBJIGZvciB0aGUgY2xpZW50PG86cD48L286cD48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7ICI+SSBhZ3JlZSB0aGF0IHlvdXIgcHJvcG9zYWwgbWFrZXMgUEFUQ0gg c2VtYW50aWNzIHNpbXBsZXIgYW5kIG1vcmUgZWxlZ2FudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mZ3Q7ICYj ODIzMDsNCjwvc3Bhbj5zbyBpdCB3b3VsZCBhcHBlYXIgdG8gYmUgd29ydGggZG9pbmcuJm5ic3A7 PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JIHN0cm9uZ2x5IGRpc2FncmVlIGhlcmUuJm5ic3A7IFRo aXMgc3RhdGVtZW50cyBhc3N1bWVzIHRoYXQgc2ltcGxpY2l0eSBvZiB0aGUgY2xpZW50IEFQSSBp cyB0aGUgb25seSBmYWN0b3IgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCB3aXRoIHRoZSBzcGVj LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5FbW1hbnVlbCYj ODIxNztzIGV4YW1wbGUgaXMgZnJvbSBhIHJlYWwtd29ybGQgc2VydmljZSBwcm92aWRlciB0aGF0 IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGltcGxlbWVudCB0aGUgc3BlYyBlYXNpbHkgd2l0aCBhIHVp ZCBwZXIgZWxlbWVudC4mbmJzcDsgSGUgaXMgd29ya2luZyBvbiBhIFNDSU0NCiBpbnRlcmZhY2Ug dGhhdCB3aWxsIGhlbHAgZmFjaWxpdGF0ZSBkYXRhIGV4Y2hhbmdlIGJldHdlZW4gbXVsdGlwbGUg QWN0aXZlIERpcmVjdG9yeSBzZXJ2ZXJzLiZuYnNwOyBZb3VyIHNvbHV0aW9uIHdhcyB0byBjaGFu Z2UgdGhlIGRhdGEgbW9kZWwgZnJvbSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsgIj5tYWlsOiA8YSBocmVmPSJtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20i PmpvaG5fc21pdGhAeWFob28uY29tPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpvaG4uc21pdGhAZ21h aWwuY29tIj5qb2huLnNtaXRoQGdtYWlsLmNvbTwvYT4sIDxhIGhyZWY9Im1haWx0bzpqc21pdGgx OTcwQGhvdG1haWwuY29tIj5qc21pdGgxOTcwQGhvdG1haWwuY29tPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPnRvIHRoaXM6PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5tYWlsOiZuYnNwO2Fh NjYtZGFmOWVhM2JkOTAyPTxhIGhyZWY9Im1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbSI+am9o bl9zbWl0aEB5YWhvby5jb208L2E+LDljZGEtODY0NmMzMDg1YmJmPTxhIGhyZWY9Im1haWx0bzpq b2huLnNtaXRoQGdtYWlsLmNvbSI+am9obi5zbWl0aEBnbWFpbC5jb208L2E+LCZuYnNwOzdhNmQx ZGU2NjRlMT08YSBocmVmPSJtYWlsdG86anNtaXRoMTk3MEBob3RtYWlsLmNvbSI+anNtaXRoMTk3 MEBob3RtYWlsLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+SSBkbyBub3Qga25vdyBvZiBhIHNpbmdsZSBvcmdhbml6YXRpb24gdGhhdCB3b3VsZCBj aGFuZ2UgdGhlaXIgQWN0aXZlIERpcmVjdG9yeSBkYXRhIG1vZGVsIHRvIGZpdCB0aGlzLiZuYnNw OyBGb3Igb25lIHRoaW5nLCBpdCB3b3VsZCBiZSBhIGh1Z2UgZGF0YSBtaWdyYXRpb24gZWZmb3J0 DQogKGxpa2VseSBhY3Jvc3Mgb3RoZXIgZG9tYWluIGNvbnRyb2xsZXJzLCBldGMmIzgyMzA7KSB0 byBhc3NpZ24gdGhlc2UgdW5pcXVlIGlkZW50aWZpZXJzLiZuYnNwOyBUaGlzIGFsc28gYXNzdW1l cyB0aGF0IFNDSU0gaXMgdGhlIG9ubHkgcmVhZGVyL3dyaXRlciBvZiB0aGlzIGRhdGEsIHdoaWNo IHdpbGwgYWxtb3N0IG5ldmVyIGJlIHRoZSBjYXNlLiZuYnNwOyBJZiB0aGUgZGF0YSBtb2RlbCBy ZXF1aXJlcyB1aWRzIGZvciBldmVyeSBlbGVtZW50LCB0aGVuIGV2ZXJ5IHBpZWNlDQogb2Ygbm9u LVNDSU0gY29kZSB0aGF0IHdyaXRlcyBkYXRhIGludG8gdGhlIGRpcmVjdG9yeSB3aWxsIGhhdmUg dG8gZm9sbG93IHRoaXMuJm5ic3A7IEFkZGl0aW9uYWxseSwgdGhlcmUgYXJlICo8Yj5tYW55PC9i PiogdG9vbHMgYW5kIGFwcGxpY2F0aW9ucyAmbmJzcDsoZWcgJiM4MjExOyBhZGRyZXNzIGJvb2tz KSB0aGF0IHJlbHkgb24gYSBjZXJ0YWluIGRhdGEgbW9kZWwgaW4gQWN0aXZlIERpcmVjdG9yeSwg YW5kIHRoaXMgd291bGQgY2F1c2UgdGhlbSB0byBicmVhay4mbmJzcDsgSU1PDQogdGhpcyBzYW1l IGFyZ3VtZW50IGhvbGRzIHRydWUgZm9yIG1vc3Qgc2VydmljZSBwcm92aWRlcnMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+UEFUQ0ggaXMgYW4gb3B0aW9uYWwgcGFydCBvZiB0aGUgc3BlYy4gJm5ic3A7SXQgd2Fz IHByaW1hcmlseSBpbnRyb2R1Y2VkIHRvIG1ha2UgbW9kaWZ5aW5nIHJlc291cmNlcyB3aXRoIGxh cmdlIG11bHRpLXZhbHVlZCBsaXN0cyBtb3JlIGVmZmljaWVudC4mbmJzcDsgSXQgZG9lcyBub3Qg bmVlZA0KIHRvIHNvbHZlIGV2ZXJ5IHByb2JsZW0gKGVnICYjODIxMTsgbW9kaWZ5aW5nIHN1Yi1l bGVtZW50cyBpbiBuZXN0ZWQgYXJyYXlzKS4mbmJzcDsgQWRkaW5nIHVpZHMgdG8gZXZlcnkgbXVs dGktdmFsdWVkIGVsZW1lbnQgZG9lcyBub3Qgc3RyaWtlIHRoZSByaWdodCBiYWxhbmNlIGJldHdl ZW4gdGhlIG5lZWRzIG9mIHRoZSBjbGllbnQgYW5kIHRoZSBuZWVkcyBvZiB0aGUgc2VydmljZSBw cm92aWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+LS1L ZWxseTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFo b21hLCBzYW5zLXNlcmlmOyAiPiBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCBbPGEgaHJlZj0ibWFp bHRvOmcuYy5wcmFzYWRAZ21haWwuY29tIj5tYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+ XQ0KPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiAxOjM1IEFNPGJyPjxi PlRvOjwvYj4gUGhpbCBIdW50OyBNZWxpbmRhIFNob3JlPGJyPjxiPkNjOjwvYj4gRW1tYW51ZWwg RHJldXg7IEtlbGx5IEdyaXp6bGU7IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2lt QGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwg Vm9sIDgsIElzc3VlIDI0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlc3BvbmRp bmcgdG8gZXh0cmFjdCBvZiBNZWxpbmRhIFNob3JlJ3MgbWFpbCBmcm9tIGRpZ2VzdDo8bzpwPjwv bzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOmJyZWFr LXdvcmQiPlRoZSBpc3N1ZSBiZWluZyByYWlzZWQgaGVyZSBpc24ndCBlbmRwb2ludCBsb2dpYywg YnV0PG86cD48L286cD48L3ByZT48cHJlPm5ldHdvcmsgdHJhZmZpYywgYW5kIEknbSBwcmV0dHkg c3VyZSBpdCdzIG5vdCB2ZXJ5IGhlbHBmdWwgdG88bzpwPjwvbzpwPjwvcHJlPjxwcmU+cmVzcG9u ZCB0byB0aGUgb2JzZXJ2YXRpb24gdGhhdCB5b3VyIG1vZGVsIHJlcXVpcmVzIG1vcmU8bzpwPjwv bzpwPjwvcHJlPjxwcmU+bWVzc2FnZXMgd2l0aCBhIGNvbXBsYWludCBhYm91dCB3aGF0IHlvdSBz ZWVtIHRvIHRoaW5rIGlzIGE8bzpwPjwvbzpwPjwvcHJlPjxwcmU+Y29tcGxleCBhbGdvcml0aG0g Zm9yIGF0dHJpYnV0ZSBwcm9jZXNzaW5nLjxvOnA+PC9vOnA+PC9wcmU+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IGRlcGVuZHMgb24gaG93IGl0J3MgaW1wbGVtZW50ZWQuIEknbSBjb25maWRlbnQg d2UgY2FuIGhhdmUgdGhlIGJlc3Qgb2YgYm90aCAtIHNpbXBsZSBBUEkgd2l0aCBsb3ctb3Zlcmhl YWQgaW1wbGVtZW50YXRpb24uIENhbiB3ZSBicmFpbnN0b3JtIEhPVyB0aGlzIHByb3Bvc2FsIGNh biBiZSBpbXBsZW1lbnRlZCByYXRoZXIgdGhhbiBXSFkgaXQgY2FuJ3QgYmUgaW1wbGVtZW50ZWQg KHdoaWNoIGlzIG1vc3RseQ0KIHdoYXQgSSd2ZSBiZWVuIGhlYXJpbmcgc28gZmFyKT8gQWZ0ZXIg YWxsLCBubyBvbmUgaGFzIGNoYWxsZW5nZWQgdGhlIGNsYWltIHRoYXQgdGhpcyBwcm9wb3NhbCBk cmFzdGljYWxseSBzaW1wbGlmaWVzIHRoZSBBUEkgZm9yIHRoZSBjbGllbnQsIHNvIGl0IHdvdWxk IGFwcGVhciB0byBiZSB3b3J0aCBkb2luZy4mbmJzcDtJJ20gc3VyZSB0aGVyZSdzIG1vcmUgdGhh biBlbm91Z2ggaW50ZWxsZWN0dWFsIGhvcnNlcG93ZXIgaW4gdGhpcyB3b3JraW5nIGdyb3VwDQog dG8gcHVsbCB0aGlzIG9mZiBpZiB3ZSBwdXQgb3VyIG1pbmRzIHRvIGl0LjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+R2FuZXNoPG86cD48L286cD48L3A+PC9kaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAxMyBBdWd1c3QgMjAxMiAxMzo1NCwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQg Jmx0OzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsmbmJz cDtJIHN0cm9uZ2x5IG9iamVjdCB0byBhbnl0aGluZyB0aGF0IGxlYWRzIHRvIGEgcmVhZCBiZWZv cmUgbW9kaWZ5IHJlcXVpcmVtZW50LiBUb28gY29tcGxleCBhbmQgdG9vIGNoYXR0eS48bzpwPjwv bzpwPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSBQaGlsLCBidXQgeW91J3Jl IGNvbnRyYWRpY3RpbmcgeW91cnNlbGYgaGVyZS4mbmJzcDtUaGVyZSBzZWVtcyB0byBiZSBhbiBh d2Z1bCBsb3Qgb2YgbWF0Y2hpbmcgKGkuZS4sIHJlYWRpbmcpIGdvaW5nIG9uIGluIHRoZSBzcGVj IGFzIGl0IHN0YW5kcywgd2l0aCBpZi10aGVuIGNsYXVzZXMgdG8gZG8gb25lIHRoaW5nIG9yIGFu b3RoZXIgaWYgdGhlIG1hdGNoIGVpdGhlciBzdWNjZWVkcyBvciBmYWlscy4gVGhpcw0KIGlzIGEg Y29tcGxleCwgY2hhdHR5IHByb3RvY29sIHJpZ2h0IG5vdyE8bzpwPjwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IE11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzOiZuYnNwOyBBbiBhdHRyaWJ1dGUgdmFsdWUgaW4gdGhlIFBBVENIIHJlcXVlc3Q8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9keSBpcyBhZGRlZCB0byB0aGUgdmFs dWUgY29sbGVjdGlvbiBpZiB0aGUgdmFsdWUgZG9lcyBub3QgZXhpc3Q8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgYW5kIG1lcmdlZCBpZiBhIG1hdGNoaW5nIHZhbHVlIGlzIHByZXNl bnQuJm5ic3A7IFZhbHVlcyBhcmUgbWF0Y2hlZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBjb21wYXJpbmcgdGhlIHZhbHVlIFN1Yi1BdHRyaWJ1dGUgZnJvbSB0aGUgUEFUQ0gg cmVxdWVzdCBib2R5IHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSB2YWx1 ZSBTdWItQXR0cmlidXRlIG9mIHRoZSBSZXNvdXJjZS4mbmJzcDsgQXR0cmlidXRlcyB0aGF0IGRv IG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYXZlIGEgdmFsdWUgU3ViLUF0 dHJpYnV0ZTsgZS5nLiwgYWRkcmVzc2VzLCBvciBkbyBub3QgaGF2ZSB1bmlxdWU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUgU3ViLUF0dHJpYnV0ZXMgY2Fubm90IGJlIG1h dGNoZWQgYW5kIG11c3QgaW5zdGVhZCBiZSBkZWxldGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+ PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZW4gYWRkZWQuJm5ic3A7IFNwZWNpZmljIHZhbHVlcyBjYW4gYmUgcmVtb3Zl ZCBmcm9tIGEgUmVzb3VyY2UgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRk aW5nIGFuICJvcGVyYXRpb24iIFN1Yi1BdHRyaWJ1dGUgd2l0aCB0aGUgdmFsdWUgImRlbGV0ZSIg dG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0dHJpYnV0ZSBpbiB0aGUg UEFUQ0ggcmVxdWVzdCBib2R5LiZuYnNwOyBBcyB3aXRoIGFkZGluZy91cGRhdGluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgdmFsdWUgY29sbGVjdGlvbnMsIHRo ZSB2YWx1ZSB0byBkZWxldGUgaXMgZGV0ZXJtaW5lZCBieTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb21wYXJpbmcgdGhlIHZhbHVlIFN1Yi1BdHRyaWJ1dGUgZnJvbSB0aGUgUEFU Q0ggcmVxdWVzdCBib2R5IHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSB2 YWx1ZSBTdWItQXR0cmlidXRlIG9mIHRoZSBSZXNvdXJjZS4mbmJzcDsgQXR0cmlidXRlcyB0aGF0 IGRvIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYXZlIGEgdmFsdWUgU3Vi LUF0dHJpYnV0ZSBvciB0aGF0IGhhdmUgYSBub24tdW5pcXVlIHZhbHVlIFN1Yi08bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXR0cmlidXRlIGFyZSBtYXRjaGVkIGJ5IGNvbXBhcmlu ZyBhbGwgU3ViLUF0dHJpYnV0ZSB2YWx1ZXMgZnJvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5IHRvIHRoZSBTdWItQXR0cmlidXRlIHZhbHVl cyBvZiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzb3VyY2UuJm5ic3A7 IEEgZGVsZXRlIG9wZXJhdGlvbiBpcyBpZ25vcmVkIGlmIHRoZSBhdHRyaWJ1dGUncyBuYW1lPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIGluIHRoZSBtZXRhLmF0dHJpYnV0ZXMg bGlzdC4mbmJzcDsgSWYgdGhlIHJlcXVlc3RlZCB2YWx1ZSB0byBkZWxldGU8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT48cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZG9lcyBub3QgbWF0Y2ggYSB1bmlxdWUgdmFsdWUgb24gdGhl IFJlc291cmNlIHRoZSBzZXJ2ZXIgTUFZPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHJldHVybiBhIEhUVFAgNDAwIGVycm9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjwvZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgYSBzcGVjIHRoYXQgaXMgc3VwcG9zZWQgdG8gYmUgYWJv dXQgc2ltcGxpY2l0eSwgdGhlIGFib3ZlIGRlc2NyaXB0aW9uIGlzIGFueXRoaW5nIGJ1dCBzaW1w bGUuIEkga25vdyB5b3UgZ3V5cyBoYXZlIHdvcmtlZCBoYXJkIG9uIHRoaXMgYW5kIEkgZG9uJ3Qg bWVhbiB0byBkaXNwYXJhZ2UgdGhvc2UgZWZmb3J0cywgYnV0IHRoaW5rIGFib3V0IGhvdyB0aGUg YWJvdmUgcGFzc2FnZSB3b3VsZCBhcHBlYXIgdG8NCiBhIG5ldyByZWFkZXIgKGkuZS4sIGEgbm92 aWNlIHRvIHRoZSBzcGVjLCBub3QgYSB0ZWNobm9sb2d5IG5vdmljZSkuPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIHNvbWV0aGluZyBmdW5kYW1lbnRh bGx5IGJyb2tlbiwgYW5kIGl0IGlzIHRoaXM6IG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIHdpdGhv dXQgYSB1bmlxdWUgaWRlbnRpZmllciBwZXIgdmFsdWUuIElmIHlvdSBkb24ndCBmaXggdGhhdCwg eW91IHdvbid0IGdldCBzaW1wbGljaXR5LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSBrbm93IExEQVAgdHJlZXMgYXJlIGJyb2tlbiBmb3IgbXVsdGktdmFsdWVk IGF0dHJpYnV0ZXMuIEFzIE1hcmsgV2FobA0KPGEgaHJlZj0iaHR0cDovL3d3dy5sZGFwLmNvbS8x L2NvbW1lbnRhcnkvd2FobC8yMDA1MDYxN18wMS5zaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KZmFt b3VzbHkgY29tbWVudGVkPC9hPiBiYWNrIGluIDIwMDUsPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPiI8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1pbWFnZTogaW5pdGlh bDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNrZ3JvdW5kLW9yaWdpbjogaW5p dGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1 LCAyNTAsIDI1Myk7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgYmFja2dyb3VuZC1w b3NpdGlvbjogaW5pdGlhbCBpbml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0 aWFsOyAiPlVuZm9ydHVuYXRlbHksIHNvbWUgb2YgdGhlIGVtZXJnaW5nIHByb3RvY29scyB3aGlj aCBhbHNvIGludGVuZCB0byByZXByZXNlbnQgYW5kIHRyYW5zZmVyIHBlcnNvbmFsIGlkZW50aXR5 IGluZm9ybWF0aW9uIGhhdmUgcGVyaGFwcyB0YWtlbiBhIHN0ZXAgYmFja3dhcmRzIGJ5IG5vdCBl dmVuIGNvbnNpZGVyaW5nDQogdGhlc2UgaXNzdWVzLCBwZXJoYXBzIHN3ZWVwaW5nIHRoZW0gdW5k ZXIgdGhlIHJ1ZyBpbiB0aGUgZ3Vpc2Ugb2Ygc2ltcGxpY2l0eSwgWE1MaWZpY2F0aW9uLCBvciAi Zml4IGluIHRoZSBuZXh0IHZlcnNpb24iLCB3aGljaCBvbmx5IHBvc3Rwb25lIGZpbmRpbmcgaW50 ZXJvcGVyYWJsZSBzb2x1dGlvbnMgdG8gYWxsb3dpbmcgYXBwbGljYXRpb25zIHRvIGV4cHJlc3Mg dGhlIGlkZW50aXR5IGVudHJpZXMgdGhleSB3YW50IHRvIGV4cHJlc3MuPC9zcGFuPiI8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+U0NJTSBpcyBleGFjdGx5IG9uZSBv ZiB0aGVzZSAiZW1lcmdpbmcgcHJvdG9jb2xzIiBXYWhsIHRhbGtzIGFib3V0LCBhbmQgd2hhdCBJ IHNlZSBub3cgc3RyaWtlcyBtZSBhcyAic3dlZXBpbmcgdGhlc2UgaXNzdWVzIHVuZGVyIHRoZSBy dWcgaW4gdGhlIGd1aXNlIG9mIHNpbXBsaWNpdHkiLiBBcG9sb2dpZXMgZm9yIHRoZSBibHVudG5l c3MuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHRha2UgaXMg dGhhdCBTUHMgYXJlIF9hbHJlYWR5XyBzdHJ1Z2dsaW5nIHRvIG1hbmFnZSBtdWx0aS12YWx1ZWQg YXR0cmlidXRlcywgYW5kDQo8YSBocmVmPSJodHRwOi8vZmYxOTU5LndvcmRwcmVzcy5jb20vMjAx MS8wNy8yOC9yZXBsYWNlLWEtdmFsdWUtb2YtYS1tdWx0aS12YWx1ZWQtYXR0cmlidXRlLyIgdGFy Z2V0PSJfYmxhbmsiPg0KZXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUgY2x1bXN5PC9hPi4gVGhleSB3 b3VsZCBiZSBncmF0ZWZ1bCBmb3IgYSBzcGVjaWZpY2F0aW9uIHRoYXQgbWFkZSBvcGVyYXRpb25z IGVhc2llciBhdCB0aGUgY29zdCBvZiBhIHJlLWVuZ2luZWVyZWQgc2NoZW1hLiBUaGF0IGNhbGxz IGZvciBzb21lIHRob3VnaHQgbGVhZGVyc2hpcCBmcm9tIHRoaXMgd29ya2luZyBncm91cC48bzpw PjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdhbmVzaDxvOnA+PC9vOnA+PC9w PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTMg QXVndXN0IDIwMTIgMTA6MTMsIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBz dHJvbmdseSBvYmplY3QgdG8gYW55dGhpbmcgdGhhdCBsZWFkcyB0byBhIHJlYWQgYmVmb3JlIG1v ZGlmeSByZXF1aXJlbWVudC4gVG9vIGNvbXBsZXggYW5kIHRvbyBjaGF0dHkuJm5ic3A7PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj48YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjAxMi0wOC0xMiwgYXQgMTU6MjksIEdhbmVzaCBhbmQg U2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzBGMjQzRSI+Jmd0OyBXb3VsZCBpdCBoYXZlIHRvIGJlIHN0b3JlZCBvbiB0aGUgYWNjb3Vu dCBkYXRhYmFzZSBvZiB0aGUgc2VydmljZSBwcm92aWRlcj88L3NwYW4+PG86cD48L286cD48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzBGMjQzRSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwRjI0M0UiPlllcy48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMEYyNDNFIj4mZ3Q7IElmIHNvLCBJIGJlbGlldmUgdGhhdCB0aGlzIGlz IGltcHJhY3RpY2FibGUgaW4gdGhlIGNvcmUgc2NoZW1hLiZuYnNwO0luZGVlZCBpdCBpbXBsaWVz IHRoYXQgYSBzZXJ2aWNlIHByb3ZpZGVyIG11c3QgZXh0ZW5kIHRoZSBzY2hlbWEgb2YgaGlzIGFj Y291bnQgcmVwb3NpdG9yeQ0KIChMREFQIHBhcnRpdGlvbiwgU1FMIGRiLCAmIzgyMzA7KSBhbmQg JiM4MjIwO3ByZXBhcmUgaXQmIzgyMjE7IGZvciBTQ0lNIGludGVncmF0aW9uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5PyBUaGF0IGRvZXNuJ3QgbmVjZXNz YXJpbHkgZm9sbG93LiBJbXBsZW1lbnRhdGlvbiBpcyBpbmRlcGVuZGVudCBvZiByZXByZXNlbnRh dGlvbi4gV2UncmUgdGFsa2luZyBhYm91dCBhIGNoYW5nZSBpbiByZXByZXNlbnRhdGlvbiB0byBt YWtlIHRoZSBBUEkgY2xlYW5lci48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgYSBzaW1wbGUgZXhhbXBsZSwgaWYgYW4gTERBUCBub2RlIGlzIGJlaW5nIHVzZWQg dG8gaG9sZCBhIGxpc3Qgb2YgY29tbWEtc2VwYXJhdGVkIGVtYWlsIGFkZHJlc3NlcywgaXQgY2Fu IGp1c3QgYXMgZWFzaWx5IHN0b3JlIGNvbW1hLXNlcGFyYXRlZCBuYW1lLXZhbHVlIHBhaXJzLjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5tYWlsOiA8YSBocmVm PSJtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huX3NtaXRo QHlhaG9vLmNvbTwvYT4sIDxhIGhyZWY9Im1haWx0bzpqb2huLnNtaXRoQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmpvaG4uc21pdGhAZ21haWwuY29tPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpz bWl0aDE5NzBAaG90bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qc21pdGgxOTcwQGhvdG1haWwu Y29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+Y2FuIGJlIGNoYW5nZWQg dG88L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+bWFpbDombmJzcDthYTY2 LWRhZjllYTNiZDkwMj08YSBocmVmPSJtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdl dD0iX2JsYW5rIj5qb2huX3NtaXRoQHlhaG9vLmNvbTwvYT4sOWNkYS04NjQ2YzMwODViYmY9PGEg aHJlZj0ibWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9obi5z bWl0aEBnbWFpbC5jb208L2E+LCZuYnNwOzdhNmQxZGU2NjRlMT08YSBocmVmPSJtYWlsdG86anNt aXRoMTk3MEBob3RtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpzbWl0aDE5NzBAaG90bWFpbC5j b208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5UaGF0J3Mgd2h5IEkgYXNrZWQg aWYgdGhlcmUgd2FzIGFuIFNQIHJlcHJlc2VudGF0aXZlIG9uIHRoaXMgd29ya2luZyBncm91cCB3 aG8gY291bGQgZXhwbGFpbiB3aGF0IHN1Y2ggYSBjaGFuZ2UgY291bGQgbWVhbiBmb3IgdGhlbS4g QXMgb2Ygbm93LCBpdCBsb29rcyBsaWtlIG90aGVyIHBlb3BsZSBhcmUgcHJlc3VtaW5nIHRoYXQN CiBTUHMgd2lsbCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlc2UgY2hhbmdlcyBlYXNpbHkg YW5kIGFyZSByZWplY3RpbmcgdGhlbSBmb3IgdGhhdCByZWFzb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyAiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsgIj5HYW5lc2g8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDEzIEF1Z3VzdCAyMDEyIDA0OjI5LCBFbW1hbnVlbCBEcmV1eCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVkcmV1eEBjbG91ZGl3YXkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWRyZXV4QGNsb3Vk aXdheS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w7A8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7IDwvc3Bhbj4NCmFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0 LW51bWJlciA9ICIyNDMiPHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMTUs IDM2LCA2Mik7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPldoZXJlIHdvdWxk DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+M2NiYWFmZjhlODRlPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMEYyNDNFIj4gY29tZSBmcm9tPyBXb3VsZCBpdCBoYXZlIHRvIGJlIHN0 b3JlZCBvbiB0aGUgYWNjb3VudCBkYXRhYmFzZSBvZiB0aGUgc2VydmljZSBwcm92aWRlcj88L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMEYyNDNFIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMEYyNDNFIj5JZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbXBy YWN0aWNhYmxlIGluIHRoZSBjb3JlIHNjaGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhhdCBhIHNl cnZpY2UgcHJvdmlkZXIgbXVzdCBleHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCByZXBv c2l0b3J5DQogKExEQVAgcGFydGl0aW9uLCBTUUwgZGIsICYjODIzMDspIGFuZCAmIzgyMjA7cHJl cGFyZSBpdCYjODIyMTsgZm9yIFNDSU0gaW50ZWdyYXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzBGMjQzRSI+VGhpcyB3b3VsZCBiZSBhIHNob3cgc3RvcHBlci4gU0NJTSBtdXN0 IGJlIHRyYW5zcGFyZW50LCBhbmQgbXVzdCBiZSBhYmxlIHRvIGJlIHB1dCBvbiB0b3Agb2YgYW4g ZXhpc3Rpbmcgc3lzdGVtIHRvIHByb3ZpZGUgcHJvdmlzaW9uaW5nIGFwaXMuPC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzBGMjQzRSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzBGMjQzRSI+U2FpZCBkaWZmZXJlbnRseSwgU0NJTSBtdXN0IG5vdCBiZSBpbnRydXNp dmUgZm9yIGV4aXN0aW5nIHN5c3RlbXMgYW5kIG11c3Qgbm90IHJlcXVpcmUgbW9kaWZpY2F0aW9u cyB0byBhbGxvdyBpdHMgaW50ZWdyYXRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzBGMjQzRSI+Q29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBzdWdnZXN0aW9uLjwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwRjI0M0UiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPi0tPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+RW1tYW51ZWwgRHJldXg8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGEgaHJlZj0iaHR0cDovL3d3 dy5jbG91ZGl3YXkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5jbG91ZGl3YXkuY29t PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Ij5UZWw6DQo8YSBocmVmPSJ0ZWw6JTJCMzMlMjA0JTIwMjYlMjA3OCUyMDE3JTIwNTgiIHRhcmdl dD0iX2JsYW5rIj4rMzMgNCAyNiA3OCAxNyA1ODwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+TW9iaWxlOg0KPGEgaHJlZj0idGVsOiUyQjMz JTIwNiUyMDQ3JTIwODElMjAyNiUyMDcwIiB0YXJnZXQ9Il9ibGFuayI+KzMzIDYgNDcgODEgMjYg NzA8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyAiPnNreXBlOiBFbW1hbnVlbC5EcmV1eDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1m YW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5z LXNlcmlmOyAiPiBHYW5lc2ggYW5kDQogU2FzaGkgUHJhc2FkIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmcuYy5wcmFzYWRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Zy5jLnByYXNhZEBnbWFp bC5jb208L2E+XQ0KPGJyPjxiPkVudm95w6kmbmJzcDs6PC9iPiBkaW1hbmNoZSAxMiBhb8O7dCAy MDEyIDA0OjUzPGJyPjxiPsOAJm5ic3A7OjwvYj4gS2VsbHkgR3JpenpsZTxicj48Yj5DYyZuYnNw Ozo8L2I+IDxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2Np bUBpZXRmLm9yZzwvYT47IFBoaWwgSHVudDxicj48Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2Np bV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAyNDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyBiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNr Z3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBi YWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBmb250LWZh bWlseTogVGFob21hLCBzYW5zLXNlcmlmOyBiYWNrZ3JvdW5kLXBvc2l0aW9uOiBpbml0aWFsIGlu aXRpYWw7IGJhY2tncm91bmQtcmVwZWF0OiBpbml0aWFsIGluaXRpYWw7ICI+TXVsdGktdmFsdWVk IGF0dHJpYnV0ZXMgdGhhdCBkb24ndCBoYXZlIGEgdmFsdWUgc3ViLWF0dHJpYnV0ZSAoZWcgLSBh ZGRyZXNzKSBoYXZlIHRvIHNwZWNpZmllZCBjb21wbGV0ZWx5IGZvciB1bmlxdWVuZXNzLiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+VGhhdCdzIGV4YWN0bHkgdGhlIHBvaW50LiBIb3cgZG8gd2UgInNwZWNpZnkgY29tcGxldGVs eSBmb3IgdW5pcXVlbmVzcyI/PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+SW4g dGhlIGV4YW1wbGUgYmVsb3csIGhvdyBhcmUgeW91IHByb3Bvc2luZyB0aGF0IHRoZSBmb2xsb3dp bmcgZWxlbWVudCBiZSB1cGRhdGVkIGlmIHdlIGNhbid0IHVzZSBwb3NpdGlvbmFsIGluZGV4ZXM/ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+YWRkcmVzc2VzWzFdLnN0cmVldC1u dW1iZXIgPSAiMjQzIjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlVzZXIgb2Jq ZWN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ezxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOyAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgYWRkcmVzc2VzOiBbPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJGUiI+Jm5ic3A7ICZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg InR5cGUiIDogImhvbWUiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJzdHJl ZXQtbnVtYmVyIiA6ICIzNSIsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInN0 cmVldC1uYW1lIiA6ICJIaWdoIFJvYWQiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICJzdWJ1cmIiIDogIkVhc3QgQ2FtZGVuIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAicG9zdGNvZGUiIDogIjUzNDYiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICJzdGF0ZSIgOiAiU0EiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyB9LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICJ0eXBlIiA6ICJvZmZpY2UiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICJzdHJlZXQtbnVtYmVyIiA6ICIyMTMiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICJzdHJlZXQtbmFtZSIgOiAiTWFpbiBTdHJlZXQiLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICJzdWJ1cmIiIDogIkFkZWxhaWRlIiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAicG9zdGNvZGUiIDogIjUwMDAiLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICJzdGF0ZSIgOiAiU0EiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZu YnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7IF08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj59PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+SXQncyBpbXByYWN0aWNhbCB0byB1c2UgdGhlIHZhbHVl IGJlY2F1c2UgaXQncyB0aGUgd2hvbGUgZGljdGlvbmFyeSBlbGVtZW50OjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ezxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAidHlwZSIg OiAib2ZmaWNlIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgInN0cmVldC1udW1iZXIiIDogIjIxMyIs PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICJzdHJlZXQtbmFtZSIgOiAiTWFpbiBTdHJlZXQiLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOyAic3VidXJiIiA6ICJBZGVsYWlkZSIsPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5i c3A7ICJwb3N0Y29kZSIgOiAiNTAwMCIsPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICJzdGF0ZSIgOiAi U0EiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAiY291bnRyeSIgOiAiQXVzdHJhbGlhIjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPn08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5XaXRoIG15 IHByb3Bvc2FsLCB0aGUgImFkZHJlc3NlcyIgYXJyYXkgZ2V0cyBjb252ZXJ0ZWQgdG8gYSBkaWN0 aW9uYXJ5LCBhbmQgdGhlbiB3ZSBoYXZlIGEgc3RhYmxlIHdheSBvZiByZWZlcmVuY2luZyB0aGlz IGVsZW1lbnQ6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5hZGRyZXNz ZXMuM2NiYWFmZjhlODRlLnN0cmVldC1udW1iZXIgPSAiMjQzIjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRlIiPns8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgLi4uPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7IGFkZHJlc3NlczogezxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgImQ2ZWEzNjU0 NjJmNSIgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgezxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICJ0eXBlIiA6ICJob21lIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAic3RyZWV0LW51bWJlciIgOiAiMzUiLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICJzdHJlZXQtbmFtZSIgOiAiSGlnaCBSb2FkIiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAic3VidXJiIiA6ICJFYXN0IENhbWRlbiIsPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInBvc3Rjb2RlIiA6ICI1MzQ2Iiw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAic3RhdGUiIDogIlNBIiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAiY291bnRyeSIgOiAiQXVzdHJhbGlhIjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOyAmbmJzcDsgfSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7ICIzY2JhYWZmOGU4NGUi IDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAidHlwZSIgOiAib2ZmaWNlIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAic3RyZWV0LW51bWJlciIgOiAiMjEzIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAic3RyZWV0LW5hbWUiIDogIk1haW4gU3RyZWV0Iiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAic3VidXJiIiA6ICJBZGVsYWlkZSIsPG86cD48L286cD48L3Nw YW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInBvc3Rjb2RlIiA6ICI1MDAwIiw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAic3RhdGUiIDogIlNBIiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAiY291bnRyeSIgOiAiQXVzdHJhbGlhIjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyB9PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+fTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSdyZSBwcm9wb3Npbmcgb25lIG1lY2hh bmlzbSBmb3IgY29tcG9zaXRlIGF0dHJpYnV0ZXMgYW5kIGFub3RoZXIgbWVjaGFuaXNtIGZvciBz aW1wbGUgYXR0cmlidXRlcywgSSB3b3VsZCBzdWdnZXN0IHRoYXQncyBhY3R1YWxseSBtb3JlIGNv bXBsZXggdGhhbiBhZG9wdGluZw0KIGEgc2luZ2xlIG1lY2hhbmlzbSB0aGF0IHdvcmtzIHRoZSBz YW1lIHdheSBmb3IgX2FsbF8gYXR0cmlidXRlcy4gUmVtZW1iZXIgdGhhdCBhIGxvdCBvZiB0aGUg YWRtaW5pc3RyYXRpb24gaXMgcHJvYmFibHkgZ29pbmcgdG8gYmUgc2NyaXB0ZWQgcmF0aGVyIHRo YW4gZG9uZSBieSBoYW5kLCBhbmQgaGF2aW5nIHR3byBtZWNoYW5pc21zIChkZXBlbmRpbmcgb24g d2hldGhlciB0aGUgYXR0cmlidXRlIGlzIHNpbXBsZSBvciBjb21wb3NpdGUpIHdpbGwNCiBjb21w bGljYXRlIGV2ZXJ5IHNjcmlwdCB0aGF0IGhhcyB0byBiZSB3cml0dGVuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlRoZXJlJ3MgYSBsb3Qgb2YgdGFsayBhYm91dCB0 aGUgImJ1cmRlbiIgb24gdGhlIFNQcywgYnV0IEkgYmVsaWV2ZSB0aGlzIGlzIG92ZXJibG93bi4g SXMgdGhlcmUgYW55IFNQIHJlcHJlc2VudGF0aXZlIGluIHRoaXMgV0cgd2hvIGNhbiB0ZWxsIHVz IHdoYXQgdGhpcyBwcm9wb3NhbA0KIHdpbGwgYWN0dWFsbHkgZW50YWlsIGZvciB0aGVtPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+R2Fu ZXNoPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPk9uIDEyIEF1Z3VzdCAyMDEyIDExOjUzLCBLZWxs eSBHcml6emxlICZsdDs8YSBocmVmPSJtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+R2FuZXNoLDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 ICI+VGhpcyBpcyBleGFjdGx5IGhvdyBQQVRDSCB3b3JrcyBpbiBTQ0lNIDEuMC4gJm5ic3A7TXVs dGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBoYXZlIGEgdmFsdWUgc3ViLWF0dHJpYnV0ZQ0KIGNh biBiZSByZW1vdmVkIGJ5IHNwZWNpZnlpbmcgb25seSB0aGUgdmFsdWUgc2luY2UgaXQgaXMgdW5p cXVlLiAmbmJzcDtNdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB0aGF0IGRvbid0IGhhdmUgYSB2YWx1 ZSBzdWItYXR0cmlidXRlIChlZyAtIGFkZHJlc3MpIGhhdmUgdG8gc3BlY2lmaWVkIGNvbXBsZXRl bHkgZm9yIHVuaXF1ZW5lc3MuICZuYnNwO0FzIEkgaGF2ZSBzYWlkIGJlZm9yZSwgSSBhbSB2ZXJ5 IG9wcG9zZWQgdG8gYWRkaW5nIGEgdW5pcXVlIGlkZW50aWZpZXINCiB0byBlYWNoIGVsZW1lbnQg aW4gYSBtdWx0aS12YWx1ZWQgY29sbGVjdGlvbiBkdWUgdG8gdGhlIGJ1cmRlbiBpdCB3aWxsIHB1 dCBvbiBTUHMuICZuYnNwO0lzIGl0IGVsZWdhbnQ/ICZuYnNwO05vLiAmbmJzcDtJcyBpdCBmdW5j dGlvbmFsPyAmbmJzcDtZZXMuICZuYnNwO1dpbGwgdGhpcyBub24tZWxlZ2FuY2UgYWZmZWN0IGFk b3B0aW9uPyAmbmJzcDtNeSBvcGluaW9uIGlzIHRoYXQgYWRkaW5nIHVuaXF1ZSBrZXlzIHRvIGVh Y2ggZWxlbWVudCB3aWxsIGhhdmUgYSBtdWNoIG1vcmUgZGV0cmltZW50YWwNCiBlZmZlY3Qgb24g YWRvcHRpb24uPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5JIGRvIGJlbGlldmUgdGhhdCBp biBnZW5lcmFsIFBBVENIIGNhbiBiZSBtYWRlIG1vcmUgaW50dWl0aXZlIHdpdGhvdXQgYWRkaW5n IHVpZHMgdG8gZWFjaCBlbGVtZW50LiAmbmJzcDtUaGUNCiB2ZXJicyB0aGF0IHlvdSBwcm9wb3Nl IG1ha2Ugc2Vuc2UuICZuYnNwO1RoZXJlIGlzIGFsc28gYSBKU09OIFBhdGNoIGluZm9ybWF0aW9u YWwgZHJhZnQgaW4gdGhlIElFVEYgdGhhdCBpcyBpbnRlcmVzdGluZyAtJm5ic3A7PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gt MDIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LWFwcHNhd2ctanNvbi1wYXRjaC0wMjwvYT4uDQogJm5ic3A7SXQgcmVsaWVzIG9uIGEgSlNPTiBQ b2ludGVyIGRyYWZ0IHdoaWNoIHVzZXMgaW5kZXgtYmFzZWQgYWRkcmVzc2luZyBmb3IgbXVsdGkt dmFsdWVkIGF0dHJpYnV0ZXMuICZuYnNwO0kgdGhpbmsgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0 aGF0IHNob3VsZCBiZSBsb29rZWQgYXQgd2l0aGluIHRoZSBXRyBhbmQgSSB3b3VsZCBiZSB3aWxs aW5nIHRvIGxlYWQgdGhpcyBlZmZvcnQuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNl cmlmOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5JJ20g Y3VyaW91cyBpZiBhbnlvbmUgZWxzZSBpbiB0aGUgV0cgaXMgaW4gZmF2b3Igb2YgdW5pcXVlIGlk ZW50aWZpZXJzIGZvciBldmVyeSBtdWx0aS12YWx1ZWQgZWxlbWVudC48L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBz YW5zLXNlcmlmOyAiPi0tS2VsbHk8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRp diBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50 ZXIiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGhyIHNpemU9IjIi IHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj48L3NwYW4+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fu cy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZh bWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBo cmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbS1i b3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2Fk IFs8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5n LmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgQXVndXN0 IDExLCAyMDEyIDEwOjUwIEFNPGJyPjxiPlRvOjwvYj4gUGhpbCBIdW50PGJyPjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYu b3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgs IElzc3VlIDI0PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ UGhpbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlRoZSByZWFzb24gd2UgY2Fubm90 IHVzZSB0aGUgdmFsdWUgaXRzZWxmIHRvIGlkZW50aWZ5IGFuIGVsZW1lbnQgaXMgdGhhdCB0aGlz IG1ldGhvZCB3aWxsIG9ubHkgd29yayBmb3Igc2ltcGxlIGVsZW1lbnRzLCBub3QgZm9yIG5lc3Rl ZCBzdHJ1Y3R1cmVzLiBpLmUuLCBpZiB3ZSBoYWQNCiBhbiBhcnJheSBvZiBkaWN0aW9uYXJpZXMg KGUuZy4sIHdlIGhhZCB0byByZWNvcmQgYW4gYXJyYXkgb2YgYWRkcmVzc2VzIGZvciBlYWNoIGN1 c3RvbWVyLCB3aXRoIGVhY2ggYWRkcmVzcyBlbGVtZW50IGhhdmluZyBzdWItZWxlbWVudHMgbGlr ZSBzdHJlZXQgbnVtYmVyLCBzdHJlZXQgbmFtZSwgc3VidXJiLCBldGMuKSwgdGhlbiBpdCB3b3Vs ZCBiZSBjbHVtc3kgdG8gc3VwcGx5IHRoZSBlbnRpcmUgdmFsdWUgb2YgdGhlIGFycmF5IGVsZW1l bnQNCiBiZWNhdXNlIGl0J3MgaXRzZWxmIGEgZGljdGlvbmFyeS4gQ3JlYXRpbmcgYSB1bmlxdWUg a2V5IGZvciBlYWNoIGVsZW1lbnQgc2NhbGVzIGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPkdhbmVzaDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPk9uIDEyIEF1Z3Vz dCAyMDEyIDAxOjEyLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3Jh Y2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+R2FuZXNoLA0KPG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+SGVyZSdz IHRoZSBzYW1wbGUgdGhhdCBjb25jZXJuZWQgbWUuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+ VGhlIHR3byBvcGVyYXRpb25zIGRpZmZlciBzaWduaWZpY2FudGx5LCBhbmQgaXQncyBub3QgdmVy eSBpbnR1aXRpdmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+V2l0aCBteSBzdWdnZXN0aW9uLCBoZXJl J3MgaG93IHRvIGRlbGV0ZSBhIHNpbmdsZSBtZW1iZXIgZnJvbSBhIGdyb3VwOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZh bWlseTogJ0NvdXJpZXIgTmV3JzsgIj5QQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1i NGZkLTliNGRhM2Y5MDhjZSBIb3N0Og0KPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tLyIgdGFy Z2V0PSJfYmxhbmsiPmV4YW1wbGUuY29tPC9hPiBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24gQXV0 aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOCBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzki IHs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4ib3BlcmF0aW9ucyIgOiBbPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVw dDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ezwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyAiPiJSRVRJUkUiIDogezwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyAiPiJrZXkiIDogIm1lbWJlcnMuMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2 Ijwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTog OC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPn08L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj59PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+XSB9 DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Js b2NrcXVvdGU+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj5Zb3Ug Z2F2ZSBvdGhlciBleGFtcGxlcyBvZiBhbiBhdHRyaWJ1dGUgd2l0aCBhbiBpZGVudGlmaWVyIHRo YXQgbWF0Y2hlZCB0aGF0IHZhbHVlIG9yIG9mIGlkZW50aWZpZXJzIHRoYXQgd2VyZQ0KIGFkZGl0 aW9uYWwgdW5pcXVlIGtleXMuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6 ICdDb3VyaWVyIE5ldyc7ICI+R2l2ZW4gdGhhdCBtdWx0aS12YWx1ZXMgbXVzdCBiZSBlYWNoIHVu aXF1ZSwgSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIHRoZSBleHRyYSBpbmRleGluZyB0byBzdXBw b3J0IHRoaXMuIEp1c3QNCiB1c2UgdGhlIHZhbHVlIGFzIHRoZSBpdGVtIHlvdSB3aXNoIHRvIGRl bGV0ZS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj5JIGFncmVlLCB0aGUgZGVsZXRlIHZhbHVlIG9wZXJhdGlvbiBjb3VsZCBiZSBtb3JlIGV4 cGxpY2l0IGFuZCBjbGVhciBpbiBnZW5lcmFsLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2 PjxkaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNl cmlmOyAiPlBoaWw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj5AaW5kZXBlbmRlbnRp ZDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTog OXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyAiPjxhIGhyZWY9Imh0dHA6 Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20iIHRhcmdldD0iX2JsYW5rIj53d3cuaW5kZXBlbmRlbnRp ZC5jb208L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTMuNXB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNhLCBzYW5zLXNlcmlm OyAiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+T24gMjAxMi0wOC0xMSwgYXQgMjozMCBBTSwg R2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7IEZv ciB0aGUgbXVsdGktdmFsdWUgZXhhbXBsZSB5b3UgZ2F2ZSB5b3UgdXNlZCB0aGUgdmFsdWUgYXMg dGhlIGF0dHJpYnV0ZSBuYW1lIGtleS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RlIiPk5vdyBJJ20gY29uZnVzZWQgOi0pLiBJIGRvbid0IGJlbGlldmUgYW55IG9mIG15IGV4YW1w bGVzIGV2ZXIgdXNlZCBhIHZhbHVlIGFzIHRoZSBrZXkuPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+Q291bGQgeW91IHBsZWFzZSBzaG93IG1lIHdoaWNoIGV4YW1wbGUgeW91IG1l YW4sIGFuZCB3aGljaCBwYXJ0cyBvZiBpdCB5b3UgYmVsaWV2ZSB0byBiZSB0aGUgdmFsdWU/PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5HYW5lc2gm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj5PbiAxMSBBdWd1c3QgMjAxMiAxMzo1OSwgUGhpbCBIdW50ICZsdDs8YSBo cmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1 bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+PGJyPg0KRm9yIHRoZSBt dWx0aS12YWx1ZSBleGFtcGxlIHlvdSBnYXZlIHlvdSB1c2VkIHRoZSB2YWx1ZSBhcyB0aGUgYXR0 cmlidXRlIG5hbWUga2V5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PlRoYXQgbWVhbnMgYSBsb3QgbW9yZSBjb21wbGV4IGluZGV4aW5nIHN0cnVjdHVyZS4gQmV0dGVy IHRvIGp1c3Qgc2F5IGRlbGV0ZSBhIHNwZWNpZmljIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPlRoZSBzcGVjIGFscmVhZHkgYWxsb3dzIG11bHRpcGxlIHZh bHVlcyB0byBoYXZlIHRhZ3MgbGlrZSBob21lLCB3b3JrLCBldGMuPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImNvbG9yOiM4ODg4ODgiPlBoaWw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkZSIj48YnI+DQpPbiAyMDEyLTA4LTEwLCBhdCAyMTo0NSwgR2FuZXNoIGFu ZCBTYXNoaSBQcmFzYWQgJmx0OzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPjxkaXY+PGRpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZndDsmbmJzcDtJbiB5b3VyIGV4YW1wbGUg eW91IGFyZSBjb25mbGF0aW5nIHZhbHVlIHdpdGggYW4gYXR0cmlidXRlIGlkLiZuYnNwOzxicj48 YnI+DQpJIGRvbid0IGJlbGlldmUgc28uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPkkn bSBhZG9wdGluZyBhIG1vZGVsIHdoZXJlIGV2ZXJ5IGF0dHJpYnV0ZSBvZiB0aGUgcmVzb3VyY2Ug aXMgYSBrZXktdmFsdWUgcGFpci4gVGhlIGtleSBpcyBhIG5hbWUgb3IgSUQuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Rm9yIG5vbi1yZXBlYXRpbmcgYXR0cmlidXRlcyAoYm90 aCBzaW1wbGUgYW5kIGNvbXBvc2l0ZSksIHRoZSBrZXkgaXMgdGhlIGF0dHJpYnV0ZSBuYW1lIGl0 c2VsZi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlNpbXBs ZSBhdHRyaWJ1dGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+S2V5OiAiZG9i IjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRlIiPlZhbHVlOiAiMDEgSmFuIDE5NzAiPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGUiI+Rm9yIGNvbXBvc2l0ZSBhdHRyaWJ1dGVzLCB0aGUga2V5IGVt cGxveXMgZG90IG5vdGF0aW9uIHRvIHNwZWNpZnkgdGhlIGZ1bGx5LXF1YWxpZmllZCBhdHRyaWJ1 dGUgbmFtZSwgZS5nLiwgImFkZHJlc3MucG9zdGNvZGUiLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiPkNvbXBvc2l0ZSBhdHRyaWJ1dGU6PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+S2V5OiAiYWRkcmVzcy5zdHJlZXQtbnVtYmVyIjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlZh bHVlOiAiMTAiPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+S2V5OiAiYWRkcmVz cy5zdWJ1cmIiPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+VmFsdWU6ICJFYXN0IENhbWRlbiI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5Gb3IgcmVwZWF0aW5nIChtdWx0aS12YWx1ZWQpIGF0dHJp YnV0ZXMsIEknbSBzdWdnZXN0aW5nIHRoYXQgdGhlcmUgYmUgbmV3IGtleXMgZm9yIGVhY2ggaW5k aXZpZHVhbCB2YWx1ZSwgb3RoZXJ3aXNlIHRoZXkgYXJlIGltcG9zc2libGUgdG8gZGlzdGluZ3Vp c2gsIGFuZCBhIHBvc2l0aW9uYWwNCiBpbmRleCBpcyBpbmFkZXF1YXRlLiBTbyB3ZSBjb252ZXJ0 IHRoZSBhcnJheSBpbnRvIGEgZGljdGlvbmFyeSBhbmQgdGhpcyB0aGVuIGJlY29tZXMgYSBjb21w b3NpdGUgYXR0cmlidXRlIHVzaW5nIGRvdCBub3RhdGlvbiBmb3IgdGhlIGtleS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5NdWx0aS12YWx1ZWQgYXR0cmlidXRlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPktleTogImVtYWlscy43ZGZjYjQ0NC03NGQ4LTRm MTctYWE2Ni1kYWY5ZWEzYmQ5MDIiPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+VmFsdWU6ICI8YSBocmVmPSJtYWls dG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huX3NtaXRoQHlhaG9v LmNvbTwvYT4iPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+U28gdGhpcyBhbGxv d3MgdXMgdG8gYXBwbHkgdW5pZm9ybSB0cmVhdG1lbnQgdG8gYW55IGFyYml0cmFyaWx5IGRlZXAg cmVzb3VyY2Ugc3RydWN0dXJlLiBXZSBjYW4gcmVmZXIgdG8gZXZlcnkgbGVhZiB2YWx1ZSB3aXRo IGEga2V5IHRoYXQgaXMgdGhlIGZ1bGx5LXF1YWxpZmllZA0KIG5hbWUgdXNpbmcgZG90IG5vdGF0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlRoZSB2ZXJicyBhcmUganVz dCB1bmFtYmlndW91cyBvcGVyYXRpb25zIG9uIHRoZXNlIChub3cpIGV4cGxpY2l0bHkgYWRkcmVz c2FibGUgYXR0cmlidXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5JTkNM VURFIHRvIGEgY29sbGVjdGlvbiBhbmQgc3BlY2lmeSBvbmx5IHRoZSB2YWx1ZS4gVGhlIGtleSBp cyBnZW5lcmF0ZWQgYW5kIHJldHVybmVkLiBUaGUgZnVsbHktcXVhbGlmaWVkIGtleSBpcyAmbHQ7 Y29sbGVjdGlvbi1uYW1lJmd0Oy4mbHQ7bmV3bHktZ2VuZXJhdGVkLUlEJmd0OyBhbmQgdGhlDQog dmFsdWUgaXMgd2hhdCB3YXMgc3BlY2lmaWVkIGluIHRoZSBJTkNMVURFLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPlJFUExBQ0UgYSBmdWxseS1xdWFsaWZpZWQga2V5IHdpdGgg YSBuZXcgdmFsdWUuIElmIHRoZSBrZXkgZG9lc24ndCBleGlzdCwgcmV0dXJuIGEgIjQwNCBOb3Qg Rm91bmQiLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlBMQUNFIGEgdmFsdWUg YXQgdGhlIGxvZ2ljYWwgbG9jYXRpb24gaW1wbGllZCBieSB0aGUgZnVsbHktcXVhbGlmaWVkIGtl eS4gSWYgdGhlcmUgaXMgYWxyZWFkeSBhIGtleSB3aXRoIHRoYXQgbmFtZSwgcmV0dXJuIGEgIjQw OSBDb25mbGljdCIuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Rk9SQ0UgdGhl IGZ1bGx5LXF1YWxpZmllZCBrZXkgdG8gaG9sZCB0aGUgZ2l2ZW4gdmFsdWUsIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlciBpdCBleGlzdGVkIGJlZm9yZSBvciBub3QuIE9ubHkgZXJyb3JzIHBvc3NpYmxl IGFyZSAiNDAwIEJhZCBSZXF1ZXN0IiBhbmQgIjUwMCBJbnRlcm5hbA0KIEVycm9yIi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5SRVRJUkUgYW4gYXR0cmlidXRlIG9yIGEgY29s bGVjdGlvbiBnaXZlbiBpdHMgZnVsbHktcXVhbGlmaWVkIGtleS4gVGhlIGltcGxlbWVudGF0aW9u IHdpbGwgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGF0dHJpYnV0ZSB3aWxsIGRpc2FwcGVhciBlbnRp cmVseSBvciB3aWxsIGV4aXN0DQogaG9sZGluZyBhIG51bGwgdmFsdWUgKHRoZSBibGFuayBzdHJp bmcgIiIgb3IgdGhlIGVtcHR5IG9iamVjdCB7fSApLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRlIiPkknbGwgZXhwbGFpbiBpbiBhIHNlcGFyYXRlIHBvc3Qgd2h5IHdlIG5lZWQgb3Bl cmF0aW9uIHZlcmJzIGxpa2UgdGhlc2UgdGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlIEhUVFAg dmVyYnMuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZSIj5HYW5lc2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5PbiAxMSBBdWd1c3Qg MjAxMiAxMDozOCwgJmx0OzxhIGhyZWY9Im1haWx0bzpzY2ltLXJlcXVlc3RAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zY2ltLXJlcXVlc3RAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwg bWVzc2FnZTxicj4NCmF0dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGln ZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0PGJyPg0Kc3Vic2NyaXB0aW9uLiAmbmJzcDtUbyBkbyBz bywgZ28gdG88YnI+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2NpbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2NpbTwvYT48YnI+PGJyPg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0 IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQ8YnI+DQpNSU1FIG9yIFBsYWlu IFRleHQgRGlnZXN0cz8iIHRvIE1JTUUuICZuYnNwO1lvdSBjYW4gc2V0IHRoaXMgb3B0aW9uPGJy Pg0KZ2xvYmFsbHkgZm9yIGFsbCB0aGUgbGlzdCBkaWdlc3RzIHlvdSByZWNlaXZlIGF0IHRoaXMg cG9pbnQuPGJyPjxicj48YnI+PGJyPg0KU2VuZCBzY2ltIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9u cyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPjxicj4NClRv IHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdDxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PGJyPg0Kb3IsIHZpYSBlbWFpbCwgc2Vu ZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpzY2ltLXJlcXVlc3RAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5zY2ltLXJlcXVlc3RAaWV0Zi5vcmc8L2E+PGJyPjxicj4NCllvdSBj YW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86c2NpbS1vd25lckBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNjaW0tb3duZXJAaWV0Zi5vcmc8L2E+PGJyPjxicj4NCldoZW4gcmVwbHlp bmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8 YnI+DQp0aGFuICJSZTogQ29udGVudHMgb2Ygc2NpbSBkaWdlc3QuLi4iPGJyPjxicj4NClRvZGF5 J3MgVG9waWNzOjxicj48YnI+DQombmJzcDsgJm5ic3A7MS4gUmU6IFNDSU0gUHJvdG9jb2wgLSAz IHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVudCAoUGhpbCBIdW50KTxicj48YnI+PGJyPg0KLS0t LS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtQaGls IEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDs8YnI+DQpUbzombmJzcDtHYW5lc2gg YW5kIFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCkNjOiZu YnNwOyJEaW9kYXRpLCBNYXJrIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcmsuRGlvZGF0aUBnYXJ0 bmVyLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1hcmsuRGlvZGF0aUBnYXJ0bmVyLmNvbTwvYT4mZ3Q7 LCBFbW1hbnVlbCBEcmV1eCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkcmV1eEBjbG91ZGl3YXkuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZWRyZXV4QGNsb3VkaXdheS5jb208L2E+Jmd0OywgVHJleSBEcmFr ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRyZXkuZHJha2VAdW5ib3VuZGlkLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnRyZXkuZHJha2VAdW5ib3VuZGlkLmNvbTwvYT4mZ3Q7LA0KIEtlbGx5IEdyaXp6bGUg Jmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iIHRhcmdldD0i X2JsYW5rIj5rZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208L2E+Jmd0OywgIjxhIGhyZWY9Im1h aWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBpZXRmLm9yZzwvYT4iICZs dDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6Jm5ic3A7RnJpLCAxMCBBdWcgMjAxMiAxNzozNjo1NCAt MDcwMDxicj4NClN1YmplY3Q6Jm5ic3A7UmU6IFtzY2ltXSBTQ0lNIFByb3RvY29sIC0gMyBzdWdn ZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+R2FuZXNoLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPkluIHlvdXIgZXhhbXBsZSB5b3UgYXJlIGNvbmZs YXRpbmcgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgaWQuIEkgZmluZCB0aGF0IGNvbmZ1c2luZy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5JIGFncmVlIHRob3VnaCB0 aGF0IG9wZXJhdGlvbnMgaW4gcGF0Y2ggY291bGQgYmUgYSBsb3QgbW9yZSBleHBsaWNpdC4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5FZyBleHBsaWNpdGx5IGRlbGV0 aW5nIGEgdmFsdWUgYnkgc2F5aW5nIGRlbGV0ZSBvciByZXRpcmUuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+PGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCk9uIDIwMTItMDgtMTAsIGF0IDE2OjE5LCBHYW5l c2ggYW5kIFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOiAxMS41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JIGFtIGNvbmNlcm5lZCBhYm91dCB5b3Vy IHNlY29uZCBzdWdnZXN0aW9uOjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5MZXQncyBkaXNjdXNzIHRoYXQgbm93LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlRoZSB0cmFkZS1vZmZzIGFyZSB2ZXJ5IGNsZWFyIGhl cmUuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+UHJvczo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5Qcm8gMS4gVGhlIEFQSSB0byBtYW5pcHVsYXRlIHJlc291 cmNlcyBiZWNvbWVzIHNvIG11Y2ggY2xlYW5lciwgY29uc2lzdGVudCBhbmQgaW50dWl0aXZlIHdo ZW4gZXZlcnkgaW5kaXZpZHVhbCBhdHRyaWJ1dGUgdmFsdWUgZ2V0cyBpdHMgb3duIElELjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPkhlcmUncyBob3cgdG8gZGVsZXRlIGEgc2lu Z2xlIG1lbWJlciBmcm9tIGEgR3JvdXAsIGFzIHBlciB0aGUgY3VycmVudCBzcGVjOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwcmU+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgUEFUQ0ggL0dy b3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4Y2U8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgSG9zdDogPGEgaHJlZj0iaHR0cDovL2V4 YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmV4YW1wbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pz b248L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgQXV0aG9y aXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkODwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyZuYnNwOyBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzkiPC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6 Y29yZToxLjAiXSw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgIm1lbWJlcnMiOiBbPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgImRpc3BsYXkiOiAiQmFicyBKZW5zZW4iLDwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAidmFsdWUiOiAiMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2 Ijwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAib3BlcmF0aW9uIjogImRlbGV0ZSI8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBdPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCkhlcmUncyBob3cgdG8g ZGVsZXRlIEFMTCBtZW1iZXJzIGZyb20gYSBncm91cCBhY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQg c3BlYzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5i c3A7IFBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IEhvc3Q6IDxhIGhy ZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5leGFtcGxlLmNvbTwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgQWNjZXB0OiBh cHBsaWNhdGlvbi9qc29uPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7 Jm5ic3A7IEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDg8L3NwYW4+PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgRVRhZzogVy8iYTMzMGJjNTRmMDY3MWM5 Ijwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyB7PC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJzY2hlbWFzIjogWyJ1cm46 c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJtZXRhIjogezwvc3Bhbj48c3BhbiBsYW5nPSJG UiI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiYXR0 cmlidXRlcyI6IFs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl PjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIm1lbWJlcnMiPC9zcGFuPjxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IF08L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxw cmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZu YnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj48YnI+DQpUaGUgdHdvIG9wZXJhdGlv bnMgZGlmZmVyIHNpZ25pZmljYW50bHksIGFuZCBpdCdzIG5vdCB2ZXJ5IGludHVpdGl2ZS4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZSIj5XaXRoIG15IHN1Z2dlc3Rpb24sIGhlcmUncyBob3cgdG8gZGVsZXRl IGEgc2luZ2xlIG1lbWJlciBmcm9tIGEgZ3JvdXA6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyAiPlBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNl IEhvc3Q6DQo8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ZXhh bXBsZS5jb208L2E+IEFjY2VwdDogYXBwbGljYXRpb24vanNvbiBBdXRob3JpemF0aW9uOiBCZWFy ZXIgaDQ4MGRqczkzaGQ4IEVUYWc6IFcvImEzMzBiYzU0ZjA2NzFjOSIgezwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyAiPiJvcGVyYXRpb25zIiA6IFs8L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj57PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+IlJF VElSRSIgOiB7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9u dC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ImtleSIgOiAibWVt YmVycy4yODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiPC9zcGFuPjxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1p bHk6ICdDb3VyaWVyIE5ldyc7ICI+fTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAi Pn08L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj5dIH0NCjwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PGJyPg0KSGVyZSdzIGhvdyBJIHN1Z2dlc3QgZGVsZXRpbmcgQUxMIG1lbWJlcnMg ZnJvbSBhIGdyb3VwOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPlBBVENI IC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlIEhvc3Q6DQo8YSBo cmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208L2E+ IEFjY2VwdDogYXBwbGljYXRpb24vanNvbiBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkz aGQ4IEVUYWc6IFcvImEzMzBiYzU0ZjA2NzFjOSIgezwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmll ciBOZXcnOyAiPiJvcGVyYXRpb25zIiA6IFs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj57PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+IlJFVElSRSIgOiB7PC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVw dDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ImtleSIgOiAibWVtYmVycyI8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBm b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj59PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7ICI+fTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPl0gfQ0KPC9zcGFu PjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+PGJyPkknbSBzdXJlIHlvdSdsbCBhZ3JlZSB0aGF0 IHRoaXMgaXMgc2ltcGxlciwgbW9yZSBjb25zaXN0ZW50IGFuZCBtb3JlIGludHVpdGl2ZSB0byBh IHJlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5Qcm8gMjogV2UgY2Fu IGFwcGx5IHRoaXMgbWVjaGFuaXNtIGNvbnNpc3RlbnRseSB0byB0aHJlZSBhcmVhczo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZSIj4oYSkgTWFuaXB1bGF0aW5nIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIG9mIGEgcmVz b3VyY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIj4oYikgTWFuaXB1bGF0aW5nIG1lbWJlcnMgb2YgYSBncm91cDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRlIiPihjKSBQZXJmb3JtaW5nIGJ1bGsgb3BlcmF0aW9ucywgd2hlcmUgd2Ugc2lt cGx5IHVzZSBIVFRQIHZlcmJzIGluc3RlYWQgb2YgdGhlIHNwZWNpYWxpc2VkIChhbmQgc2VtYW50 aWNhbGx5IGxlc3MgYW1iaWd1b3VzKSB2ZXJicyBJIHN1Z2dlc3RlZCBmb3IgYXR0cmlidXRlcywg dGhlDQogImtleSIgYmVjb21lcyB0aGUgVVJJLCBhbmQgdGhlICJ2YWx1ZSIgYmVjb21lcyB0aGUg Y29ycmVzcG9uZGluZyBKU09OIG9iamVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkZSIj5BbGwgb2YgdGhlbSByZXR1cm4gIjIwNyBNdWx0aS1TdGF0dXMiIHdpdGggdGhlICJyZXN1 bHRzIiBhcnJheSBob2xkaW5nIGluZGl2aWR1YWwgc3RhdHVzIGNvZGVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPkluIHRoZSBjdXJyZW50IHNwZWMsIChhKSBhbmQgKGIpIGFy ZSBkb25lIHNpbWlsYXJseSBidXQgKGMpIGlzIHZlcnkgZGlmZmVyZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRlIiPlBybyAzOiBBZG9wdGlvbiBvZiB0aGUgc3RhbmRhcmQgYnkg Y2xpZW50cyBpcyBsaWtlbHkgdG8gYmUgaGlnaGVyIGJlY2F1c2UgaXQncyBzaW1wbGVyIGZvciB0 aGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPlBybyA0OiBOZXcgKG5vdCBp bmN1bWJlbnQpIGNsb3VkIHByb3ZpZGVycyB3aWxsIHByb2JhYmx5IGZpbmQgdGhpcyBlYXNpZXIg dG8gaW1wbGVtZW50IGJlY2F1c2UgdGhleSBoYXZlIG5vIGxlZ2FjeS4gVGhleSB3aWxsIHByb2Jh Ymx5IHVzZSBzb21lIGZvcm0gb2YgTm9TUUwgZGF0YWJhc2UNCiBhbmQgd29uJ3QgYmUgY29uc3Ry YWluZWQgYnkgdGhlIGxpbWl0YXRpb25zIG9mIExEQVAgZGlyZWN0b3JpZXMuPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Q29uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkZSIj5Db24gMTogSW5jdW1iZW50IGNsb3VkIHByb3ZpZGVycyB3aXRoIGV4aXN0aW5nIGRh dGEgc3RvcmVzIGluIGEgZGlyZWN0b3J5IGZvcm1hdCAod2hlcmUgbXVsdGktdmFsdWVkIGF0dHJp YnV0ZXMgYXJlIHN0b3JlZCBhcyBjb21tYS1zZXBhcmF0ZWQgdmFsdWVzIHVuZGVyIGEgc2luZ2xl DQogYXR0cmlidXRlIG5vZGUpIHdpbGwgZmluZCBpdCBkaWZmaWN1bHQgdG8gbWlncmF0ZSB0byB0 aGlzIG1vZGVsIGFuZCBzdG9yZSBlYWNoIGF0dHJpYnV0ZSB2YWx1ZSBhcyBhIHN1Yi1ub2RlIHdp dGggaXRzIG93biBrZXkuIFRoaXMgd2lsbCAiaGluZGVyIGFkb3B0aW9uIG9mIHRoZSBzcGVjIiwg d2hpY2ggaXMgd2hhdCB5b3UgZmVhci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZS Ij5IYXZlIEkgc3VtbWVkIHVwIHRoZSBQcm9zIGFuZCBDb25zIGNvcnJlY3RseT8gSSdtIGJpYXNl ZCBvZiBjb3Vyc2UsIHNvIEkgY291bGQgaGF2ZSBtaXNzZWQgYSBDb24gb3IgaHlwZWQgYSBQcm8g Oi0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5JbiBvdGhlciB3b3Jkcywgd2UncmUgZGViYXRp bmcgaW50ZXJmYWNlIGNvbXBsZXhpdHkgKGN1cnJlbnQgc3BlYykgdmVyc3VzIGltcGxlbWVudGF0 aW9uIGNvbXBsZXhpdHkgKG15IHN1Z2dlc3Rpb24pLiBCb3RoIGNhbiBoaW5kZXIgYWRvcHRpb24g b2YgdGhlIHNwZWMgYnkgZGlmZmVyZW50DQogcGFydGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj5IZXJlJ3Mgd2hhdCB3ZSBuZWVkIHRvIGRpc2N1c3MgLSBEbyB0aGUgUHJv cyBtYWtlIHRoZSBzdWdnZXN0aW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9i bG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxv Y2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjwvYm9keT48L2h0bWw+DQo= --_000_CC4E982CBA4A5chrisphillipscanarieca_-- From g.c.prasad@gmail.com Mon Aug 13 14:07:34 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BE221F8650 for ; Mon, 13 Aug 2012 14:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipuzrPyX802f for ; Mon, 13 Aug 2012 14:07:30 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B43E821F864A for ; Mon, 13 Aug 2012 14:07:29 -0700 (PDT) Received: by bkty7 with SMTP id y7so1795731bkt.31 for ; Mon, 13 Aug 2012 14:07: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:from:date:message-id:subject:to :cc:content-type; bh=tEJjfIjJ5QpMRBMrtHJGU7qY6tuViiiG3XNC8S6jtNY=; b=dbPxKAPzXDHso1Q4taBF+QOz0rTtuU4xqEecK6rtiWlev7CIG3u5Y8m4gD2MdiZlo3 K9Oj74Fdvt9TVooqTPZS++xm1Wc1S5J1eGlbXTMmH3qFDpQz+rIgXi/l64ySx6FOy5Ic J5IZmd6Xt1DcU3plA5lf57T+2oENzzmj4/RFuyuw3tjzJCShbT5gT/ehz8s+/788kaU6 zs53Cx8VEIcFzk8X2BAwICU/k3ogn8qdRRAaXppz+SjQRVpQauggD4TymhhKpDonixtQ CXQttUe7nICpGRScggKEW+BLGt/LI5BfmbCqZbuhIcvnufWzRVqJW5+d8HwYvkaUKzbt VTqA== Received: by 10.205.128.141 with SMTP id he13mr5159819bkc.112.1344892048557; Mon, 13 Aug 2012 14:07:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Mon, 13 Aug 2012 14:07:08 -0700 (PDT) In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Tue, 14 Aug 2012 07:07:08 +1000 Message-ID: To: Kelly Grizzle Content-Type: multipart/alternative; boundary=0015173febead0c67f04c72c1486 Cc: Emmanuel Dreux , Melinda Shore , "scim@ietf.org" , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:07:34 -0000 --0015173febead0c67f04c72c1486 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Kelly. You've been most patient in hearing me out, I must say. I couldn't ask for more. Replying to Chris Philips's mail: > Given that you have a number of thoughts about what could be changed in SCIM,Leif's recommendation to craft them in an Internet Draft may be a better way to convey your thoughts. I'm coming around to the same conclusion. Do you think such an Internet Draft should be about changing SCIM, or should it propose a complementary spec for SPs who use a "NoLDAP" data store? I think the underlying problem is with LDAP, and unless we change that, these proposals won't fly. Regards, Ganesh On 14 August 2012 01:54, Kelly Grizzle wrote: > There are really two implementation options for a uid per element =96 > either store the uids in the native underlying data store or have some > secondary data store that maps elements to their uids. The third option = is > to hope that a service provider has a NoLDAP data store or its equivalent= . > None of these are practical for rapid and wide-spread adoption.**** > > ** ** > > > put the two together to propose a solution.**** > > ** ** > > As I said before, I am completely on board with cleaning up the PATCH > semantics (eg =96 the inconsistency between meta.attributes and > operation=3Ddelete, etc=85). Your suggestion of using different verbs is= a > good option to consider. This cannot be based on a uid per element, > though. It seems as though you have admitted this in your conclusion =96= =93As > for LDAP and SCIM, I guess the best TLA is RIP.=94**** > > ** ** > > --Kelly**** > > ** ** > > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 9:56 AM > *To:* Kelly Grizzle > *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > ** ** > > That was one suggestion. Another way could be container nodes with their > own "dn"s. If one suggestion won't work, tell me another way to make it > work. I'm waiting to hear a constructive suggestion that can square an > elegant API with the implementation constraints that come from having to > store multi-valued attributes in LDAP directories.**** > > ** ** > > I've heard enough of WHY this won't work. For a change, tell me HOW it ca= n > be made to work. Everyone now knows what the proposal means in terms of t= he > API, and implementors understand the constraints of legacy data stores, s= o > put the two together to propose a solution. C'mon, we have the "smartest > guys in the room" here, surely we should be able to crack this.**** > > ** ** > > Regards,**** > > Ganesh**** > > ** ** > > P.S. I'm rapidly reaching my own conclusions about what is to be done:***= * > > > http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-no= ldap.html > **** > > ** ** > > On 14 August 2012 00:27, Kelly Grizzle > wrote:**** > > > After all, no one has challenged the claim that this proposal > drastically simplifies the API for the client**** > > **** > > I agree that your proposal makes PATCH semantics simpler and more elegant= . > **** > > **** > > **** > > > =85 so it would appear to be worth doing. **** > > **** > > I strongly disagree here. This statements assumes that simplicity of the > client API is the only factor that should be considered with the spec.***= * > > **** > > Emmanuel=92s example is from a real-world service provider that would not= be > able to implement the spec easily with a uid per element. He is working = on > a SCIM interface that will help facilitate data exchange between multiple > Active Directory servers. Your solution was to change the data model fro= m > this:**** > > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > **** > > to this:**** > > **** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > **** > > I do not know of a single organization that would change their Active > Directory data model to fit this. For one thing, it would be a huge data > migration effort (likely across other domain controllers, etc=85) to assi= gn > these unique identifiers. This also assumes that SCIM is the only > reader/writer of this data, which will almost never be the case. If the > data model requires uids for every element, then every piece of non-SCIM > code that writes data into the directory will have to follow this. > Additionally, there are **many** tools and applications (eg =96 address > books) that rely on a certain data model in Active Directory, and this > would cause them to break. IMO this same argument holds true for most > service providers.**** > > **** > > **** > > PATCH is an optional part of the spec. It was primarily introduced to > make modifying resources with large multi-valued lists more efficient. I= t > does not need to solve every problem (eg =96 modifying sub-elements in ne= sted > arrays). Adding uids to every multi-valued element does not strike the > right balance between the needs of the client and the needs of the servic= e > provider.**** > > **** > > --Kelly**** > > **** > > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 1:35 AM > *To:* Phil Hunt; Melinda Shore > *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org**** > > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > Responding to extract of Melinda Shore's mail from digest:**** > > **** > > The issue being raised here isn't endpoint logic, but**** > > network traffic, and I'm pretty sure it's not very helpful to**** > > respond to the observation that your model requires more**** > > messages with a complaint about what you seem to think is a**** > > complex algorithm for attribute processing.**** > > **** > > It depends on how it's implemented. I'm confident we can have the best of > both - simple API with low-overhead implementation. Can we brainstorm HOW > this proposal can be implemented rather than WHY it can't be implemented > (which is mostly what I've been hearing so far)? After all, no one has > challenged the claim that this proposal drastically simplifies the API fo= r > the client, so it would appear to be worth doing. I'm sure there's more > than enough intellectual horsepower in this working group to pull this of= f > if we put our minds to it.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote:**** > > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty.**** > > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now!**** > > **** > > Multi-valued attributes: An attribute value in the PATCH request**** > > body is added to the value collection if the value does not exist**= ** > > and merged if a matching value is present. Values are matched by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute; e.g., addresses, or do not have unique*= *** > > value Sub-Attributes cannot be matched and must instead be deleted*= *** > > then added. Specific values can be removed from a Resource by**** > > adding an "operation" Sub-Attribute with the value "delete" to the*= *** > > attribute in the PATCH request body. As with adding/updating**** > > attribute value collections, the value to delete is determined by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute or that have a non-unique value Sub-**** > > Attribute are matched by comparing all Sub-Attribute values from***= * > > the PATCH request body to the Sub-Attribute values of the**** > > Resource. A delete operation is ignored if the attribute's name***= * > > is in the meta.attributes list. If the requested value to delete**= ** > > does not match a unique value on the Resource the server MAY**** > > return a HTTP 400 error.**** > > **** > > For a spec that is supposed to be about simplicity, the above description > is anything but simple. I know you guys have worked hard on this and I > don't mean to disparage those efforts, but think about how the above > passage would appear to a new reader (i.e., a novice to the spec, not a > technology novice).**** > > **** > > There is something fundamentally broken, and it is this: multi-valued > attributes without a unique identifier per value. If you don't fix that, > you won't get simplicity.**** > > **** > > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl f= amously > commented back > in 2005,**** > > **** > > "Unfortunately, some of the emerging protocols which also intend to > represent and transfer personal identity information have perhaps taken a > step backwards by not even considering these issues, perhaps sweeping the= m > under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt > version", which only postpone finding interoperable solutions to allowing > applications to express the identity entries they want to express."**** > > **** > > SCIM is exactly one of these "emerging protocols" Wahl talks about, and > what I see now strikes me as "sweeping these issues under the rug in the > guise of simplicity". Apologies for the bluntness.**** > > **** > > My take is that SPs are _already_ struggling to manage multi-valued > attributes, and existing mechanisms are clumsy. > They would be grateful for a specification that made operations easier at > the cost of a re-engineered schema. That calls for some thought leadershi= p > from this working group.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 10:13, Phil Hunt wrote:**** > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Phil**** > > > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote:**** > > > Would it have to be stored on the account database of the service > provider?**** > > **** > > Yes.**** > > **** > > > If so, I believe that this is impracticable in the core schema. Indeed > it implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > **** > > Why? That doesn't necessarily follow. Implementation is independent of > representation. We're talking about a change in representation to make th= e > API cleaner.**** > > **** > > As a simple example, if an LDAP node is being used to hold a list of > comma-separated email addresses, it can just as easily store > comma-separated name-value pairs.**** > > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > can be changed to**** > > **** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > **** > > That's why I asked if there was an SP representative on this working grou= p > who could explain what such a change could mean for them. As of now, it > looks like other people are presuming that SPs will not be able to > implement these changes easily and are rejecting them for that reason.***= * > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 04:29, Emmanuel Dreux wrote:**** > > =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > Where would 3cbaaff8e84e come from? Would it have to be stored on the > account database of the service provider?**** > > **** > > If so, I believe that this is impracticable in the core schema. Indeed it > implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > This would be a show stopper. SCIM must be transparent, and must be able > to be put on top of an existing system to provide provisioning apis.**** > > **** > > Said differently, SCIM must not be intrusive for existing systems and mus= t > not require modifications to allow its integration.**** > > Correct me if I misunderstood your suggestion.**** > > **** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > **** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org; Phil Hunt > *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. **** > > **** > > That's exactly the point. How do we "specify completely for uniqueness"?*= * > ** > > **** > > In the example below, how are you proposing that the following element be > updated if we can't use positional indexes?**** > > **** > > addresses[1].street-number =3D "243"**** > > **** > > User object:**** > > **** > > {**** > > ...**** > > addresses: [**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > ]**** > > }**** > > **** > > It's impractical to use the value because it's the whole dictionary > element:**** > > **** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > **** > > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element:**** > > **** > > addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > {**** > > ...**** > > addresses: {**** > > "d6ea365462f5" :**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > "3cbaaff8e84e" :**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > }**** > > }**** > > **** > > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written.**** > > **** > > There's a lot of talk about the "burden" on the SPs, but I believe this i= s > overblown. Is there any SP representative in this WG who can tell us what > this proposal will actually entail for them?**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 12 August 2012 11:53, Kelly Grizzle > wrote:**** > > Ganesh,**** > > **** > > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t > have a value sub-attribute can be removed by specifying only the value > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption.**** > > **** > > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort.**** > > **** > > I'm curious if anyone else in the WG is in favor of unique identifiers fo= r > every multi-valued element.**** > > **** > > --Kelly**** > > **** > ------------------------------ > > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > Phil, **** > > **** > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > **** > > **** > > Regards,**** > > Ganesh**** > > On 12 August 2012 01:12, Phil Hunt wrote:**** > > Ganesh, **** > > **** > > Here's the sample that concerned me...**** > > The two operations differ significantly, and it's not very intuitive. **= * > * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } **** > > **** > > **** > > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys.**** > > **** > > Given that multi-values must be each unique, I don't see the point of the > extra indexing to support this. Just use the value as the item you wish t= o > delete.**** > > **** > > I agree, the delete value operation could be more explicit and clear in > general.**** > > **** > > Phil**** > > **** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > **** > > **** > > **** > > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** > > **** > > > For the multi-value example you gave you used the value as the > attribute name key. **** > > **** > > Now I'm confused :-). I don't believe any of my examples ever used a valu= e > as the key.**** > > **** > > Could you please show me which example you mean, and which parts of it yo= u > believe to be the value?**** > > **** > > Regards,**** > > Ganesh **** > > On 11 August 2012 13:59, Phil Hunt wrote:**** > > > For the multi-value example you gave you used the value as the attribute > name key. **** > > **** > > That means a lot more complex indexing structure. Better to just say > delete a specific value. **** > > **** > > The spec already allows multiple values to have tags like home, work, etc= . > **** > > **** > > Phil**** > > > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote:**** > > > In your example you are conflating value with an attribute id. > > I don't believe so. **** > > **** > > I'm adopting a model where every attribute of the resource is a key-value > pair. The key is a name or ID.**** > > **** > > For non-repeating attributes (both simple and composite), the key is the > attribute name itself. **** > > **** > > Simple attribute:**** > > **** > > Key: "dob"**** > > Value: "01 Jan 1970"**** > > **** > > For composite attributes, the key employs dot notation to specify the > fully-qualified attribute name, e.g., "address.postcode".**** > > **** > > Composite attribute:**** > > **** > > Key: "address.street-number"**** > > Value: "10"**** > > **** > > Key: "address.suburb"**** > > Value: "East Camden"**** > > **** > > For repeating (multi-valued) attributes, I'm suggesting that there be new > keys for each individual value, otherwise they are impossible to > distinguish, and a positional index is inadequate. So we convert the arra= y > into a dictionary and this then becomes a composite attribute using dot > notation for the key.**** > > **** > > Multi-valued attribute:**** > > **** > > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** > > Value: "john_smith@yahoo.com"**** > > **** > > So this allows us to apply uniform treatment to any arbitrarily deep > resource structure. We can refer to every leaf value with a key that is t= he > fully-qualified name using dot notation.**** > > **** > > The verbs are just unambiguous operations on these (now) explicitly > addressable attributes.**** > > **** > > INCLUDE to a collection and specify only the value. The key is generated > and returned. The fully-qualified key is > . and the value is what was specifie= d > in the INCLUDE.**** > > **** > > REPLACE a fully-qualified key with a new value. If the key doesn't exist, > return a "404 Not Found".**** > > **** > > PLACE a value at the logical location implied by the fully-qualified key. > If there is already a key with that name, return a "409 Conflict".**** > > **** > > FORCE the fully-qualified key to hold the given value, regardless of > whether it existed before or not. Only errors possible are "400 Bad > Request" and "500 Internal Error".**** > > **** > > RETIRE an attribute or a collection given its fully-qualified key. The > implementation will determine whether the attribute will disappear entire= ly > or will exist holding a null value (the blank string "" or the empty obje= ct > {} ).**** > > **** > > I'll explain in a separate post why we need operation verbs like these > that are independent of the HTTP verbs.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 11 August 2012 10:38, wrote:**** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) > > > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux < > edreux@cloudiway.com>, Trey Drake , Kelly > Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > Ganesh,**** > > **** > > In your example you are conflating value with an attribute id. I find tha= t > confusing. **** > > **** > > I agree though that operations in patch could be a lot more explicit. ***= * > > **** > > Eg explicitly deleting a value by saying delete or retire. **** > > > Phil**** > > > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote:**** > > > I am concerned about your second suggestion: **** > > **** > > Let's discuss that now.**** > > **** > > The trade-offs are very clear here.**** > > **** > > Pros:**** > > **** > > Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t > and intuitive when every individual attribute value gets its own ID.**** > > **** > > Here's how to delete a single member from a Group, as per the current spe= c: > **** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "members": [**** > > {**** > > "display": "Babs Jensen",**** > > "value": "2819c223-7f76-453a-919d-413861904646"**** > > "operation": "delete"**** > > }**** > > ]**** > > }**** > > > Here's how to delete ALL members from a group according to the current > spec:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "meta": {**** > > "attributes": [**** > > "members"**** > > ]**** > > }**** > > }**** > > > The two operations differ significantly, and it's not very intuitive. ***= * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } > Here's how I suggest deleting ALL members from a group:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members"**** > > }**** > > }**** > > ] } **** > > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader.**** > > **** > > Pro 2: We can apply this mechanism consistently to three areas:**** > > (a) Manipulating multi-valued attributes of a resource**** > > (b) Manipulating members of a group**** > > (c) Performing bulk operations, where we simply use HTTP verbs instead of > the specialised (and semantically less ambiguous) verbs I suggested for > attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object.**** > > **** > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes.**** > > **** > > In the current spec, (a) and (b) are done similarly but (c) is very > different.**** > > **** > > Pro 3: Adoption of the standard by clients is likely to be higher because > it's simpler for them.**** > > **** > > Pro 4: New (not incumbent) cloud providers will probably find this easier > to implement because they have no legacy. They will probably use some for= m > of NoSQL database and won't be constrained by the limitations of LDAP > directories.**** > > **** > > Cons:**** > > **** > > Con 1: Incumbent cloud providers with existing data stores in a directory > format (where multi-valued attributes are stored as comma-separated value= s > under a single attribute node) will find it difficult to migrate to this > model and store each attribute value as a sub-node with its own key. This > will "hinder adoption of the spec", which is what you fear.**** > > **** > > Have I summed up the Pros and Cons correctly? I'm biased of course, so I > could have missed a Con or hyped a Pro :-).**** > > **** > > In other words, we're debating interface complexity (current spec) versus > implementation complexity (my suggestion). Both can hinder adoption of th= e > spec by different parties.**** > > **** > > Here's what we need to discuss - Do the Pros make the suggestio**** > > **** > > **** > > ** ** > --0015173febead0c67f04c72c1486 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks, Kelly. You've been most patient in hearing me out, I must say. = I couldn't ask for more.

Replying to Chris Philips&#= 39;s mail:
>=A0Given = that you have a number of thoughts about what could be changed in SCIM,Leif= 's recommendation to =A0craft them in an Internet Draft may be a better= way to convey your thoughts.

I'm coming around to the same c= onclusion. Do you think such an Internet Draft should be about changing SCI= M, or should it propose a complementary spec for SPs who use a "NoLDAP= " data store? I think the underlying problem is with LDAP, and unless = we change that, these proposals won't fly.

Regards,
Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

There are really two impl= ementation options for a uid per element =96 either store the uids in the n= ative underlying data store or have some secondary data store that maps elements to their uids.=A0 The third option is to hope that a se= rvice provider has a NoLDAP data store or its equivalent.=A0 None of these = are practical for rapid and wide-spread adoption.

=A0<= /p>

> put the two together to propose a solution.=A0<= /p>

As I said before, I= am completely on board with cleaning up the PATCH semantics (eg =96 the in= consistency between meta.attributes and operation=3Ddelete, etc=85).=A0 Your suggestion of using different verbs is a good option to consider.=A0 = This cannot be based on a uid per element, though.=A0 It seems as though yo= u have admitted this in your conclusion =96 =93As for LDAP and SCIM, I gues= s the best TLA is RIP.=94

=A0<= /p>

--Kelly

=A0<= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24
=

=A0

That was one suggestion. Another way could be contai= ner nodes with their own "dn"s. If one suggestion won't work,= tell me another way to make it work. I'm waiting to hear a constructiv= e suggestion that can square an elegant API with the implementation constraints that come from having to store multi-valued att= ributes in LDAP directories.

=A0

I've heard enough of WHY this won't work. Fo= r a change, tell me HOW it can be made to work. Everyone now knows what the= proposal means in terms of the API, and implementors understand the constr= aints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys= in the room" here, surely we should be able to crack this.<= /u>

=A0

Regards,

Ganesh

=A0

P.S. I'm rapidly reaching my own conclusions abo= ut what is to be done:

=A0

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

> After all, no one has challenged the claim that= this proposal drastically simplifies the API for the client<= /p>

=A0<= /p>

I agree that your proposa= l makes PATCH semantics simpler and more elegant.

=A0<= /p>

=A0<= /p>

> =85 so it would appear to be worth doing.=A0

=A0<= /p>

I strongly disagree here.= =A0 This statements assumes that simplicity of the client API is the only factor that should be considered with the spec.

=A0<= /p>

Emmanuel=92s example is f= rom a real-world service provider that would not be able to implement the spec easily with a uid per element.=A0 He is working on a SCIM interface t= hat will help facilitate data exchange between multiple Active Directory se= rvers.=A0 Your solution was to change the data model from this:

=A0<= /p> 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

=A0<= /p>

to this:=

=A0<= /p>

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0<= /p>

I do not know of a single= organization that would change their Active Directory data model to fit this.=A0 For one thing, it would be a huge data migration effort (likely a= cross other domain controllers, etc=85) to assign these unique identifiers.= =A0 This also assumes that SCIM is the only reader/writer of this data, whi= ch will almost never be the case.=A0 If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this.=A0 Ad= ditionally, there are *many* tools and applications =A0(eg =96 addre= ss books) that rely on a certain data model in Active Directory, and this would cause them to break.=A0 IMO this= same argument holds true for most service providers.<= /p>

=A0<= /p>

=A0<= /p>

PATCH is an optional part= of the spec. =A0It was primarily introduced to make modifying resources wi= th large multi-valued lists more efficient.=A0 It does not need to solve ever= y problem (eg =96 modifying sub-elements in nested arrays).=A0 Adding uids = to every multi-valued element does not strike the right balance between the= needs of the client and the needs of the service provider.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

Responding to extract of Melinda Shore's mail fr= om digest:

=A0

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to<=
u>
respond to the observation that your model requires more=

messages with a complaint about what you seem to think is a<=
/u>
complex algorithm for attribute processing.

=A0

It depends on how it's implemented. I'm conf= ident we can have the best of both - simple API with low-overhead implement= ation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've= been hearing so far)? After all, no one has challenged the claim that this= proposal drastically simplifies the API for the client, so it would appear= to be worth doing.=A0I'm sure there's more than enough intellectual horsepower in this working group to pull this off= if we put our minds to it.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 13:54, Ganesh and Sashi Prasad <= ;g.c.prasad@gmail= .com> wrote:

>=A0I strongly obj= ect to anything that leads to a read before modify requirement. Too complex= and too chatty.

Sorry Phil, but you're contradicting yourself he= re.=A0There seems to be an awful lot of matching (i.e., reading) going on i= n the spec as it stands, with if-then clauses to do one thing or another if the match either succeeds or fails. This is a complex,= chatty protocol right now!

=A0

=A0=A0 Multi-valued attributes:=A0 An=
 attribute value in the PATCH request
=A0=A0=A0=A0=A0 body is added to the =
value collection if the value does not exist
=A0=A0=A0=A0=A0 and merged if a match=
ing value is present.=A0 Values are matched by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute; e.g., addresses, or do not have unique
=A0=A0=A0=A0=A0 value Sub-Attributes =
cannot be matched and must instead be deleted
=A0=A0=A0=A0=A0 then added.=A0 Specif=
ic values can be removed from a Resource by
=A0=A0=A0=A0=A0 adding an "opera=
tion" Sub-Attribute with the value "delete" to the=

=A0=A0=A0=A0=A0 attribute in the PATC=
H request body.=A0 As with adding/updating
=A0=A0=A0=A0=A0 attribute value colle=
ctions, the value to delete is determined by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute or that have a non-unique value Sub-
=A0=A0=A0=A0=A0 Attribute are matched=
 by comparing all Sub-Attribute values from
=A0=A0=A0=A0=A0 the PATCH request bod=
y to the Sub-Attribute values of the
=A0=A0=A0=A0=A0 Resource.=A0 A delete=
 operation is ignored if the attribute's name

=A0=A0=A0=A0=A0 is in the meta.attrib=
utes list.=A0 If the requested value to delete


=A0=A0=A0=A0=A0 does not match a uniq=
ue value on the Resource the server MAY


=A0=A0=A0=A0=A0 return a HTTP 400 err=
or.

=A0

For a spec that is supposed to be about simplicity, = the above description is anything but simple. I know you guys have worked h= ard on this and I don't mean to disparage those efforts, but think about how the above passage would appear to a new reader (i.e., = a novice to the spec, not a technology novice).

=A0

There is something fundamentally broken, and it is t= his: multi-valued attributes without a unique identifier per value. If you = don't fix that, you won't get simplicity.

=A0

We know LDAP trees are broken for multi-valued attri= butes. As Mark Wahl famously commented back in 2005,

=A0

"Unfortunately, some of the emergi= ng protocols which also intend to represent and transfer personal identity = information have perhaps taken a step backwards by not even considering these issues, = perhaps sweeping them under the rug in the guise of simplicity, XMLificatio= n, or "fix in the next version", which only postpone finding inte= roperable solutions to allowing applications to express the identity entries they want to express."<= u>

=A0

SCIM is exactly one of these "emerging protocol= s" Wahl talks about, and what I see now strikes me as "sweeping t= hese issues under the rug in the guise of simplicity". Apologies for the bluntness.

=A0

My take is that SPs are _already_ struggling to mana= ge multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specificat= ion that made operations easier at the cost of a re-engineered schema. That= calls for some thought leadership from this working group.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> w= rote:

I strongly object to anything that leads to a read b= efore modify requirement. Too complex and too chatty.=A0

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

> Would it have to = be stored on the account database of the service provider?=

=A0

Yes.<= /u>

=A0

> If so, I believe = that this is impracticable in the core schema.=A0Indeed it implies that a s= ervice provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

=A0

Why? That doesn't necessarily follow. Implementa= tion is independent of representation. We're talking about a change in = representation to make the API cleaner.

=A0

As a simple example, if an LDAP node is being used t= o hold a list of comma-separated email addresses, it can just as easily sto= re comma-separated name-value pairs.

=A0

=A0

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0

That's why I asked if there was an SP representative o= n this working group who could explain what such a change could mean for th= em. As of now, it looks like other people are presuming that SPs will not be a= ble to implement these changes easily and are rejecting them for that reaso= n.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

=F0=A0 addresses.3cbaaff8e84e.street-number =3D "243"

=A0<= /p>

Where would 3cbaaff8e84e come from? Would it have to be stored on the account database of th= e service provider?

=A0

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a service = provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This would be a show s= topper. SCIM must be transparent, and must be able to be put on top of an e= xisting system to provide provisioning apis.

=A0

Said differently, SCIM= must not be intrusive for existing systems and must not require modificati= ons to allow its integration.

Correct me if I misund= erstood your suggestion.

=A0

--

Regards,=

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78= 17 58

Mobile: +33 6 47 81= 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that d= on't have a value sub-attribute (eg - address) have to specified comple= tely for uniqueness.=A0=A0

=A0

That's exactly the point. How = do we "specify completely for uniqueness"?

=A0

In the example below, how are you = proposing that the following element be updated if we can't use positio= nal indexes?

=A0

addresses[1].street-number =3D &qu= ot;243"

=A0

User object:<= /p>

=A0

{

=A0 ...

=A0 addresses: [<= /u>

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the va= lue because it's the whole dictionary element:

=A0

{

=A0 "type" : "offic= e",

=A0 "street-number" : &q= uot;213",

=A0 "street-name" : &quo= t;Main Street",

=A0 "suburb" : "Ade= laide",

=A0 "postcode" : "5= 000",

=A0 "state" : "SA&q= uot;,

=A0 "country" : "Au= stralia"

}

=A0

With my proposal, the "addres= ses" array gets converted to a dictionary, and then we have a stable w= ay of referencing this element:

=A0

addresses.3cbaaff8e84e.street-numb= er =3D "243"

=A0

{

=A0 ...

=A0 addresses: {<= /u>

=A0 =A0 "d6ea365462f5" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechan= ism for composite attributes and another mechanism for simple attributes, I= would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember = that a lot of the administration is probably going to be scripted rather th= an done by hand, and having two mechanisms (depending on whether the attrib= ute is simple or composite) will complicate every script that has to be written.

=A0

There's a lot of talk about th= e "burden" on the SPs, but I believe this is overblown. Is there = any SP representative in this WG who can tell us what this proposal will actually entail for them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Gri= zzle <k= elly.grizzle@sailpoint.com> wrote:

Ganesh,=

=A0

This is exactly how PATCH wo= rks in SCIM 1.0. =A0Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. =A0Multi-v= alued attributes that don't have a value sub-attribute (eg - address) h= ave to specified completely for uniqueness. =A0As I have said before, I am = very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will put= on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in general= PATCH can be made more intuitive without adding uids to each element. =A0T= he verbs that you propose make sense. =A0There is also a JSON Patch informati= onal draft in the IETF that is interesting -=A0http://tools.= ietf.org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= u>

=A0

I'm curious if anyone el= se in the WG is in favor of unique identifiers for every multi-valued eleme= nt.

=A0

--Kelly=

=A0

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value= itself to identify an element is that this method will only work for simpl= e elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for= each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creating a unique key for each eleme= nt scales better.

=A0

Regards,

Gan= esh

On 12 August 2012 01:12, Phil Hunt= <phil.hunt@or= acle.com> wrote:

Ganesh,

=A0

Here's the sample that concern= ed me...

The two operations differ signific= antly, and it's not very intuitive.=A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute with an= identifier that matched that value or of identifiers that were additional unique keys.

=A0

Given that multi-values must be each unique, I = don't see the point of the extra indexing to support this. Just use the value as the item you wish to delete.

=A0

I agree, the delete value operation could be mo= re explicit and clear in general.

=A0

Phil<= /p>

=A0

@independentid

phil.hunt@o= racle.com

=A0<= /p>

=A0=

=A0

On 2012-08-11, at 2:30 AM, Ganesh = and Sashi Prasad wrote:

=A0=

>=A0 For the multi-value exampl= e you gave you used the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don= 9;t believe any of my examples ever used a value as the key.<= u>

=A0

Could you please show me which exa= mple you mean, and which parts of it you believe to be the value?=

=A0

Regards,

Gan= esh=A0

On 11 August 2012 13:59, Phil Hunt= <phil.hunt@or= acle.com> wrote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex inde= xing structure. Better to just say delete a specific value.=A0

=A0

The spec already allows multiple v= alues to have tags like home, work, etc.

=A0=

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are con= flating value with an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where eve= ry attribute of the resource is a key-value pair. The key is a name or ID.<= /span>

=A0

For non-repeating attributes (both= simple and composite), the key is the attribute name itself.=A0<= /u>

=A0

Simple attribute:=

=A0

Key: "dob"=

Value: "01 Jan 1970"

=A0

For composite attributes, the key = employs dot notation to specify the fully-qualified attribute name, e.g., &= quot;address.postcode".

=A0

Composite attribute:=

=A0

Key: "address.street-number&q= uot;

Value: "10"

=A0

Key: "address.suburb"

Value: "East Camden"

=A0

For repeating (multi-valued) attri= butes, I'm suggesting that there be new keys for each individual value,= otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this th= en becomes a composite attribute using dot notation for the key.<= /u>

=A0

Multi-valued attribute:<= /u>

=A0

Key: "emails.7dfcb444-74d8-4f= 17-aa66-daf9ea3bd902"

Value: "john_smith@yahoo.com"<= u>

=A0

So this allows us to apply uniform= treatment to any arbitrarily deep resource structure. We can refer to ever= y leaf value with a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous ope= rations on these (now) explicitly addressable attributes.<= /u>

=A0

INCLUDE to a collection and specif= y only the value. The key is generated and returned. The fully-qualified ke= y is <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

=A0

REPLACE a fully-qualified key with= a new value. If the key doesn't exist, return a "404 Not Found&qu= ot;.

=A0

PLACE a value at the logical locat= ion implied by the fully-qualified key. If there is already a key with that= name, return a "409 Conflict".

=A0

FORCE the fully-qualified key to h= old the given value, regardless of whether it existed before or not. Only e= rrors possible are "400 Bad Request" and "500 Internal Error".

=A0

RETIRE an attribute or a collectio= n given its fully-qualified key. The implementation will determine whether = the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {}= ).

=A0

I'll explain in a separate pos= t why we need operation verbs like these that are independent of the HTTP v= erbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org= > wrote:

If you have received this digest w= ithout all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating= value with an attribute id. I find that confusing.=A0=

=A0

I agree though that operations in = patch could be a lot more explicit.=A0

=A0

Eg explicitly deleting a value by = saying delete or retire.=A0


Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

=A0

Let's discuss that now.=

=A0

The trade-offs are very clear here= .

=A0

Pros:

=A0

Pro 1. The API to manipulate resou= rces becomes so much cleaner, consistent and intuitive when every individua= l attribute value gets its own ID.

=A0

Here's how to delete a single = member from a Group, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "member=
s": [


=A0=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0=A0 =
"display": "Babs Jensen",


=A0=A0=A0=A0=A0=A0=A0=A0 =
"value": "2819c223-7f76-453a-919d-413861904646"<=
u>


=A0=A0=A0=A0=A0=A0=A0=A0 =
"operation": "delete"


=A0=A0=A0=A0=A0=A0 }


=A0=A0=A0=A0 ]<=
/u>


=A0=A0 }=





Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "meta&q=
uot;: {


=A0=A0=A0=A0=A0=A0 "=
attributes": [


=A0=A0=A0=A0=A0=A0=A0=A0 =
"members"


=A0=A0=A0=A0=A0=A0 ]


=A0=A0=A0=A0 }<=
/u>


=A0=A0 }=





The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members"=

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism= consistently to three areas:

(a) Manipulating multi-valued attr= ibutes of a resource

(b) Manipulating members of a grou= p

(c) Performing bulk operations, wh= ere we simply use HTTP verbs instead of the specialised (and semantically l= ess ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the cor= responding JSON object.

=A0

All of them return "207 Multi= -Status" with the "results" array holding individual status = codes.

=A0

In the current spec, (a) and (b) a= re done similarly but (c) is very different.

=A0

Pro 3: Adoption of the standard by= clients is likely to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud p= roviders will probably find this easier to implement because they have no l= egacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers w= ith existing data stores in a directory format (where multi-valued attribut= es are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store = each attribute value as a sub-node with its own key. This will "hinder= adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons= correctly? I'm biased of course, so I could have missed a Con or hyped= a Pro :-).

=A0

In other words, we're debating= interface complexity (current spec) versus implementation complexity (my s= uggestion). Both can hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss= - Do the Pros make the suggestio

=A0

=A0

=A0


--0015173febead0c67f04c72c1486-- From leifj@mnt.se Mon Aug 13 14:38:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B09821F85E6 for ; Mon, 13 Aug 2012 14:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgaY4wDoglwo for ; Mon, 13 Aug 2012 14:38:41 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39721F85DF for ; Mon, 13 Aug 2012 14:38:40 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7DLcZeR003969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2012 23:38:39 +0200 (CEST) Message-ID: <502973DB.5070705@mnt.se> Date: Mon, 13 Aug 2012 23:38:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:38:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/13/2012 11:07 PM, Ganesh and Sashi Prasad wrote: > Thanks, Kelly. You've been most patient in hearing me out, I must > say. I couldn't ask for more. > > Replying to Chris Philips's mail: >> Given that you have a number of thoughts about what could be >> changed > in SCIM,Leif's recommendation to craft them in an Internet Draft > may be a better way to convey your thoughts. > > I'm coming around to the same conclusion. Do you think such an > Internet Draft should be about changing SCIM, or should it propose > a complementary spec for SPs who use a "NoLDAP" data store? I think > the underlying problem is with LDAP, and unless we change that, > these proposals won't fly. I don't think it matters at this point. My advise is to write up a coherent proposal and think of it as input to the discussion. Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlApc9sACgkQ8Jx8FtbMZnckngCeLtFgo49lnQWmP8pCmUWXT2WF mF0An3ISQqeEdcneAT9cTK06zCBvqoNm =50gi -----END PGP SIGNATURE----- From trey.drake@unboundid.com Mon Aug 13 14:47:20 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0632021F84F5 for ; Mon, 13 Aug 2012 14:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY-vpKz6NOKk for ; Mon, 13 Aug 2012 14:47:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8AEF21F854A for ; Mon, 13 Aug 2012 14:47:15 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so8766336obb.31 for ; Mon, 13 Aug 2012 14:47:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=IZ7mjgh0cLVZ0qNf1vD90vcgvf8ON6T+4Z43i/BIg8o=; b=OOivcArnSZzYkWpl05MP9uuBXQirAtAyQ58uU80Bq+fPk7HZVhfSQMY6teB19BzlhD QDMO0w51SrmOz1wgYNAboEJgi01rpIwCD8q6EzOIkF4Yx2fwpQqeQKFHC0jup5vUWT48 ww3CGKCrrQgMOxPAi9Wjw4qAIaIwUPx006uGqAdWVJ2szY/829O3jhZMJWyQQoNS7OT+ sI3I5r9WQ4PMiW3AdYIj25C7qFPhneKhITRuG6S1bnLuIakIC6sFX3CgmiYaoH5+iWjJ uTCaaGYAgOfqh3msGeqkninWB62VKFpz0iFFa8uB4/QX2zT7Vgc05U8gwvBfhQIociDk HiQQ== Received: by 10.182.131.98 with SMTP id ol2mr15149008obb.69.1344894435126; Mon, 13 Aug 2012 14:47:15 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id aa6sm636998oec.0.2012.08.13.14.47.13 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 14:47:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0DF57EB-84D7-4C1E-AF94-C18C3B7DE37D" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: Date: Mon, 13 Aug 2012 16:47:12 -0500 Message-Id: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQkn539JsFlS0rV7b1XcQbfMrCGSaYa48aO8pwV39DS7c1CZ1TPEH6YgGVg8/JbNL4H/WDtx Cc: "scim@ietf.org" , Phil Hunt , Emmanuel Dreux , Melinda Shore , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 21:47:20 -0000 --Apple-Mail=_C0DF57EB-84D7-4C1E-AF94-C18C3B7DE37D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don't believe LDAP is the culprit. You'd find the same issue in most = *existing* data models to include relational. The issue is whether = you're forcing the hand of the SP to overhaul their data model to = accommodate SCIM. I don't believe we would get very far if we took that = tack. Thanks, Trey On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad = wrote: > Thanks, Kelly. You've been most patient in hearing me out, I must say. = I couldn't ask for more. >=20 > Replying to Chris Philips's mail: > > Given that you have a number of thoughts about what could be changed = in SCIM,Leif's recommendation to craft them in an Internet Draft may be = a better way to convey your thoughts. >=20 > I'm coming around to the same conclusion. Do you think such an = Internet Draft should be about changing SCIM, or should it propose a = complementary spec for SPs who use a "NoLDAP" data store? I think the = underlying problem is with LDAP, and unless we change that, these = proposals won't fly. >=20 > Regards, > Ganesh >=20 > On 14 August 2012 01:54, Kelly Grizzle = wrote: > There are really two implementation options for a uid per element =96 = either store the uids in the native underlying data store or have some = secondary data store that maps elements to their uids. The third option = is to hope that a service provider has a NoLDAP data store or its = equivalent. None of these are practical for rapid and wide-spread = adoption. >=20 > =20 >=20 > > put the two together to propose a solution. >=20 > =20 >=20 > As I said before, I am completely on board with cleaning up the PATCH = semantics (eg =96 the inconsistency between meta.attributes and = operation=3Ddelete, etc=85). Your suggestion of using different verbs = is a good option to consider. This cannot be based on a uid per = element, though. It seems as though you have admitted this in your = conclusion =96 =93As for LDAP and SCIM, I guess the best TLA is RIP.=94 >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 9:56 AM > To: Kelly Grizzle > Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org >=20 >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > =20 >=20 > That was one suggestion. Another way could be container nodes with = their own "dn"s. If one suggestion won't work, tell me another way to = make it work. I'm waiting to hear a constructive suggestion that can = square an elegant API with the implementation constraints that come from = having to store multi-valued attributes in LDAP directories. >=20 > =20 >=20 > I've heard enough of WHY this won't work. For a change, tell me HOW it = can be made to work. Everyone now knows what the proposal means in terms = of the API, and implementors understand the constraints of legacy data = stores, so put the two together to propose a solution. C'mon, we have = the "smartest guys in the room" here, surely we should be able to crack = this. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > P.S. I'm rapidly reaching my own conclusions about what is to be done: >=20 > = http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nol= dap.html=20 >=20 > =20 >=20 > On 14 August 2012 00:27, Kelly Grizzle = wrote: >=20 > > After all, no one has challenged the claim that this proposal = drastically simplifies the API for the client >=20 > =20 >=20 > I agree that your proposal makes PATCH semantics simpler and more = elegant. >=20 > =20 >=20 > =20 >=20 > > =85 so it would appear to be worth doing.=20 >=20 > =20 >=20 > I strongly disagree here. This statements assumes that simplicity of = the client API is the only factor that should be considered with the = spec. >=20 > =20 >=20 > Emmanuel=92s example is from a real-world service provider that would = not be able to implement the spec easily with a uid per element. He is = working on a SCIM interface that will help facilitate data exchange = between multiple Active Directory servers. Your solution was to change = the data model from this: >=20 > =20 >=20 > mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com > =20 >=20 > to this: >=20 > =20 >=20 > mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >=20 > =20 >=20 > I do not know of a single organization that would change their Active = Directory data model to fit this. For one thing, it would be a huge = data migration effort (likely across other domain controllers, etc=85) = to assign these unique identifiers. This also assumes that SCIM is the = only reader/writer of this data, which will almost never be the case. = If the data model requires uids for every element, then every piece of = non-SCIM code that writes data into the directory will have to follow = this. Additionally, there are *many* tools and applications (eg =96 = address books) that rely on a certain data model in Active Directory, = and this would cause them to break. IMO this same argument holds true = for most service providers. >=20 > =20 >=20 > =20 >=20 > PATCH is an optional part of the spec. It was primarily introduced to = make modifying resources with large multi-valued lists more efficient. = It does not need to solve every problem (eg =96 modifying sub-elements = in nested arrays). Adding uids to every multi-valued element does not = strike the right balance between the needs of the client and the needs = of the service provider. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 1:35 AM > To: Phil Hunt; Melinda Shore > Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org >=20 >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > =20 >=20 > Responding to extract of Melinda Shore's mail from digest: >=20 > =20 >=20 > The issue being raised here isn't endpoint logic, but > network traffic, and I'm pretty sure it's not very helpful to > respond to the observation that your model requires more > messages with a complaint about what you seem to think is a > complex algorithm for attribute processing. > =20 >=20 > It depends on how it's implemented. I'm confident we can have the best = of both - simple API with low-overhead implementation. Can we brainstorm = HOW this proposal can be implemented rather than WHY it can't be = implemented (which is mostly what I've been hearing so far)? After all, = no one has challenged the claim that this proposal drastically = simplifies the API for the client, so it would appear to be worth doing. = I'm sure there's more than enough intellectual horsepower in this = working group to pull this off if we put our minds to it. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 13 August 2012 13:54, Ganesh and Sashi Prasad = wrote: >=20 > > I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty. >=20 > Sorry Phil, but you're contradicting yourself here. There seems to be = an awful lot of matching (i.e., reading) going on in the spec as it = stands, with if-then clauses to do one thing or another if the match = either succeeds or fails. This is a complex, chatty protocol right now! >=20 > =20 >=20 > Multi-valued attributes: An attribute value in the PATCH request > body is added to the value collection if the value does not = exist > and merged if a matching value is present. Values are matched = by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute; e.g., addresses, or do not have = unique > value Sub-Attributes cannot be matched and must instead be = deleted > then added. Specific values can be removed from a Resource by > adding an "operation" Sub-Attribute with the value "delete" to = the > attribute in the PATCH request body. As with adding/updating > attribute value collections, the value to delete is determined = by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute or that have a non-unique value Sub- > Attribute are matched by comparing all Sub-Attribute values from > the PATCH request body to the Sub-Attribute values of the > Resource. A delete operation is ignored if the attribute's name > is in the meta.attributes list. If the requested value to = delete > does not match a unique value on the Resource the server MAY > return a HTTP 400 error. > =20 >=20 > For a spec that is supposed to be about simplicity, the above = description is anything but simple. I know you guys have worked hard on = this and I don't mean to disparage those efforts, but think about how = the above passage would appear to a new reader (i.e., a novice to the = spec, not a technology novice). >=20 > =20 >=20 > There is something fundamentally broken, and it is this: multi-valued = attributes without a unique identifier per value. If you don't fix that, = you won't get simplicity. >=20 > =20 >=20 > We know LDAP trees are broken for multi-valued attributes. As Mark = Wahl famously commented back in 2005, >=20 > =20 >=20 > "Unfortunately, some of the emerging protocols which also intend to = represent and transfer personal identity information have perhaps taken = a step backwards by not even considering these issues, perhaps sweeping = them under the rug in the guise of simplicity, XMLification, or "fix in = the next version", which only postpone finding interoperable solutions = to allowing applications to express the identity entries they want to = express." >=20 > =20 >=20 > SCIM is exactly one of these "emerging protocols" Wahl talks about, = and what I see now strikes me as "sweeping these issues under the rug in = the guise of simplicity". Apologies for the bluntness. >=20 > =20 >=20 > My take is that SPs are _already_ struggling to manage multi-valued = attributes, and existing mechanisms are clumsy. They would be grateful = for a specification that made operations easier at the cost of a = re-engineered schema. That calls for some thought leadership from this = working group. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 13 August 2012 10:13, Phil Hunt wrote: >=20 > I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty.=20 >=20 > Phil >=20 >=20 > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad = wrote: >=20 > > Would it have to be stored on the account database of the service = provider? >=20 > =20 >=20 > Yes. >=20 > =20 >=20 > > If so, I believe that this is impracticable in the core schema. = Indeed it implies that a service provider must extend the schema of his = account repository (LDAP partition, SQL db, =85) and =93prepare it=94 = for SCIM integration. >=20 > =20 >=20 > Why? That doesn't necessarily follow. Implementation is independent of = representation. We're talking about a change in representation to make = the API cleaner. >=20 > =20 >=20 > As a simple example, if an LDAP node is being used to hold a list of = comma-separated email addresses, it can just as easily store = comma-separated name-value pairs. >=20 > =20 >=20 > mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com > can be changed to >=20 > =20 >=20 > mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >=20 > =20 >=20 > That's why I asked if there was an SP representative on this working = group who could explain what such a change could mean for them. As of = now, it looks like other people are presuming that SPs will not be able = to implement these changes easily and are rejecting them for that = reason. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 13 August 2012 04:29, Emmanuel Dreux wrote: >=20 > =F0 addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 >=20 > Where would 3cbaaff8e84e come from? Would it have to be stored on the = account database of the service provider? >=20 > =20 >=20 > If so, I believe that this is impracticable in the core schema. Indeed = it implies that a service provider must extend the schema of his account = repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration. >=20 > This would be a show stopper. SCIM must be transparent, and must be = able to be put on top of an existing system to provide provisioning = apis. >=20 > =20 >=20 > Said differently, SCIM must not be intrusive for existing systems and = must not require modifications to allow its integration. >=20 > Correct me if I misunderstood your suggestion. >=20 > =20 >=20 > -- >=20 > Regards, >=20 > Emmanuel Dreux >=20 > http://www.cloudiway.com >=20 > Tel: +33 4 26 78 17 58 >=20 > Mobile: +33 6 47 81 26 70 >=20 > skype: Emmanuel.Dreux >=20 > =20 >=20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 > =C0 : Kelly Grizzle > Cc : scim@ietf.org; Phil Hunt > Objet : Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > =20 >=20 > > Multi-valued attributes that don't have a value sub-attribute (eg - = address) have to specified completely for uniqueness. =20 >=20 > =20 >=20 > That's exactly the point. How do we "specify completely for = uniqueness"? >=20 > =20 >=20 > In the example below, how are you proposing that the following element = be updated if we can't use positional indexes? >=20 > =20 >=20 > addresses[1].street-number =3D "243" >=20 > =20 >=20 > User object: >=20 > =20 >=20 > { >=20 > ... >=20 > addresses: [ >=20 > { >=20 > "type" : "home", >=20 > "street-number" : "35", >=20 > "street-name" : "High Road", >=20 > "suburb" : "East Camden", >=20 > "postcode" : "5346", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > }, >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > ] >=20 > } >=20 > =20 >=20 > It's impractical to use the value because it's the whole dictionary = element: >=20 > =20 >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > =20 >=20 > With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element: >=20 > =20 >=20 > addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 >=20 > { >=20 > ... >=20 > addresses: { >=20 > "d6ea365462f5" : >=20 > { >=20 > "type" : "home", >=20 > "street-number" : "35", >=20 > "street-name" : "High Road", >=20 > "suburb" : "East Camden", >=20 > "postcode" : "5346", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > }, >=20 > "3cbaaff8e84e" : >=20 > { >=20 > "type" : "office", >=20 > "street-number" : "213", >=20 > "street-name" : "Main Street", >=20 > "suburb" : "Adelaide", >=20 > "postcode" : "5000", >=20 > "state" : "SA", >=20 > "country" : "Australia" >=20 > } >=20 > } >=20 > } >=20 > =20 >=20 > If you're proposing one mechanism for composite attributes and another = mechanism for simple attributes, I would suggest that's actually more = complex than adopting a single mechanism that works the same way for = _all_ attributes. Remember that a lot of the administration is probably = going to be scripted rather than done by hand, and having two mechanisms = (depending on whether the attribute is simple or composite) will = complicate every script that has to be written. >=20 > =20 >=20 > There's a lot of talk about the "burden" on the SPs, but I believe = this is overblown. Is there any SP representative in this WG who can = tell us what this proposal will actually entail for them? >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 12 August 2012 11:53, Kelly Grizzle = wrote: >=20 > Ganesh, >=20 > =20 >=20 > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes = that have a value sub-attribute can be removed by specifying only the = value since it is unique. Multi-valued attributes that don't have a = value sub-attribute (eg - address) have to specified completely for = uniqueness. As I have said before, I am very opposed to adding a unique = identifier to each element in a multi-valued collection due to the = burden it will put on SPs. Is it elegant? No. Is it functional? Yes. = Will this non-elegance affect adoption? My opinion is that adding = unique keys to each element will have a much more detrimental effect on = adoption. >=20 > =20 >=20 > I do believe that in general PATCH can be made more intuitive without = adding uids to each element. The verbs that you propose make sense. = There is also a JSON Patch informational draft in the IETF that is = interesting - = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies = on a JSON Pointer draft which uses index-based addressing for = multi-valued attributes. I think that this is something that should be = looked at within the WG and I would be willing to lead this effort. >=20 > =20 >=20 > I'm curious if anyone else in the WG is in favor of unique identifiers = for every multi-valued element. >=20 > =20 >=20 > --Kelly >=20 > =20 >=20 > From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of = Ganesh and Sashi Prasad [g.c.prasad@gmail.com] > Sent: Saturday, August 11, 2012 10:50 AM > To: Phil Hunt > Cc: scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > Phil, >=20 > =20 >=20 > The reason we cannot use the value itself to identify an element is = that this method will only work for simple elements, not for nested = structures. i.e., if we had an array of dictionaries (e.g., we had to = record an array of addresses for each customer, with each address = element having sub-elements like street number, street name, suburb, = etc.), then it would be clumsy to supply the entire value of the array = element because it's itself a dictionary. Creating a unique key for each = element scales better. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > On 12 August 2012 01:12, Phil Hunt wrote: >=20 > Ganesh, >=20 > =20 >=20 > Here's the sample that concerned me... >=20 > The two operations differ significantly, and it's not very intuitive.=20= >=20 > With my suggestion, here's how to delete a single member from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members.2819c223-7f76-453a-919d-413861904646" >=20 > } >=20 > } >=20 > ] } >=20 > =20 >=20 > =20 >=20 > You gave other examples of an attribute with an identifier that = matched that value or of identifiers that were additional unique keys. >=20 > =20 >=20 > Given that multi-values must be each unique, I don't see the point of = the extra indexing to support this. Just use the value as the item you = wish to delete. >=20 > =20 >=20 > I agree, the delete value operation could be more explicit and clear = in general. >=20 > =20 >=20 > Phil >=20 > =20 >=20 > @independentid >=20 > www.independentid.com >=20 > phil.hunt@oracle.com >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >=20 > =20 >=20 > > For the multi-value example you gave you used the value as the = attribute name key.=20 >=20 > =20 >=20 > Now I'm confused :-). I don't believe any of my examples ever used a = value as the key. >=20 > =20 >=20 > Could you please show me which example you mean, and which parts of it = you believe to be the value? >=20 > =20 >=20 > Regards, >=20 > Ganesh=20 >=20 > On 11 August 2012 13:59, Phil Hunt wrote: >=20 >=20 > For the multi-value example you gave you used the value as the = attribute name key.=20 >=20 > =20 >=20 > That means a lot more complex indexing structure. Better to just say = delete a specific value.=20 >=20 > =20 >=20 > The spec already allows multiple values to have tags like home, work, = etc. >=20 > =20 >=20 > Phil >=20 >=20 > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad = wrote: >=20 > > In your example you are conflating value with an attribute id.=20 >=20 > I don't believe so. >=20 > =20 >=20 > I'm adopting a model where every attribute of the resource is a = key-value pair. The key is a name or ID. >=20 > =20 >=20 > For non-repeating attributes (both simple and composite), the key is = the attribute name itself.=20 >=20 > =20 >=20 > Simple attribute: >=20 > =20 >=20 > Key: "dob" >=20 > Value: "01 Jan 1970" >=20 > =20 >=20 > For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode". >=20 > =20 >=20 > Composite attribute: >=20 > =20 >=20 > Key: "address.street-number" >=20 > Value: "10" >=20 > =20 >=20 > Key: "address.suburb" >=20 > Value: "East Camden" >=20 > =20 >=20 > For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to = distinguish, and a positional index is inadequate. So we convert the = array into a dictionary and this then becomes a composite attribute = using dot notation for the key. >=20 > =20 >=20 > Multi-valued attribute: >=20 > =20 >=20 > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >=20 > Value: "john_smith@yahoo.com" >=20 > =20 >=20 > So this allows us to apply uniform treatment to any arbitrarily deep = resource structure. We can refer to every leaf value with a key that is = the fully-qualified name using dot notation. >=20 > =20 >=20 > The verbs are just unambiguous operations on these (now) explicitly = addressable attributes. >=20 > =20 >=20 > INCLUDE to a collection and specify only the value. The key is = generated and returned. The fully-qualified key is = . and the value is what was = specified in the INCLUDE. >=20 > =20 >=20 > REPLACE a fully-qualified key with a new value. If the key doesn't = exist, return a "404 Not Found". >=20 > =20 >=20 > PLACE a value at the logical location implied by the fully-qualified = key. If there is already a key with that name, return a "409 Conflict". >=20 > =20 >=20 > FORCE the fully-qualified key to hold the given value, regardless of = whether it existed before or not. Only errors possible are "400 Bad = Request" and "500 Internal Error". >=20 > =20 >=20 > RETIRE an attribute or a collection given its fully-qualified key. The = implementation will determine whether the attribute will disappear = entirely or will exist holding a null value (the blank string "" or the = empty object {} ). >=20 > =20 >=20 > I'll explain in a separate post why we need operation verbs like these = that are independent of the HTTP verbs. >=20 > =20 >=20 > Regards, >=20 > Ganesh >=20 > =20 >=20 > On 11 August 2012 10:38, wrote: >=20 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >=20 >=20 > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux = , Trey Drake , Kelly = Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >=20 > Ganesh, >=20 > =20 >=20 > In your example you are conflating value with an attribute id. I find = that confusing.=20 >=20 > =20 >=20 > I agree though that operations in patch could be a lot more explicit.=20= >=20 > =20 >=20 > Eg explicitly deleting a value by saying delete or retire.=20 >=20 >=20 > Phil >=20 >=20 > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad = wrote: >=20 > > I am concerned about your second suggestion:=20 >=20 > =20 >=20 > Let's discuss that now. >=20 > =20 >=20 > The trade-offs are very clear here. >=20 > =20 >=20 > Pros: >=20 > =20 >=20 > Pro 1. The API to manipulate resources becomes so much cleaner, = consistent and intuitive when every individual attribute value gets its = own ID. >=20 > =20 >=20 > Here's how to delete a single member from a Group, as per the current = spec: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current = spec: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20= >=20 > With my suggestion, here's how to delete a single member from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members.2819c223-7f76-453a-919d-413861904646" >=20 > } >=20 > } >=20 > ] }=20 > Here's how I suggest deleting ALL members from a group: >=20 > =20 >=20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >=20 > "operations" : [ >=20 > { >=20 > "RETIRE" : { >=20 > "key" : "members" >=20 > } >=20 > } >=20 > ] } >=20 >=20 > I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader. >=20 > =20 >=20 > Pro 2: We can apply this mechanism consistently to three areas: >=20 > (a) Manipulating multi-valued attributes of a resource >=20 > (b) Manipulating members of a group >=20 > (c) Performing bulk operations, where we simply use HTTP verbs instead = of the specialised (and semantically less ambiguous) verbs I suggested = for attributes, the "key" becomes the URI, and the "value" becomes the = corresponding JSON object. >=20 > =20 >=20 > All of them return "207 Multi-Status" with the "results" array holding = individual status codes. >=20 > =20 >=20 > In the current spec, (a) and (b) are done similarly but (c) is very = different. >=20 > =20 >=20 > Pro 3: Adoption of the standard by clients is likely to be higher = because it's simpler for them. >=20 > =20 >=20 > Pro 4: New (not incumbent) cloud providers will probably find this = easier to implement because they have no legacy. They will probably use = some form of NoSQL database and won't be constrained by the limitations = of LDAP directories. >=20 > =20 >=20 > Cons: >=20 > =20 >=20 > Con 1: Incumbent cloud providers with existing data stores in a = directory format (where multi-valued attributes are stored as = comma-separated values under a single attribute node) will find it = difficult to migrate to this model and store each attribute value as a = sub-node with its own key. This will "hinder adoption of the spec", = which is what you fear. >=20 > =20 >=20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so = I could have missed a Con or hyped a Pro :-). >=20 > =20 >=20 > In other words, we're debating interface complexity (current spec) = versus implementation complexity (my suggestion). Both can hinder = adoption of the spec by different parties. >=20 > =20 >=20 > Here's what we need to discuss - Do the Pros make the suggestio >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_C0DF57EB-84D7-4C1E-AF94-C18C3B7DE37D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = don't believe LDAP is the culprit.  You'd find the same issue in = most *existing* data models to include relational.  The issue is = whether you're forcing the hand of the SP to overhaul their data model = to accommodate SCIM.  I don't believe we would get very far if we = took that = tack.

Thanks,
Trey

On = Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

Thanks, Kelly. You've been most patient in hearing me out, = I must say. I couldn't ask for more.

Replying to = Chris Philips's mail:
> Given that you have a number of = thoughts about what could be changed in SCIM,Leif's recommendation to =  craft them in an Internet Draft may be a better way to convey your = thoughts.

I'm coming around to the same = conclusion. Do you think such an Internet Draft should be about changing = SCIM, or should it propose a complementary spec for SPs who use a = "NoLDAP" data store? I think the underlying problem is with LDAP, and = unless we change that, these proposals won't fly.

Regards,
Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

There are really two implementation options for a = uid per element =96 either store the uids in the native underlying data = store or have some secondary data store that maps elements to their uids.  The third option is to hope = that a service provider has a NoLDAP data store or its equivalent.  = None of these are practical for rapid and wide-spread = adoption.

 

> put the two together to propose a solution.

 

As I said before, I am completely on board with = cleaning up the PATCH semantics (eg =96 the inconsistency between = meta.attributes and operation=3Ddelete, etc=85).  Your suggestion of using different verbs is a good option to = consider.  This cannot be based on a uid per element, though.  = It seems as though you have admitted this in your conclusion =96 =93As = for LDAP and SCIM, I guess the best TLA is = RIP.=94

 

--Kelly

 

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

 

That = was one suggestion. Another way could be container nodes with their own = "dn"s. If one suggestion won't work, tell me another way to make it = work. I'm waiting to hear a constructive suggestion that can square an = elegant API with the implementation constraints that come from having to store multi-valued = attributes in LDAP directories.

 

I've heard enough of WHY this won't work. = For a change, tell me HOW it can be made to work. Everyone now knows = what the proposal means in terms of the API, and implementors understand = the constraints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in = the room" here, surely we should be able to crack = this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions = about what is to be done:

 

On 14 August 2012 00:27, Kelly Grizzle = <kelly.grizzle@sailpoint.com> = wrote:

> After all, no one has challenged the = claim that this proposal drastically simplifies the API for the = client

 

I agree that your proposal makes PATCH semantics = simpler and more elegant.

 

 

> =85 so it would appear to be worth doing. 

 

I strongly disagree here.  This statements = assumes that simplicity of the client API is the only factor that should be considered with the = spec.

 

Emmanuel=92s example is from a real-world service = provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM = interface that will help facilitate data exchange between multiple = Active Directory servers.  Your solution was to change the data = model from this:

 

mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com

 

I do not know of a single organization that would = change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort = (likely across other domain controllers, etc=85) to assign these unique = identifiers.  This also assumes that SCIM is the only reader/writer = of this data, which will almost never be the case.  If the data model requires uids for every element, then every piece of = non-SCIM code that writes data into the directory will have to follow = this.  Additionally, there are *many* tools and applications =  (eg =96 address books) that rely on a certain data model in Active Directory, and this would cause them to break.  = IMO this same argument holds true for most service = providers.

 

 

PATCH is an optional part of the spec.  It = was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to = solve every problem (eg =96 modifying sub-elements in nested = arrays).  Adding uids to every multi-valued element does not strike = the right balance between the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

 

Responding to extract of Melinda Shore's mail from = digest:

 

The issue being =
raised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful =
to
respond to the observation that your model requires =
more
messages with a complaint about what you seem to think is =
a
complex algorithm for attribute processing.

 

It depends on how it's implemented. I'm = confident we can have the best of both - simple API with low-overhead = implementation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've been = hearing so far)? After all, no one has challenged the claim that this = proposal drastically simplifies the API for the client, so it would = appear to be worth doing. I'm sure there's more than enough intellectual horsepower in this working group to pull this = off if we put our minds to it.

 

Regards,

Ganesh

 

On 13 August 2012 13:54, Ganesh and Sashi = Prasad <g.c.prasad@gmail.com> wrote:

> I = strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty.

Sorry Phil, but you're contradicting = yourself here. There seems to be an awful lot of matching (i.e., = reading) going on in the spec as it stands, with if-then clauses to do = one thing or another if the match either succeeds or fails. This is a = complex, chatty protocol right now!

 

   Multi-valued =
attributes:  An attribute value in the PATCH =
request
      =
body is added to the value collection if the value does not =
exist
      and =
merged if a matching value is present.  Values are matched =
by
      =
comparing the value Sub-Attribute from the PATCH request body =
to
      the =
value Sub-Attribute of the Resource.  Attributes that do =
not
      =
have a value Sub-Attribute; e.g., addresses, or do not have =
unique
      =
value Sub-Attributes cannot be matched and must instead be =
deleted
      =
then added.  Specific values can be removed from a Resource =
by
      =
adding an "operation" Sub-Attribute with the value "delete" to =
the
      =
attribute in the PATCH request body.  As with =
adding/updating
      =
attribute value collections, the value to delete is determined =
by
      =
comparing the value Sub-Attribute from the PATCH request body =
to
      the =
value Sub-Attribute of the Resource.  Attributes that do =
not
      =
have a value Sub-Attribute or that have a non-unique value =
Sub-
      =
Attribute are matched by comparing all Sub-Attribute values =
from
      the =
PATCH request body to the Sub-Attribute values of =
the
      =
Resource.  A delete operation is ignored if the attribute's =
name
      is =
in the meta.attributes list.  If the requested value to =
delete
      =
does not match a unique value on the Resource the server =
MAY
      =
return a HTTP 400 error.

 

For a spec that is supposed to be about = simplicity, the above description is anything but simple. I know you = guys have worked hard on this and I don't mean to disparage those = efforts, but think about how the above passage would appear to a new reader = (i.e., a novice to the spec, not a technology novice).

 

There is something fundamentally broken, and = it is this: multi-valued attributes without a unique identifier per = value. If you don't fix that, you won't get = simplicity.

 

We know LDAP trees are broken for = multi-valued attributes. As Mark Wahl famously commented back in 2005,

 

"Unfortunately, some of the emerging protocols which also intend = to represent and transfer personal identity information have perhaps taken a step backwards by not even considering these = issues, perhaps sweeping them under the rug in the guise of simplicity, = XMLification, or "fix in the next version", which only postpone finding = interoperable solutions to allowing applications to express the identity entries they want to = express."

 

SCIM is exactly one of these "emerging = protocols" Wahl talks about, and what I see now strikes me as "sweeping = these issues under the rug in the guise of simplicity". Apologies for the bluntness.

 

My take is that SPs are _already_ struggling = to manage multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a = specification that made operations easier at the cost of a re-engineered = schema. That calls for some thought leadership from this working = group.

 

Regards,

Ganesh

 

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:

I strongly object to anything that leads to = a read before modify requirement. Too complex and too chatty. 

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> Would it = have to be stored on the account database of the service = provider?

 

Yes.

 

> If so, I believe that this is impracticable = in the core schema. Indeed it implies that a service provider must = extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration.

 

Why? That doesn't necessarily follow. = Implementation is independent of representation. We're talking about a = change in representation to make the API cleaner.

 

As a simple example, if an LDAP node is = being used to hold a list of comma-separated email addresses, it can = just as easily store comma-separated name-value pairs.

 

 

mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com

 

That's = why I asked if there was an SP representative on this working group who = could explain what such a change could mean for them. As of now, it looks like other people are presuming that SPs will not = be able to implement these changes easily and are rejecting them for = that reason.

 

Regards,

Ganesh

 

On 13 August 2012 04:29, Emmanuel Dreux = <edreux@cloudiway.com> wrote:

=F0  addresses.3cbaaff8e84e.street-number =3D "243"

 

Where would 3cbaaff8e84e come from? Would it have to be stored on the = account database of the service provider?

 

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a = service provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration.

This would be a show stopper. SCIM must be = transparent, and must be able to be put on top of an existing system to = provide provisioning apis.

 

Said differently, SCIM = must not be intrusive for existing systems and must not require = modifications to allow its integration.

Correct me if I = misunderstood your suggestion.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 = 78 17 58

Mobile: +33 6 47 = 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : dimanche 12 ao=FBt 2012 04:53
=C0 : Kelly Grizzle
Cc : scim@ietf.org; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue = 24

 

>  Multi-valued attributes that don't have a value = sub-attribute (eg - address) have to specified completely for = uniqueness.  

 

That's exactly the point. = How do we "specify completely for uniqueness"?

 

In the example below, how = are you proposing that the following element be updated if we can't use = positional indexes?

 

addresses[1].street-number = =3D "243"

 

User = object:

 

{

  = ...

  addresses: = [

    = {

      = "type" : "home",

      = "street-number" : "35",

      = "street-name" : "High Road",

      = "suburb" : "East Camden",

      = "postcode" : "5346",

      = "state" : "SA",

      = "country" : "Australia"

    = },

    = {

      = "type" : "office",

      = "street-number" : "213",

      = "street-name" : "Main Street",

      = "suburb" : "Adelaide",

      = "postcode" : "5000",

      = "state" : "SA",

      = "country" : "Australia"

    = }

  = ]

}

 

It's impractical to use = the value because it's the whole dictionary = element:

 

{

  "type" : = "office",

  "street-number" : = "213",

  "street-name" : = "Main Street",

  "suburb" : = "Adelaide",

  "postcode" : = "5000",

  "state" : = "SA",

  "country" : = "Australia"

}

 

With my proposal, the = "addresses" array gets converted to a dictionary, and then we have a = stable way of referencing this element:

 

addresses.3cbaaff8e84e.street-number =3D = "243"

 

{

  = ...

  addresses: = {

    = "d6ea365462f5" :

    = {

      = "type" : "home",

      = "street-number" : "35",

      = "street-name" : "High Road",

      = "suburb" : "East Camden",

      = "postcode" : "5346",

      = "state" : "SA",

      = "country" : "Australia"

    = },

    = "3cbaaff8e84e" :

    = {

      = "type" : "office",

      = "street-number" : "213",

      = "street-name" : "Main Street",

      = "suburb" : "Adelaide",

      = "postcode" : "5000",

      = "state" : "SA",

      = "country" : "Australia"

    = }

  = }

}

 

If you're proposing one = mechanism for composite attributes and another mechanism for simple = attributes, I would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. = Remember that a lot of the administration is probably going to be = scripted rather than done by hand, and having two mechanisms (depending = on whether the attribute is simple or composite) will complicate every script that has to be = written.

 

There's a lot of talk = about the "burden" on the SPs, but I believe this is overblown. Is there = any SP representative in this WG who can tell us what this proposal will actually entail for them?

 

Regards,

Ganesh

 

On 12 August 2012 11:53, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Ganesh,

 

This is exactly how PATCH works in SCIM 1.0.  Multi-valued = attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. =  Multi-valued attributes that don't have a value sub-attribute (eg = - address) have to specified completely for uniqueness.  As I have = said before, I am very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will = put on SPs.  Is it elegant?  No.  Is it functional? =  Yes.  Will this non-elegance affect adoption?  My = opinion is that adding unique keys to each element will have a much more = detrimental effect on adoption.

 

I do believe that in general PATCH can be made more intuitive = without adding uids to each element.  The verbs that you propose make sense.  There is also a JSON Patch = informational draft in the IETF that is interesting - http://tools.ietf.org/html/draft-ietf-appsawg-json-patch= -02.  It relies on a JSON Pointer draft which uses index-based = addressing for multi-valued attributes.  I think that this is = something that should be looked at within the WG and I would be willing = to lead this effort.

 

I'm curious if anyone else in the WG is in favor of unique = identifiers for every multi-valued element.

 

--Kelly

 

From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh and = Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

Phil,

 

The reason we cannot use = the value itself to identify an element is that this method will only = work for simple elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses = for each customer, with each address element having sub-elements like = street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictionary. Creating a unique key for each = element scales better.

 

Regards,

Ganesh

On 12 August 2012 01:12, = Phil Hunt <phil.hunt@oracle.com> = wrote:

Ganesh,

 

Here's the sample that = concerned me...

The two operations differ = significantly, and it's not very = intuitive. 

With my suggestion, here's = how to delete a single member from a group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members.2819c223-7f76-453a-919d-413861904646"

}

}

] }

 

 

You gave = other examples of an attribute with an identifier that matched that = value or of identifiers that were additional unique keys.

 

Given that = multi-values must be each unique, I don't see the point of the extra = indexing to support this. Just use the value as the item you wish to delete.

 

I agree, = the delete value operation could be more explicit and clear in = general.

 

 

 

 

On 2012-08-11, at 2:30 AM, = Ganesh and Sashi Prasad wrote:

 

>  For the multi-value example you gave you used the = value as the attribute name key. 

 

Now I'm confused :-). I = don't believe any of my examples ever used a value as the = key.

 

Could you please show me = which example you mean, and which parts of it you believe to be the = value?

 

Regards,

Ganesh 

On 11 August 2012 13:59, = Phil Hunt <phil.hunt@oracle.com> = wrote:


For the multi-value example you gave you used the value as the attribute = name key. 

 

That means a lot more = complex indexing structure. Better to just say delete a specific = value. 

 

The spec already allows = multiple values to have tags like home, work, = etc.

 

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

> In your example = you are conflating value with an attribute id. 

I don't believe so.

 

I'm adopting a model where = every attribute of the resource is a key-value pair. The key is a name = or ID.

 

For non-repeating = attributes (both simple and composite), the key is the attribute name = itself. 

 

Simple = attribute:

 

Key: = "dob"

Value: "01 Jan = 1970"

 

For composite attributes, = the key employs dot notation to specify the fully-qualified attribute = name, e.g., "address.postcode".

 

Composite = attribute:

 

Key: = "address.street-number"

Value: = "10"

 

Key: = "address.suburb"

Value: "East = Camden"

 

For repeating = (multi-valued) attributes, I'm suggesting that there be new keys for = each individual value, otherwise they are impossible to distinguish, and = a positional index is inadequate. So we convert the array into a dictionary and this = then becomes a composite attribute using dot notation for the = key.

 

Multi-valued = attribute:

 

Key: = "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

 

So this allows us to apply = uniform treatment to any arbitrarily deep resource structure. We can = refer to every leaf value with a key that is the fully-qualified name using dot notation.

 

The verbs are just = unambiguous operations on these (now) explicitly addressable = attributes.

 

INCLUDE to a collection = and specify only the value. The key is generated and returned. The = fully-qualified key is = <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

 

REPLACE a fully-qualified = key with a new value. If the key doesn't exist, return a "404 Not = Found".

 

PLACE a value at the = logical location implied by the fully-qualified key. If there is already = a key with that name, return a "409 Conflict".

 

FORCE the fully-qualified = key to hold the given value, regardless of whether it existed before or = not. Only errors possible are "400 Bad Request" and "500 Internal Error".

 

RETIRE an attribute or a = collection given its fully-qualified key. The implementation will = determine whether the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {} = ).

 

I'll explain in a separate = post why we need operation verbs like these that are independent of the = HTTP verbs.

 

Regards,

Ganesh

 

On 11 August 2012 10:38, = <scim-request@ietf.org> = wrote:

If= you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil = Hunt)


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudiway.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" = <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

Ganesh,

 

In your example you are = conflating value with an attribute id. I find that = confusing. 

 

I agree though that = operations in patch could be a lot more = explicit. 

 

Eg explicitly deleting a = value by saying delete or retire. 


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

 >  I am concerned about your second = suggestion: 

 

Let's discuss that = now.

 

The trade-offs are very = clear here.

 

Pros:

 

Pro 1. The API to = manipulate resources becomes so much cleaner, consistent and intuitive = when every individual attribute value gets its own = ID.

 

Here's how to delete a = single member from a Group, as per the current = spec:

 

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: =
application/json
   =
Authorization: Bearer h480djs93hd8
   ETag: =
W/"a330bc54f0671c9"
 
   =
{
    =
 "schemas": ["urn:scim:schemas:core:1.0"],
    =
 "members": [
       =
{
        =
; "display": "Babs Jensen",
        =
; "value": =
"2819c223-7f76-453a-919d-413861904646"
        =
; "operation": "delete"
       =
}
    =
 ]
   =
}


Here's how to delete ALL members from a group according to the current = spec:

 

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: =
application/json
   =
Authorization: Bearer h480djs93hd8
   ETag: =
W/"a330bc54f0671c9"
 
   =
{
    =
 "schemas": ["urn:scim:schemas:core:1.0"],
    =
 "meta": {
       =
"attributes": [
        =
; "members"
       =
]
    =
 }
   =
}


The two operations differ significantly, and it's not very = intuitive. 

With my suggestion, here's = how to delete a single member from a group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members.2819c223-7f76-453a-919d-413861904646"

}

}

] }
Here's how I suggest deleting ALL members from a = group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members"

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader.

 

Pro 2: We can apply this = mechanism consistently to three areas:

(a) Manipulating = multi-valued attributes of a resource

(b) Manipulating members = of a group

(c) Performing bulk = operations, where we simply use HTTP verbs instead of the specialised = (and semantically less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the corresponding JSON = object.

 

All of them return "207 = Multi-Status" with the "results" array holding individual status = codes.

 

In the current spec, (a) = and (b) are done similarly but (c) is very = different.

 

Pro 3: Adoption of the = standard by clients is likely to be higher because it's simpler for = them.

 

Pro 4: New (not incumbent) = cloud providers will probably find this easier to implement because they = have no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP = directories.

 

Cons:

 

Con 1: Incumbent cloud = providers with existing data stores in a directory format (where = multi-valued attributes are stored as comma-separated values under a = single attribute node) will find it difficult to migrate to this model and = store each attribute value as a sub-node with its own key. This will = "hinder adoption of the spec", which is what you = fear.

 

Have I summed up the Pros = and Cons correctly? I'm biased of course, so I could have missed a Con = or hyped a Pro :-).

 

In other words, we're = debating interface complexity (current spec) versus implementation = complexity (my suggestion). Both can hinder adoption of the spec by = different parties.

 

Here's what we need to = discuss - Do the Pros make the suggestio

 

 

 


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

= --Apple-Mail=_C0DF57EB-84D7-4C1E-AF94-C18C3B7DE37D-- From mrutkows@us.ibm.com Mon Aug 13 15:40:51 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F3F21F84A2 for ; Mon, 13 Aug 2012 15:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.235 X-Spam-Level: X-Spam-Status: No, score=-9.235 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyExxAlRxC5v for ; Mon, 13 Aug 2012 15:40:51 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62721F84A1 for ; Mon, 13 Aug 2012 15:40:51 -0700 (PDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 13 Aug 2012 16:40:50 -0600 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 13 Aug 2012 16:39:58 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 3286C1FF001B for ; Mon, 13 Aug 2012 22:39:53 +0000 (WET) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7DMdvbh173398 for ; Mon, 13 Aug 2012 16:39:57 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7DMfFkC020193 for ; Mon, 13 Aug 2012 16:41:15 -0600 Received: from d03nm133.boulder.ibm.com (d03nm133.boulder.ibm.com [9.17.195.180]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7DMfEQj020164 for ; Mon, 13 Aug 2012 16:41:15 -0600 Auto-Submitted: auto-generated From: Matt Rutkowski To: scim@ietf.org Message-ID: Date: Mon, 13 Aug 2012 16:39:55 -0600 X-MIMETrack: Serialize by Router on D03NM133/03/M/IBM(Release 8.5.3HF266 | January 13, 2012) at 08/13/2012 16:39:56 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF0CADFEF07A18f9e8a93df938690918c08BBF0CADFEF07A1" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12081322-1780-0000-0000-00000850352A X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000290; HX=3.00000194; KW=3.00000007; PH=3.00000001; SC=3.00000007; SDB=6.00165065; UDB=6.00037365; UTC=2012-08-13 22:40:48 Subject: [scim] AUTO: Matt Rutkowski/Austin/IBM is travelling (returning 08/20/2012) X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 22:40:51 -0000 --0__=08BBF0CADFEF07A18f9e8a93df938690918c08BBF0CADFEF07A1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 08/20/2012. I will be travelling on business and unable to respond to email reliabl= y. For emergencies please contact my manager Johanna Koester or call my mo= bile number in Bluepages. Note: This is an automated response to your message "scim Digest, Vol = 8, Issue 56" sent on 08/13/2012 15:07:35. This is the only notification you will receive while this person is awa= y.= --0__=08BBF0CADFEF07A18f9e8a93df938690918c08BBF0CADFEF07A1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 08= /20/2012.

I will be travelling on bus= iness and unable to respond to email reliably.  For emergencies pl= ease contact my manager Johanna Koester or call my mobile number in Blu= epages.


Note: Thi= s is an automated response to your message  "scim Digest, Vol 8, Issue 56" sent = on 08/13/2012 15:07:35.

This is t= he only notification you will receive while this person is away.= = --0__=08BBF0CADFEF07A18f9e8a93df938690918c08BBF0CADFEF07A1-- From g.c.prasad@gmail.com Mon Aug 13 17:11:32 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F421F84E2 for ; Mon, 13 Aug 2012 17:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnLtkRKwenZj for ; Mon, 13 Aug 2012 17:11:28 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E9FEF21F84E6 for ; Mon, 13 Aug 2012 17:11:26 -0700 (PDT) Received: by bkty7 with SMTP id y7so1838651bkt.31 for ; Mon, 13 Aug 2012 17:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LbT4QxgoAzDVfMRED3Af2E9TEHnajnbG0nsq/6Sa5LM=; b=Ag0gxs6BNvHWbLA4JPfgNNZ7oty3w3y95rMalWcbeCcVLpLkq7EtQL/tKb1tnNsgW8 swtIrHqnKUdUiKk3GUvJKqo3l1p6uSPNopBXmqp/hPZHuscPc0IMmle6QCYDcMsfnpwS q+e3Opdcd0ZQP2KsD3hRFWxxSEgOs4UGMrYh3Buv36Nwnff/nsjwbD+p04k+pyzrB7/0 JPy0m2zIz6X8o0szHt6E8SdKA9pK8k1WtmZLllws1PQ/WDDQePRlSS5kQtEwT8hnb0ev 3/1rVs6W+YwwuaPQXqk6gkVKzkBeaJwpsY78woBfgZkFVNBVp0iMuKnSvb8ePTMQJV/S P2WA== Received: by 10.205.128.141 with SMTP id he13mr5299136bkc.112.1344903085701; Mon, 13 Aug 2012 17:11:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Mon, 13 Aug 2012 17:11:04 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Tue, 14 Aug 2012 10:11:04 +1000 Message-ID: To: Trey Drake Content-Type: multipart/alternative; boundary=0015173febeaae3a3c04c72ea683 Cc: "scim@ietf.org" , Phil Hunt , Emmanuel Dreux , Melinda Shore , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 00:11:32 -0000 --0015173febeaae3a3c04c72ea683 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Trey, You have a point, but there are two levels to the difficulty. Relational schemas are not cast in stone the way LDAP schemas are. Many of the object classes in LDAP are not containers that can have their own DNs, so even if an SP is willing to change their data model, they won't get far if they're using LDAP. Regards, Ganesh On 14 August 2012 07:47, Trey Drake wrote: > I don't believe LDAP is the culprit. You'd find the same issue in most > *existing* data models to include relational. The issue is whether you'r= e > forcing the hand of the SP to overhaul their data model to accommodate > SCIM. I don't believe we would get very far if we took that tack. > > Thanks, > Trey > > On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad > wrote: > > Thanks, Kelly. You've been most patient in hearing me out, I must say. I > couldn't ask for more. > > Replying to Chris Philips's mail: > > Given that you have a number of thoughts about what could be changed in > SCIM,Leif's recommendation to craft them in an Internet Draft may be a > better way to convey your thoughts. > > I'm coming around to the same conclusion. Do you think such an Internet > Draft should be about changing SCIM, or should it propose a complementary > spec for SPs who use a "NoLDAP" data store? I think the underlying proble= m > is with LDAP, and unless we change that, these proposals won't fly. > > Regards, > Ganesh > > On 14 August 2012 01:54, Kelly Grizzle wrote= : > >> There are really two implementation options for a uid per element =96 >> either store the uids in the native underlying data store or have some >> secondary data store that maps elements to their uids. The third option= is >> to hope that a service provider has a NoLDAP data store or its equivalen= t. >> None of these are practical for rapid and wide-spread adoption.**** >> >> ** ** >> >> > put the two together to propose a solution.**** >> >> ** ** >> >> As I said before, I am completely on board with cleaning up the PATCH >> semantics (eg =96 the inconsistency between meta.attributes and >> operation=3Ddelete, etc=85). Your suggestion of using different verbs i= s a >> good option to consider. This cannot be based on a uid per element, >> though. It seems as though you have admitted this in your conclusion = =96 =93As >> for LDAP and SCIM, I guess the best TLA is RIP.=94**** >> >> ** ** >> >> --Kelly**** >> >> ** ** >> >> *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Sent:* Monday, August 13, 2012 9:56 AM >> *To:* Kelly Grizzle >> *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> ** ** >> >> That was one suggestion. Another way could be container nodes with their >> own "dn"s. If one suggestion won't work, tell me another way to make it >> work. I'm waiting to hear a constructive suggestion that can square an >> elegant API with the implementation constraints that come from having to >> store multi-valued attributes in LDAP directories.**** >> >> ** ** >> >> I've heard enough of WHY this won't work. For a change, tell me HOW it >> can be made to work. Everyone now knows what the proposal means in terms= of >> the API, and implementors understand the constraints of legacy data stor= es, >> so put the two together to propose a solution. C'mon, we have the "smart= est >> guys in the room" here, surely we should be able to crack this.**** >> >> ** ** >> >> Regards,**** >> >> Ganesh**** >> >> ** ** >> >> P.S. I'm rapidly reaching my own conclusions about what is to be done:**= * >> * >> >> >> http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-n= oldap.html >> **** >> >> ** ** >> >> On 14 August 2012 00:27, Kelly Grizzle >> wrote:**** >> >> > After all, no one has challenged the claim that this proposal >> drastically simplifies the API for the client**** >> >> **** >> >> I agree that your proposal makes PATCH semantics simpler and more elegan= t. >> **** >> >> **** >> >> **** >> >> > =85 so it would appear to be worth doing. **** >> >> **** >> >> I strongly disagree here. This statements assumes that simplicity of th= e >> client API is the only factor that should be considered with the spec.**= * >> * >> >> **** >> >> Emmanuel=92s example is from a real-world service provider that would no= t >> be able to implement the spec easily with a uid per element. He is work= ing >> on a SCIM interface that will help facilitate data exchange between >> multiple Active Directory servers. Your solution was to change the data >> model from this:**** >> >> **** >> >> mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com= **** >> >> **** >> >> to this:**** >> >> **** >> >> mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D >> john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** >> >> **** >> >> I do not know of a single organization that would change their Active >> Directory data model to fit this. For one thing, it would be a huge dat= a >> migration effort (likely across other domain controllers, etc=85) to ass= ign >> these unique identifiers. This also assumes that SCIM is the only >> reader/writer of this data, which will almost never be the case. If the >> data model requires uids for every element, then every piece of non-SCIM >> code that writes data into the directory will have to follow this. >> Additionally, there are **many** tools and applications (eg =96 address >> books) that rely on a certain data model in Active Directory, and this >> would cause them to break. IMO this same argument holds true for most >> service providers.**** >> >> **** >> >> **** >> >> PATCH is an optional part of the spec. It was primarily introduced to >> make modifying resources with large multi-valued lists more efficient. = It >> does not need to solve every problem (eg =96 modifying sub-elements in n= ested >> arrays). Adding uids to every multi-valued element does not strike the >> right balance between the needs of the client and the needs of the servi= ce >> provider.**** >> >> **** >> >> --Kelly**** >> >> **** >> >> *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Sent:* Monday, August 13, 2012 1:35 AM >> *To:* Phil Hunt; Melinda Shore >> *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org**** >> >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> **** >> >> Responding to extract of Melinda Shore's mail from digest:**** >> >> **** >> >> The issue being raised here isn't endpoint logic, but**** >> >> network traffic, and I'm pretty sure it's not very helpful to**** >> >> respond to the observation that your model requires more**** >> >> messages with a complaint about what you seem to think is a**** >> >> complex algorithm for attribute processing.**** >> >> **** >> >> It depends on how it's implemented. I'm confident we can have the best o= f >> both - simple API with low-overhead implementation. Can we brainstorm HO= W >> this proposal can be implemented rather than WHY it can't be implemented >> (which is mostly what I've been hearing so far)? After all, no one has >> challenged the claim that this proposal drastically simplifies the API f= or >> the client, so it would appear to be worth doing. I'm sure there's more >> than enough intellectual horsepower in this working group to pull this o= ff >> if we put our minds to it.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 13:54, Ganesh and Sashi Prasad >> wrote:**** >> >> > I strongly object to anything that leads to a read before modify >> requirement. Too complex and too chatty.**** >> >> Sorry Phil, but you're contradicting yourself here. There seems to be an >> awful lot of matching (i.e., reading) going on in the spec as it stands, >> with if-then clauses to do one thing or another if the match either >> succeeds or fails. This is a complex, chatty protocol right now!**** >> >> **** >> >> Multi-valued attributes: An attribute value in the PATCH request**** >> >> body is added to the value collection if the value does not exist*= *** >> >> and merged if a matching value is present. Values are matched by*= *** >> >> comparing the value Sub-Attribute from the PATCH request body to**= ** >> >> the value Sub-Attribute of the Resource. Attributes that do not**= ** >> >> have a value Sub-Attribute; e.g., addresses, or do not have unique= **** >> >> value Sub-Attributes cannot be matched and must instead be deleted= **** >> >> then added. Specific values can be removed from a Resource by**** >> >> adding an "operation" Sub-Attribute with the value "delete" to the= **** >> >> attribute in the PATCH request body. As with adding/updating**** >> >> attribute value collections, the value to delete is determined by*= *** >> >> comparing the value Sub-Attribute from the PATCH request body to**= ** >> >> the value Sub-Attribute of the Resource. Attributes that do not**= ** >> >> have a value Sub-Attribute or that have a non-unique value Sub-***= * >> >> Attribute are matched by comparing all Sub-Attribute values from**= ** >> >> the PATCH request body to the Sub-Attribute values of the**** >> >> Resource. A delete operation is ignored if the attribute's name**= ** >> >> is in the meta.attributes list. If the requested value to delete*= *** >> >> does not match a unique value on the Resource the server MAY**** >> >> return a HTTP 400 error.**** >> >> **** >> >> For a spec that is supposed to be about simplicity, the above descriptio= n >> is anything but simple. I know you guys have worked hard on this and I >> don't mean to disparage those efforts, but think about how the above >> passage would appear to a new reader (i.e., a novice to the spec, not a >> technology novice).**** >> >> **** >> >> There is something fundamentally broken, and it is this: multi-valued >> attributes without a unique identifier per value. If you don't fix that, >> you won't get simplicity.**** >> >> **** >> >> We know LDAP trees are broken for multi-valued attributes. As Mark Wahl = famously >> commented back >> in 2005,**** >> >> **** >> >> "Unfortunately, some of the emerging protocols which also intend to >> represent and transfer personal identity information have perhaps taken = a >> step backwards by not even considering these issues, perhaps sweeping th= em >> under the rug in the guise of simplicity, XMLification, or "fix in the n= ext >> version", which only postpone finding interoperable solutions to allowin= g >> applications to express the identity entries they want to express."**** >> >> **** >> >> SCIM is exactly one of these "emerging protocols" Wahl talks about, and >> what I see now strikes me as "sweeping these issues under the rug in the >> guise of simplicity". Apologies for the bluntness.**** >> >> **** >> >> My take is that SPs are _already_ struggling to manage multi-valued >> attributes, and existing mechanisms are clumsy. >> They would be grateful for a specification that made operations easier a= t >> the cost of a re-engineered schema. That calls for some thought leadersh= ip >> from this working group.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 10:13, Phil Hunt wrote:**** >> >> I strongly object to anything that leads to a read before modify >> requirement. Too complex and too chatty. >> >> Phil**** >> >> >> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad >> wrote:**** >> >> > Would it have to be stored on the account database of the service >> provider?**** >> >> **** >> >> Yes.**** >> >> **** >> >> > If so, I believe that this is impracticable in the core schema. Indeed >> it implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM >> integration.**** >> >> **** >> >> Why? That doesn't necessarily follow. Implementation is independent of >> representation. We're talking about a change in representation to make t= he >> API cleaner.**** >> >> **** >> >> As a simple example, if an LDAP node is being used to hold a list of >> comma-separated email addresses, it can just as easily store >> comma-separated name-value pairs.**** >> >> **** >> >> mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com= **** >> >> can be changed to**** >> >> **** >> >> mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D >> john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** >> >> **** >> >> That's why I asked if there was an SP representative on this working >> group who could explain what such a change could mean for them. As of no= w, >> it looks like other people are presuming that SPs will not be able to >> implement these changes easily and are rejecting them for that reason.**= * >> * >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 04:29, Emmanuel Dreux wrote:***= * >> >> =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> **** >> >> Where would 3cbaaff8e84e come from? Would it have to be stored on the >> account database of the service provider?**** >> >> **** >> >> If so, I believe that this is impracticable in the core schema. Indeed i= t >> implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM >> integration.**** >> >> This would be a show stopper. SCIM must be transparent, and must be able >> to be put on top of an existing system to provide provisioning apis.**** >> >> **** >> >> Said differently, SCIM must not be intrusive for existing systems and >> must not require modifications to allow its integration.**** >> >> Correct me if I misunderstood your suggestion.**** >> >> **** >> >> --**** >> >> Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> **** >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org; Phil Hunt >> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> **** >> >> > Multi-valued attributes that don't have a value sub-attribute (eg - >> address) have to specified completely for uniqueness. **** >> >> **** >> >> That's exactly the point. How do we "specify completely for uniqueness"?= * >> *** >> >> **** >> >> In the example below, how are you proposing that the following element b= e >> updated if we can't use positional indexes?**** >> >> **** >> >> addresses[1].street-number =3D "243"**** >> >> **** >> >> User object:**** >> >> **** >> >> {**** >> >> ...**** >> >> addresses: [**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> ]**** >> >> }**** >> >> **** >> >> It's impractical to use the value because it's the whole dictionary >> element:**** >> >> **** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> **** >> >> With my proposal, the "addresses" array gets converted to a dictionary, >> and then we have a stable way of referencing this element:**** >> >> **** >> >> addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> **** >> >> {**** >> >> ...**** >> >> addresses: {**** >> >> "d6ea365462f5" :**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> "3cbaaff8e84e" :**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> }**** >> >> }**** >> >> **** >> >> If you're proposing one mechanism for composite attributes and another >> mechanism for simple attributes, I would suggest that's actually more >> complex than adopting a single mechanism that works the same way for _al= l_ >> attributes. Remember that a lot of the administration is probably going = to >> be scripted rather than done by hand, and having two mechanisms (dependi= ng >> on whether the attribute is simple or composite) will complicate every >> script that has to be written.**** >> >> **** >> >> There's a lot of talk about the "burden" on the SPs, but I believe this >> is overblown. Is there any SP representative in this WG who can tell us >> what this proposal will actually entail for them?**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 12 August 2012 11:53, Kelly Grizzle >> wrote:**** >> >> Ganesh,**** >> >> **** >> >> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes >> that have a value sub-attribute can be removed by specifying only the va= lue >> since it is unique. Multi-valued attributes that don't have a value >> sub-attribute (eg - address) have to specified completely for uniqueness= . >> As I have said before, I am very opposed to adding a unique identifier = to >> each element in a multi-valued collection due to the burden it will put = on >> SPs. Is it elegant? No. Is it functional? Yes. Will this non-elegan= ce >> affect adoption? My opinion is that adding unique keys to each element >> will have a much more detrimental effect on adoption.**** >> >> **** >> >> I do believe that in general PATCH can be made more intuitive without >> adding uids to each element. The verbs that you propose make sense. Th= ere >> is also a JSON Patch informational draft in the IETF that is interesting= - >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >> on a JSON Pointer draft which uses index-based addressing for multi-valu= ed >> attributes. I think that this is something that should be looked at wit= hin >> the WG and I would be willing to lead this effort.**** >> >> **** >> >> I'm curious if anyone else in the WG is in favor of unique identifiers >> for every multi-valued element.**** >> >> **** >> >> --Kelly**** >> >> **** >> ------------------------------ >> >> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of >> Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >> *Sent:* Saturday, August 11, 2012 10:50 AM >> *To:* Phil Hunt >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> Phil, **** >> >> **** >> >> The reason we cannot use the value itself to identify an element is that >> this method will only work for simple elements, not for nested structure= s. >> i.e., if we had an array of dictionaries (e.g., we had to record an arra= y >> of addresses for each customer, with each address element having >> sub-elements like street number, street name, suburb, etc.), then it wou= ld >> be clumsy to supply the entire value of the array element because it's >> itself a dictionary. Creating a unique key for each element scales bette= r. >> **** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> On 12 August 2012 01:12, Phil Hunt wrote:**** >> >> Ganesh, **** >> >> **** >> >> Here's the sample that concerned me...**** >> >> The two operations differ significantly, and it's not very intuitive. **= * >> * >> >> With my suggestion, here's how to delete a single member from a group:**= * >> * >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> **** >> >> **** >> >> You gave other examples of an attribute with an identifier that matched >> that value or of identifiers that were additional unique keys.**** >> >> **** >> >> Given that multi-values must be each unique, I don't see the point of th= e >> extra indexing to support this. Just use the value as the item you wish = to >> delete.**** >> >> **** >> >> I agree, the delete value operation could be more explicit and clear in >> general.**** >> >> **** >> >> Phil**** >> >> **** >> >> @independentid**** >> >> www.independentid.com**** >> >> phil.hunt@oracle.com**** >> >> **** >> >> **** >> >> **** >> >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** >> >> **** >> >> > For the multi-value example you gave you used the value as the >> attribute name key. **** >> >> **** >> >> Now I'm confused :-). I don't believe any of my examples ever used a >> value as the key.**** >> >> **** >> >> Could you please show me which example you mean, and which parts of it >> you believe to be the value?**** >> >> **** >> >> Regards,**** >> >> Ganesh **** >> >> On 11 August 2012 13:59, Phil Hunt wrote:**** >> >> >> For the multi-value example you gave you used the value as the attribute >> name key. **** >> >> **** >> >> That means a lot more complex indexing structure. Better to just say >> delete a specific value. **** >> >> **** >> >> The spec already allows multiple values to have tags like home, work, et= c. >> **** >> >> **** >> >> Phil**** >> >> >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >> wrote:**** >> >> > In your example you are conflating value with an attribute id. >> >> I don't believe so. **** >> >> **** >> >> I'm adopting a model where every attribute of the resource is a key-valu= e >> pair. The key is a name or ID.**** >> >> **** >> >> For non-repeating attributes (both simple and composite), the key is the >> attribute name itself. **** >> >> **** >> >> Simple attribute:**** >> >> **** >> >> Key: "dob"**** >> >> Value: "01 Jan 1970"**** >> >> **** >> >> For composite attributes, the key employs dot notation to specify the >> fully-qualified attribute name, e.g., "address.postcode".**** >> >> **** >> >> Composite attribute:**** >> >> **** >> >> Key: "address.street-number"**** >> >> Value: "10"**** >> >> **** >> >> Key: "address.suburb"**** >> >> Value: "East Camden"**** >> >> **** >> >> For repeating (multi-valued) attributes, I'm suggesting that there be ne= w >> keys for each individual value, otherwise they are impossible to >> distinguish, and a positional index is inadequate. So we convert the arr= ay >> into a dictionary and this then becomes a composite attribute using dot >> notation for the key.**** >> >> **** >> >> Multi-valued attribute:**** >> >> **** >> >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** >> >> Value: "john_smith@yahoo.com"**** >> >> **** >> >> So this allows us to apply uniform treatment to any arbitrarily deep >> resource structure. We can refer to every leaf value with a key that is = the >> fully-qualified name using dot notation.**** >> >> **** >> >> The verbs are just unambiguous operations on these (now) explicitly >> addressable attributes.**** >> >> **** >> >> INCLUDE to a collection and specify only the value. The key is generated >> and returned. The fully-qualified key is >> . and the value is what was specifi= ed >> in the INCLUDE.**** >> >> **** >> >> REPLACE a fully-qualified key with a new value. If the key doesn't exist= , >> return a "404 Not Found".**** >> >> **** >> >> PLACE a value at the logical location implied by the fully-qualified key= . >> If there is already a key with that name, return a "409 Conflict".**** >> >> **** >> >> FORCE the fully-qualified key to hold the given value, regardless of >> whether it existed before or not. Only errors possible are "400 Bad >> Request" and "500 Internal Error".**** >> >> **** >> >> RETIRE an attribute or a collection given its fully-qualified key. The >> implementation will determine whether the attribute will disappear entir= ely >> or will exist holding a null value (the blank string "" or the empty obj= ect >> {} ).**** >> >> **** >> >> I'll explain in a separate post why we need operation verbs like these >> that are independent of the HTTP verbs.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 11 August 2012 10:38, wrote:**** >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/scim >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send scim mailing list submissions to >> scim@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >> >> You can reach the person managing the list at >> scim-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >> >> Today's Topics: >> >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >> >> >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux < >> edreux@cloudiway.com>, Trey Drake , Kelly >> Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> Ganesh,**** >> >> **** >> >> In your example you are conflating value with an attribute id. I find >> that confusing. **** >> >> **** >> >> I agree though that operations in patch could be a lot more explicit. **= * >> * >> >> **** >> >> Eg explicitly deleting a value by saying delete or retire. **** >> >> >> Phil**** >> >> >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >> wrote:**** >> >> > I am concerned about your second suggestion: **** >> >> **** >> >> Let's discuss that now.**** >> >> **** >> >> The trade-offs are very clear here.**** >> >> **** >> >> Pros:**** >> >> **** >> >> Pro 1. The API to manipulate resources becomes so much cleaner, >> consistent and intuitive when every individual attribute value gets its = own >> ID.**** >> >> **** >> >> Here's how to delete a single member from a Group, as per the current >> spec:**** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> **** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "members": [**** >> >> {**** >> >> "display": "Babs Jensen",**** >> >> "value": "2819c223-7f76-453a-919d-413861904646"**** >> >> "operation": "delete"**** >> >> }**** >> >> ]**** >> >> }**** >> >> >> Here's how to delete ALL members from a group according to the current >> spec:**** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> **** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "meta": {**** >> >> "attributes": [**** >> >> "members"**** >> >> ]**** >> >> }**** >> >> }**** >> >> >> The two operations differ significantly, and it's not very intuitive. **= * >> * >> >> With my suggestion, here's how to delete a single member from a group:**= * >> * >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } >> Here's how I suggest deleting ALL members from a group:**** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAcce= pt: application/json Authorization: Bearer h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> >> I'm sure you'll agree that this is simpler, more consistent and more >> intuitive to a reader.**** >> >> **** >> >> Pro 2: We can apply this mechanism consistently to three areas:**** >> >> (a) Manipulating multi-valued attributes of a resource**** >> >> (b) Manipulating members of a group**** >> >> (c) Performing bulk operations, where we simply use HTTP verbs instead o= f >> the specialised (and semantically less ambiguous) verbs I suggested for >> attributes, the "key" becomes the URI, and the "value" becomes the >> corresponding JSON object.**** >> >> **** >> >> All of them return "207 Multi-Status" with the "results" array holding >> individual status codes.**** >> >> **** >> >> In the current spec, (a) and (b) are done similarly but (c) is very >> different.**** >> >> **** >> >> Pro 3: Adoption of the standard by clients is likely to be higher becaus= e >> it's simpler for them.**** >> >> **** >> >> Pro 4: New (not incumbent) cloud providers will probably find this easie= r >> to implement because they have no legacy. They will probably use some fo= rm >> of NoSQL database and won't be constrained by the limitations of LDAP >> directories.**** >> >> **** >> >> Cons:**** >> >> **** >> >> Con 1: Incumbent cloud providers with existing data stores in a director= y >> format (where multi-valued attributes are stored as comma-separated valu= es >> under a single attribute node) will find it difficult to migrate to this >> model and store each attribute value as a sub-node with its own key. Thi= s >> will "hinder adoption of the spec", which is what you fear.**** >> >> **** >> >> Have I summed up the Pros and Cons correctly? I'm biased of course, so I >> could have missed a Con or hyped a Pro :-).**** >> >> **** >> >> In other words, we're debating interface complexity (current spec) versu= s >> implementation complexity (my suggestion). Both can hinder adoption of t= he >> spec by different parties.**** >> >> **** >> >> Here's what we need to discuss - Do the Pros make the suggestio**** >> >> **** >> >> **** >> >> ** ** >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --0015173febeaae3a3c04c72ea683 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Trey,


You have a point, but there are two levels to t= he difficulty. Relational schemas are not cast in stone the way LDAP schema= s are. Many of the object classes in LDAP are not containers that can have = their own DNs, so even if an SP is willing to change their data model, they= won't get far if they're using LDAP.

Regards,
Ganesh

= On 14 August 2012 07:47, Trey Drake <trey.drake@unboundid.com&g= t; wrote:
I don= 9;t believe LDAP is the culprit. =A0You'd find the same issue in most *= existing* data models to include relational. =A0The issue is whether you= 9;re forcing the hand of the SP to overhaul their data model to accommodate= SCIM. =A0I don't believe we would get very far if we took that tack.
Thanks,
Trey

On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com>= ; wrote:

Thanks, Ke= lly. You've been most patient in hearing me out, I must say. I couldn&#= 39;t ask for more.

Replying to Chris Philips's mail:=
>=A0Given that you have a number of thoughts about what coul= d be changed in SCIM,Leif's recommendation to =A0craft them in an Inter= net Draft may be a better way to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an Inte= rnet Draft should be about changing SCIM, or should it propose a complement= ary spec for SPs who use a "NoLDAP" data store? I think the under= lying problem is with LDAP, and unless we change that, these proposals won&= #39;t fly.

Regards,
Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

There are really two= implementation options for a uid per element =96 either store the uids in = the native underlying data store or have some secondary data store that maps elements to their uids.=A0 The third option is to hope that a se= rvice provider has a NoLDAP data store or its equivalent.=A0 None of these = are practical for rapid and wide-spread adoption.

=A0

> put the two together to propose a solution.As I said before, I= am completely on board with cleaning up the PATCH semantics (eg =96 the in= consistency between meta.attributes and operation=3Ddelete, etc=85).=A0 Your suggestion of using different verbs is a good option to consider.=A0 = This cannot be based on a uid per element, though.=A0 It seems as though yo= u have admitted this in your conclusion =96 =93As for LDAP and SCIM, I gues= s the best TLA is RIP.=94

=A0<= /p>

--Kelly<= /span>

=A0<= /p>

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24
=

=A0

That was one suggestion. Another way could be container nodes with = their own "dn"s. If one suggestion won't work, tell me anothe= r way to make it work. I'm waiting to hear a constructive suggestion th= at can square an elegant API with the implementation constraints that come from having to store multi-valued att= ributes in LDAP directories.

=A0

I've heard enough of WHY this won't wor= k. For a change, tell me HOW it can be made to work. Everyone now knows wha= t the proposal means in terms of the API, and implementors understand the c= onstraints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys= in the room" here, surely we should be able to crack this.<= /u>

=A0

Regards,

Ganesh

=A0

P.S. I'm rapidly reaching my own conclusion= s about what is to be done:

=A0

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@= sailpoint.com> wrote:

> After all, no one has challenged the claim= that this proposal drastically simplifies the API for the client=

=A0=

I agree that your p= roposal makes PATCH semantics simpler and more elegant.

=A0=

=A0=

> =85 so it would appear to be worth doing.=A0

=A0

I strongly disagree= here.=A0 This statements assumes that simplicity of the client API is the = only factor that should be considered with the spec.

=A0

Emmanuel=92s example is f= rom a real-world service provider that would not be able to implement the spec easily with a uid per element.=A0 He is working on a SCIM interface t= hat will help facilitate data exchange between multiple Active Directory se= rvers.=A0 Your solution was to change the data model from this:

=A0<= /p> 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

=A0<= /p>

to this:=

=A0<= /p>

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf= =3Djohn.smith@gma= il.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0<= /p>

I do not know of a sin= gle organization that would change their Active Directory data model to fit this.=A0 For one thing, it would be a huge data migration effort (likely a= cross other domain controllers, etc=85) to assign these unique identifiers.= =A0 This also assumes that SCIM is the only reader/writer of this data, whi= ch will almost never be the case.=A0 If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this.=A0 Ad= ditionally, there are *many* tools and applications =A0(eg =96 addre= ss books) that rely on a certain data model in Active Directory, and this would cause them to break.=A0 IMO this= same argument holds true for most service providers.<= /p>

=A0

=A0<= /p>

PATCH is an optional p= art of the spec. =A0It was primarily introduced to make modifying resources= with large multi-valued lists more efficient.=A0 It does not need to solve ever= y problem (eg =96 modifying sub-elements in nested arrays).=A0 Adding uids = to every multi-valued element does not strike the right balance between the= needs of the client and the needs of the service provider.

=A0

--Kelly

=A0<= /p>

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

Res= ponding to extract of Melinda Shore's mail from digest:

=A0

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to<=
u>
respond to the observation that your model requires more=

messages with a complaint about what you seem to think is a<=
/u>
complex algorithm for attribute processing.

=A0

It depends on how it's implemented. I'm= confident we can have the best of both - simple API with low-overhead impl= ementation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've= been hearing so far)? After all, no one has challenged the claim that this= proposal drastically simplifies the API for the client, so it would appear= to be worth doing.=A0I'm sure there's more than enough intellectual horsepower in this working group to pull this off= if we put our minds to it.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 13:54, Ganesh and Sashi Prasa= d <g.c.prasad@= gmail.com> wrote:

>=A0I strongl= y object to anything that leads to a read before modify requirement. Too co= mplex and too chatty.

Sorry Phil, but you're contradicting yours= elf here.=A0There seems to be an awful lot of matching (i.e., reading) goin= g on in the spec as it stands, with if-then clauses to do one thing or another if the match either succeeds or fails. This is a complex,= chatty protocol right now!

=A0

=A0=A0 Multi-valued attributes:=A0 An=
 attribute value in the PATCH request
=A0=A0=A0=A0=A0 body is added to the =
value collection if the value does not exist
=A0=A0=A0=A0=A0 and merged if a match=
ing value is present.=A0 Values are matched by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute; e.g., addresses, or do not have unique
=A0=A0=A0=A0=A0 value Sub-Attributes =
cannot be matched and must instead be deleted
=A0=A0=A0=A0=A0 then added.=A0 Specif=
ic values can be removed from a Resource by
=A0=A0=A0=A0=A0 adding an "opera=
tion" Sub-Attribute with the value "delete" to the=

=A0=A0=A0=A0=A0 attribute in the PATC=
H request body.=A0 As with adding/updating
=A0=A0=A0=A0=A0 attribute value colle=
ctions, the value to delete is determined by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute or that have a non-unique value Sub-
=A0=A0=A0=A0=A0 Attribute are matched=
 by comparing all Sub-Attribute values from
=A0=A0=A0=A0=A0 the PATCH request bod=
y to the Sub-Attribute values of the
=A0=A0=A0=A0=A0 Resource.=A0 A delete=
 operation is ignored if the attribute's name

=A0=A0=A0=A0=A0 is in the meta.attrib=
utes list.=A0 If the requested value to delete


=A0=A0=A0=A0=A0 does not match a uniq=
ue value on the Resource the server MAY


=A0=A0=A0=A0=A0 return a HTTP 400 err=
or.

=A0

For a spec that is supposed to be about simplic= ity, the above description is anything but simple. I know you guys have wor= ked hard on this and I don't mean to disparage those efforts, but think about how the above passage would appear to a new reader (i.e., = a novice to the spec, not a technology novice).

=A0

There is something fundamentally broken, and it= is this: multi-valued attributes without a unique identifier per value. If= you don't fix that, you won't get simplicity.

=A0

We know LDAP trees are broken for multi-valued = attributes. As Mark Wahl famously commented back in 2005,

=A0

"Unfortunately, some of the e= merging protocols which also intend to represent and transfer personal iden= tity information have perhaps taken a step backwards by not even considering these issues, = perhaps sweeping them under the rug in the guise of simplicity, XMLificatio= n, or "fix in the next version", which only postpone finding inte= roperable solutions to allowing applications to express the identity entries they want to express."<= u>

=A0

SCIM is exactly one of these "emerging pro= tocols" Wahl talks about, and what I see now strikes me as "sweep= ing these issues under the rug in the guise of simplicity". Apologies for the bluntness.

=A0

My take is that SPs are _already_ struggling to= manage multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specificat= ion that made operations easier at the cost of a re-engineered schema. That= calls for some thought leadership from this working group.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com= > wrote:

I strongly object to anything that leads to a r= ead before modify requirement. Too complex and too chatty.=A0

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

> Would it hav= e to be stored on the account database of the service provider?

=A0

Yes.<= /u>

=A0

<= span style=3D"color:#0f243e">> If so, I believe that this is impracticab= le in the core schema.=A0Indeed it implies that a service provider must ext= end the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

=A0

Why? That doesn't necessarily follow. Imple= mentation is independent of representation. We're talking about a chang= e in representation to make the API cleaner.

=A0

As a simple example, if an LDAP node is being u= sed to hold a list of comma-separated email addresses, it can just as easil= y store comma-separated name-value pairs.

=A0

=A0

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf= =3Djohn.smith@gma= il.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0

That's why I asked if there was an SP representa= tive on this working group who could explain what such a change could mean = for them. As of now, it looks like other people are presuming that SPs will not be a= ble to implement these changes easily and are rejecting them for that reaso= n.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

=F0=A0 addresses.3cbaaff8e84e.street-number =3D "243"

<= p class=3D"MsoNormal">=A0

Where would 3cbaaff8e84e come from? Would it have to be stored on the account database of th= e service provider?

=A0

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a service = provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This would be a show stopper. SCIM must be transparent, and must be able t= o be put on top of an existing system to provide provisioning apis.<= u>

=A0

Said differently= , SCIM must not be intrusive for existing systems and must not require modi= fications to allow its integration.

Correct me if I misund= erstood your suggestion.

=A0

--

Regards,=

Emman= uel Dreux

http://www.cloudiway.com

Tel: +33 4 26 78= 17 58

Mobile: +33 6 47 81= 26 70

skype: Emmanuel.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

=

>=A0 Multi-valued attributes that d= on't have a value sub-attribute (eg - address) have to specified comple= tely for uniqueness.=A0=A0

=A0

That's exactly the point.= How do we "specify completely for uniqueness"?<= /u>

=A0

In the example below, how are= you proposing that the following element be updated if we can't use po= sitional indexes?

=A0

addresses[1].street-number = =3D "243"

=A0

User object:=

=A0

{

=A0 ...<= /p>

=A0 addresses: [

=A0 =A0 {

=A0 =A0 =A0 "type" = : "home",

=A0 =A0 =A0 "street-numb= er" : "35",

=A0 =A0 =A0 "street-name= " : "High Road",

=A0 =A0 =A0 "suburb"= ; : "East Camden",

=A0 =A0 =A0 "postcode&qu= ot; : "5346",

=A0 =A0 =A0 "state"= : "SA",

=A0 =A0 =A0 "country&quo= t; : "Australia"

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" = : "office",

=A0 =A0 =A0 "street-numb= er" : "213",

=A0 =A0 =A0 "street-name= " : "Main Street",

=A0 =A0 =A0 "suburb"= ; : "Adelaide",

=A0 =A0 =A0 "postcode&qu= ot; : "5000",

=A0 =A0 =A0 "state"= : "SA",

=A0 =A0 =A0 "country&quo= t; : "Australia"

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use t= he value because it's the whole dictionary element:

=A0

{

=A0 "type" : "= office",

=A0 "street-number"= : "213",

=A0 "street-name" := "Main Street",

=A0 "suburb" : &quo= t;Adelaide",

=A0 "postcode" : &q= uot;5000",

=A0 "state" : "= ;SA",

=A0 "country" : &qu= ot;Australia"

}

=A0

With my proposal, the "a= ddresses" array gets converted to a dictionary, and then we have a sta= ble way of referencing this element:

=A0

addresses.3cbaaff8e84e.street= -number =3D "243"

=A0

{

=A0 ...<= /p>

=A0 addresses: {

=A0 =A0 "d6ea365462f5&qu= ot; :

=A0 =A0 {

=A0 =A0 =A0 "type" = : "home",

=A0 =A0 =A0 "street-numb= er" : "35",

=A0 =A0 =A0 "street-name= " : "High Road",

=A0 =A0 =A0 "suburb"= ; : "East Camden",

=A0 =A0 =A0 "postcode&qu= ot; : "5346",

=A0 =A0 =A0 "state"= : "SA",

=A0 =A0 =A0 "country&quo= t; : "Australia"

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e&qu= ot; :

=A0 =A0 {

=A0 =A0 =A0 "type" = : "office",

=A0 =A0 =A0 "street-numb= er" : "213",

=A0 =A0 =A0 "street-name= " : "Main Street",

=A0 =A0 =A0 "suburb"= ; : "Adelaide",

=A0 =A0 =A0 "postcode&qu= ot; : "5000",

=A0 =A0 =A0 "state"= : "SA",

=A0 =A0 =A0 "country&quo= t; : "Australia"

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one m= echanism for composite attributes and another mechanism for simple attribut= es, I would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember = that a lot of the administration is probably going to be scripted rather th= an done by hand, and having two mechanisms (depending on whether the attrib= ute is simple or composite) will complicate every script that has to be written.

=A0

There's a lot of talk abo= ut the "burden" on the SPs, but I believe this is overblown. Is t= here any SP representative in this WG who can tell us what this proposal will actually entail for them?

=A0

Regards,=

Ganesh

=A0

On 12 August 2012 11:53, Kell= y Grizzle <kelly.grizzle@sailpoint.com> wrote:

Ganesh,

=A0

This is exactly how PAT= CH works in SCIM 1.0. =A0Multi-valued attributes that have a value sub-attr= ibute can be removed by specifying only the value since it is unique. =A0Multi-v= alued attributes that don't have a value sub-attribute (eg - address) h= ave to specified completely for uniqueness. =A0As I have said before, I am = very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will put= on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in ge= neral PATCH can be made more intuitive without adding uids to each element.= =A0The verbs that you propose make sense. =A0There is also a JSON Patch informati= onal draft in the IETF that is interesting -=A0http://tools.= ietf.org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= u>

=A0

I'm curious if anyo= ne else in the WG is in favor of unique identifiers for every multi-valued = element.

=A0

--Kelly

=A0

From:<= /span> scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the = value itself to identify an element is that this method will only work for = simple elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for= each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creating a unique key for each eleme= nt scales better.

=A0

Regards,=

Ganesh

On 12 August 2012 01:12, Phil= Hunt <phil.hu= nt@oracle.com> wrote:

Ganesh,

=A0

Here's the sample that co= ncerned me...

The two operations differ sig= nificantly, and it's not very intuitive.=A0

With my suggestion, here'= s how to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4d= a3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7= f76-453a-919d-413861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute wi= th an identifier that matched that value or of identifiers that were additional unique keys.

=A0

Given that multi-values must be each uniqu= e, I don't see the point of the extra indexing to support this. Just use the value as the item you wish to delete.

=A0

I agree, the delete value operation could = be more explicit and clear in general.

=A0

Phil=

=A0<= /u>

@independentid=

phil.= hunt@oracle.com

=A0

=A0

=A0

On 2012-08-11, at 2:30 AM, Ga= nesh and Sashi Prasad wrote:

=A0

>= ;=A0 For the multi-value example you gave you used the value as the attribu= te name key.=A0

=A0

Now I'm confused :-). I d= on't believe any of my examples ever used a value as the key.=

=A0

Could you please show me whic= h example you mean, and which parts of it you believe to be the value?

=A0

Regards,=

Ganesh=A0

On 11 August 2012 13:59, Phil= Hunt <phil.hu= nt@oracle.com> wrote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex= indexing structure. Better to just say delete a specific value.=A0<= u>

=A0

The spec already allows multi= ple values to have tags like home, work, etc.

=A0

Phil<= /span>


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you ar= e conflating value with an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model wher= e every attribute of the resource is a key-value pair. The key is a name or= ID.

=A0

For non-repeating attributes = (both simple and composite), the key is the attribute name itself.=A0

=A0

Simple attribute:

=A0

Key: "dob"

Value: "01 Jan 1970"= ;

=A0

For composite attributes, the= key employs dot notation to specify the fully-qualified attribute name, e.= g., "address.postcode".

=A0

Composite attribute:

=A0

Key: "address.street-num= ber"

Value: "10"<= u>

=A0

Key: "address.suburb&quo= t;

Value: "East Camden"= ;

=A0

For repeating (multi-valued) = attributes, I'm suggesting that there be new keys for each individual v= alue, otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this th= en becomes a composite attribute using dot notation for the key.<= /u>

=A0

Multi-valued attribute:

=A0

Key: "emails.7dfcb444-74= d8-4f17-aa66-daf9ea3bd902"

=A0

So this allows us to apply un= iform treatment to any arbitrarily deep resource structure. We can refer to= every leaf value with a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguou= s operations on these (now) explicitly addressable attributes.

=A0

INCLUDE to a collection and s= pecify only the value. The key is generated and returned. The fully-qualifi= ed key is <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

=A0

REPLACE a fully-qualified key= with a new value. If the key doesn't exist, return a "404 Not Fou= nd".

=A0

PLACE a value at the logical = location implied by the fully-qualified key. If there is already a key with= that name, return a "409 Conflict".

=A0

FORCE the fully-qualified key= to hold the given value, regardless of whether it existed before or not. O= nly errors possible are "400 Bad Request" and "500 Internal Error".

=A0

RETIRE an attribute or a coll= ection given its fully-qualified key. The implementation will determine whe= ther the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {}= ).

=A0

I'll explain in a separat= e post why we need operation verbs like these that are independent of the H= TTP verbs.

=A0

Regards,=

Ganesh

=A0

On 11 August 2012 10:38, <= scim-request@iet= f.org> wrote:

If you have received this digest without all the individual mess= age
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,<= /p>

=A0

In your example you are confl= ating value with an attribute id. I find that confusing.=A0

=A0

I agree though that operation= s in patch could be a lot more explicit.=A0

=A0

Eg explicitly deleting a valu= e by saying delete or retire.=A0


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:<= /span>=A0

=A0

Let's discuss that now.

=A0

The trade-offs are very clear= here.

=A0

Pros:

=A0

Pro 1. The API to manipulate = resources becomes so much cleaner, consistent and intuitive when every indi= vidual attribute value gets its own ID.

=A0

Here's how to delete a si= ngle member from a Group, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "member=
s": [


=A0=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0=A0 =
"display": "Babs Jensen",


=A0=A0=A0=A0=A0=A0=A0=A0 =
"value": "2819c223-7f76-453a-919d-413861904646"<=
u>


=A0=A0=A0=A0=A0=A0=A0=A0 =
"operation": "delete"


=A0=A0=A0=A0=A0=A0 }


=A0=A0=A0=A0 ]<=
/u>


=A0=A0 }=



Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "meta&q=
uot;: {


=A0=A0=A0=A0=A0=A0 "=
attributes": [


=A0=A0=A0=A0=A0=A0=A0=A0 =
"members"


=A0=A0=A0=A0=A0=A0 ]


=A0=A0=A0=A0 }<=
/u>


=A0=A0 }=



The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here'= s how to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4d= a3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7= f76-453a-919d-413861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4d= a3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members"

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mech= anism consistently to three areas:

(a) Manipulating multi-valued= attributes of a resource

(b) Manipulating members of a= group

(c) Performing bulk operation= s, where we simply use HTTP verbs instead of the specialised (and semantica= lly less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the cor= responding JSON object.

=A0

All of them return "207 = Multi-Status" with the "results" array holding individual st= atus codes.

=A0

In the current spec, (a) and = (b) are done similarly but (c) is very different.

=A0

Pro 3: Adoption of the standa= rd by clients is likely to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cl= oud providers will probably find this easier to implement because they have= no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud provid= ers with existing data stores in a directory format (where multi-valued att= ributes are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store = each attribute value as a sub-node with its own key. This will "hinder= adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and= Cons correctly? I'm biased of course, so I could have missed a Con or = hyped a Pro :-).

=A0

In other words, we're deb= ating interface complexity (current spec) versus implementation complexity = (my suggestion). Both can hinder adoption of the spec by different parties.

=A0

Here's what we need to di= scuss - Do the Pros make the suggestio

=A0

=A0

=A0


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


--0015173febeaae3a3c04c72ea683-- From y.oiwa@aist.go.jp Mon Aug 13 21:09:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648A921F8627 for ; Mon, 13 Aug 2012 21:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.677 X-Spam-Level: X-Spam-Status: No, score=-7.677 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDBxcc1Mr8Jv for ; Mon, 13 Aug 2012 21:09:52 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3621F8623 for ; Mon, 13 Aug 2012 21:09:52 -0700 (PDT) Received: from mail-gg0-f199.google.com ([209.85.161.199]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUCnPjUXjg+tzW1A0jk2e2S1COpAFgSiZ@postini.com; Mon, 13 Aug 2012 21:09:52 PDT Received: by ggmo4 with SMTP id o4so7986829ggm.2 for ; Mon, 13 Aug 2012 21:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=PSsXXYX1Xs0bsjiTYNegaptFTzGQyyI3dfr+BDGakdE=; b=ldPpCLqQaL2Xj+LpqHkUZHEw4EctBWukBoQkvCMeFlkZanFurPhQyUnKU7dybBqw8G AKsdLrDDo5YgbeCl27zKfm3mICs3jlj7aJ3SANCRC6U8aomLvUvaGqEIJr+3JAGTMmkY 3Qb6DvhZjobAYo4w5FoYWSWvoUY60Pjlp6GL0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=PSsXXYX1Xs0bsjiTYNegaptFTzGQyyI3dfr+BDGakdE=; b=Ij6OqWsTxBJaSBtng7Ue1oXn8fnWdbGacH6zwP6aYjDSqBeFNwU3IOacD2SidbTo9k 68nInMS40jF61K96acvu6A0NSYBipyPZcJnPQsNUo1mhlbyW50qbGxXi6ZpXloJuJ0q6 jFIiCHn/iRucouRF63cGSjGvh5MaebREMLW6ASYtEButXXl/0kvTO4rRHw6nwRtzCChE qMpQuJigRaO+BW1IF21T4fcr6GiPUZxHnko4W8g/0m1dZzWCsfeXhZGv4sPhuahLapmy cRBX/qLyssH61/9N6lnIhvQQl8MJSHgJAskiV8Mq2/jY/Of6RxEaVkM79wrrdcr87myd ujLg== Received: by 10.42.97.70 with SMTP id m6mr7487729icn.27.1344917389126; Mon, 13 Aug 2012 21:09:49 -0700 (PDT) Received: by 10.42.97.70 with SMTP id m6mr7487723icn.27.1344917389044; Mon, 13 Aug 2012 21:09:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.99.3 with HTTP; Mon, 13 Aug 2012 21:09:28 -0700 (PDT) From: Yutaka OIWA Date: Tue, 14 Aug 2012 13:09:28 +0900 Message-ID: To: scim Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJUVoFTAAXjf9+3Rp798Y892KFjNrr5wju4ywcwvEz2U87b2eIH2fnJfIJdkTTlKfqGXTKmcCZjLKaGT7ZdYvP2TXXHepheTNu67mEeHHQm5B/EhS36GIvlJ2S5dReVRPAATrZ Cc: http-auth@ietf.org Subject: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 04:09:53 -0000 Dear SCIM people, I am currently proposing a new HTTP authentication protocol for enabling secure mutual authentication using shared credentials (including pre-shared keys or passwords). There are many features beyond conventional authentication methods, but from the viewpoint of key/credential management (related to scim), this authentication scheme have two properties concurrently: * enables use of encrypted (hashed) passwords on the server side - somewhat similar to Basic/Form - contrary to CHAP/Digest (which require passwords-equivalent), * allows non-plaintext exchange on-wire - similar to, but much stronger than CHAP/Digest - contrary to Basic/Form. Server-side encrypted passwords are per-server basis, so any stolen credential cannot be reused by other people, provided that the client-side credentials have fair amount of entropy (unlike 1234, password or xhtdj). Under this background, my point asking on this mail is: we have one missing feature on our protocol design: delivery of encrypted passwords from clients to servers on the first registration phase. Currently we have two ways for first-time registration: * letting servers know the plaintext passwords, and encrypt them on the server side. * encrypting the passwords manually on the client side, while carefully inputing protocol-dependent security parameters that the server gives. But both of them are unsatisfactory. We have planned to develop a common format in the next steps for exchanging such authentication parameters between peers for single account registrations using Web browsers/Web Forms or other clients. Looking beyond our proposal, there are also many key/credential formats which requires key deliveries from clients to servers on the first registration, including such as X.509 certificates (either full-certificate or just DN part), unsigned RSA public keys, JWKs, SSH pubkeys, machine-generated strong secrets, and even unix-hashed passwords. We now aware that many parts of requirements for such use-cases are common with what SCIM requires, and we should avoid designing two similar parts on the same table. I remember that in Vancouver SCIM session, some people also raised requirements for deploying such non-plaintext secret within SCIM framework. So, I'd like to reuse current data format for SCIM exchange for such purposes. To do that, I plan to propose a generic extension mechanism for putting key formats other than just plaintext passwords. Such format may be useful for other credentials as well, and it can, of course, be used for SCIM-based account management. So I think that this extension satisfies some needs for SCIM as well as other use cases. Feedbacks are appreciated. -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From trey.drake@unboundid.com Mon Aug 13 21:39:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C1221F86DE for ; Mon, 13 Aug 2012 21:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T75L1w9VmPG8 for ; Mon, 13 Aug 2012 21:39:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D135E21F8671 for ; Mon, 13 Aug 2012 21:39:33 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9272353obb.31 for ; Mon, 13 Aug 2012 21:39:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7WzY/9XDbVjmBdknrFjDaLvvOO70YQTQzUugLojwvLo=; b=dmvcc36X7KdOea3fXnbmWd1ci4htbu6MBLlOMhLPmGZUTZfuy8AKDiwfCMGstfgGvH psLCl0JYStexDy8yD+Z1xVzvBgvqQ/YwjcP1p4cBP0vizh0+AMiwkFU73gFVNuq00FR4 NXUHplJjnnWbnmXt9ewx4LDEcvhBgmPc8uIzPjkCFmqcapA8Bn55c9BESAZy+ff/yRZL niJpTuITCmXRGwGBKu5R/SapROlb5w8FtcCpfcbX9UIEDzRmJQ3h9itcHZ9t4Dd8WmEj xVJvoUm3k+twY5a5v8zLwLJYusAjj3YXC5RtYLLeYsieE0CG8PAcAw/pyA5fyriEuXLx jQmQ== Received: by 10.182.52.42 with SMTP id q10mr16284550obo.46.1344919173057; Mon, 13 Aug 2012 21:39:33 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id qk5sm1678979obc.10.2012.08.13.21.39.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Aug 2012 21:39:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E7D1D59E-4F2D-4AF5-95BC-255C4A3E7B8B" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: Date: Mon, 13 Aug 2012 23:39:29 -0500 Message-Id: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Ganesh and Sashi Prasad X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQnlWDEuJilkADt5vWa5PigJnwoUNyrAC0mpOyU6jP+jq/vb34FMFRa/7XTQSds28qW+kmCn Cc: "scim@ietf.org" , Phil Hunt , Emmanuel Dreux , Melinda Shore , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 04:39:43 -0000 --Apple-Mail=_E7D1D59E-4F2D-4AF5-95BC-255C4A3E7B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 IMO, one of the reasons why SCIM adoption is growing is that it does not = force implementors to rework their schema. I realize that you may think = relational schemas may be more pliant, but most implementors are not = deploying a greenfields SCIM backend. Rather, SCIM is a front-end atop = existing infrastructure. A service provider backed with a "user" table = defined with columns mapped to SCIM user attributes will be just as = handicapped as a SP backed with LDAP/person. Specifically, there's no = hook for meta-data (guid) on a relational database column. =20 I'm not sure what you mean by object classes not having a DN. Object = classes don't have DNs - entries do. Thanks, Trey On Aug 13, 2012, at 7:11 PM, Ganesh and Sashi Prasad = wrote: > Hi Trey, >=20 > You have a point, but there are two levels to the difficulty. = Relational schemas are not cast in stone the way LDAP schemas are. Many = of the object classes in LDAP are not containers that can have their own = DNs, so even if an SP is willing to change their data model, they won't = get far if they're using LDAP. >=20 > Regards, > Ganesh >=20 > On 14 August 2012 07:47, Trey Drake wrote: > I don't believe LDAP is the culprit. You'd find the same issue in = most *existing* data models to include relational. The issue is whether = you're forcing the hand of the SP to overhaul their data model to = accommodate SCIM. I don't believe we would get very far if we took that = tack. >=20 > Thanks, > Trey >=20 > On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad = wrote: >=20 >> Thanks, Kelly. You've been most patient in hearing me out, I must = say. I couldn't ask for more. >>=20 >> Replying to Chris Philips's mail: >> > Given that you have a number of thoughts about what could be = changed in SCIM,Leif's recommendation to craft them in an Internet = Draft may be a better way to convey your thoughts. >>=20 >> I'm coming around to the same conclusion. Do you think such an = Internet Draft should be about changing SCIM, or should it propose a = complementary spec for SPs who use a "NoLDAP" data store? I think the = underlying problem is with LDAP, and unless we change that, these = proposals won't fly. >>=20 >> Regards, >> Ganesh >>=20 >> On 14 August 2012 01:54, Kelly Grizzle = wrote: >> There are really two implementation options for a uid per element =96 = either store the uids in the native underlying data store or have some = secondary data store that maps elements to their uids. The third option = is to hope that a service provider has a NoLDAP data store or its = equivalent. None of these are practical for rapid and wide-spread = adoption. >>=20 >> =20 >>=20 >> > put the two together to propose a solution. >>=20 >> =20 >>=20 >> As I said before, I am completely on board with cleaning up the PATCH = semantics (eg =96 the inconsistency between meta.attributes and = operation=3Ddelete, etc=85). Your suggestion of using different verbs = is a good option to consider. This cannot be based on a uid per = element, though. It seems as though you have admitted this in your = conclusion =96 =93As for LDAP and SCIM, I guess the best TLA is RIP.=94 >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Sent: Monday, August 13, 2012 9:56 AM >> To: Kelly Grizzle >> Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org >>=20 >>=20 >> Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >>=20 >> =20 >>=20 >> That was one suggestion. Another way could be container nodes with = their own "dn"s. If one suggestion won't work, tell me another way to = make it work. I'm waiting to hear a constructive suggestion that can = square an elegant API with the implementation constraints that come from = having to store multi-valued attributes in LDAP directories. >>=20 >> =20 >>=20 >> I've heard enough of WHY this won't work. For a change, tell me HOW = it can be made to work. Everyone now knows what the proposal means in = terms of the API, and implementors understand the constraints of legacy = data stores, so put the two together to propose a solution. C'mon, we = have the "smartest guys in the room" here, surely we should be able to = crack this. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> P.S. I'm rapidly reaching my own conclusions about what is to be = done: >>=20 >> = http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nol= dap.html=20 >>=20 >> =20 >>=20 >> On 14 August 2012 00:27, Kelly Grizzle = wrote: >>=20 >> > After all, no one has challenged the claim that this proposal = drastically simplifies the API for the client >>=20 >> =20 >>=20 >> I agree that your proposal makes PATCH semantics simpler and more = elegant. >>=20 >> =20 >>=20 >> =20 >>=20 >> > =85 so it would appear to be worth doing.=20 >>=20 >> =20 >>=20 >> I strongly disagree here. This statements assumes that simplicity of = the client API is the only factor that should be considered with the = spec. >>=20 >> =20 >>=20 >> Emmanuel=92s example is from a real-world service provider that would = not be able to implement the spec easily with a uid per element. He is = working on a SCIM interface that will help facilitate data exchange = between multiple Active Directory servers. Your solution was to change = the data model from this: >>=20 >> =20 >>=20 >> mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com >> =20 >>=20 >> to this: >>=20 >> =20 >>=20 >> mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >>=20 >> =20 >>=20 >> I do not know of a single organization that would change their Active = Directory data model to fit this. For one thing, it would be a huge = data migration effort (likely across other domain controllers, etc=85) = to assign these unique identifiers. This also assumes that SCIM is the = only reader/writer of this data, which will almost never be the case. = If the data model requires uids for every element, then every piece of = non-SCIM code that writes data into the directory will have to follow = this. Additionally, there are *many* tools and applications (eg =96 = address books) that rely on a certain data model in Active Directory, = and this would cause them to break. IMO this same argument holds true = for most service providers. >>=20 >> =20 >>=20 >> =20 >>=20 >> PATCH is an optional part of the spec. It was primarily introduced = to make modifying resources with large multi-valued lists more = efficient. It does not need to solve every problem (eg =96 modifying = sub-elements in nested arrays). Adding uids to every multi-valued = element does not strike the right balance between the needs of the = client and the needs of the service provider. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Sent: Monday, August 13, 2012 1:35 AM >> To: Phil Hunt; Melinda Shore >> Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org >>=20 >>=20 >> Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >>=20 >> =20 >>=20 >> Responding to extract of Melinda Shore's mail from digest: >>=20 >> =20 >>=20 >> The issue being raised here isn't endpoint logic, but >> network traffic, and I'm pretty sure it's not very helpful to >> respond to the observation that your model requires more >> messages with a complaint about what you seem to think is a >> complex algorithm for attribute processing. >> =20 >>=20 >> It depends on how it's implemented. I'm confident we can have the = best of both - simple API with low-overhead implementation. Can we = brainstorm HOW this proposal can be implemented rather than WHY it can't = be implemented (which is mostly what I've been hearing so far)? After = all, no one has challenged the claim that this proposal drastically = simplifies the API for the client, so it would appear to be worth doing. = I'm sure there's more than enough intellectual horsepower in this = working group to pull this off if we put our minds to it. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> On 13 August 2012 13:54, Ganesh and Sashi Prasad = wrote: >>=20 >> > I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty. >>=20 >> Sorry Phil, but you're contradicting yourself here. There seems to be = an awful lot of matching (i.e., reading) going on in the spec as it = stands, with if-then clauses to do one thing or another if the match = either succeeds or fails. This is a complex, chatty protocol right now! >>=20 >> =20 >>=20 >> Multi-valued attributes: An attribute value in the PATCH request >> body is added to the value collection if the value does not = exist >> and merged if a matching value is present. Values are matched = by >> comparing the value Sub-Attribute from the PATCH request body = to >> the value Sub-Attribute of the Resource. Attributes that do = not >> have a value Sub-Attribute; e.g., addresses, or do not have = unique >> value Sub-Attributes cannot be matched and must instead be = deleted >> then added. Specific values can be removed from a Resource by >> adding an "operation" Sub-Attribute with the value "delete" to = the >> attribute in the PATCH request body. As with adding/updating >> attribute value collections, the value to delete is determined = by >> comparing the value Sub-Attribute from the PATCH request body = to >> the value Sub-Attribute of the Resource. Attributes that do = not >> have a value Sub-Attribute or that have a non-unique value Sub- >> Attribute are matched by comparing all Sub-Attribute values = from >> the PATCH request body to the Sub-Attribute values of the >> Resource. A delete operation is ignored if the attribute's = name >> is in the meta.attributes list. If the requested value to = delete >> does not match a unique value on the Resource the server MAY >> return a HTTP 400 error. >> =20 >>=20 >> For a spec that is supposed to be about simplicity, the above = description is anything but simple. I know you guys have worked hard on = this and I don't mean to disparage those efforts, but think about how = the above passage would appear to a new reader (i.e., a novice to the = spec, not a technology novice). >>=20 >> =20 >>=20 >> There is something fundamentally broken, and it is this: multi-valued = attributes without a unique identifier per value. If you don't fix that, = you won't get simplicity. >>=20 >> =20 >>=20 >> We know LDAP trees are broken for multi-valued attributes. As Mark = Wahl famously commented back in 2005, >>=20 >> =20 >>=20 >> "Unfortunately, some of the emerging protocols which also intend to = represent and transfer personal identity information have perhaps taken = a step backwards by not even considering these issues, perhaps sweeping = them under the rug in the guise of simplicity, XMLification, or "fix in = the next version", which only postpone finding interoperable solutions = to allowing applications to express the identity entries they want to = express." >>=20 >> =20 >>=20 >> SCIM is exactly one of these "emerging protocols" Wahl talks about, = and what I see now strikes me as "sweeping these issues under the rug in = the guise of simplicity". Apologies for the bluntness. >>=20 >> =20 >>=20 >> My take is that SPs are _already_ struggling to manage multi-valued = attributes, and existing mechanisms are clumsy. They would be grateful = for a specification that made operations easier at the cost of a = re-engineered schema. That calls for some thought leadership from this = working group. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> On 13 August 2012 10:13, Phil Hunt wrote: >>=20 >> I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty.=20 >>=20 >> Phil >>=20 >>=20 >> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad = wrote: >>=20 >> > Would it have to be stored on the account database of the service = provider? >>=20 >> =20 >>=20 >> Yes. >>=20 >> =20 >>=20 >> > If so, I believe that this is impracticable in the core schema. = Indeed it implies that a service provider must extend the schema of his = account repository (LDAP partition, SQL db, =85) and =93prepare it=94 = for SCIM integration. >>=20 >> =20 >>=20 >> Why? That doesn't necessarily follow. Implementation is independent = of representation. We're talking about a change in representation to = make the API cleaner. >>=20 >> =20 >>=20 >> As a simple example, if an LDAP node is being used to hold a list of = comma-separated email addresses, it can just as easily store = comma-separated name-value pairs. >>=20 >> =20 >>=20 >> mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com >> can be changed to >>=20 >> =20 >>=20 >> mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com >>=20 >> =20 >>=20 >> That's why I asked if there was an SP representative on this working = group who could explain what such a change could mean for them. As of = now, it looks like other people are presuming that SPs will not be able = to implement these changes easily and are rejecting them for that = reason. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> On 13 August 2012 04:29, Emmanuel Dreux wrote: >>=20 >> =F0 addresses.3cbaaff8e84e.street-number =3D "243" >>=20 >> =20 >>=20 >> Where would 3cbaaff8e84e come from? Would it have to be stored on the = account database of the service provider? >>=20 >> =20 >>=20 >> If so, I believe that this is impracticable in the core schema. = Indeed it implies that a service provider must extend the schema of his = account repository (LDAP partition, SQL db, =85) and =93prepare it=94 = for SCIM integration. >>=20 >> This would be a show stopper. SCIM must be transparent, and must be = able to be put on top of an existing system to provide provisioning = apis. >>=20 >> =20 >>=20 >> Said differently, SCIM must not be intrusive for existing systems and = must not require modifications to allow its integration. >>=20 >> Correct me if I misunderstood your suggestion. >>=20 >> =20 >>=20 >> -- >>=20 >> Regards, >>=20 >> Emmanuel Dreux >>=20 >> http://www.cloudiway.com >>=20 >> Tel: +33 4 26 78 17 58 >>=20 >> Mobile: +33 6 47 81 26 70 >>=20 >> skype: Emmanuel.Dreux >>=20 >> =20 >>=20 >> De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 >> Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 >> =C0 : Kelly Grizzle >> Cc : scim@ietf.org; Phil Hunt >> Objet : Re: [scim] scim Digest, Vol 8, Issue 24 >>=20 >> =20 >>=20 >> > Multi-valued attributes that don't have a value sub-attribute (eg = - address) have to specified completely for uniqueness. =20 >>=20 >> =20 >>=20 >> That's exactly the point. How do we "specify completely for = uniqueness"? >>=20 >> =20 >>=20 >> In the example below, how are you proposing that the following = element be updated if we can't use positional indexes? >>=20 >> =20 >>=20 >> addresses[1].street-number =3D "243" >>=20 >> =20 >>=20 >> User object: >>=20 >> =20 >>=20 >> { >>=20 >> ... >>=20 >> addresses: [ >>=20 >> { >>=20 >> "type" : "home", >>=20 >> "street-number" : "35", >>=20 >> "street-name" : "High Road", >>=20 >> "suburb" : "East Camden", >>=20 >> "postcode" : "5346", >>=20 >> "state" : "SA", >>=20 >> "country" : "Australia" >>=20 >> }, >>=20 >> { >>=20 >> "type" : "office", >>=20 >> "street-number" : "213", >>=20 >> "street-name" : "Main Street", >>=20 >> "suburb" : "Adelaide", >>=20 >> "postcode" : "5000", >>=20 >> "state" : "SA", >>=20 >> "country" : "Australia" >>=20 >> } >>=20 >> ] >>=20 >> } >>=20 >> =20 >>=20 >> It's impractical to use the value because it's the whole dictionary = element: >>=20 >> =20 >>=20 >> { >>=20 >> "type" : "office", >>=20 >> "street-number" : "213", >>=20 >> "street-name" : "Main Street", >>=20 >> "suburb" : "Adelaide", >>=20 >> "postcode" : "5000", >>=20 >> "state" : "SA", >>=20 >> "country" : "Australia" >>=20 >> } >>=20 >> =20 >>=20 >> With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element: >>=20 >> =20 >>=20 >> addresses.3cbaaff8e84e.street-number =3D "243" >>=20 >> =20 >>=20 >> { >>=20 >> ... >>=20 >> addresses: { >>=20 >> "d6ea365462f5" : >>=20 >> { >>=20 >> "type" : "home", >>=20 >> "street-number" : "35", >>=20 >> "street-name" : "High Road", >>=20 >> "suburb" : "East Camden", >>=20 >> "postcode" : "5346", >>=20 >> "state" : "SA", >>=20 >> "country" : "Australia" >>=20 >> }, >>=20 >> "3cbaaff8e84e" : >>=20 >> { >>=20 >> "type" : "office", >>=20 >> "street-number" : "213", >>=20 >> "street-name" : "Main Street", >>=20 >> "suburb" : "Adelaide", >>=20 >> "postcode" : "5000", >>=20 >> "state" : "SA", >>=20 >> "country" : "Australia" >>=20 >> } >>=20 >> } >>=20 >> } >>=20 >> =20 >>=20 >> If you're proposing one mechanism for composite attributes and = another mechanism for simple attributes, I would suggest that's actually = more complex than adopting a single mechanism that works the same way = for _all_ attributes. Remember that a lot of the administration is = probably going to be scripted rather than done by hand, and having two = mechanisms (depending on whether the attribute is simple or composite) = will complicate every script that has to be written. >>=20 >> =20 >>=20 >> There's a lot of talk about the "burden" on the SPs, but I believe = this is overblown. Is there any SP representative in this WG who can = tell us what this proposal will actually entail for them? >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> On 12 August 2012 11:53, Kelly Grizzle = wrote: >>=20 >> Ganesh, >>=20 >> =20 >>=20 >> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes = that have a value sub-attribute can be removed by specifying only the = value since it is unique. Multi-valued attributes that don't have a = value sub-attribute (eg - address) have to specified completely for = uniqueness. As I have said before, I am very opposed to adding a unique = identifier to each element in a multi-valued collection due to the = burden it will put on SPs. Is it elegant? No. Is it functional? Yes. = Will this non-elegance affect adoption? My opinion is that adding = unique keys to each element will have a much more detrimental effect on = adoption. >>=20 >> =20 >>=20 >> I do believe that in general PATCH can be made more intuitive without = adding uids to each element. The verbs that you propose make sense. = There is also a JSON Patch informational draft in the IETF that is = interesting - = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies = on a JSON Pointer draft which uses index-based addressing for = multi-valued attributes. I think that this is something that should be = looked at within the WG and I would be willing to lead this effort. >>=20 >> =20 >>=20 >> I'm curious if anyone else in the WG is in favor of unique = identifiers for every multi-valued element. >>=20 >> =20 >>=20 >> --Kelly >>=20 >> =20 >>=20 >> From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of = Ganesh and Sashi Prasad [g.c.prasad@gmail.com] >> Sent: Saturday, August 11, 2012 10:50 AM >> To: Phil Hunt >> Cc: scim@ietf.org >> Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >>=20 >> Phil, >>=20 >> =20 >>=20 >> The reason we cannot use the value itself to identify an element is = that this method will only work for simple elements, not for nested = structures. i.e., if we had an array of dictionaries (e.g., we had to = record an array of addresses for each customer, with each address = element having sub-elements like street number, street name, suburb, = etc.), then it would be clumsy to supply the entire value of the array = element because it's itself a dictionary. Creating a unique key for each = element scales better. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> On 12 August 2012 01:12, Phil Hunt wrote: >>=20 >> Ganesh, >>=20 >> =20 >>=20 >> Here's the sample that concerned me... >>=20 >> The two operations differ significantly, and it's not very intuitive.=20= >>=20 >> With my suggestion, here's how to delete a single member from a = group: >>=20 >> =20 >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >>=20 >> "operations" : [ >>=20 >> { >>=20 >> "RETIRE" : { >>=20 >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>=20 >> } >>=20 >> } >>=20 >> ] } >>=20 >> =20 >>=20 >> =20 >>=20 >> You gave other examples of an attribute with an identifier that = matched that value or of identifiers that were additional unique keys. >>=20 >> =20 >>=20 >> Given that multi-values must be each unique, I don't see the point of = the extra indexing to support this. Just use the value as the item you = wish to delete. >>=20 >> =20 >>=20 >> I agree, the delete value operation could be more explicit and clear = in general. >>=20 >> =20 >>=20 >> Phil >>=20 >> =20 >>=20 >> @independentid >>=20 >> www.independentid.com >>=20 >> phil.hunt@oracle.com >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: >>=20 >> =20 >>=20 >> > For the multi-value example you gave you used the value as the = attribute name key.=20 >>=20 >> =20 >>=20 >> Now I'm confused :-). I don't believe any of my examples ever used a = value as the key. >>=20 >> =20 >>=20 >> Could you please show me which example you mean, and which parts of = it you believe to be the value? >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh=20 >>=20 >> On 11 August 2012 13:59, Phil Hunt wrote: >>=20 >>=20 >> For the multi-value example you gave you used the value as the = attribute name key.=20 >>=20 >> =20 >>=20 >> That means a lot more complex indexing structure. Better to just say = delete a specific value.=20 >>=20 >> =20 >>=20 >> The spec already allows multiple values to have tags like home, work, = etc. >>=20 >> =20 >>=20 >> Phil >>=20 >>=20 >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad = wrote: >>=20 >> > In your example you are conflating value with an attribute id.=20 >>=20 >> I don't believe so. >>=20 >> =20 >>=20 >> I'm adopting a model where every attribute of the resource is a = key-value pair. The key is a name or ID. >>=20 >> =20 >>=20 >> For non-repeating attributes (both simple and composite), the key is = the attribute name itself.=20 >>=20 >> =20 >>=20 >> Simple attribute: >>=20 >> =20 >>=20 >> Key: "dob" >>=20 >> Value: "01 Jan 1970" >>=20 >> =20 >>=20 >> For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode". >>=20 >> =20 >>=20 >> Composite attribute: >>=20 >> =20 >>=20 >> Key: "address.street-number" >>=20 >> Value: "10" >>=20 >> =20 >>=20 >> Key: "address.suburb" >>=20 >> Value: "East Camden" >>=20 >> =20 >>=20 >> For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to = distinguish, and a positional index is inadequate. So we convert the = array into a dictionary and this then becomes a composite attribute = using dot notation for the key. >>=20 >> =20 >>=20 >> Multi-valued attribute: >>=20 >> =20 >>=20 >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" >>=20 >> Value: "john_smith@yahoo.com" >>=20 >> =20 >>=20 >> So this allows us to apply uniform treatment to any arbitrarily deep = resource structure. We can refer to every leaf value with a key that is = the fully-qualified name using dot notation. >>=20 >> =20 >>=20 >> The verbs are just unambiguous operations on these (now) explicitly = addressable attributes. >>=20 >> =20 >>=20 >> INCLUDE to a collection and specify only the value. The key is = generated and returned. The fully-qualified key is = . and the value is what was = specified in the INCLUDE. >>=20 >> =20 >>=20 >> REPLACE a fully-qualified key with a new value. If the key doesn't = exist, return a "404 Not Found". >>=20 >> =20 >>=20 >> PLACE a value at the logical location implied by the fully-qualified = key. If there is already a key with that name, return a "409 Conflict". >>=20 >> =20 >>=20 >> FORCE the fully-qualified key to hold the given value, regardless of = whether it existed before or not. Only errors possible are "400 Bad = Request" and "500 Internal Error". >>=20 >> =20 >>=20 >> RETIRE an attribute or a collection given its fully-qualified key. = The implementation will determine whether the attribute will disappear = entirely or will exist holding a null value (the blank string "" or the = empty object {} ). >>=20 >> =20 >>=20 >> I'll explain in a separate post why we need operation verbs like = these that are independent of the HTTP verbs. >>=20 >> =20 >>=20 >> Regards, >>=20 >> Ganesh >>=20 >> =20 >>=20 >> On 11 August 2012 10:38, wrote: >>=20 >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >>=20 >> https://www.ietf.org/mailman/listinfo/scim >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send scim mailing list submissions to >> scim@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >>=20 >> You can reach the person managing the list at >> scim-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >>=20 >> Today's Topics: >>=20 >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >>=20 >>=20 >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux = , Trey Drake , Kelly = Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement >>=20 >> Ganesh, >>=20 >> =20 >>=20 >> In your example you are conflating value with an attribute id. I find = that confusing.=20 >>=20 >> =20 >>=20 >> I agree though that operations in patch could be a lot more explicit.=20= >>=20 >> =20 >>=20 >> Eg explicitly deleting a value by saying delete or retire.=20 >>=20 >>=20 >> Phil >>=20 >>=20 >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad = wrote: >>=20 >> > I am concerned about your second suggestion:=20 >>=20 >> =20 >>=20 >> Let's discuss that now. >>=20 >> =20 >>=20 >> The trade-offs are very clear here. >>=20 >> =20 >>=20 >> Pros: >>=20 >> =20 >>=20 >> Pro 1. The API to manipulate resources becomes so much cleaner, = consistent and intuitive when every individual attribute value gets its = own ID. >>=20 >> =20 >>=20 >> Here's how to delete a single member from a Group, as per the current = spec: >>=20 >> =20 >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >> =20 >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "members": [ >> { >> "display": "Babs Jensen", >> "value": "2819c223-7f76-453a-919d-413861904646" >> "operation": "delete" >> } >> ] >> } >>=20 >> Here's how to delete ALL members from a group according to the = current spec: >>=20 >> =20 >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce >> Host: example.com >> Accept: application/json >> Authorization: Bearer h480djs93hd8 >> ETag: W/"a330bc54f0671c9" >> =20 >> { >> "schemas": ["urn:scim:schemas:core:1.0"], >> "meta": { >> "attributes": [ >> "members" >> ] >> } >> } >>=20 >> The two operations differ significantly, and it's not very intuitive.=20= >>=20 >> With my suggestion, here's how to delete a single member from a = group: >>=20 >> =20 >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >>=20 >> "operations" : [ >>=20 >> { >>=20 >> "RETIRE" : { >>=20 >> "key" : "members.2819c223-7f76-453a-919d-413861904646" >>=20 >> } >>=20 >> } >>=20 >> ] }=20 >> Here's how I suggest deleting ALL members from a group: >>=20 >> =20 >>=20 >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { >>=20 >> "operations" : [ >>=20 >> { >>=20 >> "RETIRE" : { >>=20 >> "key" : "members" >>=20 >> } >>=20 >> } >>=20 >> ] } >>=20 >>=20 >> I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader. >>=20 >> =20 >>=20 >> Pro 2: We can apply this mechanism consistently to three areas: >>=20 >> (a) Manipulating multi-valued attributes of a resource >>=20 >> (b) Manipulating members of a group >>=20 >> (c) Performing bulk operations, where we simply use HTTP verbs = instead of the specialised (and semantically less ambiguous) verbs I = suggested for attributes, the "key" becomes the URI, and the "value" = becomes the corresponding JSON object. >>=20 >> =20 >>=20 >> All of them return "207 Multi-Status" with the "results" array = holding individual status codes. >>=20 >> =20 >>=20 >> In the current spec, (a) and (b) are done similarly but (c) is very = different. >>=20 >> =20 >>=20 >> Pro 3: Adoption of the standard by clients is likely to be higher = because it's simpler for them. >>=20 >> =20 >>=20 >> Pro 4: New (not incumbent) cloud providers will probably find this = easier to implement because they have no legacy. They will probably use = some form of NoSQL database and won't be constrained by the limitations = of LDAP directories. >>=20 >> =20 >>=20 >> Cons: >>=20 >> =20 >>=20 >> Con 1: Incumbent cloud providers with existing data stores in a = directory format (where multi-valued attributes are stored as = comma-separated values under a single attribute node) will find it = difficult to migrate to this model and store each attribute value as a = sub-node with its own key. This will "hinder adoption of the spec", = which is what you fear. >>=20 >> =20 >>=20 >> Have I summed up the Pros and Cons correctly? I'm biased of course, = so I could have missed a Con or hyped a Pro :-). >>=20 >> =20 >>=20 >> In other words, we're debating interface complexity (current spec) = versus implementation complexity (my suggestion). Both can hinder = adoption of the spec by different parties. >>=20 >> =20 >>=20 >> Here's what we need to discuss - Do the Pros make the suggestio >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 >=20 --Apple-Mail=_E7D1D59E-4F2D-4AF5-95BC-255C4A3E7B8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 IMO, = one of the reasons why SCIM adoption is growing is that it does not = force implementors to rework their schema.  I realize that you may = think relational schemas may be more pliant, but most implementors are = not deploying a greenfields SCIM backend.  Rather, SCIM is a = front-end atop existing infrastructure.  A service provider backed = with a "user" table defined with columns mapped to SCIM user attributes = will be just as handicapped as a SP backed with LDAP/person. =  Specifically, there's no hook for meta-data (guid) on a relational = database column.  

I'm not sure what you mean by = object classes not having a DN.  Object classes don't have DNs - = entries = do.

Thanks,
Trey

On= Aug 13, 2012, at 7:11 PM, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

Hi Trey,

You have a point, but there = are two levels to the difficulty. Relational schemas are not cast in = stone the way LDAP schemas are. Many of the object classes in LDAP are = not containers that can have their own DNs, so even if an SP is willing = to change their data model, they won't get far if they're using = LDAP.

Regards,
Ganesh

On 14 August 2012 07:47, Trey Drake <trey.drake@unboundid.com> wrote:
I don't believe LDAP is the culprit. =  You'd find the same issue in most *existing* data models to = include relational.  The issue is whether you're forcing the hand = of the SP to overhaul their data model to accommodate SCIM.  I = don't believe we would get very far if we took that tack.

Thanks,
Trey

On Aug 13, 2012, at 4:07 PM, Ganesh and Sashi Prasad = <g.c.prasad@gmail.com> wrote:

Thanks, = Kelly. You've been most patient in hearing me out, I must say. I = couldn't ask for more.

Replying to Chris Philips's = mail:
> Given that you have a number of thoughts about what could be changed = in SCIM,Leif's recommendation to  craft them in an Internet Draft = may be a better way to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an = Internet Draft should be about changing SCIM, or should it propose a = complementary spec for SPs who use a "NoLDAP" data store? I think the = underlying problem is with LDAP, and unless we change that, these = proposals won't fly.

Regards,
Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:

There are really two implementation options for a = uid per element =96 either store the uids in the native underlying data = store or have some secondary data store that maps elements to their uids.  The third option is to hope = that a service provider has a NoLDAP data store or its equivalent.  = None of these are practical for rapid and wide-spread = adoption.

 

> put the two together to propose a solution.

 

As I said before, I am completely on board with = cleaning up the PATCH semantics (eg =96 the inconsistency between = meta.attributes and operation=3Ddelete, etc=85).  Your suggestion of using different verbs is a good option to = consider.  This cannot be based on a uid per element, though.  = It seems as though you have admitted this in your conclusion =96 =93As = for LDAP and SCIM, I guess the best TLA is = RIP.=94

 

--Kelly

 

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

 

That was one suggestion. Another way could be = container nodes with their own "dn"s. If one suggestion won't work, tell = me another way to make it work. I'm waiting to hear a constructive = suggestion that can square an elegant API with the implementation constraints that come from having to store multi-valued = attributes in LDAP directories.

 

I've heard enough of WHY this won't work. = For a change, tell me HOW it can be made to work. Everyone now knows = what the proposal means in terms of the API, and implementors understand = the constraints of legacy data stores, so put the two together to propose a solution. C'mon, we have the "smartest guys in = the room" here, surely we should be able to crack = this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions = about what is to be done:

 

On 14 August 2012 00:27, Kelly Grizzle = <kelly.grizzle@sailpoint.com> = wrote:

> After all, no one has challenged the = claim that this proposal drastically simplifies the API for the = client

 

I agree that your proposal makes PATCH semantics = simpler and more elegant.

 

 

> =85 so it would appear to be worth doing. 

 

I strongly disagree here.  This statements = assumes that simplicity of the client API is the only factor that should be considered with the = spec.

 

Emmanuel=92s example is from a real-world service = provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM = interface that will help facilitate data exchange between multiple = Active Directory servers.  Your solution was to change the data = model from this:

 

mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com

 

I do not know of a single organization that would = change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort = (likely across other domain controllers, etc=85) to assign these unique = identifiers.  This also assumes that SCIM is the only reader/writer = of this data, which will almost never be the case.  If the data model requires uids for every element, then every piece of = non-SCIM code that writes data into the directory will have to follow = this.  Additionally, there are *many* tools and applications =  (eg =96 address books) that rely on a certain data model in Active Directory, and this would cause them to break.  = IMO this same argument holds true for most service = providers.

 

 

PATCH is an optional part of the spec.  It = was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to = solve every problem (eg =96 modifying sub-elements in nested = arrays).  Adding uids to every multi-valued element does not strike = the right balance between the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

 

Responding to extract of Melinda Shore's mail from = digest:

 

The issue being =
raised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful =
to
respond to the observation that your model requires =
more
messages with a complaint about what you seem to think is =
a
complex algorithm for attribute processing.

 

It depends on how it's implemented. I'm = confident we can have the best of both - simple API with low-overhead = implementation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've been = hearing so far)? After all, no one has challenged the claim that this = proposal drastically simplifies the API for the client, so it would = appear to be worth doing. I'm sure there's more than enough intellectual horsepower in this working group to pull this = off if we put our minds to it.

 

Regards,

Ganesh

 

On 13 August 2012 13:54, Ganesh and Sashi = Prasad <g.c.prasad@gmail.com> wrote:

> I = strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty.

Sorry Phil, but you're contradicting = yourself here. There seems to be an awful lot of matching (i.e., = reading) going on in the spec as it stands, with if-then clauses to do = one thing or another if the match either succeeds or fails. This is a = complex, chatty protocol right now!

 

   Multi-valued =
attributes:  An attribute value in the PATCH =
request
      =
body is added to the value collection if the value does not =
exist
      and =
merged if a matching value is present.  Values are matched =
by
      =
comparing the value Sub-Attribute from the PATCH request body =
to
      the =
value Sub-Attribute of the Resource.  Attributes that do =
not
      =
have a value Sub-Attribute; e.g., addresses, or do not have =
unique
      =
value Sub-Attributes cannot be matched and must instead be =
deleted
      =
then added.  Specific values can be removed from a Resource =
by
      =
adding an "operation" Sub-Attribute with the value "delete" to =
the
      =
attribute in the PATCH request body.  As with =
adding/updating
      =
attribute value collections, the value to delete is determined =
by
      =
comparing the value Sub-Attribute from the PATCH request body =
to
      the =
value Sub-Attribute of the Resource.  Attributes that do =
not
      =
have a value Sub-Attribute or that have a non-unique value =
Sub-
      =
Attribute are matched by comparing all Sub-Attribute values =
from
      the =
PATCH request body to the Sub-Attribute values of =
the
      =
Resource.  A delete operation is ignored if the attribute's =
name
      is =
in the meta.attributes list.  If the requested value to =
delete
      =
does not match a unique value on the Resource the server =
MAY
      =
return a HTTP 400 error.

 

For a spec that is supposed to be about = simplicity, the above description is anything but simple. I know you = guys have worked hard on this and I don't mean to disparage those = efforts, but think about how the above passage would appear to a new reader = (i.e., a novice to the spec, not a technology novice).

 

There is something fundamentally broken, and = it is this: multi-valued attributes without a unique identifier per = value. If you don't fix that, you won't get = simplicity.

 

We know LDAP trees are broken for = multi-valued attributes. As Mark Wahl famously commented back in 2005,

 

"Unfortunately, some of the emerging protocols which also intend = to represent and transfer personal identity information have perhaps taken a step backwards by not even considering these = issues, perhaps sweeping them under the rug in the guise of simplicity, = XMLification, or "fix in the next version", which only postpone finding = interoperable solutions to allowing applications to express the identity entries they want to = express."

 

SCIM is exactly one of these "emerging = protocols" Wahl talks about, and what I see now strikes me as "sweeping = these issues under the rug in the guise of simplicity". Apologies for the bluntness.

 

My take is that SPs are _already_ struggling = to manage multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a = specification that made operations easier at the cost of a re-engineered = schema. That calls for some thought leadership from this working = group.

 

Regards,

Ganesh

 

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:

I strongly object to anything that leads to = a read before modify requirement. Too complex and too chatty. 

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

> Would it = have to be stored on the account database of the service = provider?

 

Yes.

 

> If so, I believe that this is impracticable = in the core schema. Indeed it implies that a service provider must = extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration.

 

Why? That doesn't necessarily follow. = Implementation is independent of representation. We're talking about a = change in representation to make the API cleaner.

 

As a simple example, if an LDAP node is = being used to hold a list of comma-separated email addresses, it can = just as easily store comma-separated name-value pairs.

 

 

mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com

 

That's = why I asked if there was an SP representative on this working group who = could explain what such a change could mean for them. As of now, it looks like other people are presuming that SPs will not = be able to implement these changes easily and are rejecting them for = that reason.

 

Regards,

Ganesh

 

On 13 August 2012 04:29, Emmanuel Dreux = <edreux@cloudiway.com> wrote:

=F0  addresses.3cbaaff8e84e.street-number =3D "243"

 

Where would 3cbaaff8e84e come from? Would it have to be stored on the = account database of the service provider?

 

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a = service provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration.

This would be a show stopper. SCIM must be = transparent, and must be able to be put on top of an existing system to = provide provisioning apis.

 

Said differently, SCIM = must not be intrusive for existing systems and must not require = modifications to allow its integration.

Correct me if I = misunderstood your suggestion.

 

--

Regards,

Emmanuel Dreux

http://www.cloudiway.com

Tel: +33 4 26 = 78 17 58

Mobile: +33 6 47 = 81 26 70

skype: Emmanuel.Dreux

 

De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9 : dimanche 12 ao=FBt 2012 04:53
=C0 : Kelly Grizzle
Cc : scim@ietf.org; Phil Hunt
Objet : Re: [scim] scim Digest, Vol 8, Issue = 24

 

>  Multi-valued attributes that don't have a value = sub-attribute (eg - address) have to specified completely for = uniqueness.  

 

That's exactly the point. = How do we "specify completely for uniqueness"?

 

In the example below, how = are you proposing that the following element be updated if we can't use = positional indexes?

 

addresses[1].street-number = =3D "243"

 

User = object:

 

{

  = ...

  addresses: = [

    = {

      = "type" : "home",

      = "street-number" : "35",

      = "street-name" : "High Road",

      = "suburb" : "East Camden",

      = "postcode" : "5346",

      = "state" : "SA",

      = "country" : "Australia"

    = },

    = {

      = "type" : "office",

      = "street-number" : "213",

      = "street-name" : "Main Street",

      = "suburb" : "Adelaide",

      = "postcode" : "5000",

      = "state" : "SA",

      = "country" : "Australia"

    = }

  = ]

}

 

It's impractical to use = the value because it's the whole dictionary = element:

 

{

  "type" : = "office",

  "street-number" : = "213",

  "street-name" : = "Main Street",

  "suburb" : = "Adelaide",

  "postcode" : = "5000",

  "state" : = "SA",

  "country" : = "Australia"

}

 

With my proposal, the = "addresses" array gets converted to a dictionary, and then we have a = stable way of referencing this element:

 

addresses.3cbaaff8e84e.street-number =3D = "243"

 

{

  = ...

  addresses: = {

    = "d6ea365462f5" :

    = {

      = "type" : "home",

      = "street-number" : "35",

      = "street-name" : "High Road",

      = "suburb" : "East Camden",

      = "postcode" : "5346",

      = "state" : "SA",

      = "country" : "Australia"

    = },

    = "3cbaaff8e84e" :

    = {

      = "type" : "office",

      = "street-number" : "213",

      = "street-name" : "Main Street",

      = "suburb" : "Adelaide",

      = "postcode" : "5000",

      = "state" : "SA",

      = "country" : "Australia"

    = }

  = }

}

 

If you're proposing one = mechanism for composite attributes and another mechanism for simple = attributes, I would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. = Remember that a lot of the administration is probably going to be = scripted rather than done by hand, and having two mechanisms (depending = on whether the attribute is simple or composite) will complicate every script that has to be = written.

 

There's a lot of talk = about the "burden" on the SPs, but I believe this is overblown. Is there = any SP representative in this WG who can tell us what this proposal will actually entail for them?

 

Regards,

Ganesh

 

On 12 August 2012 11:53, = Kelly Grizzle <kelly.grizzle@sailpoint.com> = wrote:

Ganesh,

 

This is exactly how PATCH works in SCIM 1.0.  Multi-valued = attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. =  Multi-valued attributes that don't have a value sub-attribute (eg = - address) have to specified completely for uniqueness.  As I have = said before, I am very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will = put on SPs.  Is it elegant?  No.  Is it functional? =  Yes.  Will this non-elegance affect adoption?  My = opinion is that adding unique keys to each element will have a much more = detrimental effect on adoption.

 

I do believe that in general PATCH can be made more intuitive = without adding uids to each element.  The verbs that you propose make sense.  There is also a JSON Patch = informational draft in the IETF that is interesting - http://tools.ietf.org/html/draft-ietf-appsawg-json-patch= -02.  It relies on a JSON Pointer draft which uses index-based = addressing for multi-valued attributes.  I think that this is = something that should be looked at within the WG and I would be willing = to lead this effort.

 

I'm curious if anyone else in the WG is in favor of unique = identifiers for every multi-valued element.

 

--Kelly

 

From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh and = Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org
Subject: Re: [scim] scim Digest, Vol 8, Issue = 24

Phil,

 

The reason we cannot use = the value itself to identify an element is that this method will only = work for simple elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses = for each customer, with each address element having sub-elements like = street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictionary. Creating a unique key for each = element scales better.

 

Regards,

Ganesh

On 12 August 2012 01:12, = Phil Hunt <phil.hunt@oracle.com> = wrote:

Ganesh,

 

Here's the sample that = concerned me...

The two operations differ = significantly, and it's not very = intuitive. 

With my suggestion, here's = how to delete a single member from a group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members.2819c223-7f76-453a-919d-413861904646"

}

}

] }

 

 

You gave = other examples of an attribute with an identifier that matched that = value or of identifiers that were additional unique keys.

 

Given that = multi-values must be each unique, I don't see the point of the extra = indexing to support this. Just use the value as the item you wish to delete.

 

I agree, = the delete value operation could be more explicit and clear in = general.

 

 

 

 

On 2012-08-11, at 2:30 AM, = Ganesh and Sashi Prasad wrote:

 

>  For the multi-value example you gave you used the = value as the attribute name key. 

 

Now I'm confused :-). I = don't believe any of my examples ever used a value as the = key.

 

Could you please show me = which example you mean, and which parts of it you believe to be the = value?

 

Regards,

Ganesh 

On 11 August 2012 13:59, = Phil Hunt <phil.hunt@oracle.com> = wrote:


For the multi-value example you gave you used the value as the attribute = name key. 

 

That means a lot more = complex indexing structure. Better to just say delete a specific = value. 

 

The spec already allows = multiple values to have tags like home, work, = etc.

 

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

> In your example = you are conflating value with an attribute id. 

I don't believe so.

 

I'm adopting a model where = every attribute of the resource is a key-value pair. The key is a name = or ID.

 

For non-repeating = attributes (both simple and composite), the key is the attribute name = itself. 

 

Simple = attribute:

 

Key: = "dob"

Value: "01 Jan = 1970"

 

For composite attributes, = the key employs dot notation to specify the fully-qualified attribute = name, e.g., "address.postcode".

 

Composite = attribute:

 

Key: = "address.street-number"

Value: = "10"

 

Key: = "address.suburb"

Value: "East = Camden"

 

For repeating = (multi-valued) attributes, I'm suggesting that there be new keys for = each individual value, otherwise they are impossible to distinguish, and = a positional index is inadequate. So we convert the array into a dictionary and this = then becomes a composite attribute using dot notation for the = key.

 

Multi-valued = attribute:

 

Key: = "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"

 

So this allows us to apply = uniform treatment to any arbitrarily deep resource structure. We can = refer to every leaf value with a key that is the fully-qualified name using dot notation.

 

The verbs are just = unambiguous operations on these (now) explicitly addressable = attributes.

 

INCLUDE to a collection = and specify only the value. The key is generated and returned. The = fully-qualified key is = <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

 

REPLACE a fully-qualified = key with a new value. If the key doesn't exist, return a "404 Not = Found".

 

PLACE a value at the = logical location implied by the fully-qualified key. If there is already = a key with that name, return a "409 Conflict".

 

FORCE the fully-qualified = key to hold the given value, regardless of whether it existed before or = not. Only errors possible are "400 Bad Request" and "500 Internal Error".

 

RETIRE an attribute or a = collection given its fully-qualified key. The implementation will = determine whether the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {} = ).

 

I'll explain in a separate = post why we need operation verbs like these that are independent of the = HTTP verbs.

 

Regards,

Ganesh

 

On 11 August 2012 10:38, = <scim-request@ietf.org> = wrote:

If= you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

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

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



Send scim mailing list submissions to
        scim@ietf.org

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

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

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

Today's Topics:

   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil = Hunt)


---------- Forwarded message ----------
From: Phil Hunt <phil.hunt@oracle.com>
To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux = <edreux@cloudiway.com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" = <scim@ietf.org>
Date: Fri, 10 Aug 2012 17:36:54 -0700
Subject: Re: [scim] SCIM Protocol - 3 suggestions for = improvement

Ganesh,

 

In your example you are = conflating value with an attribute id. I find that = confusing. 

 

I agree though that = operations in patch could be a lot more = explicit. 

 

Eg explicitly deleting a = value by saying delete or retire. 


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> = wrote:

 >  I am concerned about your second = suggestion: 

 

Let's discuss that = now.

 

The trade-offs are very = clear here.

 

Pros:

 

Pro 1. The API to = manipulate resources becomes so much cleaner, consistent and intuitive = when every individual attribute value gets its own = ID.

 

Here's how to delete a = single member from a Group, as per the current = spec:

 

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: =
application/json
   =
Authorization: Bearer h480djs93hd8
   ETag: =
W/"a330bc54f0671c9"
 
   =
{
    =
 "schemas": ["urn:scim:schemas:core:1.0"],
    =
 "members": [
       =
{
        =
; "display": "Babs Jensen",
        =
; "value": =
"2819c223-7f76-453a-919d-413861904646"
        =
; "operation": "delete"
       =
}
    =
 ]
   =
}


Here's how to delete ALL members from a group according to the current = spec:

 

   PATCH =
/Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce
   Host: example.com
   Accept: =
application/json
   =
Authorization: Bearer h480djs93hd8
   ETag: =
W/"a330bc54f0671c9"
 
   =
{
    =
 "schemas": ["urn:scim:schemas:core:1.0"],
    =
 "meta": {
       =
"attributes": [
        =
; "members"
       =
]
    =
 }
   =
}


The two operations differ significantly, and it's not very = intuitive. 

With my suggestion, here's = how to delete a single member from a group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members.2819c223-7f76-453a-919d-413861904646"

}

}

] }
Here's how I suggest deleting ALL members from a = group:

 

PATCH = /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" {

"operations" : [

{

"RETIRE" : = {

"key" : = "members"

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader.

 

Pro 2: We can apply this = mechanism consistently to three areas:

(a) Manipulating = multi-valued attributes of a resource

(b) Manipulating members = of a group

(c) Performing bulk = operations, where we simply use HTTP verbs instead of the specialised = (and semantically less ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the corresponding JSON = object.

 

All of them return "207 = Multi-Status" with the "results" array holding individual status = codes.

 

In the current spec, (a) = and (b) are done similarly but (c) is very = different.

 

Pro 3: Adoption of the = standard by clients is likely to be higher because it's simpler for = them.

 

Pro 4: New (not incumbent) = cloud providers will probably find this easier to implement because they = have no legacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP = directories.

 

Cons:

 

Con 1: Incumbent cloud = providers with existing data stores in a directory format (where = multi-valued attributes are stored as comma-separated values under a = single attribute node) will find it difficult to migrate to this model and = store each attribute value as a sub-node with its own key. This will = "hinder adoption of the spec", which is what you = fear.

 

Have I summed up the Pros = and Cons correctly? I'm biased of course, so I could have missed a Con = or hyped a Pro :-).

 

In other words, we're = debating interface complexity (current spec) versus implementation = complexity (my suggestion). Both can hinder adoption of the spec by = different parties.

 

Here's what we need to = discuss - Do the Pros make the suggestio

 

 

 


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



= --Apple-Mail=_E7D1D59E-4F2D-4AF5-95BC-255C4A3E7B8B-- From leifj@mnt.se Tue Aug 14 00:45:39 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0896C21F854A for ; Tue, 14 Aug 2012 00:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7UlQOcpCiJb for ; Tue, 14 Aug 2012 00:45:38 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D43F321F8548 for ; Tue, 14 Aug 2012 00:45:37 -0700 (PDT) Received: from [192.36.125.241] (dhcp.pilsnet.sunet.se [192.36.125.241] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7E7jV53017887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Aug 2012 09:45:35 +0200 (CEST) Message-ID: <502A021B.30803@mnt.se> Date: Tue, 14 Aug 2012 09:45:31 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 07:45:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/14/2012 06:39 AM, Trey Drake wrote: > IMO, one of the reasons why SCIM adoption is growing is that it > does not force implementors to rework their schema. I realize that > you may think relational schemas may be more pliant, but most > implementors are not deploying a greenfields SCIM backend. Rather, > SCIM is a front-end atop existing infrastructure. A service > provider backed with a "user" table defined with columns mapped to > SCIM user attributes will be just as handicapped as a SP backed > with LDAP/person. Specifically, there's no hook for meta-data > (guid) on a relational database column. As an individual I also strongly object to the notion that RDBMS schema are more pliable than LDAP dito - in practice, once you nail down your RDBMS model you're pretty much stuck with it. But we digress (severely). Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqAhsACgkQ8Jx8FtbMZncivACdHM14Uiw5zesZMuofbF1UnCKu j4oAnRZ6o3XmpCv/27XCxRzEPyr1FQTr =lOOH -----END PGP SIGNATURE----- From melinda.shore@gmail.com Tue Aug 14 09:25:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE421F86E4 for ; Tue, 14 Aug 2012 09:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uFoT7H+cMSq for ; Tue, 14 Aug 2012 09:25:29 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3640D21F86E1 for ; Tue, 14 Aug 2012 09:25:29 -0700 (PDT) Received: by qcac10 with SMTP id c10so490843qca.31 for ; Tue, 14 Aug 2012 09:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=NAJCuY7T683PW7KtV23NSzrMPE9SvQdFTZXZ+H1LY48=; b=J4f/bJSfiLEAFkbQKaHc+evJ1iutu9twugsIiRGH1fxhwXiedThda5zyu44+waJvoW uUklksSYdj3QCqIixyiIEZ3MGfczI63+/VC+CuPBr+o5Ctt0AYv72gKUm3YECDtqWMoW k35750K0ZrwE6hGeHqdGWzPSKltNeQyJENfdUZF6dsgl+NgmgK3RAh3G59WAYEYP2vJO fvOsE69xOuXKsze3g2dRHv8b4IBUUKOW4yATn1OqenrMVIQvP2zYDb3ElyDpJDcoxx4q eYBMq+yRsPtqXGFFCBW/EIp8jx5Q65PFRZ6jryXX6qZY1N5ln7G399v3NJHUYtZCmLsp GFDA== Received: by 10.60.172.101 with SMTP id bb5mr21589497oec.44.1344961528531; Tue, 14 Aug 2012 09:25:28 -0700 (PDT) Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.208]) by mx.google.com with ESMTPS id ad9sm3096385obc.8.2012.08.14.09.25.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 09:25:28 -0700 (PDT) Message-ID: <502A7BF6.1060102@gmail.com> Date: Tue, 14 Aug 2012 08:25:26 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> <502A021B.30803@mnt.se> In-Reply-To: <502A021B.30803@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:25:30 -0000 On 8/13/12 11:45 PM, Leif Johansson wrote: > As an individual I also strongly object to the notion that RDBMS schema > are more pliable than LDAP dito - in practice, once you nail down your > RDBMS model you're pretty much stuck with it. In my previous gig we were provisioning LDAP directory entries out of SQL databases (SQL->SQL->LDAP) and I don't think I agree with that, actually, or at least not in terms of attributes. However, just because it's pretty straightforward to add new tables and fields doesn't mean that there's not a pile of dependent software that also needs to be changed, or that it's easy to remove tables or fields. LDAP is far less flexible in that regard. But still, we're probably constrained by the least flexible piece of the puzzle (wow, what a stupid mixed metaphor), which is LDAP. I've seen one SPML implementation and it was not spec-conforming. Melinda From tonynad@microsoft.com Tue Aug 14 12:55:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0195121E80A4; Tue, 14 Aug 2012 12:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+JXwUiaeelM; Tue, 14 Aug 2012 12:55:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id F1CAE21E80A2; Tue, 14 Aug 2012 12:55:09 -0700 (PDT) Received: from mail184-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:55:09 +0000 Received: from mail184-co1 (localhost [127.0.0.1]) by mail184-co1-R.bigfish.com (Postfix) with ESMTP id 4EA7EC001F2; Tue, 14 Aug 2012 19:55:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zz9371I542M1418Izz1202h1082kzz1033IL8275dh15d4Iz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail184-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail184-co1 (localhost.localdomain [127.0.0.1]) by mail184-co1 (MessageSwitch) id 1344974106977758_28148; Tue, 14 Aug 2012 19:55:06 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.232]) by mail184-co1.bigfish.com (Postfix) with ESMTP id E2C99AC0044; Tue, 14 Aug 2012 19:55:06 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:55:06 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 14 Aug 2012 19:55:05 +0000 Received: from mail222-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:54:41 +0000 Received: from mail222-va3 (localhost [127.0.0.1]) by mail222-va3-R.bigfish.com (Postfix) with ESMTP id 5F9251803C3; Tue, 14 Aug 2012 19:54:41 +0000 (UTC) Received: from mail222-va3 (localhost.localdomain [127.0.0.1]) by mail222-va3 (MessageSwitch) id 1344974079787490_31440; Tue, 14 Aug 2012 19:54:39 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.247]) by mail222-va3.bigfish.com (Postfix) with ESMTP id BE125CC0244; Tue, 14 Aug 2012 19:54:39 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:54:37 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT005.namprd03.prod.outlook.com ([10.255.97.40]) with mapi id 14.16.0175.005; Tue, 14 Aug 2012 19:54:36 +0000 From: Anthony Nadalin To: Yutaka OIWA , scim Mailing List Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNedKx8vonFDTtDEClM85v3BplBJdZh/Qw Date: Tue, 14 Aug 2012 19:54: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-originating-ip: [64.134.196.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AIST.GO.JP$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "http-auth@ietf.org" Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:55:11 -0000 I just question the delivery of passwords at all, clear text or encrypted. -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Yut= aka OIWA Sent: Monday, August 13, 2012 9:09 PM To: scim Mailing List Cc: http-auth@ietf.org Subject: [scim] scim data format and structured credentials delivery/instal= lations Dear SCIM people, I am currently proposing a new HTTP authentication protocol for enabling se= cure mutual authentication using shared credentials (including pre-shared k= eys or passwords). There are many features beyond conventional authentication methods, but fro= m the viewpoint of key/credential management (related to scim), this authen= tication scheme have two properties concurrently: * enables use of encrypted (hashed) passwords on the server side - somewhat similar to Basic/Form - contrary to CHAP/Digest (which require passwords-equivalent), * allows non-plaintext exchange on-wire - similar to, but much stronger than CHAP/Digest - contrary to Basic/Form. Server-side encrypted passwords are per-server basis, so any stolen credent= ial cannot be reused by other people, provided that the client-side credent= ials have fair amount of entropy (unlike 1234, password or xhtdj). Under this background, my point asking on this mail is: we have one missing feature on our protocol design: delivery of encrypted p= asswords from clients to servers on the first registration phase. Currently we have two ways for first-time registration: * letting servers know the plaintext passwords, and encrypt them on the se= rver side. * encrypting the passwords manually on the client side, while carefully inputing protocol-dependent security parameters that the server gives. But both of them are unsatisfactory. We have planned to develop a common format in the next steps for exchanging= such authentication parameters between peers for single account registrati= ons using Web browsers/Web Forms or other clients. Looking beyond our proposal, there are also many key/credential formats whi= ch requires key deliveries from clients to servers on the first registratio= n, including such as X.509 certificates (either full-certificate or just DN= part), unsigned RSA public keys, JWKs, SSH pubkeys, machine-generated stro= ng secrets, and even unix-hashed passwords. We now aware that many parts of requirements for such use-cases are common = with what SCIM requires, and we should avoid designing two similar parts on= the same table. I remember that in Vancouver SCIM session, some people also raised requirem= ents for deploying such non-plaintext secret within SCIM framework. So, I'd like to reuse current data format for SCIM exchange for such purpos= es. To do that, I plan to propose a generic extension mechanism for putting key formats other than just plaintext passwords. Such format may be useful fo= r other credentials as well, and it can, of course, be used for SCIM-based a= ccount management. So I think that this extension satisfies some needs for SCIM as well as oth= er use cases. Feedbacks are appreciated. --=20 Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Tue Aug 14 12:55:29 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C321E80A9 for ; Tue, 14 Aug 2012 12:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.017 X-Spam-Level: X-Spam-Status: No, score=0.017 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132, URI_HEX=0.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMUDnLt+i6rp for ; Tue, 14 Aug 2012 12:55:14 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8BB21E80A8 for ; Tue, 14 Aug 2012 12:55:14 -0700 (PDT) Received: from mail47-co1-R.bigfish.com (10.243.78.249) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:55:14 +0000 Received: from mail47-co1 (localhost [127.0.0.1]) by mail47-co1-R.bigfish.com (Postfix) with ESMTP id 5C34E700167 for ; Tue, 14 Aug 2012 19:55:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -93 X-BigFish: VS-93(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85dh1432I1418Iac5W4015I9d9Rzz1202h1082kzz1033IL8275bh8275dhz2fh2a8h683h839hd25hf0ah107ah) Received-SPF: pass (mail47-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail47-co1 (localhost.localdomain [127.0.0.1]) by mail47-co1 (MessageSwitch) id 1344974109440133_20643; Tue, 14 Aug 2012 19:55:09 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.234]) by mail47-co1.bigfish.com (Postfix) with ESMTP id 66386600050 for ; Tue, 14 Aug 2012 19:55:09 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:55:08 +0000 Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 14 Aug 2012 19:55:07 +0000 Received: from mail180-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 19:54:43 +0000 Received: from mail180-va3 (localhost [127.0.0.1]) by mail180-va3-R.bigfish.com (Postfix) with ESMTP id 5EF541A03AF for ; Tue, 14 Aug 2012 19:54:43 +0000 (UTC) Received: from mail180-va3 (localhost.localdomain [127.0.0.1]) by mail180-va3 (MessageSwitch) id 1344974079271954_13369; Tue, 14 Aug 2012 19:54:39 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.244]) by mail180-va3.bigfish.com (Postfix) with ESMTP id 2E7274E003F; Tue, 14 Aug 2012 19:54:39 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 19:54:38 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0175.005; Tue, 14 Aug 2012 19:54:37 +0000 From: Anthony Nadalin To: Ganesh and Sashi Prasad , Kelly Grizzle Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PxauTTbuBYIUChqkOgTJ2ncpdT/IGAgABLt4CAAHBZgIAACouAgACooICAABCQAIABBZAAgAAyWwCAAC3MgIAAPeGAgAAs0YCAAIPngIAACBsAgAAQRICAAFdPAIABTnQA Date: Tue, 14 Aug 2012 19:54:37 +0000 Message-ID: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.196.209] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7E3ABL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CLOUDIWAY.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "scim@ietf.org" , Phil Hunt , Melinda Shore , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 19:55:29 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7E3ABL2PRD0310MB362_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should not be constrained by LDAP restrictions, this would not be produc= tive. From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Gan= esh and Sashi Prasad Sent: Monday, August 13, 2012 2:07 PM To: Kelly Grizzle Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Thanks, Kelly. You've been most patient in hearing me out, I must say. I co= uldn't ask for more. Replying to Chris Philips's mail: > Given that you have a number of thoughts about what could be changed in S= CIM,Leif's recommendation to craft them in an Internet Draft may be a bett= er way to convey your thoughts. I'm coming around to the same conclusion. Do you think such an Internet Dra= ft should be about changing SCIM, or should it propose a complementary spec= for SPs who use a "NoLDAP" data store? I think the underlying problem is w= ith LDAP, and unless we change that, these proposals won't fly. Regards, Ganesh On 14 August 2012 01:54, Kelly Grizzle > wrote: There are really two implementation options for a uid per element - either = store the uids in the native underlying data store or have some secondary d= ata store that maps elements to their uids. The third option is to hope th= at a service provider has a NoLDAP data store or its equivalent. None of t= hese are practical for rapid and wide-spread adoption. > put the two together to propose a solution. As I said before, I am completely on board with cleaning up the PATCH seman= tics (eg - the inconsistency between meta.attributes and operation=3Ddelete= , etc...). Your suggestion of using different verbs is a good option to co= nsider. This cannot be based on a uid per element, though. It seems as th= ough you have admitted this in your conclusion - "As for LDAP and SCIM, I g= uess the best TLA is RIP." --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 9:56 AM To: Kelly Grizzle Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 That was one suggestion. Another way could be container nodes with their ow= n "dn"s. If one suggestion won't work, tell me another way to make it work.= I'm waiting to hear a constructive suggestion that can square an elegant A= PI with the implementation constraints that come from having to store multi= -valued attributes in LDAP directories. I've heard enough of WHY this won't work. For a change, tell me HOW it can = be made to work. Everyone now knows what the proposal means in terms of the= API, and implementors understand the constraints of legacy data stores, so= put the two together to propose a solution. C'mon, we have the "smartest g= uys in the room" here, surely we should be able to crack this. Regards, Ganesh P.S. I'm rapidly reaching my own conclusions about what is to be done: http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nold= ap.html On 14 August 2012 00:27, Kelly Grizzle > wrote: > After all, no one has challenged the claim that this proposal drastically= simplifies the API for the client I agree that your proposal makes PATCH semantics simpler and more elegant. > ... so it would appear to be worth doing. I strongly disagree here. This statements assumes that simplicity of the c= lient API is the only factor that should be considered with the spec. Emmanuel's example is from a real-world service provider that would not be = able to implement the spec easily with a uid per element. He is working on= a SCIM interface that will help facilitate data exchange between multiple = Active Directory servers. Your solution was to change the data model from = this: mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com to this: mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com I do not know of a single organization that would change their Active Direc= tory data model to fit this. For one thing, it would be a huge data migrat= ion effort (likely across other domain controllers, etc...) to assign these= unique identifiers. This also assumes that SCIM is the only reader/writer= of this data, which will almost never be the case. If the data model requ= ires uids for every element, then every piece of non-SCIM code that writes = data into the directory will have to follow this. Additionally, there are = *many* tools and applications (eg - address books) that rely on a certain = data model in Active Directory, and this would cause them to break. IMO th= is same argument holds true for most service providers. PATCH is an optional part of the spec. It was primarily introduced to make= modifying resources with large multi-valued lists more efficient. It does= not need to solve every problem (eg - modifying sub-elements in nested arr= ays). Adding uids to every multi-valued element does not strike the right = balance between the needs of the client and the needs of the service provid= er. --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 1:35 AM To: Phil Hunt; Melinda Shore Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Responding to extract of Melinda Shore's mail from digest: The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. It depends on how it's implemented. I'm confident we can have the best of b= oth - simple API with low-overhead implementation. Can we brainstorm HOW th= is proposal can be implemented rather than WHY it can't be implemented (whi= ch is mostly what I've been hearing so far)? After all, no one has challeng= ed the claim that this proposal drastically simplifies the API for the clie= nt, so it would appear to be worth doing. I'm sure there's more than enough= intellectual horsepower in this working group to pull this off if we put o= ur minds to it. Regards, Ganesh On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote: > I strongly object to anything that leads to a read before modify requirem= ent. Too complex and too chatty. Sorry Phil, but you're contradicting yourself here. There seems to be an aw= ful lot of matching (i.e., reading) going on in the spec as it stands, with= if-then clauses to do one thing or another if the match either succeeds or= fails. This is a complex, chatty protocol right now! Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. For a spec that is supposed to be about simplicity, the above description i= s anything but simple. I know you guys have worked hard on this and I don't= mean to disparage those efforts, but think about how the above passage wou= ld appear to a new reader (i.e., a novice to the spec, not a technology nov= ice). There is something fundamentally broken, and it is this: multi-valued attri= butes without a unique identifier per value. If you don't fix that, you won= 't get simplicity. We know LDAP trees are broken for multi-valued attributes. As Mark Wahl fam= ously commented ba= ck in 2005, "Unfortunately, some of the emerging protocols which also intend to represe= nt and transfer personal identity information have perhaps taken a step bac= kwards by not even considering these issues, perhaps sweeping them under th= e rug in the guise of simplicity, XMLification, or "fix in the next version= ", which only postpone finding interoperable solutions to allowing applicat= ions to express the identity entries they want to express." SCIM is exactly one of these "emerging protocols" Wahl talks about, and wha= t I see now strikes me as "sweeping these issues under the rug in the guise= of simplicity". Apologies for the bluntness. My take is that SPs are _already_ struggling to manage multi-valued attribu= tes, and existing mechanisms are clumsy. They would be grateful f= or a specification that made operations easier at the cost of a re-engineer= ed schema. That calls for some thought leadership from this working group. Regards, Ganesh On 13 August 2012 10:13, Phil Hunt > wrote: I strongly object to anything that leads to a read before modify requiremen= t. Too complex and too chatty. Phil On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote: > Would it have to be stored on the account database of the service provide= r? Yes. > If so, I believe that this is impracticable in the core schema. Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. Why? That doesn't necessarily follow. Implementation is independent of repr= esentation. We're talking about a change in representation to make the API = cleaner. As a simple example, if an LDAP node is being used to hold a list of comma-= separated email addresses, it can just as easily store comma-separated name= -value pairs. mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com can be changed to mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com That's why I asked if there was an SP representative on this working group = who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement t= hese changes easily and are rejecting them for that reason. Regards, Ganesh On 13 August 2012 04:29, Emmanuel Dreux > wrote: =3D> addresses.3cbaaff8e84e.street-number =3D "243" Where would 3cbaaff8e84e come from? Would it have to be stored on the accou= nt database of the service provider? If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposi= tory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. This would be a show stopper. SCIM must be transparent, and must be able to= be put on top of an existing system to provide provisioning apis. Said differently, SCIM must not be intrusive for existing systems and must = not require modifications to allow its integration. Correct me if I misunderstood your suggestion. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 =C0 : Kelly Grizzle Cc : scim@ietf.org; Phil Hunt Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestio --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7E3ABL2PRD0310MB362_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We should not be constrai= ned by LDAP restrictions, this would not be productive.

 <= /p>

From: scim-bou= nces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Monday, August 13, 2012 2:07 PM
To: Kelly Grizzle
Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Thanks, Kelly. You've been most patient in hearing m= e out, I must say. I couldn't ask for more.

 

Replying to Chris Philips's mail:

>  

Regards,

Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

There are really two implementation opt= ions for a uid per element – either store the uids in the native underlying data store or have some secondary data store that maps e= lements to their uids.  The third option is to hope that a service pro= vider has a NoLDAP data store or its equivalent.  None of these are pr= actical for rapid and wide-spread adoption.

 

> put the two together to propose a solution.

 

As I said before, I am completely on bo= ard with cleaning up the PATCH semantics (eg – the inconsistency between meta.attributes and operation=3Ddelete, etc…).  Your su= ggestion of using different verbs is a good option to consider.  This = cannot be based on a uid per element, though.  It seems as though you = have admitted this in your conclusion – “As for LDAP and SCIM, I guess the best TLA is RIP.”

 

--Kelly

 

From: Ganesh and Sashi Prasa= d [mailto:g.c.pra= sad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

That was one suggestion. Another way could be container nodes with= their own "dn"s. If one suggestion won't work, tell me another w= ay to make it work. I'm waiting to hear a constructive suggestion that can square an elegant API with the implementation constrai= nts that come from having to store multi-valued attributes in LDAP director= ies.

 

I've heard enough of WHY this won't work. For a change, tell me HO= W it can be made to work. Everyone now knows what the proposal means in ter= ms of the API, and implementors understand the constraints of legacy data stores, so put the two together to propose = a solution. C'mon, we have the "smartest guys in the room" here, = surely we should be able to crack this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions about what is to be d= one:

 

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:

> After all, no one has challenged the claim that this proposal= drastically simplifies the API for the client

 

I agree that your proposal makes PATCH = semantics simpler and more elegant.

 

 

> … so it would appear to be worth doing. 

 

I strongly disagree here.  This st= atements assumes that simplicity of the client API is the only factor that should be considered with the spec.

 

Emmanuel’s example is from a real= -world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interfac= e that will help facilitate data exchange between multiple Active Directory= servers.  Your solution was to change the data model from this:

 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, = ;7a6d1de664e1=3Djsmith1970@hotmail.com

 

I do not know of a single organization = that would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likel= y across other domain controllers, etc…) to assign these unique ident= ifiers.  This also assumes that SCIM is the only reader/writer of this= data, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this. = Additionally, there are *many* tools and applications  (eg = 211; address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO t= his same argument holds true for most service providers.<= /p>

 

 

PATCH is an optional part of the spec. =  It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve e= very problem (eg – modifying sub-elements in nested arrays).  Ad= ding uids to every multi-valued element does not strike the right balance b= etween the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasa= d [mailto:g.c.pra= sad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Responding to extract of Melinda Shore's mail from digest:

 

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more

messages with a complaint about what you seem to think is a=



complex algorithm for attribute processing.




 






It depends on how it's implemented. I'm confident we can have the =
best of both - simple API with low-overhead implementation. Can we brainsto=
rm HOW this proposal can be implemented
 rather than WHY it can't be implemented (which is mostly what I've been he=
aring so far)? After all, no one has challenged the claim that this proposa=
l drastically simplifies the API for the client, so it would appear to be w=
orth doing. I'm sure there's more
 than enough intellectual horsepower in this working group to pull this off=
 if we put our minds to it.






 






Regards,






Ganesh




 




On 13 August 2012 13:54, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> w=
rote:




> I strongly object to anything that leads to a read before modi=
fy requirement. Too complex and too chatty.




Sorry Phil, but you're contradicting yourself here. There see=
ms to be an awful lot of matching (i.e., reading) going on in the spec as i=
t stands, with if-then clauses to do one
 thing or another if the match either succeeds or fails. This is a complex,=
 chatty protocol right now!




 






   Multi-valued attributes:=
  An attribute value in the PATCH request


      body i=
s added to the value collection if the value does not exist


      and me=
rged if a matching value is present.  Values are matched by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute; e.g., addresses, or do not have unique


      value =
Sub-Attributes cannot be matched and must instead be deleted


      then a=
dded.  Specific values can be removed from a Resource by


      adding=
 an "operation" Sub-Attribute with the value "delete" t=
o the


      attrib=
ute in the PATCH request body.  As with adding/updating


      attrib=
ute value collections, the value to delete is determined by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute or that have a non-unique value Sub-=



      Attrib=
ute are matched by comparing all Sub-Attribute values from


      the PA=
TCH request body to the Sub-Attribute values of the


      Resour=
ce.  A delete operation is ignored if the attribute's name=



      is in =
the meta.attributes list.  If the requested value to delete


      does n=
ot match a unique value on the Resource the server MAY

      return=
 a HTTP 400 error.






 






For a spec that is supposed to be about simplicity, the above desc=
ription is anything but simple. I know you guys have worked hard on this an=
d I don't mean to disparage those efforts,
 but think about how the above passage would appear to a new reader (i.e., =
a novice to the spec, not a technology novice).






 






There is something fundamentally broken, and it is this: multi-val=
ued attributes without a unique identifier per value. If you don't fix that=
, you won't get simplicity.






 






We know LDAP trees are broken for multi-valued attributes. As Mark=
 Wahl

famously commented back in 2005,






 






"Unfortunately, some of the emerging protocols w=
hich also intend to represent and transfer personal identity information
 have perhaps taken a step backwards by not even considering these issues, =
perhaps sweeping them under the rug in the guise of simplicity, XMLificatio=
n, or "fix in the next version", which only postpone finding inte=
roperable solutions to allowing applications
 to express the identity entries they want to express."






 






SCIM is exactly one of these "emerging protocols" Wahl t=
alks about, and what I see now strikes me as "sweeping these issues un=
der the rug in the guise of simplicity". Apologies
 for the bluntness.






 






My take is that SPs are _already_ struggling to manage multi-value=
d attributes, and

existing mechanisms are clumsy. They would be grateful for a specificat=
ion that made operations easier at the cost of a re-engineered schema. That=
 calls for some thought leadership from this working group.






 






Regards,






Ganesh






 




On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:






I strongly object to anything that leads to a read before modify r=
equirement. Too complex and too chatty. =




Phil












On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








> Would it have to be stored on t=
he account database of the service provider?


 


Yes.


 


> If so, I believe that this is i=
mpracticable in the core schema. Indeed it implies that a service prov=
ider must extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.




 






Why? That doesn't necessarily follow. Implementation is independen=
t of representation. We're talking about a change in representation to make=
 the API cleaner.






 






As a simple example, if an LDAP node is being used to hold a list =
of comma-separated email addresses, it can just as easily store comma-separ=
ated name-value pairs.






 







 






mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, =
;7a6d1de664e1=3Djsmith1970@hotmail.com






 




That's why I asked if there was an SP representative on this working gro=
up who could explain what such a change could mean for them.
 As of now, it looks like other people are presuming that SPs will not be a=
ble to implement these changes easily and are rejecting them for that reaso=
n.




 






Regards,






Ganesh






 




On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com> wrote:






=F0  
addresses.3cbaaff8e84e.street-number =3D "243"


 


Where would
3cbaaff8e84e come from? Would it have to be stored on the account database of th=
e service provider?


 


If so, I believe that this is imprac=
ticable in the core schema. Indeed it implies that a service provider must =
extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.


This would be a show stopper. SCIM m=
ust be transparent, and must be able to be put on top of an existing system=
 to provide provisioning apis.


 


Said differently, SCIM must not be i=
ntrusive for existing systems and must not require modifications to allow i=
ts integration.


Correct me if I misunderstood your s=
uggestion.


 


--


Regards,


Emmanuel Dreux<=
/o:p>


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

Tel:
+33 4 2=
6 78 17 58


Mobile:
+33 6 4=
7 81 26 70


skype: Emmanuel.Dreux


 



De : Ganesh and
 Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9 : dimanche 12 ao=FBt 2012 04:53

=C0 : Kelly Grizzle

Cc : scim@ie=
tf.org; Phil Hunt

Objet : Re: [scim] scim Digest, Vol 8, Issue 24




 


> 
Multi-valued attributes that d=
on't have a value sub-attribute (eg - address) have to specified completely=
 for uniqueness.  




 






That's exactly the point. How do we "specif=
y completely for uniqueness"?






 






In the example below, how are you proposing that=
 the following element be updated if we can't use positional indexes?






 






addresses[1].street-number =3D "243"






 






User object:






 








{






  ...






  addresses: [






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  ]






}






 






It's impractical to use the value because it's t=
he whole dictionary element:






 








{






  "type" : "office",






  "street-number" : "213&quo=
t;,






  "street-name" : "Main Stre=
et",






  "suburb" : "Adelaide"=
,






  "postcode" : "5000",<=
/span>






  "state" : "SA",






  "country" : "Australia&quo=
t;






}








 






With my proposal, the "addresses" arra=
y gets converted to a dictionary, and then we have a stable way of referenc=
ing this element:






 








addresses.3cbaaff8e84e.street-number =3D "2=
43"




 








{






  ...






  addresses: {






    "d6ea365462f5" :<=
o:p>






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    "3cbaaff8e84e" :<=
o:p>






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  }






}






 






If you're proposing one mechanism for composite =
attributes and another mechanism for simple attributes, I would suggest tha=
t's actually more complex than adopting
 a single mechanism that works the same way for _all_ attributes. Remember =
that a lot of the administration is probably going to be scripted rather th=
an done by hand, and having two mechanisms (depending on whether the attrib=
ute is simple or composite) will
 complicate every script that has to be written.








 






There's a lot of talk about the "burden&quo=
t; on the SPs, but I believe this is overblown. Is there any SP representat=
ive in this WG who can tell us what this proposal
 will actually entail for them?






 






Regards,






Ganesh




 




On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@s=
ailpoint.com> wrote:








Ganesh,






 






This is exactly how PATCH works in SCIM 1.=
0.  Multi-valued attributes that have a value sub-attribute
 can be removed by specifying only the value since it is unique.  Mult=
i-valued attributes that don't have a value sub-attribute (eg - address) ha=
ve to specified completely for uniqueness.  As I have said before, I a=
m very opposed to adding a unique identifier
 to each element in a multi-valued collection due to the burden it will put=
 on SPs.  Is it elegant?  No.  Is it functional?  Yes. =
 Will this non-elegance affect adoption?  My opinion is that addi=
ng unique keys to each element will have a much more detrimental
 effect on adoption.






 






I do believe that in general PATCH can be =
made more intuitive without adding uids to each element.  The
 verbs that you propose make sense.  There is also a JSON Patch inform=
ational draft in the IETF that is interesting - http://=
tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.
  It relies on a JSON Pointer draft which uses index-based addressing =
for multi-valued attributes.  I think that this is something that shou=
ld be looked at within the WG and I would be willing to lead this effort.






 






I'm curious if anyone else in the WG is in=
 favor of unique identifiers for every multi-valued element.






 






--Kelly




 












From:
scim-bounces@iet=
f.org [scim-=
bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]

Sent: Saturday, August 11, 2012 10:50 AM

To: Phil Hunt

Cc: scim@ietf.org=


Subject: Re: [scim] scim Digest, Vol 8, Issue 24









Phil,





 






The reason we cannot use the value itself to ide=
ntify an element is that this method will only work for simple elements, no=
t for nested structures. i.e., if we had
 an array of dictionaries (e.g., we had to record an array of addresses for=
 each customer, with each address element having sub-elements like street n=
umber, street name, suburb, etc.), then it would be clumsy to supply the en=
tire value of the array element
 because it's itself a dictionary. Creating a unique key for each element s=
cales better.






 






Regards,






Ganesh




On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com=
> wrote:




Ganesh,





 






Here's the sample that concerned me...












The two operations differ significantly, and it'=
s not very intuitive. 






With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }











 








 








You gave other examples of an attribute with an identifier th=
at matched that value or of identifiers that were
 additional unique keys.






 






Given that multi-values must be each unique, I don't see the =
point of the extra indexing to support this. Just
 use the value as the item you wish to delete.






 






I agree, the delete value operation could be more explicit an=
d clear in general.






 









 




 








 






On 2012-08-11, at 2:30 AM, Ganesh and Sashi Pras=
ad wrote:




 


>  For the multi-value example you gave =
you used the value as the attribute name key. 





 






Now I'm confused :-). I don't believe any of my =
examples ever used a value as the key.






 






Could you please show me which example you mean,=
 and which parts of it you believe to be the value?






 






Regards,






Ganesh 




On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com=
> wrote:








For the multi-value example you gave you used the value as the attribute na=
me key. 






 






That means a lot more complex indexing structure=
. Better to just say delete a specific value. 






 






The spec already allows multiple values to have =
tags like home, work, etc.






 =







Phil











On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
















> In your example you are conflating val=
ue with an attribute id. 



I don't believe so. 




 






I'm adopting a model where every attribute of th=
e resource is a key-value pair. The key is a name or ID.<=
/p>





 






For non-repeating attributes (both simple and co=
mposite), the key is the attribute name itself. 






 








Simple attribute:






 






Key: "dob"






Value: "01 Jan 1970"=







 








For composite attributes, the key employs dot no=
tation to specify the fully-qualified attribute name, e.g., "address.p=
ostcode".






 






Composite attribute:






 






Key: "address.street-number"






Value: "10"






 






Key: "address.suburb"






Value: "East Camden"=







 






For repeating (multi-valued) attributes, I'm sug=
gesting that there be new keys for each individual value, otherwise they ar=
e impossible to distinguish, and a positional
 index is inadequate. So we convert the array into a dictionary and this th=
en becomes a composite attribute using dot notation for the key.






 






Multi-valued attribute:






 






Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea=
3bd902"







 






So this allows us to apply uniform treatment to =
any arbitrarily deep resource structure. We can refer to every leaf value w=
ith a key that is the fully-qualified
 name using dot notation.






 






The verbs are just unambiguous operations on the=
se (now) explicitly addressable attributes.






 






INCLUDE to a collection and specify only the val=
ue. The key is generated and returned. The fully-qualified key is <colle=
ction-name>.<newly-generated-ID> and the
 value is what was specified in the INCLUDE.






 






REPLACE a fully-qualified key with a new value. =
If the key doesn't exist, return a "404 Not Found".






 






PLACE a value at the logical location implied by=
 the fully-qualified key. If there is already a key with that name, return =
a "409 Conflict".






 






FORCE the fully-qualified key to hold the given =
value, regardless of whether it existed before or not. Only errors possible=
 are "400 Bad Request" and "500 Internal
 Error".






 






RETIRE an attribute or a collection given its fu=
lly-qualified key. The implementation will determine whether the attribute =
will disappear entirely or will exist
 holding a null value (the blank string "" or the empty object {}=
 ).






 






I'll explain in a separate post why we need oper=
ation verbs like these that are independent of the HTTP verbs.<=
/o:p>






 






Regards,






Ganesh






 




On 11 August 2012 10:38, <scim-request@ietf.org> wrote=
:


If you have received this digest without all the=
 individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



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



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







Send scim mailing list submissions to

        scim@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

        https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to

        scim-request@ietf.org



You can reach the person managing the list at

        scim-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of scim digest..."



Today's Topics:



   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun=
t)





---------- Forwarded message ----------

From: Phil Hunt <phil.hunt@oracle.com>

To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>

Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux =
<edreux@cloudi=
way.com>, Trey Drake <trey.drake@unboundid.com>,
 Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>

Date: Fri, 10 Aug 2012 17:36:54 -0700

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








Ganesh,






 






In your example you are conflating value with an=
 attribute id. I find that confusing. 






 






I agree though that operations in patch could be=
 a lot more explicit. 






 






Eg explicitly deleting a value by saying delete =
or retire. 








Phil








On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








 >  I am concerned about your second suggestion: 





 






Let's discuss that now.






 






The trade-offs are very clear here.<=
/o:p>






 






Pros:






 






Pro 1. The API to manipulate resources becomes s=
o much cleaner, consistent and intuitive when every individual attribute va=
lue gets its own ID.






 






Here's how to delete a single member from a Grou=
p, as per the current spec:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"members": [


    &=
nbsp;  {


    &=
nbsp;    "display": "Babs Jensen",


    &=
nbsp;    "value": "2819c223-7f76-453a-919d-41=
3861904646"


    &=
nbsp;    "operation": "delete"


    &=
nbsp;  }


     =
]


   }




Here's how to delete ALL members from a group according to the current spec=
:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"meta": {


    &=
nbsp;  "attributes": [


    &=
nbsp;    "members"


    &=
nbsp;  ]


     =
}


   }




The two operations differ significantly, and it's not very intuitive. =







With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }


Here's how I suggest deleting ALL members from a group:





 








PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members"






}






}






] }







I'm sure you'll agree that this is simpler, more consistent and more intuit=
ive to a reader.






 






Pro 2: We can apply this mechanism consistently =
to three areas:






(a) Manipulating multi-valued attributes of a re=
source






(b) Manipulating members of a group<=
/o:p>






(c) Performing bulk operations, where we simply =
use HTTP verbs instead of the specialised (and semantically less ambiguous)=
 verbs I suggested for attributes, the
 "key" becomes the URI, and the "value" becomes the cor=
responding JSON object.






 






All of them return "207 Multi-Status" =
with the "results" array holding individual status codes.<=
o:p>






 






In the current spec, (a) and (b) are done simila=
rly but (c) is very different.






 






Pro 3: Adoption of the standard by clients is li=
kely to be higher because it's simpler for them.






 






Pro 4: New (not incumbent) cloud providers will =
probably find this easier to implement because they have no legacy. They wi=
ll probably use some form of NoSQL database
 and won't be constrained by the limitations of LDAP directories.






 






Cons:






 






Con 1: Incumbent cloud providers with existing d=
ata stores in a directory format (where multi-valued attributes are stored =
as comma-separated values under a single
 attribute node) will find it difficult to migrate to this model and store =
each attribute value as a sub-node with its own key. This will "hinder=
 adoption of the spec", which is what you fear.






 






Have I summed up the Pros and Cons correctly? I'=
m biased of course, so I could have missed a Con or hyped a Pro :-).=





 




In other words, we're debating interface complex=
ity (current spec) versus implementation complexity (my suggestion). Both c=
an hinder adoption of the spec by different
 parties.






 






Here's what we need to discuss - Do the Pros mak=
e the suggestio
















































































 










 

 

 

--_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9E7E3ABL2PRD0310MB362_-- From phil.hunt@oracle.com Tue Aug 14 14:47:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA821E80B9; Tue, 14 Aug 2012 14:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.203 X-Spam-Level: X-Spam-Status: No, score=-9.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP8NEa3w42Pm; Tue, 14 Aug 2012 14:47:44 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBB821E80BA; Tue, 14 Aug 2012 14:47:43 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7ELletx024724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Aug 2012 21:47:40 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7ELld4k000969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Aug 2012 21:47:40 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7ELldo9013074; Tue, 14 Aug 2012 16:47:39 -0500 Received: from [25.73.205.86] (/74.198.150.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 14 Aug 2012 14:47:39 -0700 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Tue, 14 Aug 2012 15:47:36 -0600 To: Anthony Nadalin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Yutaka OIWA , "http-auth@ietf.org" , scim Mailing List Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 21:47:45 -0000 If one were moving away from an ldap directory to say a scim directory how w= ould you set a password in the directory without using ldap? IOW, what if t= he self-service api used scim? Phil On 2012-08-14, at 13:54, Anthony Nadalin wrote: > I just question the delivery of passwords at all, clear text or encrypted.= >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Yu= taka OIWA > Sent: Monday, August 13, 2012 9:09 PM > To: scim Mailing List > Cc: http-auth@ietf.org > Subject: [scim] scim data format and structured credentials delivery/insta= llations >=20 > Dear SCIM people, >=20 > > I am currently proposing a new HTTP authentication protocol for enabling s= ecure mutual authentication using shared credentials (including pre-shared k= eys or passwords). > There are many features beyond conventional authentication methods, but fr= om the viewpoint of key/credential management (related to scim), this authen= tication scheme have two properties concurrently: >=20 > * enables use of encrypted (hashed) passwords on the server side > - somewhat similar to Basic/Form > - contrary to CHAP/Digest (which require passwords-equivalent), > * allows non-plaintext exchange on-wire > - similar to, but much stronger than CHAP/Digest > - contrary to Basic/Form. >=20 > Server-side encrypted passwords are per-server basis, so any stolen creden= tial cannot be reused by other people, provided that the client-side credent= ials have fair amount of entropy (unlike 1234, password or xhtdj). > >=20 > Under this background, my point asking on this mail is: > we have one missing feature on our protocol design: delivery of encrypted p= asswords from clients to servers on the first registration phase. > Currently we have two ways for first-time registration: > * letting servers know the plaintext passwords, and encrypt them on the se= rver side. > * encrypting the passwords manually on the client side, while carefully > inputing protocol-dependent security parameters that the server gives. > But both of them are unsatisfactory. > We have planned to develop a common format in the next steps for exchangin= g such authentication parameters between peers for single account registrati= ons using Web browsers/Web Forms or other clients. >=20 > Looking beyond our proposal, there are also many key/credential formats wh= ich requires key deliveries from clients to servers on the first registratio= n, including such as X.509 certificates (either full-certificate or just DN p= art), unsigned RSA public keys, JWKs, SSH pubkeys, machine-generated strong s= ecrets, and even unix-hashed passwords. > We now aware that many parts of requirements for such use-cases are common= with what SCIM requires, and we should avoid designing two similar parts on= the same table. > I remember that in Vancouver SCIM session, some people also raised require= ments for deploying such non-plaintext secret within SCIM framework. >=20 > So, I'd like to reuse current data format for SCIM exchange for such purpo= ses. > To do that, I plan to propose a generic extension mechanism for putting ke= y > formats other than just plaintext passwords. Such format may be useful f= or > other credentials as well, and it can, of course, be used for SCIM-based a= ccount management. > So I think that this extension satisfies some needs for SCIM as well as ot= her use cases. >=20 > Feedbacks are appreciated. >=20 > --=20 > Yutaka OIWA, Ph.D. Leader, Software Reliability Research Grou= p > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B= 5] _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Tue Aug 14 15:35:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8421E80C1 for ; Tue, 14 Aug 2012 15:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.892 X-Spam-Level: X-Spam-Status: No, score=-7.892 tagged_above=-999 required=5 tests=[AWL=-1.293, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdAfB57upiSc for ; Tue, 14 Aug 2012 15:35:32 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 97AC121E80BC for ; Tue, 14 Aug 2012 15:35:32 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q7EMZTt3010629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Aug 2012 17:35:29 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7EMZTLR003980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 14 Aug 2012 17:35:29 -0500 Received: from [135.244.39.114] (faynberg.lra.lucent.com [135.244.39.114]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7EMZSq7022182; Tue, 14 Aug 2012 17:35:28 -0500 (CDT) Message-ID: <502AD2B0.1080305@alcatel-lucent.com> Date: Tue, 14 Aug 2012 18:35:28 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> In-Reply-To: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 22:35:33 -0000 Just to interject some thoughts and more questions: I think this goes back to the question that Hui-Lan raised at the meeting during Kelly's presentation. As Kelly explained, there were different use cases, and we need to differentiate. (Also a good topic to relflect in the use case document!) One use case is the first-time provisioning, on which the initial password (assumed to be known to the end-user) has to be stored temporarily until it is changed by the end-user. The other was the actual act of changing the password. As we thought more about it, it appears that in neither case should the password be actually stored (only its salted hash should be stored, along with salt). But if the salt is to be chosen by the database only, this will necessitate the transmission of the password itself in the case of the first-time provisioning. The threat here can, of course, be mitigated by a combination of 1) fast action by the end-user to reset the password and 2) multiple-factor authentication during the reset. But can we come up with specifying a way to get an agreement on the value of salt before the provisioning so that the provisioning entity and the directory share it? If we can, then only the salted hash can be transmitted in place of the password. Then, during the reset, the directory will of course generate the new salt. Another alternative, potentially subject to dictionary attack, is to transmit both the salt and the hashed password. Igor On 8/14/2012 5:47 PM, Phil Hunt wrote: > If one were moving away from an ldap directory to say a scim directory how would you set a password in the directory without using ldap? IOW, what if the self-service api used scim? > > Phil > > On 2012-08-14, at 13:54, Anthony Nadalin wrote: > >> I just question the delivery of passwords at all, clear text or encrypted. >> > tf.org/mailman/listinfo/scim From melinda.shore@gmail.com Tue Aug 14 15:52:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3862021E8095 for ; Tue, 14 Aug 2012 15:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L745YH3OgtGu for ; Tue, 14 Aug 2012 15:52:54 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A460921F85CD for ; Tue, 14 Aug 2012 15:52:54 -0700 (PDT) Received: by ggnh4 with SMTP id h4so1202406ggn.31 for ; Tue, 14 Aug 2012 15:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7W02LB5UQy6NGX6E419iRl3NsoL2s6qUPpoZbPKAqhk=; b=GjMLBUfhYUOHtL/lVHARn6oZ8fsEVCpvdbXTGzVm46BfcT03Oji9bl18XO/XajX+gJ F92jx6IUiHeOoiHA2NF3KHX5GDUvMOiWiY0WZx79KxBHHRPzptUHxV4W2kn2Vodl8OMb pzVy8lE9UcX/5CtRUAnSFa5lA4ygBHb5qSYk2N4crzq7EIkMQFmhytOLLaihbcK87J49 YvEqsVcz6jmEX0/iZeTCN5ERYUcfxMr08B8D4sda0XNNBLZZ9A9vJdJl7wXsbxFHYSJo Y6t0z862BXMcvkwLZOIkUnC8/cHMh5gHRU22cux2/RfZA0tB1JIJbktdDFQErv9oc+J6 Fi2A== Received: by 10.50.34.169 with SMTP id a9mr14787706igj.13.1344984773765; Tue, 14 Aug 2012 15:52:53 -0700 (PDT) Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.208]) by mx.google.com with ESMTPS id xm2sm977479igb.3.2012.08.14.15.52.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 15:52:53 -0700 (PDT) Message-ID: <502AD6C3.4020206@gmail.com> Date: Tue, 14 Aug 2012 14:52:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> In-Reply-To: <502AD2B0.1080305@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 22:52:55 -0000 I suspect that the password problem is going to be unduly hairy, given the proliferation of password schemes - in particular proprietary ones. My first question would actually be this: is there an expectation that the password (or at least the initial password) in the service being provisioned from is going to be the same as the one being used in the system being provisioned to? Let's say, for the sake of argument, that they're both storing hashed password - how do you know they're both using the same hash algorithm? What if they're not? And what about those cases where the company who developed the service being provisioned to is less than clueful about security and they don't want to tell you what they're doing with passwords? It happens. At the moment my feeling is that the password attribute should probably be an opaque blob, acknowledging the non-trivial potential for interoperability problems. I suspect those interoperability problems are going to be there, anyway, just given the nature of how authentication is treated in Product Land. I could probably wake up tomorrow and feel completely differently, but at the moment it's not clear to me that specifying what goes into a password attribute is going to be much of an aid to interoperability. Melinda From tonynad@microsoft.com Tue Aug 14 16:40:34 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A5321E80B0; Tue, 14 Aug 2012 16:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=1.742, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr6TNKKEg2Dr; Tue, 14 Aug 2012 16:40:33 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0021E80CC; Tue, 14 Aug 2012 16:40:33 -0700 (PDT) Received: from mail257-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 23:40:33 +0000 Received: from mail257-tx2 (localhost [127.0.0.1]) by mail257-tx2-R.bigfish.com (Postfix) with ESMTP id F34D31401E2; Tue, 14 Aug 2012 23:40:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I936eI542M1432I1418Izz1202h1082kzz1033IL8275bh8275dh15d4Iz2fh2a8h683h839h944hd25hf0ah107ah) Received-SPF: pass (mail257-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail257-tx2 (localhost.localdomain [127.0.0.1]) by mail257-tx2 (MessageSwitch) id 1344987631173569_9558; Tue, 14 Aug 2012 23:40:31 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.240]) by mail257-tx2.bigfish.com (Postfix) with ESMTP id 1EA3ECC0045; Tue, 14 Aug 2012 23:40:31 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 23:40:29 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 14 Aug 2012 23:40:28 +0000 Received: from mail91-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 23:40:27 +0000 Received: from mail91-ch1 (localhost [127.0.0.1]) by mail91-ch1-R.bigfish.com (Postfix) with ESMTP id 8A17180367; Tue, 14 Aug 2012 23:40:27 +0000 (UTC) Received: from mail91-ch1 (localhost.localdomain [127.0.0.1]) by mail91-ch1 (MessageSwitch) id 1344987625170674_8116; Tue, 14 Aug 2012 23:40:25 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241]) by mail91-ch1.bigfish.com (Postfix) with ESMTP id 1D45BE008C; Tue, 14 Aug 2012 23:40:25 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 23:40:24 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0175.005; Tue, 14 Aug 2012 23:40:23 +0000 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNemZ7+PBrJZk02kepIx2WtbByhpdZ901w Date: Tue, 14 Aug 2012 23:40:23 +0000 Message-ID: References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> In-Reply-To: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.134.163.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ORACLE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AIST.GO.JP$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: Yutaka OIWA , "http-auth@ietf.org" , scim Mailing List Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 23:40:34 -0000 Could be hints/parts/entrpy/rules but not the actual password -----Original Message----- From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 Sent: Tuesday, August 14, 2012 2:48 PM To: Anthony Nadalin Cc: Yutaka OIWA; scim Mailing List; http-auth@ietf.org Subject: Re: [scim] scim data format and structured credentials delivery/in= stallations If one were moving away from an ldap directory to say a scim directory how = would you set a password in the directory without using ldap? IOW, what if= the self-service api used scim? Phil On 2012-08-14, at 13:54, Anthony Nadalin wrote: > I just question the delivery of passwords at all, clear text or encrypted= . >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Y= utaka OIWA > Sent: Monday, August 13, 2012 9:09 PM > To: scim Mailing List > Cc: http-auth@ietf.org > Subject: [scim] scim data format and structured credentials delivery/inst= allations >=20 > Dear SCIM people, >=20 > > I am currently proposing a new HTTP authentication protocol for enabling = secure mutual authentication using shared credentials (including pre-shared= keys or passwords). > There are many features beyond conventional authentication methods, but f= rom the viewpoint of key/credential management (related to scim), this auth= entication scheme have two properties concurrently: >=20 > * enables use of encrypted (hashed) passwords on the server side > - somewhat similar to Basic/Form > - contrary to CHAP/Digest (which require passwords-equivalent), > * allows non-plaintext exchange on-wire > - similar to, but much stronger than CHAP/Digest > - contrary to Basic/Form. >=20 > Server-side encrypted passwords are per-server basis, so any stolen crede= ntial cannot be reused by other people, provided that the client-side crede= ntials have fair amount of entropy (unlike 1234, password or xhtdj). > >=20 > Under this background, my point asking on this mail is: > we have one missing feature on our protocol design: delivery of encrypted= passwords from clients to servers on the first registration phase. > Currently we have two ways for first-time registration: > * letting servers know the plaintext passwords, and encrypt them on the s= erver side. > * encrypting the passwords manually on the client side, while carefully > inputing protocol-dependent security parameters that the server gives. > But both of them are unsatisfactory. > We have planned to develop a common format in the next steps for exchangi= ng such authentication parameters between peers for single account registra= tions using Web browsers/Web Forms or other clients. >=20 > Looking beyond our proposal, there are also many key/credential formats w= hich requires key deliveries from clients to servers on the first registrat= ion, including such as X.509 certificates (either full-certificate or just = DN part), unsigned RSA public keys, JWKs, SSH pubkeys, machine-generated st= rong secrets, and even unix-hashed passwords. > We now aware that many parts of requirements for such use-cases are commo= n with what SCIM requires, and we should avoid designing two similar parts = on the same table. > I remember that in Vancouver SCIM session, some people also raised requir= ements for deploying such non-plaintext secret within SCIM framework. >=20 > So, I'd like to reuse current data format for SCIM exchange for such purp= oses. > To do that, I plan to propose a generic extension mechanism for putting k= ey > formats other than just plaintext passwords. Such format may be useful = for > other credentials as well, and it can, of course, be used for SCIM-based= account management. > So I think that this extension satisfies some needs for SCIM as well as o= ther use cases. >=20 > Feedbacks are appreciated. >=20 > --=20 > Yutaka OIWA, Ph.D. Leader, Software Reliability Research Gro= up > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46= B5] _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Tue Aug 14 21:55:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653FF21E8086 for ; Tue, 14 Aug 2012 21:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfBbqgyE6lb9 for ; Tue, 14 Aug 2012 21:55:14 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 23DE221E80AB for ; Tue, 14 Aug 2012 21:55:11 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 14 Aug 2012 21:55:11 -0700 From: Michael Hammer To: "igor.faynberg@alcatel-lucent.com" , "scim@ietf.org" Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNem0gXgViH6RDZU+M3avm2wjKmZdaTyRA Date: Wed, 15 Aug 2012 04:55:09 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> In-Reply-To: <502AD2B0.1080305@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.11] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006E_01CD7A67.75D00680" MIME-Version: 1.0 Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 04:55:15 -0000 ------=_NextPart_000_006E_01CD7A67.75D00680 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Diffie-Helman anyone? There are ways to generate keys without a middleman attack. See what ZRTP does. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Igor Faynberg Sent: Tuesday, August 14, 2012 3:35 PM To: scim@ietf.org Subject: Re: [scim] scim data format and structured credentials delivery/installations Just to interject some thoughts and more questions: I think this goes back to the question that Hui-Lan raised at the meeting during Kelly's presentation. As Kelly explained, there were different use cases, and we need to differentiate. (Also a good topic to relflect in the use case document!) One use case is the first-time provisioning, on which the initial password (assumed to be known to the end-user) has to be stored temporarily until it is changed by the end-user. The other was the actual act of changing the password. As we thought more about it, it appears that in neither case should the password be actually stored (only its salted hash should be stored, along with salt). But if the salt is to be chosen by the database only, this will necessitate the transmission of the password itself in the case of the first-time provisioning. The threat here can, of course, be mitigated by a combination of 1) fast action by the end-user to reset the password and 2) multiple-factor authentication during the reset. But can we come up with specifying a way to get an agreement on the value of salt before the provisioning so that the provisioning entity and the directory share it? If we can, then only the salted hash can be transmitted in place of the password. Then, during the reset, the directory will of course generate the new salt. Another alternative, potentially subject to dictionary attack, is to transmit both the salt and the hashed password. Igor On 8/14/2012 5:47 PM, Phil Hunt wrote: > If one were moving away from an ldap directory to say a scim directory how would you set a password in the directory without using ldap? IOW, what if the self-service api used scim? > > Phil > > On 2012-08-14, at 13:54, Anthony Nadalin wrote: > >> I just question the delivery of passwords at all, clear text or encrypted. >> > tf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_006E_01CD7A67.75D00680 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx NTA0NTUwNFowIwYJKoZIhvcNAQkEMRYEFAOzNsfaY0BSvbFvFq1TSBU6pE68MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA4I8CHTEpVh7Z322ASApDxJF4807G8XoGGwPvI5csh+W7 MAqyRmujAUIHNa0BxXgWdruECiR8gWEYq8HMaxr4y4m4rMjf4jVMR/GiP4vdbM+hv0ZVkKOL8wvj WrsSfxVqv8q1fnxV0fqUwVLSCurZ4gsPIXTaVqZPYFBrfvnhiPYAAAAAAAA= ------=_NextPart_000_006E_01CD7A67.75D00680-- From melinda.shore@gmail.com Tue Aug 14 22:03:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853721E8086 for ; Tue, 14 Aug 2012 22:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsvOT30jnBox for ; Tue, 14 Aug 2012 22:03:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B847621E805E for ; Tue, 14 Aug 2012 22:03:30 -0700 (PDT) Received: by iabz21 with SMTP id z21so108712iab.31 for ; Tue, 14 Aug 2012 22:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FF55HwFa5ZmLcz8gfD5yQIicOXMSpnaVc+ozRgV7yjY=; b=PJO2zzoFPxFjXsoiX1QBH+w5DtV1xrMWEXPH7MQEAm0dFaAa6uCRaMdmbtZxpZ76/O NJ5Ul5z9le2eBrv/57eZONXVQU86N5+v5v+wAJL+BTbqMJZFOsYgT/ZdAckV4/Q9a5bk F77HxSlBXpD8iBWVxpjwxpGU7RuYRUZURNtEScP7IMddcK93Q/AkwTiegp59inyyZ7Vg px3WqsaKvOaI/T+XcKggGIAz3yusM4aD88KfjSmSvqgGmsYtj42eF6EWveZYyRuJzTW1 xF1gxfh9y6FHwfoGaWU46Ohh3QKDQbhtij1Ca4WKvuhIaQnawRuJvyVSbU1zXrNieF4I vzXQ== Received: by 10.42.64.9 with SMTP id e9mr12935185ici.20.1345007010277; Tue, 14 Aug 2012 22:03:30 -0700 (PDT) Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.208]) by mx.google.com with ESMTPS id ko9sm14476567igc.16.2012.08.14.22.03.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 22:03:29 -0700 (PDT) Message-ID: <502B2D9E.5020006@gmail.com> Date: Tue, 14 Aug 2012 21:03:26 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:03:31 -0000 On 8/14/12 8:55 PM, Michael Hammer wrote: > Diffie-Helman anyone? No. Let's try to be clear about which problem is being addressed here. It is not to generate keying material to protect a session between client and server, or server and client, or two peers, or whomever. It is about provisioning a *user* password along with other account/directory information. Melinda From michael.hammer@yaanatech.com Tue Aug 14 22:24:12 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5733211E80A2 for ; Tue, 14 Aug 2012 22:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj4miaa4jOrX for ; Tue, 14 Aug 2012 22:24:11 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id DA4DC11E809C for ; Tue, 14 Aug 2012 22:24:11 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 14 Aug 2012 22:24:12 -0700 From: Michael Hammer To: "melinda.shore@gmail.com" , "scim@ietf.org" Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNem0gXgViH6RDZU+M3avm2wjKmZdaTyRAgAB39QD//5AO4A== Date: Wed, 15 Aug 2012 05:24:10 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> <502B2D9E.5020006@gmail.com> In-Reply-To: <502B2D9E.5020006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.11] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0107_01CD7A6B.85D01B70" MIME-Version: 1.0 Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:24:12 -0000 ------=_NextPart_000_0107_01CD7A6B.85D01B70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So, are you saying that the password is never passed in the clear? The earlier messages seem to suggest that it was. That is what does not seem clear at all here. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Tuesday, August 14, 2012 10:03 PM To: scim@ietf.org Subject: Re: [scim] scim data format and structured credentials delivery/installations On 8/14/12 8:55 PM, Michael Hammer wrote: > Diffie-Helman anyone? No. Let's try to be clear about which problem is being addressed here. It is not to generate keying material to protect a session between client and server, or server and client, or two peers, or whomever. It is about provisioning a *user* password along with other account/directory information. Melinda _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0107_01CD7A6B.85D01B70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx NTA1MjQwOFowIwYJKoZIhvcNAQkEMRYEFPhyf2TY0ph3llP1/8TrYcmxYoJTMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA46iFXcsHImLAmhUhxhPJW2adgXRCFKTFPwfPi7YIYnyg 5Fap3y/qgWxj4UED6EKvpNVXLTuFCZqUAys4N7xzoWZhteadShYnuLX73cH9ni2r0/IrLb7hSHhZ LBhhAJCcBnLTWG2G/XS31jW91Vn0fk3DJf0WQLVYI7lOtCJ+MxoAAAAAAAA= ------=_NextPart_000_0107_01CD7A6B.85D01B70-- From melinda.shore@gmail.com Tue Aug 14 22:26:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FF421E8086 for ; Tue, 14 Aug 2012 22:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+5T2e7b13lT for ; Tue, 14 Aug 2012 22:26:42 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B55EC11E80A2 for ; Tue, 14 Aug 2012 22:26:42 -0700 (PDT) Received: by yenm5 with SMTP id m5so1505659yen.31 for ; Tue, 14 Aug 2012 22:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FNZaL74PIhuJFHR/BN0349zj91JuY73A13FrfrluqFg=; b=n/uOftnpHBvCj8kljvwKB5JKesX8kwXRsdR1DYVvM65d7WmjvyilOMjG/d+1ewrwbf vhqxBSQYGGv1QtZDGOqrTaiNZjY2nyueige9mzCyB+GZf+dSw7TRDJ4mfqO5X/C5S1cJ acUJUtkQ+EpXnw2vQbNOrTrl6cU3eK/+CWfCWlYtDjwVWJynOpLMzyfUb9sl4DNg2xCt rLZ/si/l/HcQ7CpmFhu+KehveR2j3Yo8w8MkPTtSWD1n8SU9w7osLsZFEfBGJqXNa8l2 HbV1G14f9QbrAPXptiC6G3x4xsN+6ItXXw/5Vxl5eDkW7w/0jm8LTtoc+FPskykE9eHa G65Q== Received: by 10.42.54.3 with SMTP id p3mr16114797icg.41.1345008401809; Tue, 14 Aug 2012 22:26:41 -0700 (PDT) Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.208]) by mx.google.com with ESMTPS id dk6sm12365970igb.0.2012.08.14.22.26.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 22:26:41 -0700 (PDT) Message-ID: <502B330D.4010705@gmail.com> Date: Tue, 14 Aug 2012 21:26:37 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Michael Hammer References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> <502B2D9E.5020006@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:26:43 -0000 On 8/14/12 9:24 PM, Michael Hammer wrote: > So, are you saying that the password is never passed in the clear? > The earlier messages seem to suggest that it was. > That is what does not seem clear at all here. You really want to do DH over a TLS connection? Melinda From michael.hammer@yaanatech.com Tue Aug 14 22:33:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F8911E80A2 for ; Tue, 14 Aug 2012 22:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3ahc7Hr42rn for ; Tue, 14 Aug 2012 22:33:33 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 22B2311E809C for ; Tue, 14 Aug 2012 22:33:33 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 14 Aug 2012 22:33:33 -0700 From: Michael Hammer To: "melinda.shore@gmail.com" Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNeqaO5ZuPKH39yEqS5B7Zx6vI/ZdaWFPA Date: Wed, 15 Aug 2012 05:33:31 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30D61F886@ex2k10mb2.corp.yaanatech.com> References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> <502B2D9E.5020006@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> <502B330D.4010705@gmail.com> In-Reply-To: <502B330D.4010705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.11] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010C_01CD7A6C.D31C0D20" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:33:33 -0000 ------=_NextPart_000_010C_01CD7A6C.D31C0D20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I dunno, is that TLS connection proxied? I'm just trying to follow the conversation and understand what is the threat, if any first. The premise has not really been stated, so we could be making different assumptions. Mike -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com] Sent: Tuesday, August 14, 2012 10:27 PM To: Michael Hammer Cc: scim@ietf.org Subject: Re: [scim] scim data format and structured credentials delivery/installations On 8/14/12 9:24 PM, Michael Hammer wrote: > So, are you saying that the password is never passed in the clear? > The earlier messages seem to suggest that it was. > That is what does not seem clear at all here. You really want to do DH over a TLS connection? Melinda ------=_NextPart_000_010C_01CD7A6C.D31C0D20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx NTA1MzMyOFowIwYJKoZIhvcNAQkEMRYEFHa1+1S3w+Rw5zD0OiRhgs6iWb9zMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGANmqYp9E+xj9mVxDZOG4rrJBj6BxUbhuBVSei8Bx8O1PA Hvb4xHlYG3OEAPQqm2HMyH/j9sHl2mEntmsYUSkuaFdIdWq9CQl47eoxm5t6rNQs9gP539GD7gG2 69DbmgTvXapocAWtAs4gJEJ3S3Kr8jiLrFKH6sLSChCddnDid5EAAAAAAAA= ------=_NextPart_000_010C_01CD7A6C.D31C0D20-- From melinda.shore@gmail.com Tue Aug 14 22:37:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD78521E8086 for ; Tue, 14 Aug 2012 22:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTdM0oZqT5J7 for ; Tue, 14 Aug 2012 22:37:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2998521E805E for ; Tue, 14 Aug 2012 22:37:43 -0700 (PDT) Received: by yhq56 with SMTP id 56so1504034yhq.31 for ; Tue, 14 Aug 2012 22:37:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RWcmai2U3gnJCweoLOwlYD067PSJH8LagApPKIq9TcI=; b=ONqFIQbWunzUNKdtphRPFLNJRmj/Lvq6Oipo3nJkq6IBK9NcUIy/318SytQecgvVVd 5pBFZAt+tLQlBZuAQCU59uS50UvZW9nDTuFw6w6k4bzptnyNpLL+1LuPtmUnl4hP3i/I RQk31snCUs5e3Fy4dHNj/1K23lXc/8LO85tVTCEzNALzdFv1xa3pMWnNmkdG75qtq6C3 TDTb0jOT7rIwXKT5db32ANGmfSWtln3haN+IBhP7bxG0c1w6QYyXxDo0QvfqvGymVmZZ l9O9TmTk9SOdBCaU1Shdh932vHhNoYsOSbVpqBXpdfAeElFUlWzhQ/sp9i0gHuKsroRv tFMg== Received: by 10.50.95.228 with SMTP id dn4mr16075669igb.25.1345009062244; Tue, 14 Aug 2012 22:37:42 -0700 (PDT) Received: from spandex.local (66-230-82-208-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.208]) by mx.google.com with ESMTPS id dk6sm12402721igb.0.2012.08.14.22.37.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 22:37:41 -0700 (PDT) Message-ID: <502B359E.3030204@gmail.com> Date: Tue, 14 Aug 2012 21:37:34 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Michael Hammer References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> <502B2D9E.5020006@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> <502B330D.4010705@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F886@ex2k10mb2.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB30D61F886@ex2k10mb2.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:37:43 -0000 On 8/14/12 9:33 PM, Michael Hammer wrote: > The premise has not really been stated, so we could be making different > assumptions. I think it has, but I could be all wet. One of the attributes associated with a user account is a password, and it's pretty common to provision that into an ldap directory with an ldif stanza. I think the question here is about generalizing that. Personally, I don't think it's possible because of variation among password schemes, but clearly some other people have something specific in mind. I'm trying to figure out what that is. I would tend to assume that nobody's going to be proxying SCIM clients or servers because of privacy concerns and the sensitivity of the data, but you know what they say about "assume." Melinda From michael.hammer@yaanatech.com Tue Aug 14 22:45:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C497421E80AB for ; Tue, 14 Aug 2012 22:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0AOK4DcunUR for ; Tue, 14 Aug 2012 22:45:15 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA4A21E805E for ; Tue, 14 Aug 2012 22:45:15 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Tue, 14 Aug 2012 22:45:15 -0700 From: Michael Hammer To: "melinda.shore@gmail.com" Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNeqaO5ZuPKH39yEqS5B7Zx6vI/ZdaWFPAgAB33AD//4vjMA== Date: Wed, 15 Aug 2012 05:45:14 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB30D61F8B7@ex2k10mb2.corp.yaanatech.com> References: <1C1A381D-C22E-462D-A258-268316BD957F@oracle.com> <502AD2B0.1080305@alcatel-lucent.com> <00C069FD01E0324C9FFCADF539701DB30D61F75A@ex2k10mb2.corp.yaanatech.com> <502B2D9E.5020006@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F83C@ex2k10mb2.corp.yaanatech.com> <502B330D.4010705@gmail.com> <00C069FD01E0324C9FFCADF539701DB30D61F886@ex2k10mb2.corp.yaanatech.com> <502B359E.3030204@gmail.com> In-Reply-To: <502B359E.3030204@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.11] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0119_01CD7A6E.74EDB8A0" MIME-Version: 1.0 Cc: "scim@ietf.org" Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 05:45:15 -0000 ------=_NextPart_000_0119_01CD7A6E.74EDB8A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Agree with you there. I try not to assume too much. Guess, I'll sit back and see what the use case is here. Mike -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com] Sent: Tuesday, August 14, 2012 10:38 PM To: Michael Hammer Cc: scim@ietf.org Subject: Re: [scim] scim data format and structured credentials delivery/installations On 8/14/12 9:33 PM, Michael Hammer wrote: > The premise has not really been stated, so we could be making > different assumptions. I think it has, but I could be all wet. One of the attributes associated with a user account is a password, and it's pretty common to provision that into an ldap directory with an ldif stanza. I think the question here is about generalizing that. Personally, I don't think it's possible because of variation among password schemes, but clearly some other people have something specific in mind. I'm trying to figure out what that is. I would tend to assume that nobody's going to be proxying SCIM clients or servers because of privacy concerns and the sensitivity of the data, but you know what they say about "assume." Melinda ------=_NextPart_000_0119_01CD7A6E.74EDB8A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgx NTA1NDUwOVowIwYJKoZIhvcNAQkEMRYEFCsanI5uuQSEMhGfopDI9Aycr2weMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAGLSzK9xta5FVTzt/Fao3vvEnidFMNtK+FEvfgz5IxB6E Kc4U+ooFzaR9vUdnyvsGgz3pdQ/C8d5/50UrtOG9IBmzeZtkfIBkjMDRUpOECu3dpZ0spqqYbHi7 Jrduo2ysCI4Jt8h6u9pBWHRhKR4JL7Nt7iXQev2798UKQcBskcgAAAAAAAA= ------=_NextPart_000_0119_01CD7A6E.74EDB8A0-- From prvs=3574116D4D=erik.wahlstrom@nexussafe.com Wed Aug 15 10:36:49 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93DEC21F8627 for ; Wed, 15 Aug 2012 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKFQHEgecjDR for ; Wed, 15 Aug 2012 10:36:49 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD621F8625 for ; Wed, 15 Aug 2012 10:36:47 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 15 Aug 2012 19:36:41 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 15 Aug 2012 19:36:30 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Yutaka OIWA Thread-Topic: [scim] scim data format and structured credentials delivery/installations Thread-Index: AQHNedKsd7/9tCgrA0CZKCQhxPO0A5dbA9SA Date: Wed, 15 Aug 2012 17:36:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.60] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <89457FAE785987419BA6900B9AE0A87A@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: scim Mailing List Subject: Re: [scim] scim data format and structured credentials delivery/installations X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 17:36:49 -0000 This is a deep end of the pool kind of question. The use case of moving pas= swords is a valid one but tricky to standardize due to the fact that it's s= o different every where and the data is so sensitive. That's is also why it= 's just an opaque value in SCIM 1.1. You can just send an clear text or an = agreed on format, SCIM protocol don't care at the moment. We started this s= ame discussion but opted into just making it opaque in first version due to= the complexity of it. I think at least this should be in a future use case document for SCIM. Gre= at if you guys have started working on this, I would love to see that exten= sion (or core change if its solid). / Erik On Aug 14, 2012, at 6:09 AM, Yutaka OIWA wrote: > Dear SCIM people, >=20 > > I am currently proposing a new HTTP authentication protocol for > enabling secure mutual authentication using shared credentials > (including pre-shared keys or passwords). > There are many features beyond conventional authentication methods, > but from the viewpoint of key/credential management (related to scim), > this authentication scheme have two properties concurrently: >=20 > * enables use of encrypted (hashed) passwords on the server side > - somewhat similar to Basic/Form > - contrary to CHAP/Digest (which require passwords-equivalent), > * allows non-plaintext exchange on-wire > - similar to, but much stronger than CHAP/Digest > - contrary to Basic/Form. >=20 > Server-side encrypted passwords are per-server basis, > so any stolen credential cannot be reused by other people, > provided that the client-side credentials have fair amount of entropy > (unlike 1234, password or xhtdj). > >=20 > Under this background, my point asking on this mail is: > we have one missing feature on our protocol design: delivery of encrypted > passwords from clients to servers on the first registration phase. > Currently we have two ways for first-time registration: > * letting servers know the plaintext passwords, and encrypt them on > the server side. > * encrypting the passwords manually on the client side, while carefully > inputing protocol-dependent security parameters that the server gives. > But both of them are unsatisfactory. > We have planned to develop a common format in the next steps > for exchanging such authentication parameters between peers > for single account registrations using Web browsers/Web Forms or other cl= ients. >=20 > Looking beyond our proposal, there are also many key/credential formats > which requires key deliveries from clients to servers on the first > registration, including such as X.509 certificates (either full-certifica= te or > just DN part), unsigned RSA public keys, JWKs, SSH pubkeys, > machine-generated strong secrets, and even unix-hashed passwords. > We now aware that many parts of requirements for such use-cases are > common with what SCIM requires, and we should avoid designing two > similar parts on the same table. > I remember that in Vancouver SCIM session, some people also raised > requirements for deploying such non-plaintext secret within SCIM framewor= k. >=20 > So, I'd like to reuse current data format for SCIM exchange for such purp= oses. > To do that, I plan to propose a generic extension mechanism for putting k= ey > formats other than just plaintext passwords. Such format may be useful = for > other credentials as well, and it can, of course, be used for SCIM-based > account management. > So I think that this extension satisfies some needs for SCIM as well as > other use cases. >=20 > Feedbacks are appreciated. >=20 > --=20 > Yutaka OIWA, Ph.D. Leader, Software Reliability Research Gro= up > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46= B5] > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From g.c.prasad@gmail.com Thu Aug 16 03:38:02 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466D21F8607 for ; Thu, 16 Aug 2012 03:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0WslC+j88s0 for ; Thu, 16 Aug 2012 03:37:58 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E203C21F84D9 for ; Thu, 16 Aug 2012 03:37:54 -0700 (PDT) Received: by bkty7 with SMTP id y7so1034549bkt.31 for ; Thu, 16 Aug 2012 03:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9PDeIoYgydXNieMBiPMkbw+VSF7Lw2gXZKkqsmCkPkE=; b=ePVUzBnYA7Ob7pdhc9WNvo7y9jnRi5oX3SSZgBtYLS/P6BpWm70w8bDsdCY54zvVLy 8W/2GAJCDfD0s730Rtm6SNwnM1PfZMBnlHN8ehzOTyq7SN2sQ+LIyRN0D/Et4FAL7gRQ g7aHQINvLa5OZ9GmwAMEBn74JAlWx8L8eoiDPweSWDeP5r/unDOtbYyeNX/GQ7dPOuzy tCulE44N2elLGcYEJCdVgH6bH+BlxVOSEsi5+CldFUI4C7EC6rUULimIweXgo/GrVf3D IPtWSrneSwYra8VKO1UxnNw+GCfd0gTJRWxAXZMq+AwvBtXl/IHaKMX4n/YpbuNKIliy cTWQ== Received: by 10.204.152.19 with SMTP id e19mr256543bkw.8.1345113473594; Thu, 16 Aug 2012 03:37:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Thu, 16 Aug 2012 03:37:33 -0700 (PDT) In-Reply-To: References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> From: Ganesh and Sashi Prasad Date: Thu, 16 Aug 2012 20:37:33 +1000 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=0015175d0406c6b53904c75fa278 Cc: "scim@ietf.org" , Phil Hunt , Emmanuel Dreux , Melinda Shore , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 10:38:02 -0000 --0015175d0406c6b53904c75fa278 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, Would this hybrid architecture be a workable compromise? See diagram towards the end: http://bit.ly/Rjc39Y Regards, Ganesh On 15 August 2012 05:54, Anthony Nadalin wrote: > We should not be constrained by LDAP restrictions, this would not be > productive.**** > > ** ** > > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf > Of *Ganesh and Sashi Prasad > *Sent:* Monday, August 13, 2012 2:07 PM > *To:* Kelly Grizzle > *Cc:* Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > ** ** > > Thanks, Kelly. You've been most patient in hearing me out, I must say. I > couldn't ask for more.**** > > ** ** > > Replying to Chris Philips's mail:**** > > > Given that you have a number of thoughts about what could be changed in > SCIM,Leif's recommendation to craft them in an Internet Draft may be a > better way to convey your thoughts. > > I'm coming around to the same conclusion. Do you think such an Internet > Draft should be about changing SCIM, or should it propose a complementary > spec for SPs who use a "NoLDAP" data store? I think the underlying proble= m > is with LDAP, and unless we change that, these proposals won't fly.**** > > ** ** > > Regards,**** > > Ganesh**** > > On 14 August 2012 01:54, Kelly Grizzle > wrote:**** > > There are really two implementation options for a uid per element =96 eit= her > store the uids in the native underlying data store or have some secondary > data store that maps elements to their uids. The third option is to hope > that a service provider has a NoLDAP data store or its equivalent. None = of > these are practical for rapid and wide-spread adoption.**** > > **** > > > put the two together to propose a solution.**** > > **** > > As I said before, I am completely on board with cleaning up the PATCH > semantics (eg =96 the inconsistency between meta.attributes and > operation=3Ddelete, etc=85). Your suggestion of using different verbs is= a > good option to consider. This cannot be based on a uid per element, > though. It seems as though you have admitted this in your conclusion =96= =93As > for LDAP and SCIM, I guess the best TLA is RIP.=94**** > > **** > > --Kelly**** > > **** > > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 9:56 AM > *To:* Kelly Grizzle > *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org**** > > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > That was one suggestion. Another way could be container nodes with their > own "dn"s. If one suggestion won't work, tell me another way to make it > work. I'm waiting to hear a constructive suggestion that can square an > elegant API with the implementation constraints that come from having to > store multi-valued attributes in LDAP directories.**** > > **** > > I've heard enough of WHY this won't work. For a change, tell me HOW it ca= n > be made to work. Everyone now knows what the proposal means in terms of t= he > API, and implementors understand the constraints of legacy data stores, s= o > put the two together to propose a solution. C'mon, we have the "smartest > guys in the room" here, surely we should be able to crack this.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > P.S. I'm rapidly reaching my own conclusions about what is to be done:***= * > > > http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-no= ldap.html > **** > > **** > > On 14 August 2012 00:27, Kelly Grizzle > wrote:**** > > > After all, no one has challenged the claim that this proposal > drastically simplifies the API for the client**** > > **** > > I agree that your proposal makes PATCH semantics simpler and more elegant= . > **** > > **** > > **** > > > =85 so it would appear to be worth doing. **** > > **** > > I strongly disagree here. This statements assumes that simplicity of the > client API is the only factor that should be considered with the spec.***= * > > **** > > Emmanuel=92s example is from a real-world service provider that would not= be > able to implement the spec easily with a uid per element. He is working = on > a SCIM interface that will help facilitate data exchange between multiple > Active Directory servers. Your solution was to change the data model fro= m > this:**** > > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > **** > > to this:**** > > **** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > **** > > I do not know of a single organization that would change their Active > Directory data model to fit this. For one thing, it would be a huge data > migration effort (likely across other domain controllers, etc=85) to assi= gn > these unique identifiers. This also assumes that SCIM is the only > reader/writer of this data, which will almost never be the case. If the > data model requires uids for every element, then every piece of non-SCIM > code that writes data into the directory will have to follow this. > Additionally, there are **many** tools and applications (eg =96 address > books) that rely on a certain data model in Active Directory, and this > would cause them to break. IMO this same argument holds true for most > service providers.**** > > **** > > **** > > PATCH is an optional part of the spec. It was primarily introduced to > make modifying resources with large multi-valued lists more efficient. I= t > does not need to solve every problem (eg =96 modifying sub-elements in ne= sted > arrays). Adding uids to every multi-valued element does not strike the > right balance between the needs of the client and the needs of the servic= e > provider.**** > > **** > > --Kelly**** > > **** > > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 1:35 AM > *To:* Phil Hunt; Melinda Shore > *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org**** > > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > Responding to extract of Melinda Shore's mail from digest:**** > > **** > > The issue being raised here isn't endpoint logic, but**** > > network traffic, and I'm pretty sure it's not very helpful to**** > > respond to the observation that your model requires more**** > > messages with a complaint about what you seem to think is a**** > > complex algorithm for attribute processing.**** > > **** > > It depends on how it's implemented. I'm confident we can have the best of > both - simple API with low-overhead implementation. Can we brainstorm HOW > this proposal can be implemented rather than WHY it can't be implemented > (which is mostly what I've been hearing so far)? After all, no one has > challenged the claim that this proposal drastically simplifies the API fo= r > the client, so it would appear to be worth doing. I'm sure there's more > than enough intellectual horsepower in this working group to pull this of= f > if we put our minds to it.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote:**** > > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty.**** > > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now!**** > > **** > > Multi-valued attributes: An attribute value in the PATCH request**** > > body is added to the value collection if the value does not exist**= ** > > and merged if a matching value is present. Values are matched by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute; e.g., addresses, or do not have unique*= *** > > value Sub-Attributes cannot be matched and must instead be deleted*= *** > > then added. Specific values can be removed from a Resource by**** > > adding an "operation" Sub-Attribute with the value "delete" to the*= *** > > attribute in the PATCH request body. As with adding/updating**** > > attribute value collections, the value to delete is determined by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute or that have a non-unique value Sub-**** > > Attribute are matched by comparing all Sub-Attribute values from***= * > > the PATCH request body to the Sub-Attribute values of the**** > > Resource. A delete operation is ignored if the attribute's name***= * > > is in the meta.attributes list. If the requested value to delete**= ** > > does not match a unique value on the Resource the server MAY**** > > return a HTTP 400 error.**** > > **** > > For a spec that is supposed to be about simplicity, the above description > is anything but simple. I know you guys have worked hard on this and I > don't mean to disparage those efforts, but think about how the above > passage would appear to a new reader (i.e., a novice to the spec, not a > technology novice).**** > > **** > > There is something fundamentally broken, and it is this: multi-valued > attributes without a unique identifier per value. If you don't fix that, > you won't get simplicity.**** > > **** > > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl f= amously > commented back > in 2005,**** > > **** > > "Unfortunately, some of the emerging protocols which also intend to > represent and transfer personal identity information have perhaps taken a > step backwards by not even considering these issues, perhaps sweeping the= m > under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt > version", which only postpone finding interoperable solutions to allowing > applications to express the identity entries they want to express."**** > > **** > > SCIM is exactly one of these "emerging protocols" Wahl talks about, and > what I see now strikes me as "sweeping these issues under the rug in the > guise of simplicity". Apologies for the bluntness.**** > > **** > > My take is that SPs are _already_ struggling to manage multi-valued > attributes, and existing mechanisms are clumsy. > They would be grateful for a specification that made operations easier at > the cost of a re-engineered schema. That calls for some thought leadershi= p > from this working group.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 10:13, Phil Hunt wrote:**** > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Phil**** > > > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote:**** > > > Would it have to be stored on the account database of the service > provider?**** > > **** > > Yes.**** > > **** > > > If so, I believe that this is impracticable in the core schema. Indeed > it implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > **** > > Why? That doesn't necessarily follow. Implementation is independent of > representation. We're talking about a change in representation to make th= e > API cleaner.**** > > **** > > As a simple example, if an LDAP node is being used to hold a list of > comma-separated email addresses, it can just as easily store > comma-separated name-value pairs.**** > > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > can be changed to**** > > **** > > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > > **** > > That's why I asked if there was an SP representative on this working grou= p > who could explain what such a change could mean for them. As of now, it > looks like other people are presuming that SPs will not be able to > implement these changes easily and are rejecting them for that reason.***= * > > **** > > Regards,**** > > Ganesh**** > > **** > > On 13 August 2012 04:29, Emmanuel Dreux wrote:**** > > =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > Where would 3cbaaff8e84e come from? Would it have to be stored on the > account database of the service provider?**** > > **** > > If so, I believe that this is impracticable in the core schema. Indeed it > implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > > This would be a show stopper. SCIM must be transparent, and must be able > to be put on top of an existing system to provide provisioning apis.**** > > **** > > Said differently, SCIM must not be intrusive for existing systems and mus= t > not require modifications to allow its integration.**** > > Correct me if I misunderstood your suggestion.**** > > **** > > --**** > > Regards,**** > > Emmanuel Dreux**** > > http://www.cloudiway.com**** > > Tel: +33 4 26 78 17 58**** > > Mobile: +33 6 47 81 26 70**** > > skype: Emmanuel.Dreux**** > > **** > > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org; Phil Hunt > *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** > > **** > > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. **** > > **** > > That's exactly the point. How do we "specify completely for uniqueness"?*= * > ** > > **** > > In the example below, how are you proposing that the following element be > updated if we can't use positional indexes?**** > > **** > > addresses[1].street-number =3D "243"**** > > **** > > User object:**** > > **** > > {**** > > ...**** > > addresses: [**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > ]**** > > }**** > > **** > > It's impractical to use the value because it's the whole dictionary > element:**** > > **** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > **** > > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element:**** > > **** > > addresses.3cbaaff8e84e.street-number =3D "243"**** > > **** > > {**** > > ...**** > > addresses: {**** > > "d6ea365462f5" :**** > > {**** > > "type" : "home",**** > > "street-number" : "35",**** > > "street-name" : "High Road",**** > > "suburb" : "East Camden",**** > > "postcode" : "5346",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > },**** > > "3cbaaff8e84e" :**** > > {**** > > "type" : "office",**** > > "street-number" : "213",**** > > "street-name" : "Main Street",**** > > "suburb" : "Adelaide",**** > > "postcode" : "5000",**** > > "state" : "SA",**** > > "country" : "Australia"**** > > }**** > > }**** > > }**** > > **** > > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written.**** > > **** > > There's a lot of talk about the "burden" on the SPs, but I believe this i= s > overblown. Is there any SP representative in this WG who can tell us what > this proposal will actually entail for them?**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 12 August 2012 11:53, Kelly Grizzle > wrote:**** > > Ganesh,**** > > **** > > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t > have a value sub-attribute can be removed by specifying only the value > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption.**** > > **** > > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort.**** > > **** > > I'm curious if anyone else in the WG is in favor of unique identifiers fo= r > every multi-valued element.**** > > **** > > --Kelly**** > > **** > ------------------------------ > > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > > Phil, **** > > **** > > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > **** > > **** > > Regards,**** > > Ganesh**** > > On 12 August 2012 01:12, Phil Hunt wrote:**** > > Ganesh, **** > > **** > > Here's the sample that concerned me...**** > > The two operations differ significantly, and it's not very intuitive. **= * > * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } **** > > **** > > **** > > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys.**** > > **** > > Given that multi-values must be each unique, I don't see the point of the > extra indexing to support this. Just use the value as the item you wish t= o > delete.**** > > **** > > I agree, the delete value operation could be more explicit and clear in > general.**** > > **** > > Phil**** > > **** > > @independentid**** > > www.independentid.com**** > > phil.hunt@oracle.com**** > > **** > > **** > > **** > > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** > > **** > > > For the multi-value example you gave you used the value as the > attribute name key. **** > > **** > > Now I'm confused :-). I don't believe any of my examples ever used a valu= e > as the key.**** > > **** > > Could you please show me which example you mean, and which parts of it yo= u > believe to be the value?**** > > **** > > Regards,**** > > Ganesh **** > > On 11 August 2012 13:59, Phil Hunt wrote:**** > > > For the multi-value example you gave you used the value as the attribute > name key. **** > > **** > > That means a lot more complex indexing structure. Better to just say > delete a specific value. **** > > **** > > The spec already allows multiple values to have tags like home, work, etc= . > **** > > **** > > Phil**** > > > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote:**** > > > In your example you are conflating value with an attribute id. > > I don't believe so. **** > > **** > > I'm adopting a model where every attribute of the resource is a key-value > pair. The key is a name or ID.**** > > **** > > For non-repeating attributes (both simple and composite), the key is the > attribute name itself. **** > > **** > > Simple attribute:**** > > **** > > Key: "dob"**** > > Value: "01 Jan 1970"**** > > **** > > For composite attributes, the key employs dot notation to specify the > fully-qualified attribute name, e.g., "address.postcode".**** > > **** > > Composite attribute:**** > > **** > > Key: "address.street-number"**** > > Value: "10"**** > > **** > > Key: "address.suburb"**** > > Value: "East Camden"**** > > **** > > For repeating (multi-valued) attributes, I'm suggesting that there be new > keys for each individual value, otherwise they are impossible to > distinguish, and a positional index is inadequate. So we convert the arra= y > into a dictionary and this then becomes a composite attribute using dot > notation for the key.**** > > **** > > Multi-valued attribute:**** > > **** > > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** > > Value: "john_smith@yahoo.com"**** > > **** > > So this allows us to apply uniform treatment to any arbitrarily deep > resource structure. We can refer to every leaf value with a key that is t= he > fully-qualified name using dot notation.**** > > **** > > The verbs are just unambiguous operations on these (now) explicitly > addressable attributes.**** > > **** > > INCLUDE to a collection and specify only the value. The key is generated > and returned. The fully-qualified key is > . and the value is what was specifie= d > in the INCLUDE.**** > > **** > > REPLACE a fully-qualified key with a new value. If the key doesn't exist, > return a "404 Not Found".**** > > **** > > PLACE a value at the logical location implied by the fully-qualified key. > If there is already a key with that name, return a "409 Conflict".**** > > **** > > FORCE the fully-qualified key to hold the given value, regardless of > whether it existed before or not. Only errors possible are "400 Bad > Request" and "500 Internal Error".**** > > **** > > RETIRE an attribute or a collection given its fully-qualified key. The > implementation will determine whether the attribute will disappear entire= ly > or will exist holding a null value (the blank string "" or the empty obje= ct > {} ).**** > > **** > > I'll explain in a separate post why we need operation verbs like these > that are independent of the HTTP verbs.**** > > **** > > Regards,**** > > Ganesh**** > > **** > > On 11 August 2012 10:38, wrote:**** > > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) > > > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux < > edreux@cloudiway.com>, Trey Drake , Kelly > Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** > > Ganesh,**** > > **** > > In your example you are conflating value with an attribute id. I find tha= t > confusing. **** > > **** > > I agree though that operations in patch could be a lot more explicit. ***= * > > **** > > Eg explicitly deleting a value by saying delete or retire. **** > > > Phil**** > > > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote:**** > > > I am concerned about your second suggestion: **** > > **** > > Let's discuss that now.**** > > **** > > The trade-offs are very clear here.**** > > **** > > Pros:**** > > **** > > Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t > and intuitive when every individual attribute value gets its own ID.**** > > **** > > Here's how to delete a single member from a Group, as per the current spe= c: > **** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "members": [**** > > {**** > > "display": "Babs Jensen",**** > > "value": "2819c223-7f76-453a-919d-413861904646"**** > > "operation": "delete"**** > > }**** > > ]**** > > }**** > > > Here's how to delete ALL members from a group according to the current > spec:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** > > Host: example.com**** > > Accept: application/json**** > > Authorization: Bearer h480djs93hd8**** > > ETag: W/"a330bc54f0671c9"**** > > **** > > {**** > > "schemas": ["urn:scim:schemas:core:1.0"],**** > > "meta": {**** > > "attributes": [**** > > "members"**** > > ]**** > > }**** > > }**** > > > The two operations differ significantly, and it's not very intuitive. ***= * > > With my suggestion, here's how to delete a single member from a group:***= * > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > > }**** > > }**** > > ] } > Here's how I suggest deleting ALL members from a group:**** > > **** > > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.comAccep= t: application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > > "operations" : [**** > > {**** > > "RETIRE" : {**** > > "key" : "members"**** > > }**** > > }**** > > ] } **** > > > I'm sure you'll agree that this is simpler, more consistent and more > intuitive to a reader.**** > > **** > > Pro 2: We can apply this mechanism consistently to three areas:**** > > (a) Manipulating multi-valued attributes of a resource**** > > (b) Manipulating members of a group**** > > (c) Performing bulk operations, where we simply use HTTP verbs instead of > the specialised (and semantically less ambiguous) verbs I suggested for > attributes, the "key" becomes the URI, and the "value" becomes the > corresponding JSON object.**** > > **** > > All of them return "207 Multi-Status" with the "results" array holding > individual status codes.**** > > **** > > In the current spec, (a) and (b) are done similarly but (c) is very > different.**** > > **** > > Pro 3: Adoption of the standard by clients is likely to be higher because > it's simpler for them.**** > > **** > > Pro 4: New (not incumbent) cloud providers will probably find this easier > to implement because they have no legacy. They will probably use some for= m > of NoSQL database and won't be constrained by the limitations of LDAP > directories.**** > > **** > > Cons:**** > > **** > > Con 1: Incumbent cloud providers with existing data stores in a directory > format (where multi-valued attributes are stored as comma-separated value= s > under a single attribute node) will find it difficult to migrate to this > model and store each attribute value as a sub-node with its own key. This > will "hinder adoption of the spec", which is what you fear.**** > > **** > > Have I summed up the Pros and Cons correctly? I'm biased of course, so I > could have missed a Con or hyped a Pro :-).**** > > **** > > In other words, we're debating interface complexity (current spec) versus > implementation complexity (my suggestion). Both can hinder adoption of th= e > spec by different parties.**** > > **** > > Here's what we need to discuss - Do the Pros make the suggestio**** > > **** > > **** > > **** > > ** ** > --0015175d0406c6b53904c75fa278 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all,

Would this hybrid architecture be a workable com= promise? See diagram towards the end: http= ://bit.ly/Rjc39Y

Regards,
Ganesh

On 15 August 2012 05:54, Anthony Nadalin <tonynad@microsoft.com> wrote:

We should not be constrai= ned by LDAP restrictions, this would not be productive.

=A0<= /p>

From: scim-bounces@ietf.org [mailto:scim-= bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Monday, August 13, 2012 2:07 PM
To: Kelly Grizzle
Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt


Subject: Re: [scim] scim Digest, Vol 8, Issue 24
=

=A0

Thanks, Kelly. You've been most patient in heari= ng me out, I must say. I couldn't ask for more.

=A0

Replying to Chris Philips's mail:<= /p>

>=A0G= iven that you have a number of thoughts about what could be changed in SCIM= ,Leif's recommendation to =A0craft them in an Internet Draft may be a better way to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an Internet= Draft should be about changing SCIM, or should it propose a complementary = spec for SPs who use a "NoLDAP" data store? I think the underlyin= g problem is with LDAP, and unless we change that, these proposals won't fly.

=A0

Regards,

Ganesh<= /p>

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

There are really two impl= ementation options for a uid per element =96 either store the uids in the native underlying data store or have some secondary data store that maps e= lements to their uids.=A0 The third option is to hope that a service provid= er has a NoLDAP data store or its equivalent.=A0 None of these are practica= l for rapid and wide-spread adoption.

=A0<= /p>

> put the two together to propose a solution.

=A0<= /p>

As I said before, I am co= mpletely on board with cleaning up the PATCH semantics (eg =96 the inconsis= tency between meta.attributes and operation=3Ddelete, etc=85).=A0 Your suggestio= n of using different verbs is a good option to consider.=A0 This cannot be = based on a uid per element, though.=A0 It seems as though you have admitted= this in your conclusion =96 =93As for LDAP and SCIM, I guess the best TLA is RIP.=94

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

That was one suggestion. Another way could be contai= ner nodes with their own "dn"s. If one suggestion won't work,= tell me another way to make it work. I'm waiting to hear a constructiv= e suggestion that can square an elegant API with the implementation constrai= nts that come from having to store multi-valued attributes in LDAP director= ies.

=A0

I've heard enough of WHY this won't work. Fo= r a change, tell me HOW it can be made to work. Everyone now knows what the= proposal means in terms of the API, and implementors understand the constraints of legacy data stores, so put the two together to propose = a solution. C'mon, we have the "smartest guys in the room" he= re, surely we should be able to crack this.

=A0

Regards,

Ganesh

=A0

P.S. I'm rapidly reaching my own conclusions abo= ut what is to be done:

=A0

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

> After all, no one has challenged the claim that= this proposal drastically simplifies the API for the client<= /p>

=A0<= /p>

I agree that your proposa= l makes PATCH semantics simpler and more elegant.

=A0<= /p>

=A0<= /p>

> =85 so it would appear to be worth doing.=A0

=A0<= /p>

I strongly disagree here.= =A0 This statements assumes that simplicity of the client API is the only factor that should be considered with the spec.

=A0<= /p>

Emmanuel=92s example is f= rom a real-world service provider that would not be able to implement the spec easily with a uid per element.=A0 He is working on a SCIM interface t= hat will help facilitate data exchange between multiple Active Directory se= rvers.=A0 Your solution was to change the data model from this:

=A0<= /p> 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

=A0<= /p>

to this:=

=A0<= /p>

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0<= /p>

I do not know of a single= organization that would change their Active Directory data model to fit this.=A0 For one thing, it would be a huge data migration effort (likely a= cross other domain controllers, etc=85) to assign these unique identifiers.= =A0 This also assumes that SCIM is the only reader/writer of this data, whi= ch will almost never be the case.=A0 If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this.=A0 Ad= ditionally, there are *many* tools and applications =A0(eg =96 addre= ss books) that rely on a certain data model in Active Directory, and this would cause them to break.=A0 IMO this= same argument holds true for most service providers.<= /p>

=A0<= /p>

=A0<= /p>

PATCH is an optional part= of the spec. =A0It was primarily introduced to make modifying resources wi= th large multi-valued lists more efficient.=A0 It does not need to solve ever= y problem (eg =96 modifying sub-elements in nested arrays).=A0 Adding uids = to every multi-valued element does not strike the right balance between the= needs of the client and the needs of the service provider.

=A0<= /p>

--Kelly<= /u>

=A0<= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

Responding to extract of Melinda Shore's mail fr= om digest:

=A0

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to<=
u>
respond to the observation that your model requires more=

messages with a complaint about what you seem to think is a<=
/u>
complex algorithm for attribute processing.

=A0

It depends on how it's implemented. I'm conf= ident we can have the best of both - simple API with low-overhead implement= ation. Can we brainstorm HOW this proposal can be implemented rather than WHY it can't be implemented (which is mostly what I've= been hearing so far)? After all, no one has challenged the claim that this= proposal drastically simplifies the API for the client, so it would appear= to be worth doing.=A0I'm sure there's more than enough intellectual horsepower in this working group to pull this off= if we put our minds to it.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 13:54, Ganesh and Sashi Prasad <= ;g.c.prasad@gmail= .com> wrote:

>=A0I strongly obj= ect to anything that leads to a read before modify requirement. Too complex= and too chatty.

Sorry Phil, but you're contradicting yourself he= re.=A0There seems to be an awful lot of matching (i.e., reading) going on i= n the spec as it stands, with if-then clauses to do one thing or another if the match either succeeds or fails. This is a complex,= chatty protocol right now!

=A0

=A0=A0 Multi-valued attributes:=A0 An=
 attribute value in the PATCH request
=A0=A0=A0=A0=A0 body is added to the =
value collection if the value does not exist
=A0=A0=A0=A0=A0 and merged if a match=
ing value is present.=A0 Values are matched by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute; e.g., addresses, or do not have unique
=A0=A0=A0=A0=A0 value Sub-Attributes =
cannot be matched and must instead be deleted
=A0=A0=A0=A0=A0 then added.=A0 Specif=
ic values can be removed from a Resource by
=A0=A0=A0=A0=A0 adding an "opera=
tion" Sub-Attribute with the value "delete" to the=

=A0=A0=A0=A0=A0 attribute in the PATC=
H request body.=A0 As with adding/updating
=A0=A0=A0=A0=A0 attribute value colle=
ctions, the value to delete is determined by
=A0=A0=A0=A0=A0 comparing the value S=
ub-Attribute from the PATCH request body to
=A0=A0=A0=A0=A0 the value Sub-Attribu=
te of the Resource.=A0 Attributes that do not
=A0=A0=A0=A0=A0 have a value Sub-Attr=
ibute or that have a non-unique value Sub-
=A0=A0=A0=A0=A0 Attribute are matched=
 by comparing all Sub-Attribute values from
=A0=A0=A0=A0=A0 the PATCH request bod=
y to the Sub-Attribute values of the
=A0=A0=A0=A0=A0 Resource.=A0 A delete=
 operation is ignored if the attribute's name

=A0=A0=A0=A0=A0 is in the meta.attrib=
utes list.=A0 If the requested value to delete


=A0=A0=A0=A0=A0 does not match a uniq=
ue value on the Resource the server MAY


=A0=A0=A0=A0=A0 return a HTTP 400 err=
or.

=A0

For a spec that is supposed to be about simplicity, = the above description is anything but simple. I know you guys have worked h= ard on this and I don't mean to disparage those efforts, but think about how the above passage would appear to a new reader (i.e., = a novice to the spec, not a technology novice).

=A0

There is something fundamentally broken, and it is t= his: multi-valued attributes without a unique identifier per value. If you = don't fix that, you won't get simplicity.

=A0

We know LDAP trees are broken for multi-valued attri= butes. As Mark Wahl famously commented back in 2005,

=A0

"Unfortunately, some of the emergi= ng protocols which also intend to represent and transfer personal identity = information have perhaps taken a step backwards by not even considering these issues, = perhaps sweeping them under the rug in the guise of simplicity, XMLificatio= n, or "fix in the next version", which only postpone finding inte= roperable solutions to allowing applications to express the identity entries they want to express."<= u>

=A0

SCIM is exactly one of these "emerging protocol= s" Wahl talks about, and what I see now strikes me as "sweeping t= hese issues under the rug in the guise of simplicity". Apologies for the bluntness.

=A0

My take is that SPs are _already_ struggling to mana= ge multi-valued attributes, and existing mechanisms are clumsy. They would be grateful for a specificat= ion that made operations easier at the cost of a re-engineered schema. That= calls for some thought leadership from this working group.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> w= rote:

I strongly object to anything that leads to a read b= efore modify requirement. Too complex and too chatty.=A0

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

> Would it have to = be stored on the account database of the service provider?=

=A0

Yes.<= /u>

=A0

> If so, I believe = that this is impracticable in the core schema.=A0Indeed it implies that a s= ervice provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

=A0

Why? That doesn't necessarily follow. Implementa= tion is independent of representation. We're talking about a change in = representation to make the API cleaner.

=A0

As a simple example, if an LDAP node is being used t= o hold a list of comma-separated email addresses, it can just as easily sto= re comma-separated name-value pairs.

=A0

=A0

mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.co= m,=A07a6d1de664e1=3Djsmith1970@hotmail.com

=A0

That's why I asked if there was an SP representative o= n this working group who could explain what such a change could mean for th= em. As of now, it looks like other people are presuming that SPs will not be a= ble to implement these changes easily and are rejecting them for that reaso= n.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com= > wrote:

=F0=A0 addresses.3cbaaff8e84e.street-number =3D "243"

=A0<= /p>

Where would 3cbaaff8e84e come from? Would it have to be stored on the account database of th= e service provider?

=A0

If so, I believe that = this is impracticable in the core schema. Indeed it implies that a service = provider must extend the schema of his account repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This would be a show s= topper. SCIM must be transparent, and must be able to be put on top of an e= xisting system to provide provisioning apis.

=A0

Said differently, SCIM= must not be intrusive for existing systems and must not require modificati= ons to allow its integration.

Correct me if I misund= erstood your suggestion.

=A0

--

Regards,=

Emmanuel Dreu= x

http://www.cloudiway.com

Tel: +33 4 26 78= 17 58

Mobile: +33 6 47 81= 26 70

skype: Emmanu= el.Dreux

=A0=

De=A0: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that d= on't have a value sub-attribute (eg - address) have to specified comple= tely for uniqueness.=A0=A0

=A0

That's exactly the point. How = do we "specify completely for uniqueness"?

=A0

In the example below, how are you = proposing that the following element be updated if we can't use positio= nal indexes?

=A0

addresses[1].street-number =3D &qu= ot;243"

=A0

User object:<= /p>

=A0

{

=A0 ...

=A0 addresses: [<= /u>

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the va= lue because it's the whole dictionary element:

=A0

{

=A0 "type" : "offic= e",

=A0 "street-number" : &q= uot;213",

=A0 "street-name" : &quo= t;Main Street",

=A0 "suburb" : "Ade= laide",

=A0 "postcode" : "5= 000",

=A0 "state" : "SA&q= uot;,

=A0 "country" : "Au= stralia"

}

=A0

With my proposal, the "addres= ses" array gets converted to a dictionary, and then we have a stable w= ay of referencing this element:

=A0

addresses.3cbaaff8e84e.street-numb= er =3D "243"

=A0

{

=A0 ...

=A0 addresses: {<= /u>

=A0 =A0 "d6ea365462f5" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;home",

=A0 =A0 =A0 "street-number&qu= ot; : "35",

=A0 =A0 =A0 "street-name"= ; : "High Road",

=A0 =A0 =A0 "suburb" : &= quot;East Camden",

=A0 =A0 =A0 "postcode" := "5346",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :=

=A0 =A0 {

=A0 =A0 =A0 "type" : &qu= ot;office",

=A0 =A0 =A0 "street-number&qu= ot; : "213",

=A0 =A0 =A0 "street-name"= ; : "Main Street",

=A0 =A0 =A0 "suburb" : &= quot;Adelaide",

=A0 =A0 =A0 "postcode" := "5000",

=A0 =A0 =A0 "state" : &q= uot;SA",

=A0 =A0 =A0 "country" : = "Australia"

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechan= ism for composite attributes and another mechanism for simple attributes, I= would suggest that's actually more complex than adopting a single mechanism that works the same way for _all_ attributes. Remember = that a lot of the administration is probably going to be scripted rather th= an done by hand, and having two mechanisms (depending on whether the attrib= ute is simple or composite) will complicate every script that has to be written.

=A0

There's a lot of talk about th= e "burden" on the SPs, but I believe this is overblown. Is there = any SP representative in this WG who can tell us what this proposal will actually entail for them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Gri= zzle <k= elly.grizzle@sailpoint.com> wrote:

Ganesh,=

=A0

This is exactly how PATCH wo= rks in SCIM 1.0. =A0Multi-valued attributes that have a value sub-attribute can be removed by specifying only the value since it is unique. =A0Multi-v= alued attributes that don't have a value sub-attribute (eg - address) h= ave to specified completely for uniqueness. =A0As I have said before, I am = very opposed to adding a unique identifier to each element in a multi-valued collection due to the burden it will put= on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in general= PATCH can be made more intuitive without adding uids to each element. =A0T= he verbs that you propose make sense. =A0There is also a JSON Patch informati= onal draft in the IETF that is interesting -=A0http://tools.= ietf.org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Pointer draft which uses index-based addressing for= multi-valued attributes. =A0I think that this is something that should be = looked at within the WG and I would be willing to lead this effort.<= u>

=A0

I'm curious if anyone el= se in the WG is in favor of unique identifiers for every multi-valued eleme= nt.

=A0

--Kelly=

=A0

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value= itself to identify an element is that this method will only work for simpl= e elements, not for nested structures. i.e., if we had an array of dictionaries (e.g., we had to record an array of addresses for= each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creating a unique key for each eleme= nt scales better.

=A0

Regards,

Gan= esh

On 12 August 2012 01:12, Phil Hunt= <phil.hunt@or= acle.com> wrote:

Ganesh,

=A0

Here's the sample that concern= ed me...

The two operations differ signific= antly, and it's not very intuitive.=A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute with an= identifier that matched that value or of identifiers that were additional unique keys.

=A0

Given that multi-values must be each unique, I = don't see the point of the extra indexing to support this. Just use the value as the item you wish to delete.

=A0

I agree, the delete value operation could be mo= re explicit and clear in general.

=A0

Phil<= /p>

=A0

@independentid

phil.hunt@o= racle.com

=A0<= /p>

=A0=

=A0

On 2012-08-11, at 2:30 AM, Ganesh = and Sashi Prasad wrote:

=A0=

>=A0 For the multi-value exampl= e you gave you used the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don= 9;t believe any of my examples ever used a value as the key.<= u>

=A0

Could you please show me which exa= mple you mean, and which parts of it you believe to be the value?=

=A0

Regards,

Gan= esh=A0

On 11 August 2012 13:59, Phil Hunt= <phil.hunt@or= acle.com> wrote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex inde= xing structure. Better to just say delete a specific value.=A0

=A0

The spec already allows multiple v= alues to have tags like home, work, etc.

=A0=

Phil

On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

>=A0In your example you are con= flating value with an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where eve= ry attribute of the resource is a key-value pair. The key is a name or ID.<= /span>

=A0

For non-repeating attributes (both= simple and composite), the key is the attribute name itself.=A0<= /u>

=A0

Simple attribute:=

=A0

Key: "dob"=

Value: "01 Jan 1970"

=A0

For composite attributes, the key = employs dot notation to specify the fully-qualified attribute name, e.g., &= quot;address.postcode".

=A0

Composite attribute:=

=A0

Key: "address.street-number&q= uot;

Value: "10"

=A0

Key: "address.suburb"

Value: "East Camden"

=A0

For repeating (multi-valued) attri= butes, I'm suggesting that there be new keys for each individual value,= otherwise they are impossible to distinguish, and a positional index is inadequate. So we convert the array into a dictionary and this th= en becomes a composite attribute using dot notation for the key.<= /u>

=A0

Multi-valued attribute:<= /u>

=A0

Key: "emails.7dfcb444-74d8-4f= 17-aa66-daf9ea3bd902"

Value: "john_smith@yahoo.com"<= u>

=A0

So this allows us to apply uniform= treatment to any arbitrarily deep resource structure. We can refer to ever= y leaf value with a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous ope= rations on these (now) explicitly addressable attributes.<= /u>

=A0

INCLUDE to a collection and specif= y only the value. The key is generated and returned. The fully-qualified ke= y is <collection-name>.<newly-generated-ID> and the value is what was specified in the INCLUDE.

=A0

REPLACE a fully-qualified key with= a new value. If the key doesn't exist, return a "404 Not Found&qu= ot;.

=A0

PLACE a value at the logical locat= ion implied by the fully-qualified key. If there is already a key with that= name, return a "409 Conflict".

=A0

FORCE the fully-qualified key to h= old the given value, regardless of whether it existed before or not. Only e= rrors possible are "400 Bad Request" and "500 Internal Error".

=A0

RETIRE an attribute or a collectio= n given its fully-qualified key. The implementation will determine whether = the attribute will disappear entirely or will exist holding a null value (the blank string "" or the empty object {}= ).

=A0

I'll explain in a separate pos= t why we need operation verbs like these that are independent of the HTTP v= erbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org= > wrote:

If you have received this digest w= ithout all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating= value with an attribute id. I find that confusing.=A0=

=A0

I agree though that operations in = patch could be a lot more explicit.=A0

=A0

Eg explicitly deleting a value by = saying delete or retire.=A0


Phil

On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=A0>=A0=A0I am concerned about your second suggestion:=A0

=A0

Let's discuss that now.=

=A0

The trade-offs are very clear here= .

=A0

Pros:

=A0

Pro 1. The API to manipulate resou= rces becomes so much cleaner, consistent and intuitive when every individua= l attribute value gets its own ID.

=A0

Here's how to delete a single = member from a Group, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "member=
s": [


=A0=A0=A0=A0=A0=A0 {


=A0=A0=A0=A0=A0=A0=A0=A0 =
"display": "Babs Jensen",


=A0=A0=A0=A0=A0=A0=A0=A0 =
"value": "2819c223-7f76-453a-919d-413861904646"<=
u>


=A0=A0=A0=A0=A0=A0=A0=A0 =
"operation": "delete"


=A0=A0=A0=A0=A0=A0 }


=A0=A0=A0=A0 ]<=
/u>


=A0=A0 }=





Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf=
3ae7-8463-4692-b4fd-9b4da3f908ce
=A0=A0 Host: example.com<=
/pre>

=A0=A0 Accept: applicatio=
n/json


=A0=A0 Authorization: Bea=
rer h480djs93hd8


=A0=A0 ETag: W/"a330=
bc54f0671c9"


=A0<=
/pre>

=A0=A0 {=



=A0=A0=A0=A0 "schema=
s": ["urn:scim:schemas:core:1.0"],

=A0=A0=A0=A0 "meta&q=
uot;: {


=A0=A0=A0=A0=A0=A0 "=
attributes": [


=A0=A0=A0=A0=A0=A0=A0=A0 =
"members"


=A0=A0=A0=A0=A0=A0 ]


=A0=A0=A0=A0 }<=
/u>


=A0=A0 }=





The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here's how= to delete a single member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members.2819c223-7f76-4= 53a-919d-413861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f90= 8ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [=

{

"RETIRE" : {

"key" : "members"=

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism= consistently to three areas:

(a) Manipulating multi-valued attr= ibutes of a resource

(b) Manipulating members of a grou= p

(c) Performing bulk operations, wh= ere we simply use HTTP verbs instead of the specialised (and semantically l= ess ambiguous) verbs I suggested for attributes, the "key" becomes the URI, and the "value" becomes the cor= responding JSON object.

=A0

All of them return "207 Multi= -Status" with the "results" array holding individual status = codes.

=A0

In the current spec, (a) and (b) a= re done similarly but (c) is very different.

=A0

Pro 3: Adoption of the standard by= clients is likely to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud p= roviders will probably find this easier to implement because they have no l= egacy. They will probably use some form of NoSQL database and won't be constrained by the limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers w= ith existing data stores in a directory format (where multi-valued attribut= es are stored as comma-separated values under a single attribute node) will find it difficult to migrate to this model and store = each attribute value as a sub-node with its own key. This will "hinder= adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons= correctly? I'm biased of course, so I could have missed a Con or hyped= a Pro :-).

=A0

In other words, we're debating= interface complexity (current spec) versus implementation complexity (my s= uggestion). Both can hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss= - Do the Pros make the suggestio

=A0

=A0

=A0

=A0


--0015175d0406c6b53904c75fa278-- From jara@um.es Thu Aug 16 04:19:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB51421F8594 for ; Thu, 16 Aug 2012 04:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_81=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXCD2XSJ5Zni for ; Thu, 16 Aug 2012 04:19:11 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0557421F84BF for ; Thu, 16 Aug 2012 04:19:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 630644BD08; Thu, 16 Aug 2012 13:19:09 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KiJ2A2hPzc-S; Thu, 16 Aug 2012 13:19:08 +0200 (CEST) Received: from localhost (ursus16.um.es [155.54.212.240]) by xenon12.um.es (Postfix) with ESMTP id 7DE9F4BC7E; Thu, 16 Aug 2012 13:19:06 +0200 (CEST) Received: from ndc-wsg-3.utc.com (ndc-wsg-3.utc.com [192.249.47.176]) by webmail.atica.um.es (Horde Framework) with HTTP; Thu, 16 Aug 2012 13:19:06 +0200 Message-ID: <20120816131906.388719k7bsruirsa@webmail.atica.um.es> Date: Thu, 16 Aug 2012 13:19:06 +0200 From: Antonio Jara To: Ganesh and Sashi Prasad References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.2) Cc: Anthony Nadalin , Melinda Shore , Emmanuel Dreux , "scim@ietf.org" , Kelly Grizzle , Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 11:19:13 -0000 Hi, I think that this is too complex, the idea of splitting the =20 architecture into two directories, one for user provisioning with your =20 idea of nested dictionaries instead of arrays to avoid the complexity =20 during provisioning, and the second one the usual LDAP for =20 Authentication/Authorization attributes to be compliant with the =20 current deployments. Assuming that the requirement is coming for the provisioning phase, =20 Why not to define your design issues about the use of nested =20 dictionaries to support attributes with multiple values in the entries =20 from LDAP which needs to be used for the provisioning, and it is all. =20 People interested in using them, will reach a simple solution to =20 manage attributes with multiple values, other ones will require =20 "fight" with a more complex process. Regards Quoting Ganesh and Sashi Prasad : > Hi all, > > Would this hybrid architecture be a workable compromise? See diagram > towards the end: http://bit.ly/Rjc39Y > > Regards, > Ganesh > > On 15 August 2012 05:54, Anthony Nadalin wrote: > >> We should not be constrained by LDAP restrictions, this would not be >> productive.**** >> >> ** ** >> >> *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf >> Of *Ganesh and Sashi Prasad >> *Sent:* Monday, August 13, 2012 2:07 PM >> *To:* Kelly Grizzle >> *Cc:* Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> ** ** >> >> Thanks, Kelly. You've been most patient in hearing me out, I must say. I >> couldn't ask for more.**** >> >> ** ** >> >> Replying to Chris Philips's mail:**** >> >> > Given that you have a number of thoughts about what could be changed in >> SCIM,Leif's recommendation to craft them in an Internet Draft may be a >> better way to convey your thoughts. >> >> I'm coming around to the same conclusion. Do you think such an Internet >> Draft should be about changing SCIM, or should it propose a complementary >> spec for SPs who use a "NoLDAP" data store? I think the underlying proble= m >> is with LDAP, and unless we change that, these proposals won't fly.**** >> >> ** ** >> >> Regards,**** >> >> Ganesh**** >> >> On 14 August 2012 01:54, Kelly Grizzle >> wrote:**** >> >> There are really two implementation options for a uid per element ? eithe= r >> store the uids in the native underlying data store or have some secondary >> data store that maps elements to their uids. The third option is to hope >> that a service provider has a NoLDAP data store or its equivalent. None = of >> these are practical for rapid and wide-spread adoption.**** >> >> **** >> >> > put the two together to propose a solution.**** >> >> **** >> >> As I said before, I am completely on board with cleaning up the PATCH >> semantics (eg ? the inconsistency between meta.attributes and >> operation=3Ddelete, etc?). Your suggestion of using different verbs is a >> good option to consider. This cannot be based on a uid per element, >> though. It seems as though you have admitted this in your conclusion ? ?= As >> for LDAP and SCIM, I guess the best TLA is RIP.?**** >> >> **** >> >> --Kelly**** >> >> **** >> >> *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Sent:* Monday, August 13, 2012 9:56 AM >> *To:* Kelly Grizzle >> *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org**** >> >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> **** >> >> That was one suggestion. Another way could be container nodes with their >> own "dn"s. If one suggestion won't work, tell me another way to make it >> work. I'm waiting to hear a constructive suggestion that can square an >> elegant API with the implementation constraints that come from having to >> store multi-valued attributes in LDAP directories.**** >> >> **** >> >> I've heard enough of WHY this won't work. For a change, tell me HOW it ca= n >> be made to work. Everyone now knows what the proposal means in terms of t= he >> API, and implementors understand the constraints of legacy data stores, s= o >> put the two together to propose a solution. C'mon, we have the "smartest >> guys in the room" here, surely we should be able to crack this.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> P.S. I'm rapidly reaching my own conclusions about what is to be done:***= * >> >> >> http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-no= ldap.html >> **** >> >> **** >> >> On 14 August 2012 00:27, Kelly Grizzle >> wrote:**** >> >> > After all, no one has challenged the claim that this proposal >> drastically simplifies the API for the client**** >> >> **** >> >> I agree that your proposal makes PATCH semantics simpler and more elegant= . >> **** >> >> **** >> >> **** >> >> > ? so it would appear to be worth doing. **** >> >> **** >> >> I strongly disagree here. This statements assumes that simplicity of the >> client API is the only factor that should be considered with the spec.***= * >> >> **** >> >> Emmanuel?s example is from a real-world service provider that would not b= e >> able to implement the spec easily with a uid per element. He is working = on >> a SCIM interface that will help facilitate data exchange between multiple >> Active Directory servers. Your solution was to change the data model fro= m >> this:**** >> >> **** >> >> mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** >> >> **** >> >> to this:**** >> >> **** >> >> mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D >> john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** >> >> **** >> >> I do not know of a single organization that would change their Active >> Directory data model to fit this. For one thing, it would be a huge data >> migration effort (likely across other domain controllers, etc?) to assign >> these unique identifiers. This also assumes that SCIM is the only >> reader/writer of this data, which will almost never be the case. If the >> data model requires uids for every element, then every piece of non-SCIM >> code that writes data into the directory will have to follow this. >> Additionally, there are **many** tools and applications (eg ? address >> books) that rely on a certain data model in Active Directory, and this >> would cause them to break. IMO this same argument holds true for most >> service providers.**** >> >> **** >> >> **** >> >> PATCH is an optional part of the spec. It was primarily introduced to >> make modifying resources with large multi-valued lists more efficient. I= t >> does not need to solve every problem (eg ? modifying sub-elements in nest= ed >> arrays). Adding uids to every multi-valued element does not strike the >> right balance between the needs of the client and the needs of the servic= e >> provider.**** >> >> **** >> >> --Kelly**** >> >> **** >> >> *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Sent:* Monday, August 13, 2012 1:35 AM >> *To:* Phil Hunt; Melinda Shore >> *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org**** >> >> >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> **** >> >> Responding to extract of Melinda Shore's mail from digest:**** >> >> **** >> >> The issue being raised here isn't endpoint logic, but**** >> >> network traffic, and I'm pretty sure it's not very helpful to**** >> >> respond to the observation that your model requires more**** >> >> messages with a complaint about what you seem to think is a**** >> >> complex algorithm for attribute processing.**** >> >> **** >> >> It depends on how it's implemented. I'm confident we can have the best of >> both - simple API with low-overhead implementation. Can we brainstorm HOW >> this proposal can be implemented rather than WHY it can't be implemented >> (which is mostly what I've been hearing so far)? After all, no one has >> challenged the claim that this proposal drastically simplifies the API fo= r >> the client, so it would appear to be worth doing. I'm sure there's more >> than enough intellectual horsepower in this working group to pull this of= f >> if we put our minds to it.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 13:54, Ganesh and Sashi Prasad >> wrote:**** >> >> > I strongly object to anything that leads to a read before modify >> requirement. Too complex and too chatty.**** >> >> Sorry Phil, but you're contradicting yourself here. There seems to be an >> awful lot of matching (i.e., reading) going on in the spec as it stands, >> with if-then clauses to do one thing or another if the match either >> succeeds or fails. This is a complex, chatty protocol right now!**** >> >> **** >> >> Multi-valued attributes: An attribute value in the PATCH request**** >> >> body is added to the value collection if the value does not exist**= ** >> >> and merged if a matching value is present. Values are matched by**= ** >> >> comparing the value Sub-Attribute from the PATCH request body to***= * >> >> the value Sub-Attribute of the Resource. Attributes that do not***= * >> >> have a value Sub-Attribute; e.g., addresses, or do not have unique*= *** >> >> value Sub-Attributes cannot be matched and must instead be deleted*= *** >> >> then added. Specific values can be removed from a Resource by**** >> >> adding an "operation" Sub-Attribute with the value "delete" to the*= *** >> >> attribute in the PATCH request body. As with adding/updating**** >> >> attribute value collections, the value to delete is determined by**= ** >> >> comparing the value Sub-Attribute from the PATCH request body to***= * >> >> the value Sub-Attribute of the Resource. Attributes that do not***= * >> >> have a value Sub-Attribute or that have a non-unique value Sub-**** >> >> Attribute are matched by comparing all Sub-Attribute values from***= * >> >> the PATCH request body to the Sub-Attribute values of the**** >> >> Resource. A delete operation is ignored if the attribute's name***= * >> >> is in the meta.attributes list. If the requested value to delete**= ** >> >> does not match a unique value on the Resource the server MAY**** >> >> return a HTTP 400 error.**** >> >> **** >> >> For a spec that is supposed to be about simplicity, the above description >> is anything but simple. I know you guys have worked hard on this and I >> don't mean to disparage those efforts, but think about how the above >> passage would appear to a new reader (i.e., a novice to the spec, not a >> technology novice).**** >> >> **** >> >> There is something fundamentally broken, and it is this: multi-valued >> attributes without a unique identifier per value. If you don't fix that, >> you won't get simplicity.**** >> >> **** >> >> We know LDAP trees are broken for multi-valued attributes. As Mark =20 >> Wahl famously >> commented back >> in 2005,**** >> >> **** >> >> "Unfortunately, some of the emerging protocols which also intend to >> represent and transfer personal identity information have perhaps taken a >> step backwards by not even considering these issues, perhaps sweeping the= m >> under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt >> version", which only postpone finding interoperable solutions to allowing >> applications to express the identity entries they want to express."**** >> >> **** >> >> SCIM is exactly one of these "emerging protocols" Wahl talks about, and >> what I see now strikes me as "sweeping these issues under the rug in the >> guise of simplicity". Apologies for the bluntness.**** >> >> **** >> >> My take is that SPs are _already_ struggling to manage multi-valued >> attributes, and existing mechanisms are =20 >> clumsy. >> They would be grateful for a specification that made operations easier at >> the cost of a re-engineered schema. That calls for some thought leadershi= p >> from this working group.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 10:13, Phil Hunt wrote:**** >> >> I strongly object to anything that leads to a read before modify >> requirement. Too complex and too chatty. >> >> Phil**** >> >> >> On 2012-08-12, at 15:29, Ganesh and Sashi Prasad >> wrote:**** >> >> > Would it have to be stored on the account database of the service >> provider?**** >> >> **** >> >> Yes.**** >> >> **** >> >> > If so, I believe that this is impracticable in the core schema. Indeed >> it implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, ?) and ?prepare it? for SCIM >> integration.**** >> >> **** >> >> Why? That doesn't necessarily follow. Implementation is independent of >> representation. We're talking about a change in representation to make th= e >> API cleaner.**** >> >> **** >> >> As a simple example, if an LDAP node is being used to hold a list of >> comma-separated email addresses, it can just as easily store >> comma-separated name-value pairs.**** >> >> **** >> >> mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** >> >> can be changed to**** >> >> **** >> >> mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D >> john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** >> >> **** >> >> That's why I asked if there was an SP representative on this working grou= p >> who could explain what such a change could mean for them. As of now, it >> looks like other people are presuming that SPs will not be able to >> implement these changes easily and are rejecting them for that reason.***= * >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 13 August 2012 04:29, Emmanuel Dreux wrote:**** >> >> =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> **** >> >> Where would 3cbaaff8e84e come from? Would it have to be stored on the >> account database of the service provider?**** >> >> **** >> >> If so, I believe that this is impracticable in the core schema. Indeed it >> implies that a service provider must extend the schema of his account >> repository (LDAP partition, SQL db, ?) and ?prepare it? for SCIM >> integration.**** >> >> This would be a show stopper. SCIM must be transparent, and must be able >> to be put on top of an existing system to provide provisioning apis.**** >> >> **** >> >> Said differently, SCIM must not be intrusive for existing systems and mus= t >> not require modifications to allow its integration.**** >> >> Correct me if I misunderstood your suggestion.**** >> >> **** >> >> --**** >> >> Regards,**** >> >> Emmanuel Dreux**** >> >> http://www.cloudiway.com**** >> >> Tel: +33 4 26 78 17 58**** >> >> Mobile: +33 6 47 81 26 70**** >> >> skype: Emmanuel.Dreux**** >> >> **** >> >> *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] >> *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 >> *=C0 :* Kelly Grizzle >> *Cc :* scim@ietf.org; Phil Hunt >> *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> **** >> >> > Multi-valued attributes that don't have a value sub-attribute (eg - >> address) have to specified completely for uniqueness. **** >> >> **** >> >> That's exactly the point. How do we "specify completely for uniqueness"?*= * >> ** >> >> **** >> >> In the example below, how are you proposing that the following element be >> updated if we can't use positional indexes?**** >> >> **** >> >> addresses[1].street-number =3D "243"**** >> >> **** >> >> User object:**** >> >> **** >> >> {**** >> >> ...**** >> >> addresses: [**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> ]**** >> >> }**** >> >> **** >> >> It's impractical to use the value because it's the whole dictionary >> element:**** >> >> **** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> **** >> >> With my proposal, the "addresses" array gets converted to a dictionary, >> and then we have a stable way of referencing this element:**** >> >> **** >> >> addresses.3cbaaff8e84e.street-number =3D "243"**** >> >> **** >> >> {**** >> >> ...**** >> >> addresses: {**** >> >> "d6ea365462f5" :**** >> >> {**** >> >> "type" : "home",**** >> >> "street-number" : "35",**** >> >> "street-name" : "High Road",**** >> >> "suburb" : "East Camden",**** >> >> "postcode" : "5346",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> },**** >> >> "3cbaaff8e84e" :**** >> >> {**** >> >> "type" : "office",**** >> >> "street-number" : "213",**** >> >> "street-name" : "Main Street",**** >> >> "suburb" : "Adelaide",**** >> >> "postcode" : "5000",**** >> >> "state" : "SA",**** >> >> "country" : "Australia"**** >> >> }**** >> >> }**** >> >> }**** >> >> **** >> >> If you're proposing one mechanism for composite attributes and another >> mechanism for simple attributes, I would suggest that's actually more >> complex than adopting a single mechanism that works the same way for _all= _ >> attributes. Remember that a lot of the administration is probably going t= o >> be scripted rather than done by hand, and having two mechanisms (dependin= g >> on whether the attribute is simple or composite) will complicate every >> script that has to be written.**** >> >> **** >> >> There's a lot of talk about the "burden" on the SPs, but I believe this i= s >> overblown. Is there any SP representative in this WG who can tell us what >> this proposal will actually entail for them?**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 12 August 2012 11:53, Kelly Grizzle >> wrote:**** >> >> Ganesh,**** >> >> **** >> >> This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t >> have a value sub-attribute can be removed by specifying only the value >> since it is unique. Multi-valued attributes that don't have a value >> sub-attribute (eg - address) have to specified completely for uniqueness. >> As I have said before, I am very opposed to adding a unique identifier t= o >> each element in a multi-valued collection due to the burden it will put o= n >> SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e >> affect adoption? My opinion is that adding unique keys to each element >> will have a much more detrimental effect on adoption.**** >> >> **** >> >> I do believe that in general PATCH can be made more intuitive without >> adding uids to each element. The verbs that you propose make sense. The= re >> is also a JSON Patch informational draft in the IETF that is interesting = - >> http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies >> on a JSON Pointer draft which uses index-based addressing for multi-value= d >> attributes. I think that this is something that should be looked at with= in >> the WG and I would be willing to lead this effort.**** >> >> **** >> >> I'm curious if anyone else in the WG is in favor of unique identifiers fo= r >> every multi-valued element.**** >> >> **** >> >> --Kelly**** >> >> **** >> ------------------------------ >> >> *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh >> and Sashi Prasad [g.c.prasad@gmail.com] >> *Sent:* Saturday, August 11, 2012 10:50 AM >> *To:* Phil Hunt >> *Cc:* scim@ietf.org >> *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** >> >> Phil, **** >> >> **** >> >> The reason we cannot use the value itself to identify an element is that >> this method will only work for simple elements, not for nested structures= . >> i.e., if we had an array of dictionaries (e.g., we had to record an array >> of addresses for each customer, with each address element having >> sub-elements like street number, street name, suburb, etc.), then it woul= d >> be clumsy to supply the entire value of the array element because it's >> itself a dictionary. Creating a unique key for each element scales better= . >> **** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> On 12 August 2012 01:12, Phil Hunt wrote:**** >> >> Ganesh, **** >> >> **** >> >> Here's the sample that concerned me...**** >> >> The two operations differ significantly, and it's not very intuitive. **= * >> * >> >> With my suggestion, here's how to delete a single member from a group:***= * >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: =20 >> example.comAccept: application/json Authorization: Bearer =20 >> h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> **** >> >> **** >> >> You gave other examples of an attribute with an identifier that matched >> that value or of identifiers that were additional unique keys.**** >> >> **** >> >> Given that multi-values must be each unique, I don't see the point of the >> extra indexing to support this. Just use the value as the item you wish t= o >> delete.**** >> >> **** >> >> I agree, the delete value operation could be more explicit and clear in >> general.**** >> >> **** >> >> Phil**** >> >> **** >> >> @independentid**** >> >> www.independentid.com**** >> >> phil.hunt@oracle.com**** >> >> **** >> >> **** >> >> **** >> >> On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote:**** >> >> **** >> >> > For the multi-value example you gave you used the value as the >> attribute name key. **** >> >> **** >> >> Now I'm confused :-). I don't believe any of my examples ever used a valu= e >> as the key.**** >> >> **** >> >> Could you please show me which example you mean, and which parts of it yo= u >> believe to be the value?**** >> >> **** >> >> Regards,**** >> >> Ganesh **** >> >> On 11 August 2012 13:59, Phil Hunt wrote:**** >> >> >> For the multi-value example you gave you used the value as the attribute >> name key. **** >> >> **** >> >> That means a lot more complex indexing structure. Better to just say >> delete a specific value. **** >> >> **** >> >> The spec already allows multiple values to have tags like home, work, etc= . >> **** >> >> **** >> >> Phil**** >> >> >> On 2012-08-10, at 21:45, Ganesh and Sashi Prasad >> wrote:**** >> >> > In your example you are conflating value with an attribute id. >> >> I don't believe so. **** >> >> **** >> >> I'm adopting a model where every attribute of the resource is a key-value >> pair. The key is a name or ID.**** >> >> **** >> >> For non-repeating attributes (both simple and composite), the key is the >> attribute name itself. **** >> >> **** >> >> Simple attribute:**** >> >> **** >> >> Key: "dob"**** >> >> Value: "01 Jan 1970"**** >> >> **** >> >> For composite attributes, the key employs dot notation to specify the >> fully-qualified attribute name, e.g., "address.postcode".**** >> >> **** >> >> Composite attribute:**** >> >> **** >> >> Key: "address.street-number"**** >> >> Value: "10"**** >> >> **** >> >> Key: "address.suburb"**** >> >> Value: "East Camden"**** >> >> **** >> >> For repeating (multi-valued) attributes, I'm suggesting that there be new >> keys for each individual value, otherwise they are impossible to >> distinguish, and a positional index is inadequate. So we convert the arra= y >> into a dictionary and this then becomes a composite attribute using dot >> notation for the key.**** >> >> **** >> >> Multi-valued attribute:**** >> >> **** >> >> Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"**** >> >> Value: "john_smith@yahoo.com"**** >> >> **** >> >> So this allows us to apply uniform treatment to any arbitrarily deep >> resource structure. We can refer to every leaf value with a key that is t= he >> fully-qualified name using dot notation.**** >> >> **** >> >> The verbs are just unambiguous operations on these (now) explicitly >> addressable attributes.**** >> >> **** >> >> INCLUDE to a collection and specify only the value. The key is generated >> and returned. The fully-qualified key is >> . and the value is what was specifie= d >> in the INCLUDE.**** >> >> **** >> >> REPLACE a fully-qualified key with a new value. If the key doesn't exist, >> return a "404 Not Found".**** >> >> **** >> >> PLACE a value at the logical location implied by the fully-qualified key. >> If there is already a key with that name, return a "409 Conflict".**** >> >> **** >> >> FORCE the fully-qualified key to hold the given value, regardless of >> whether it existed before or not. Only errors possible are "400 Bad >> Request" and "500 Internal Error".**** >> >> **** >> >> RETIRE an attribute or a collection given its fully-qualified key. The >> implementation will determine whether the attribute will disappear entire= ly >> or will exist holding a null value (the blank string "" or the empty obje= ct >> {} ).**** >> >> **** >> >> I'll explain in a separate post why we need operation verbs like these >> that are independent of the HTTP verbs.**** >> >> **** >> >> Regards,**** >> >> Ganesh**** >> >> **** >> >> On 11 August 2012 10:38, wrote:**** >> >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >> >> https://www.ietf.org/mailman/listinfo/scim >> >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >> >> >> >> Send scim mailing list submissions to >> scim@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/scim >> or, via email, send a message with subject or body 'help' to >> scim-request@ietf.org >> >> You can reach the person managing the list at >> scim-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of scim digest..." >> >> Today's Topics: >> >> 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >> >> >> ---------- Forwarded message ---------- >> From: Phil Hunt >> To: Ganesh and Sashi Prasad >> Cc: "Diodati, Mark" , Emmanuel Dreux < >> edreux@cloudiway.com>, Trey Drake , Kelly >> Grizzle , "scim@ietf.org" >> Date: Fri, 10 Aug 2012 17:36:54 -0700 >> Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement**** >> >> Ganesh,**** >> >> **** >> >> In your example you are conflating value with an attribute id. I find tha= t >> confusing. **** >> >> **** >> >> I agree though that operations in patch could be a lot more explicit. ***= * >> >> **** >> >> Eg explicitly deleting a value by saying delete or retire. **** >> >> >> Phil**** >> >> >> On 2012-08-10, at 16:19, Ganesh and Sashi Prasad >> wrote:**** >> >> > I am concerned about your second suggestion: **** >> >> **** >> >> Let's discuss that now.**** >> >> **** >> >> The trade-offs are very clear here.**** >> >> **** >> >> Pros:**** >> >> **** >> >> Pro 1. The API to manipulate resources becomes so much cleaner, consisten= t >> and intuitive when every individual attribute value gets its own ID.**** >> >> **** >> >> Here's how to delete a single member from a Group, as per the current spe= c: >> **** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> **** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "members": [**** >> >> {**** >> >> "display": "Babs Jensen",**** >> >> "value": "2819c223-7f76-453a-919d-413861904646"**** >> >> "operation": "delete"**** >> >> }**** >> >> ]**** >> >> }**** >> >> >> Here's how to delete ALL members from a group according to the current >> spec:**** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce**** >> >> Host: example.com**** >> >> Accept: application/json**** >> >> Authorization: Bearer h480djs93hd8**** >> >> ETag: W/"a330bc54f0671c9"**** >> >> **** >> >> {**** >> >> "schemas": ["urn:scim:schemas:core:1.0"],**** >> >> "meta": {**** >> >> "attributes": [**** >> >> "members"**** >> >> ]**** >> >> }**** >> >> }**** >> >> >> The two operations differ significantly, and it's not very intuitive. ***= * >> >> With my suggestion, here's how to delete a single member from a group:***= * >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: =20 >> example.comAccept: application/json Authorization: Bearer =20 >> h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members.2819c223-7f76-453a-919d-413861904646"**** >> >> }**** >> >> }**** >> >> ] } >> Here's how I suggest deleting ALL members from a group:**** >> >> **** >> >> PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: =20 >> example.comAccept: application/json Authorization: Bearer =20 >> h480djs93hd8 ETag: >> W/"a330bc54f0671c9" {**** >> >> "operations" : [**** >> >> {**** >> >> "RETIRE" : {**** >> >> "key" : "members"**** >> >> }**** >> >> }**** >> >> ] } **** >> >> >> I'm sure you'll agree that this is simpler, more consistent and more >> intuitive to a reader.**** >> >> **** >> >> Pro 2: We can apply this mechanism consistently to three areas:**** >> >> (a) Manipulating multi-valued attributes of a resource**** >> >> (b) Manipulating members of a group**** >> >> (c) Performing bulk operations, where we simply use HTTP verbs instead of >> the specialised (and semantically less ambiguous) verbs I suggested for >> attributes, the "key" becomes the URI, and the "value" becomes the >> corresponding JSON object.**** >> >> **** >> >> All of them return "207 Multi-Status" with the "results" array holding >> individual status codes.**** >> >> **** >> >> In the current spec, (a) and (b) are done similarly but (c) is very >> different.**** >> >> **** >> >> Pro 3: Adoption of the standard by clients is likely to be higher because >> it's simpler for them.**** >> >> **** >> >> Pro 4: New (not incumbent) cloud providers will probably find this easier >> to implement because they have no legacy. They will probably use some for= m >> of NoSQL database and won't be constrained by the limitations of LDAP >> directories.**** >> >> **** >> >> Cons:**** >> >> **** >> >> Con 1: Incumbent cloud providers with existing data stores in a directory >> format (where multi-valued attributes are stored as comma-separated value= s >> under a single attribute node) will find it difficult to migrate to this >> model and store each attribute value as a sub-node with its own key. This >> will "hinder adoption of the spec", which is what you fear.**** >> >> **** >> >> Have I summed up the Pros and Cons correctly? I'm biased of course, so I >> could have missed a Con or hyped a Pro :-).**** >> >> **** >> >> In other words, we're debating interface complexity (current spec) versus >> implementation complexity (my suggestion). Both can hinder adoption of th= e >> spec by different parties.**** >> >> **** >> >> Here's what we need to discuss - Do the Pros make the suggestio**** >> >> **** >> >> **** >> >> **** >> >> ** ** >> > From kelly.grizzle@sailpoint.com Thu Aug 16 08:59:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B2C21F85AD for ; Thu, 16 Aug 2012 08:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.34 X-Spam-Level: X-Spam-Status: No, score=-3.34 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHvA+Zlmb-Jl for ; Thu, 16 Aug 2012 08:59:42 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id DB22821F85C6 for ; Thu, 16 Aug 2012 08:59:41 -0700 (PDT) Received: from mail116-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Aug 2012 15:59:40 +0000 Received: from mail116-co1 (localhost [127.0.0.1]) by mail116-co1-R.bigfish.com (Postfix) with ESMTP id 95B16B80399; Thu, 16 Aug 2012 15:59:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -87 X-BigFish: PS-87(z73eW41dR21cRz98dI9371Ic89bh8f9R936eIc85dh1432I1418Iac5W4015I9d9R14ffIc0c9kzz1202hzz1033IL8275bh8275dh46309nf3c47iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail116-co1: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail116-co1 (localhost.localdomain [127.0.0.1]) by mail116-co1 (MessageSwitch) id 1345132776313470_19680; Thu, 16 Aug 2012 15:59:36 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.231]) by mail116-co1.bigfish.com (Postfix) with ESMTP id 47B95D20044; Thu, 16 Aug 2012 15:59:36 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Aug 2012 15:59:35 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.97]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0175.005; Thu, 16 Aug 2012 15:59:35 +0000 From: Kelly Grizzle To: Ganesh and Sashi Prasad , Anthony Nadalin Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3PrysoINrXz30exI2CcM9WIa5dT/IGAgABLt4CAAHBZgIAACouAgACi+YWAABY3AIABBZAAgAAyWwCAAC3NgIAAPeCAgAAs0YCAAHzV0IAADy0AgAAF2KCAAGG7AIABfhKAgAKJBYCAAE4yYA== Date: Thu, 16 Aug 2012 15:59:34 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C34373302C5DD@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C34373302C5DDBY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Phil Hunt , Melinda Shore , Emmanuel Dreux Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 15:59:57 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C34373302C5DDBY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ganesh ... your write-up concedes that this will be difficult to impleme= nt for an existing service provider. I'm not sure that I understand the co= mpromise. Are you still suggesting that SCIM move to the unique-key-per-el= ement strategy? If so, the cost/benefit of this seems way off to me. You are gaining a mor= e elegant API by introducing an additional datastore and requiring replicat= ion. I don't know of any service provider that would make this trade-off. = As you said, this is something that future service providers can keep in m= ind, but it is not going to help existing providers. --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Thursday, August 16, 2012 5:38 AM To: Anthony Nadalin Cc: Kelly Grizzle; Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Hi all, Would this hybrid architecture be a workable compromise? See diagram toward= s the end: http://bit.ly/Rjc39Y Regards, Ganesh On 15 August 2012 05:54, Anthony Nadalin > wrote: We should not be constrained by LDAP restrictions, this would not be produc= tive. From: scim-bounces@ietf.org [mailto:scim-boun= ces@ietf.org] On Behalf Of Ganesh and Sashi P= rasad Sent: Monday, August 13, 2012 2:07 PM To: Kelly Grizzle Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phi= l Hunt Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Thanks, Kelly. You've been most patient in hearing me out, I must say. I co= uldn't ask for more. Replying to Chris Philips's mail: > Given that you have a number of thoughts about what could be changed in S= CIM,Leif's recommendation to craft them in an Internet Draft may be a bett= er way to convey your thoughts. I'm coming around to the same conclusion. Do you think such an Internet Dra= ft should be about changing SCIM, or should it propose a complementary spec= for SPs who use a "NoLDAP" data store? I think the underlying problem is w= ith LDAP, and unless we change that, these proposals won't fly. Regards, Ganesh On 14 August 2012 01:54, Kelly Grizzle > wrote: There are really two implementation options for a uid per element - either = store the uids in the native underlying data store or have some secondary d= ata store that maps elements to their uids. The third option is to hope th= at a service provider has a NoLDAP data store or its equivalent. None of t= hese are practical for rapid and wide-spread adoption. > put the two together to propose a solution. As I said before, I am completely on board with cleaning up the PATCH seman= tics (eg - the inconsistency between meta.attributes and operation=3Ddelete= , etc...). Your suggestion of using different verbs is a good option to co= nsider. This cannot be based on a uid per element, though. It seems as th= ough you have admitted this in your conclusion - "As for LDAP and SCIM, I g= uess the best TLA is RIP." --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 9:56 AM To: Kelly Grizzle Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 That was one suggestion. Another way could be container nodes with their ow= n "dn"s. If one suggestion won't work, tell me another way to make it work.= I'm waiting to hear a constructive suggestion that can square an elegant A= PI with the implementation constraints that come from having to store multi= -valued attributes in LDAP directories. I've heard enough of WHY this won't work. For a change, tell me HOW it can = be made to work. Everyone now knows what the proposal means in terms of the= API, and implementors understand the constraints of legacy data stores, so= put the two together to propose a solution. C'mon, we have the "smartest g= uys in the room" here, surely we should be able to crack this. Regards, Ganesh P.S. I'm rapidly reaching my own conclusions about what is to be done: http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nold= ap.html On 14 August 2012 00:27, Kelly Grizzle > wrote: > After all, no one has challenged the claim that this proposal drastically= simplifies the API for the client I agree that your proposal makes PATCH semantics simpler and more elegant. > ... so it would appear to be worth doing. I strongly disagree here. This statements assumes that simplicity of the c= lient API is the only factor that should be considered with the spec. Emmanuel's example is from a real-world service provider that would not be = able to implement the spec easily with a uid per element. He is working on= a SCIM interface that will help facilitate data exchange between multiple = Active Directory servers. Your solution was to change the data model from = this: mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com to this: mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com I do not know of a single organization that would change their Active Direc= tory data model to fit this. For one thing, it would be a huge data migrat= ion effort (likely across other domain controllers, etc...) to assign these= unique identifiers. This also assumes that SCIM is the only reader/writer= of this data, which will almost never be the case. If the data model requ= ires uids for every element, then every piece of non-SCIM code that writes = data into the directory will have to follow this. Additionally, there are = *many* tools and applications (eg - address books) that rely on a certain = data model in Active Directory, and this would cause them to break. IMO th= is same argument holds true for most service providers. PATCH is an optional part of the spec. It was primarily introduced to make= modifying resources with large multi-valued lists more efficient. It does= not need to solve every problem (eg - modifying sub-elements in nested arr= ays). Adding uids to every multi-valued element does not strike the right = balance between the needs of the client and the needs of the service provid= er. --Kelly From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Sent: Monday, August 13, 2012 1:35 AM To: Phil Hunt; Melinda Shore Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Responding to extract of Melinda Shore's mail from digest: The issue being raised here isn't endpoint logic, but network traffic, and I'm pretty sure it's not very helpful to respond to the observation that your model requires more messages with a complaint about what you seem to think is a complex algorithm for attribute processing. It depends on how it's implemented. I'm confident we can have the best of b= oth - simple API with low-overhead implementation. Can we brainstorm HOW th= is proposal can be implemented rather than WHY it can't be implemented (whi= ch is mostly what I've been hearing so far)? After all, no one has challeng= ed the claim that this proposal drastically simplifies the API for the clie= nt, so it would appear to be worth doing. I'm sure there's more than enough= intellectual horsepower in this working group to pull this off if we put o= ur minds to it. Regards, Ganesh On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote: > I strongly object to anything that leads to a read before modify requirem= ent. Too complex and too chatty. Sorry Phil, but you're contradicting yourself here. There seems to be an aw= ful lot of matching (i.e., reading) going on in the spec as it stands, with= if-then clauses to do one thing or another if the match either succeeds or= fails. This is a complex, chatty protocol right now! Multi-valued attributes: An attribute value in the PATCH request body is added to the value collection if the value does not exist and merged if a matching value is present. Values are matched by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute; e.g., addresses, or do not have unique value Sub-Attributes cannot be matched and must instead be deleted then added. Specific values can be removed from a Resource by adding an "operation" Sub-Attribute with the value "delete" to the attribute in the PATCH request body. As with adding/updating attribute value collections, the value to delete is determined by comparing the value Sub-Attribute from the PATCH request body to the value Sub-Attribute of the Resource. Attributes that do not have a value Sub-Attribute or that have a non-unique value Sub- Attribute are matched by comparing all Sub-Attribute values from the PATCH request body to the Sub-Attribute values of the Resource. A delete operation is ignored if the attribute's name is in the meta.attributes list. If the requested value to delete does not match a unique value on the Resource the server MAY return a HTTP 400 error. For a spec that is supposed to be about simplicity, the above description i= s anything but simple. I know you guys have worked hard on this and I don't= mean to disparage those efforts, but think about how the above passage wou= ld appear to a new reader (i.e., a novice to the spec, not a technology nov= ice). There is something fundamentally broken, and it is this: multi-valued attri= butes without a unique identifier per value. If you don't fix that, you won= 't get simplicity. We know LDAP trees are broken for multi-valued attributes. As Mark Wahl fam= ously commented ba= ck in 2005, "Unfortunately, some of the emerging protocols which also intend to represe= nt and transfer personal identity information have perhaps taken a step bac= kwards by not even considering these issues, perhaps sweeping them under th= e rug in the guise of simplicity, XMLification, or "fix in the next version= ", which only postpone finding interoperable solutions to allowing applicat= ions to express the identity entries they want to express." SCIM is exactly one of these "emerging protocols" Wahl talks about, and wha= t I see now strikes me as "sweeping these issues under the rug in the guise= of simplicity". Apologies for the bluntness. My take is that SPs are _already_ struggling to manage multi-valued attribu= tes, and existing mechanisms are clumsy. They would be grateful f= or a specification that made operations easier at the cost of a re-engineer= ed schema. That calls for some thought leadership from this working group. Regards, Ganesh On 13 August 2012 10:13, Phil Hunt > wrote: I strongly object to anything that leads to a read before modify requiremen= t. Too complex and too chatty. Phil On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote: > Would it have to be stored on the account database of the service provide= r? Yes. > If so, I believe that this is impracticable in the core schema. Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. Why? That doesn't necessarily follow. Implementation is independent of repr= esentation. We're talking about a change in representation to make the API = cleaner. As a simple example, if an LDAP node is being used to hold a list of comma-= separated email addresses, it can just as easily store comma-separated name= -value pairs. mail: john_smith@yahoo.com, john.smith@gmail.c= om, jsmith1970@hotmail.com can be changed to mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com, 7a6= d1de664e1=3Djsmith1970@hotmail.com That's why I asked if there was an SP representative on this working group = who could explain what such a change could mean for them. As of now, it loo= ks like other people are presuming that SPs will not be able to implement t= hese changes easily and are rejecting them for that reason. Regards, Ganesh On 13 August 2012 04:29, Emmanuel Dreux > wrote: =3D> addresses.3cbaaff8e84e.street-number =3D "243" Where would 3cbaaff8e84e come from? Would it have to be stored on the accou= nt database of the service provider? If so, I believe that this is impracticable in the core schema. Indeed it i= mplies that a service provider must extend the schema of his account reposi= tory (LDAP partition, SQL db, ...) and "prepare it" for SCIM integration. This would be a show stopper. SCIM must be transparent, and must be able to= be put on top of an existing system to provide provisioning apis. Said differently, SCIM must not be intrusive for existing systems and must = not require modifications to allow its integration. Correct me if I misunderstood your suggestion. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 =C0 : Kelly Grizzle Cc : scim@ietf.org; Phil Hunt Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > Multi-valued attributes that don't have a value sub-attribute (eg - addr= ess) have to specified completely for uniqueness. That's exactly the point. How do we "specify completely for uniqueness"? In the example below, how are you proposing that the following element be u= pdated if we can't use positional indexes? addresses[1].street-number =3D "243" User object: { ... addresses: [ { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } ] } It's impractical to use the value because it's the whole dictionary element= : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } With my proposal, the "addresses" array gets converted to a dictionary, and= then we have a stable way of referencing this element: addresses.3cbaaff8e84e.street-number =3D "243" { ... addresses: { "d6ea365462f5" : { "type" : "home", "street-number" : "35", "street-name" : "High Road", "suburb" : "East Camden", "postcode" : "5346", "state" : "SA", "country" : "Australia" }, "3cbaaff8e84e" : { "type" : "office", "street-number" : "213", "street-name" : "Main Street", "suburb" : "Adelaide", "postcode" : "5000", "state" : "SA", "country" : "Australia" } } } If you're proposing one mechanism for composite attributes and another mech= anism for simple attributes, I would suggest that's actually more complex t= han adopting a single mechanism that works the same way for _all_ attribute= s. Remember that a lot of the administration is probably going to be script= ed rather than done by hand, and having two mechanisms (depending on whethe= r the attribute is simple or composite) will complicate every script that h= as to be written. There's a lot of talk about the "burden" on the SPs, but I believe this is = overblown. Is there any SP representative in this WG who can tell us what t= his proposal will actually entail for them? Regards, Ganesh On 12 August 2012 11:53, Kelly Grizzle > wrote: Ganesh, This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes that = have a value sub-attribute can be removed by specifying only the value sinc= e it is unique. Multi-valued attributes that don't have a value sub-attrib= ute (eg - address) have to specified completely for uniqueness. As I have = said before, I am very opposed to adding a unique identifier to each elemen= t in a multi-valued collection due to the burden it will put on SPs. Is it= elegant? No. Is it functional? Yes. Will this non-elegance affect adop= tion? My opinion is that adding unique keys to each element will have a mu= ch more detrimental effect on adoption. I do believe that in general PATCH can be made more intuitive without addin= g uids to each element. The verbs that you propose make sense. There is a= lso a JSON Patch informational draft in the IETF that is interesting - http= ://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies on a JS= ON Pointer draft which uses index-based addressing for multi-valued attribu= tes. I think that this is something that should be looked at within the WG= and I would be willing to lead this effort. I'm curious if anyone else in the WG is in favor of unique identifiers for = every multi-valued element. --Kelly ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Ganesh and Sashi Prasad [= g.c.prasad@gmail.com] Sent: Saturday, August 11, 2012 10:50 AM To: Phil Hunt Cc: scim@ietf.org Subject: Re: [scim] scim Digest, Vol 8, Issue 24 Phil, The reason we cannot use the value itself to identify an element is that th= is method will only work for simple elements, not for nested structures. i.= e., if we had an array of dictionaries (e.g., we had to record an array of = addresses for each customer, with each address element having sub-elements = like street number, street name, suburb, etc.), then it would be clumsy to = supply the entire value of the array element because it's itself a dictiona= ry. Creating a unique key for each element scales better. Regards, Ganesh On 12 August 2012 01:12, Phil Hunt > wrote: Ganesh, Here's the sample that concerned me... The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } You gave other examples of an attribute with an identifier that matched tha= t value or of identifiers that were additional unique keys. Given that multi-values must be each unique, I don't see the point of the e= xtra indexing to support this. Just use the value as the item you wish to d= elete. I agree, the delete value operation could be more explicit and clear in gen= eral. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > For the multi-value example you gave you used the value as the attribute= name key. Now I'm confused :-). I don't believe any of my examples ever used a value = as the key. Could you please show me which example you mean, and which parts of it you = believe to be the value? Regards, Ganesh On 11 August 2012 13:59, Phil Hunt > wrote: For the multi-value example you gave you used the value as the attribute na= me key. That means a lot more complex indexing structure. Better to just say delete= a specific value. The spec already allows multiple values to have tags like home, work, etc. Phil On 2012-08-10, at 21:45, Ganesh and Sashi Prasad > wrote: > In your example you are conflating value with an attribute id. I don't believe so. I'm adopting a model where every attribute of the resource is a key-value p= air. The key is a name or ID. For non-repeating attributes (both simple and composite), the key is the at= tribute name itself. Simple attribute: Key: "dob" Value: "01 Jan 1970" For composite attributes, the key employs dot notation to specify the fully= -qualified attribute name, e.g., "address.postcode". Composite attribute: Key: "address.street-number" Value: "10" Key: "address.suburb" Value: "East Camden" For repeating (multi-valued) attributes, I'm suggesting that there be new k= eys for each individual value, otherwise they are impossible to distinguish= , and a positional index is inadequate. So we convert the array into a dict= ionary and this then becomes a composite attribute using dot notation for t= he key. Multi-valued attribute: Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" Value: "john_smith@yahoo.com" So this allows us to apply uniform treatment to any arbitrarily deep resour= ce structure. We can refer to every leaf value with a key that is the fully= -qualified name using dot notation. The verbs are just unambiguous operations on these (now) explicitly address= able attributes. INCLUDE to a collection and specify only the value. The key is generated an= d returned. The fully-qualified key is . and the value is what was specified in the INCLUDE. REPLACE a fully-qualified key with a new value. If the key doesn't exist, r= eturn a "404 Not Found". PLACE a value at the logical location implied by the fully-qualified key. I= f there is already a key with that name, return a "409 Conflict". FORCE the fully-qualified key to hold the given value, regardless of whethe= r it existed before or not. Only errors possible are "400 Bad Request" and = "500 Internal Error". RETIRE an attribute or a collection given its fully-qualified key. The impl= ementation will determine whether the attribute will disappear entirely or = will exist holding a null value (the blank string "" or the empty object {}= ). I'll explain in a separate post why we need operation verbs like these that= are independent of the HTTP verbs. Regards, Ganesh On 11 August 2012 10:38, > wrote: If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/scim Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send scim mailing list submissions to scim@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/scim or, via email, send a message with subject or body 'help' to scim-request@ietf.org You can reach the person managing the list at scim-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of scim digest..." Today's Topics: 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) ---------- Forwarded message ---------- From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" >, Emmanuel Dreux >, T= rey Drake >, Kell= y Grizzle >= , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement Ganesh, In your example you are conflating value with an attribute id. I find that = confusing. I agree though that operations in patch could be a lot more explicit. Eg explicitly deleting a value by saying delete or retire. Phil On 2012-08-10, at 16:19, Ganesh and Sashi Prasad > wrote: > I am concerned about your second suggestion: Let's discuss that now. The trade-offs are very clear here. Pros: Pro 1. The API to manipulate resources becomes so much cleaner, consistent = and intuitive when every individual attribute value gets its own ID. Here's how to delete a single member from a Group, as per the current spec: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "members": [ { "display": "Babs Jensen", "value": "2819c223-7f76-453a-919d-413861904646" "operation": "delete" } ] } Here's how to delete ALL members from a group according to the current spec= : PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" { "schemas": ["urn:scim:schemas:core:1.0"], "meta": { "attributes": [ "members" ] } } The two operations differ significantly, and it's not very intuitive. With my suggestion, here's how to delete a single member from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members.2819c223-7f76-453a-919d-413861904646" } } ] } Here's how I suggest deleting ALL members from a group: PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { "operations" : [ { "RETIRE" : { "key" : "members" } } ] } I'm sure you'll agree that this is simpler, more consistent and more intuit= ive to a reader. Pro 2: We can apply this mechanism consistently to three areas: (a) Manipulating multi-valued attributes of a resource (b) Manipulating members of a group (c) Performing bulk operations, where we simply use HTTP verbs instead of t= he specialised (and semantically less ambiguous) verbs I suggested for attr= ibutes, the "key" becomes the URI, and the "value" becomes the correspondin= g JSON object. All of them return "207 Multi-Status" with the "results" array holding indi= vidual status codes. In the current spec, (a) and (b) are done similarly but (c) is very differe= nt. Pro 3: Adoption of the standard by clients is likely to be higher because i= t's simpler for them. Pro 4: New (not incumbent) cloud providers will probably find this easier t= o implement because they have no legacy. They will probably use some form o= f NoSQL database and won't be constrained by the limitations of LDAP direct= ories. Cons: Con 1: Incumbent cloud providers with existing data stores in a directory f= ormat (where multi-valued attributes are stored as comma-separated values u= nder a single attribute node) will find it difficult to migrate to this mod= el and store each attribute value as a sub-node with its own key. This will= "hinder adoption of the spec", which is what you fear. Have I summed up the Pros and Cons correctly? I'm biased of course, so I co= uld have missed a Con or hyped a Pro :-). In other words, we're debating interface complexity (current spec) versus i= mplementation complexity (my suggestion). Both can hinder adoption of the s= pec by different parties. Here's what we need to discuss - Do the Pros make the suggestio --_000_56C3C758F9D6534CA3778EAA1E0C34373302C5DDBY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ganesh … your wr= ite-up concedes that this will be difficult to implement for an existing se= rvice provider.  I’m not sure that I understand the compromise.&= nbsp; Are you still suggesting that SCIM move to the unique-key-per-element stra= tegy?

 <= /p>

If so, the cost/benefit o= f this seems way off to me.  You are gaining a more elegant API by int= roducing an additional datastore and requiring replication.  I don’t know of any service provider that would make this trade-off.=   As you said, this is something that future service providers can kee= p in mind, but it is not going to help existing providers.

 <= /p>

--Kelly=

 <= /p>

From: Ganesh a= nd Sashi Prasad [mailto:g.c.prasad@gmail.com]
Sent: Thursday, August 16, 2012 5:38 AM
To: Anthony Nadalin
Cc: Kelly Grizzle; Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phi= l Hunt
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Hi all,

 

Would this hybrid architecture be a workable comprom= ise? See diagram towards the end: http://bit.ly/Rjc39Y

 

Regards,

Ganesh

On 15 August 2012 05:54, Anthony Nadalin <tonynad@microsoft.com> wrote:

We should not be constrained by LDAP re= strictions, this would not be productive.

 

From: scim-bounces@iet= f.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi Prasad
Sent: Monday, August 13, 2012 2:07 PM
To: Kelly Grizzle
Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Thanks, Kelly. You've been most patient in hearing me out, I must = say. I couldn't ask for more.

 

Replying to Chris Philips's mail:

> Given that y= ou have a number of thoughts about what could be changed in SCIM,Leif's recommendation to  craft them in an Internet Draft may be a better wa= y to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an Internet Dra= ft should be about changing SCIM, or should it propose a complementary spec= for SPs who use a "NoLDAP" data store? I think the underlying pr= oblem is with LDAP, and unless we change that, these proposals won't fly.

 

Regards,

Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:

There are really two implementation opt= ions for a uid per element – either store the uids in the native underlying data store or have some secondary data store that maps e= lements to their uids.  The third option is to hope that a service pro= vider has a NoLDAP data store or its equivalent.  None of these are pr= actical for rapid and wide-spread adoption.

 

> put the two together to propose a solution.

 

As I said before, I am completely on bo= ard with cleaning up the PATCH semantics (eg – the inconsistency between meta.attributes and operation=3Ddelete, etc…).  Your su= ggestion of using different verbs is a good option to consider.  This = cannot be based on a uid per element, though.  It seems as though you = have admitted this in your conclusion – “As for LDAP and SCIM, I guess the best TLA is RIP.”

 

--Kelly

 

From: Ganesh and Sashi Prasa= d [mailto:g.c.pra= sad@gmail.com]
Sent: Monday, August 13, 2012 9:56 AM
To: Kelly Grizzle
Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

That was one suggestion. Another way could be container nodes with= their own "dn"s. If one suggestion won't work, tell me another w= ay to make it work. I'm waiting to hear a constructive suggestion that can square an elegant API with the implementation constrai= nts that come from having to store multi-valued attributes in LDAP director= ies.

 

I've heard enough of WHY this won't work. For a change, tell me HO= W it can be made to work. Everyone now knows what the proposal means in ter= ms of the API, and implementors understand the constraints of legacy data stores, so put the two together to propose = a solution. C'mon, we have the "smartest guys in the room" here, = surely we should be able to crack this.

 

Regards,

Ganesh

 

P.S. I'm rapidly reaching my own conclusions about what is to be d= one:

 

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sailpoint.com&g= t; wrote:

> After all, no one has challenged the claim that this proposal= drastically simplifies the API for the client

 

I agree that your proposal makes PATCH = semantics simpler and more elegant.

 

 

> … so it would appear to be worth doing. 

 

I strongly disagree here.  This st= atements assumes that simplicity of the client API is the only factor that should be considered with the spec.

 

Emmanuel’s example is from a real= -world service provider that would not be able to implement the spec easily with a uid per element.  He is working on a SCIM interfac= e that will help facilitate data exchange between multiple Active Directory= servers.  Your solution was to change the data model from this:

 

m=
ail: john_smith@y=
ahoo.com, joh=
n.smith@gmail.com, jsmith1970@hotmail.com

 

to this:

 

mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, = ;7a6d1de664e1=3Djsmith1970@hotmail.com

 

I do not know of a single organization = that would change their Active Directory data model to fit this.  For one thing, it would be a huge data migration effort (likel= y across other domain controllers, etc…) to assign these unique ident= ifiers.  This also assumes that SCIM is the only reader/writer of this= data, which will almost never be the case.  If the data model requires uids for every element, then every piece of non-SC= IM code that writes data into the directory will have to follow this. = Additionally, there are *many* tools and applications  (eg = 211; address books) that rely on a certain data model in Active Directory, and this would cause them to break.  IMO t= his same argument holds true for most service providers.<= /p>

 

 

PATCH is an optional part of the spec. =  It was primarily introduced to make modifying resources with large multi-valued lists more efficient.  It does not need to solve e= very problem (eg – modifying sub-elements in nested arrays).  Ad= ding uids to every multi-valued element does not strike the right balance b= etween the needs of the client and the needs of the service provider.

 

--Kelly

 

From: Ganesh and Sashi Prasa= d [mailto:g.c.pra= sad@gmail.com]
Sent: Monday, August 13, 2012 1:35 AM
To: Phil Hunt; Melinda Shore
Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org


Subject: Re: [scim] scim Digest, Vol 8, Issue 24

 

Responding to extract of Melinda Shore's mail from digest:

 

The issue being ra=
ised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more

messages with a complaint about what you seem to think is a=



complex algorithm for attribute processing.




 






It depends on how it's implemented. I'm confident we can have the =
best of both - simple API with low-overhead implementation. Can we brainsto=
rm HOW this proposal can be implemented
 rather than WHY it can't be implemented (which is mostly what I've been he=
aring so far)? After all, no one has challenged the claim that this proposa=
l drastically simplifies the API for the client, so it would appear to be w=
orth doing. I'm sure there's more
 than enough intellectual horsepower in this working group to pull this off=
 if we put our minds to it.






 






Regards,






Ganesh




 




On 13 August 2012 13:54, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> w=
rote:




> I strongly object to anything that leads to a read before modi=
fy requirement. Too complex and too chatty.




Sorry Phil, but you're contradicting yourself here. There see=
ms to be an awful lot of matching (i.e., reading) going on in the spec as i=
t stands, with if-then clauses to do one
 thing or another if the match either succeeds or fails. This is a complex,=
 chatty protocol right now!




 






   Multi-valued attributes:=
  An attribute value in the PATCH request


      body i=
s added to the value collection if the value does not exist


      and me=
rged if a matching value is present.  Values are matched by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute; e.g., addresses, or do not have unique


      value =
Sub-Attributes cannot be matched and must instead be deleted


      then a=
dded.  Specific values can be removed from a Resource by


      adding=
 an "operation" Sub-Attribute with the value "delete" t=
o the


      attrib=
ute in the PATCH request body.  As with adding/updating


      attrib=
ute value collections, the value to delete is determined by


      compar=
ing the value Sub-Attribute from the PATCH request body to


      the va=
lue Sub-Attribute of the Resource.  Attributes that do not=



      have a=
 value Sub-Attribute or that have a non-unique value Sub-=



      Attrib=
ute are matched by comparing all Sub-Attribute values from


      the PA=
TCH request body to the Sub-Attribute values of the


      Resour=
ce.  A delete operation is ignored if the attribute's name=



      is in =
the meta.attributes list.  If the requested value to delete


      does n=
ot match a unique value on the Resource the server MAY

      return=
 a HTTP 400 error.






 






For a spec that is supposed to be about simplicity, the above desc=
ription is anything but simple. I know you guys have worked hard on this an=
d I don't mean to disparage those efforts,
 but think about how the above passage would appear to a new reader (i.e., =
a novice to the spec, not a technology novice).






 






There is something fundamentally broken, and it is this: multi-val=
ued attributes without a unique identifier per value. If you don't fix that=
, you won't get simplicity.






 






We know LDAP trees are broken for multi-valued attributes. As Mark=
 Wahl

famously commented back in 2005,






 






"Unfortunately, some of the emerging protocols w=
hich also intend to represent and transfer personal identity information
 have perhaps taken a step backwards by not even considering these issues, =
perhaps sweeping them under the rug in the guise of simplicity, XMLificatio=
n, or "fix in the next version", which only postpone finding inte=
roperable solutions to allowing applications
 to express the identity entries they want to express."






 






SCIM is exactly one of these "emerging protocols" Wahl t=
alks about, and what I see now strikes me as "sweeping these issues un=
der the rug in the guise of simplicity". Apologies
 for the bluntness.






 






My take is that SPs are _already_ struggling to manage multi-value=
d attributes, and

existing mechanisms are clumsy. They would be grateful for a specificat=
ion that made operations easier at the cost of a re-engineered schema. That=
 calls for some thought leadership from this working group.






 






Regards,






Ganesh






 




On 13 August 2012 10:13, Phil Hunt <phil.hunt@oracle.com> wrote:






I strongly object to anything that leads to a read before modify r=
equirement. Too complex and too chatty. =




Phil












On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








> Would it have to be stored on t=
he account database of the service provider?


 


Yes.


 


> If so, I believe that this is i=
mpracticable in the core schema. Indeed it implies that a service prov=
ider must extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.




 






Why? That doesn't necessarily follow. Implementation is independen=
t of representation. We're talking about a change in representation to make=
 the API cleaner.






 






As a simple example, if an LDAP node is being used to hold a list =
of comma-separated email addresses, it can just as easily store comma-separ=
ated name-value pairs.






 







 






mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com, =
;7a6d1de664e1=3Djsmith1970@hotmail.com






 




That's why I asked if there was an SP representative on this working gro=
up who could explain what such a change could mean for them.
 As of now, it looks like other people are presuming that SPs will not be a=
ble to implement these changes easily and are rejecting them for that reaso=
n.




 






Regards,






Ganesh






 




On 13 August 2012 04:29, Emmanuel Dreux <edreux@cloudiway.com> wrote:






=F0  
addresses.3cbaaff8e84e.street-number =3D "243"


 


Where would
3cbaaff8e84e come from? Would it have to be stored on the account database of th=
e service provider?


 


If so, I believe that this is imprac=
ticable in the core schema. Indeed it implies that a service provider must =
extend the schema of his account repository
 (LDAP partition, SQL db, …) and “prepare it” for SCIM in=
tegration.


This would be a show stopper. SCIM m=
ust be transparent, and must be able to be put on top of an existing system=
 to provide provisioning apis.


 


Said differently, SCIM must not be i=
ntrusive for existing systems and must not require modifications to allow i=
ts integration.


Correct me if I misunderstood your s=
uggestion.


 


--


Regards,


Emmanuel Dreux<=
/o:p>


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

Tel:
+33 4 2=
6 78 17 58


Mobile:
+33 6 4=
7 81 26 70


skype: Emmanuel.Dreux


 



De : Ganesh and
 Sashi Prasad [mailto:g.c.prasad@gmail.com]


Envoy=E9 : dimanche 12 ao=FBt 2012 04:53

=C0 : Kelly Grizzle

Cc : scim@ie=
tf.org; Phil Hunt

Objet : Re: [scim] scim Digest, Vol 8, Issue 24




 


> 
Multi-valued attributes that d=
on't have a value sub-attribute (eg - address) have to specified completely=
 for uniqueness.  




 






That's exactly the point. How do we "specif=
y completely for uniqueness"?






 






In the example below, how are you proposing that=
 the following element be updated if we can't use positional indexes?






 






addresses[1].street-number =3D "243"






 






User object:






 








{






  ...






  addresses: [






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  ]






}






 






It's impractical to use the value because it's t=
he whole dictionary element:






 








{






  "type" : "office",






  "street-number" : "213&quo=
t;,






  "street-name" : "Main Stre=
et",






  "suburb" : "Adelaide"=
,






  "postcode" : "5000",<=
/span>






  "state" : "SA",






  "country" : "Australia&quo=
t;






}








 






With my proposal, the "addresses" arra=
y gets converted to a dictionary, and then we have a stable way of referenc=
ing this element:






 








addresses.3cbaaff8e84e.street-number =3D "2=
43"




 








{






  ...






  addresses: {






    "d6ea365462f5" :<=
o:p>






    {






      "type" : "ho=
me",






      "street-number" :=
 "35",






      "street-name" : &=
quot;High Road",






      "suburb" : "=
East Camden",






      "postcode" : &quo=
t;5346",






      "state" : "S=
A",






      "country" : "=
;Australia"






    },






    "3cbaaff8e84e" :<=
o:p>






    {






      "type" : "of=
fice",






      "street-number" :=
 "213",






      "street-name" : &=
quot;Main Street",






      "suburb" : "=
Adelaide",






      "postcode" : &quo=
t;5000",






      "state" : "S=
A",






      "country" : "=
;Australia"






    }






  }






}






 






If you're proposing one mechanism for composite =
attributes and another mechanism for simple attributes, I would suggest tha=
t's actually more complex than adopting
 a single mechanism that works the same way for _all_ attributes. Remember =
that a lot of the administration is probably going to be scripted rather th=
an done by hand, and having two mechanisms (depending on whether the attrib=
ute is simple or composite) will
 complicate every script that has to be written.








 






There's a lot of talk about the "burden&quo=
t; on the SPs, but I believe this is overblown. Is there any SP representat=
ive in this WG who can tell us what this proposal
 will actually entail for them?






 






Regards,






Ganesh




 




On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@s=
ailpoint.com> wrote:








Ganesh,






 






This is exactly how PATCH works in SCIM 1.=
0.  Multi-valued attributes that have a value sub-attribute
 can be removed by specifying only the value since it is unique.  Mult=
i-valued attributes that don't have a value sub-attribute (eg - address) ha=
ve to specified completely for uniqueness.  As I have said before, I a=
m very opposed to adding a unique identifier
 to each element in a multi-valued collection due to the burden it will put=
 on SPs.  Is it elegant?  No.  Is it functional?  Yes. =
 Will this non-elegance affect adoption?  My opinion is that addi=
ng unique keys to each element will have a much more detrimental
 effect on adoption.






 






I do believe that in general PATCH can be =
made more intuitive without adding uids to each element.  The
 verbs that you propose make sense.  There is also a JSON Patch inform=
ational draft in the IETF that is interesting - http://=
tools.ietf.org/html/draft-ietf-appsawg-json-patch-02.
  It relies on a JSON Pointer draft which uses index-based addressing =
for multi-valued attributes.  I think that this is something that shou=
ld be looked at within the WG and I would be willing to lead this effort.






 






I'm curious if anyone else in the WG is in=
 favor of unique identifiers for every multi-valued element.






 






--Kelly




 












From:
scim-bounces@iet=
f.org [scim-=
bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]

Sent: Saturday, August 11, 2012 10:50 AM

To: Phil Hunt

Cc: scim@ietf.org=


Subject: Re: [scim] scim Digest, Vol 8, Issue 24









Phil,





 






The reason we cannot use the value itself to ide=
ntify an element is that this method will only work for simple elements, no=
t for nested structures. i.e., if we had
 an array of dictionaries (e.g., we had to record an array of addresses for=
 each customer, with each address element having sub-elements like street n=
umber, street name, suburb, etc.), then it would be clumsy to supply the en=
tire value of the array element
 because it's itself a dictionary. Creating a unique key for each element s=
cales better.






 






Regards,






Ganesh




On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com=
> wrote:




Ganesh,





 






Here's the sample that concerned me...












The two operations differ significantly, and it'=
s not very intuitive. 






With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }











 








 








You gave other examples of an attribute with an identifier th=
at matched that value or of identifiers that were
 additional unique keys.






 






Given that multi-values must be each unique, I don't see the =
point of the extra indexing to support this. Just
 use the value as the item you wish to delete.






 






I agree, the delete value operation could be more explicit an=
d clear in general.






 









 




 








 






On 2012-08-11, at 2:30 AM, Ganesh and Sashi Pras=
ad wrote:




 


>  For the multi-value example you gave =
you used the value as the attribute name key. 





 






Now I'm confused :-). I don't believe any of my =
examples ever used a value as the key.






 






Could you please show me which example you mean,=
 and which parts of it you believe to be the value?






 






Regards,






Ganesh 




On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com=
> wrote:








For the multi-value example you gave you used the value as the attribute na=
me key. 






 






That means a lot more complex indexing structure=
. Better to just say delete a specific value. 






 






The spec already allows multiple values to have =
tags like home, work, etc.






 =







Phil











On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:
















> In your example you are conflating val=
ue with an attribute id. 



I don't believe so. 




 






I'm adopting a model where every attribute of th=
e resource is a key-value pair. The key is a name or ID.<=
/p>





 






For non-repeating attributes (both simple and co=
mposite), the key is the attribute name itself. 






 








Simple attribute:






 






Key: "dob"






Value: "01 Jan 1970"=







 








For composite attributes, the key employs dot no=
tation to specify the fully-qualified attribute name, e.g., "address.p=
ostcode".






 






Composite attribute:






 






Key: "address.street-number"






Value: "10"






 






Key: "address.suburb"






Value: "East Camden"=







 






For repeating (multi-valued) attributes, I'm sug=
gesting that there be new keys for each individual value, otherwise they ar=
e impossible to distinguish, and a positional
 index is inadequate. So we convert the array into a dictionary and this th=
en becomes a composite attribute using dot notation for the key.






 






Multi-valued attribute:






 






Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea=
3bd902"







 






So this allows us to apply uniform treatment to =
any arbitrarily deep resource structure. We can refer to every leaf value w=
ith a key that is the fully-qualified
 name using dot notation.






 






The verbs are just unambiguous operations on the=
se (now) explicitly addressable attributes.






 






INCLUDE to a collection and specify only the val=
ue. The key is generated and returned. The fully-qualified key is <colle=
ction-name>.<newly-generated-ID> and the
 value is what was specified in the INCLUDE.






 






REPLACE a fully-qualified key with a new value. =
If the key doesn't exist, return a "404 Not Found".






 






PLACE a value at the logical location implied by=
 the fully-qualified key. If there is already a key with that name, return =
a "409 Conflict".






 






FORCE the fully-qualified key to hold the given =
value, regardless of whether it existed before or not. Only errors possible=
 are "400 Bad Request" and "500 Internal
 Error".






 






RETIRE an attribute or a collection given its fu=
lly-qualified key. The implementation will determine whether the attribute =
will disappear entirely or will exist
 holding a null value (the blank string "" or the empty object {}=
 ).






 






I'll explain in a separate post why we need oper=
ation verbs like these that are independent of the HTTP verbs.<=
/o:p>






 






Regards,






Ganesh






 




On 11 August 2012 10:38, <scim-request@ietf.org> wrote=
:


If you have received this digest without all the=
 individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to



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



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







Send scim mailing list submissions to

        scim@ietf.org



To subscribe or unsubscribe via the World Wide Web, visit

        https://www.ietf.org/mailman/listinfo/scim
or, via email, send a message with subject or body 'help' to

        scim-request@ietf.org



You can reach the person managing the list at

        scim-owner@ietf.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of scim digest..."



Today's Topics:



   1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hun=
t)





---------- Forwarded message ----------

From: Phil Hunt <phil.hunt@oracle.com>

To: Ganesh and Sashi Prasad <g.c.prasad@gmail.com>

Cc: "Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux =
<edreux@cloudi=
way.com>, Trey Drake <trey.drake@unboundid.com>,
 Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>

Date: Fri, 10 Aug 2012 17:36:54 -0700

Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement








Ganesh,






 






In your example you are conflating value with an=
 attribute id. I find that confusing. 






 






I agree though that operations in patch could be=
 a lot more explicit. 






 






Eg explicitly deleting a value by saying delete =
or retire. 








Phil








On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:








 >  I am concerned about your second suggestion: 





 






Let's discuss that now.






 






The trade-offs are very clear here.<=
/o:p>






 






Pros:






 






Pro 1. The API to manipulate resources becomes s=
o much cleaner, consistent and intuitive when every individual attribute va=
lue gets its own ID.






 






Here's how to delete a single member from a Grou=
p, as per the current spec:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"members": [


    &=
nbsp;  {


    &=
nbsp;    "display": "Babs Jensen",


    &=
nbsp;    "value": "2819c223-7f76-453a-919d-41=
3861904646"


    &=
nbsp;    "operation": "delete"


    &=
nbsp;  }


     =
]


   }




Here's how to delete ALL members from a group according to the current spec=
:






 






   PATCH /Group=
s/acbf3ae7-8463-4692-b4fd-9b4da3f908ce


   Host: example.com


   Accept: appl=
ication/json


   Authorizatio=
n: Bearer h480djs93hd8


   ETag: W/&quo=
t;a330bc54f0671c9"


 <=
/pre>

   {


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


     =
"meta": {


    &=
nbsp;  "attributes": [


    &=
nbsp;    "members"


    &=
nbsp;  ]


     =
}


   }




The two operations differ significantly, and it's not very intuitive. =







With my suggestion, here's how to delete a singl=
e member from a group:






 






PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members.2819c223-7f76-453a-919d-41386=
1904646"






}






}






] }


Here's how I suggest deleting ALL members from a group:





 








PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:
example.com Accept: a=
pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0=
671c9" {






"operations" : [






{






"RETIRE" : {






"key" : "members"






}






}






] }







I'm sure you'll agree that this is simpler, more consistent and more intuit=
ive to a reader.






 






Pro 2: We can apply this mechanism consistently =
to three areas:






(a) Manipulating multi-valued attributes of a re=
source






(b) Manipulating members of a group<=
/o:p>






(c) Performing bulk operations, where we simply =
use HTTP verbs instead of the specialised (and semantically less ambiguous)=
 verbs I suggested for attributes, the
 "key" becomes the URI, and the "value" becomes the cor=
responding JSON object.






 






All of them return "207 Multi-Status" =
with the "results" array holding individual status codes.<=
o:p>






 






In the current spec, (a) and (b) are done simila=
rly but (c) is very different.






 






Pro 3: Adoption of the standard by clients is li=
kely to be higher because it's simpler for them.






 






Pro 4: New (not incumbent) cloud providers will =
probably find this easier to implement because they have no legacy. They wi=
ll probably use some form of NoSQL database
 and won't be constrained by the limitations of LDAP directories.






 






Cons:






 






Con 1: Incumbent cloud providers with existing d=
ata stores in a directory format (where multi-valued attributes are stored =
as comma-separated values under a single
 attribute node) will find it difficult to migrate to this model and store =
each attribute value as a sub-node with its own key. This will "hinder=
 adoption of the spec", which is what you fear.






 






Have I summed up the Pros and Cons correctly? I'=
m biased of course, so I could have missed a Con or hyped a Pro :-).=





 




In other words, we're debating interface complex=
ity (current spec) versus implementation complexity (my suggestion). Both c=
an hinder adoption of the spec by different
 parties.






 






Here's what we need to discuss - Do the Pros mak=
e the suggestio
















































































 










 

 

 

 

--_000_56C3C758F9D6534CA3778EAA1E0C34373302C5DDBY2PRD0410MB354_-- From stpeter@stpeter.im Thu Aug 16 09:19:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64F21F85CD for ; Thu, 16 Aug 2012 09:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsQRnqyc6jko for ; Thu, 16 Aug 2012 09:19:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CA0EF21F85B8 for ; Thu, 16 Aug 2012 09:19:04 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0864C404EA for ; Thu, 16 Aug 2012 10:19:34 -0600 (MDT) Message-ID: <502D1D77.6080009@stpeter.im> Date: Thu, 16 Aug 2012 10:19:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "scim@ietf.org" References: <20120816161303.16998.66097.idtracker@ietfa.amsl.com> In-Reply-To: <20120816161303.16998.66097.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120816161303.16998.66097.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [scim] Fwd: I-D Action: draft-scim-api-01.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:19:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, please rename these files so they're easier to track. Either draft-drake-scim-api or (if you have approval from your WG chairs) draft-ietf-scim-api. - -------- Original Message -------- Subject: I-D Action: draft-scim-api-01.txt Date: Thu, 16 Aug 2012 09:13:03 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : System for Cross-Domain Identity Management:Protocol 1.1 Author(s) : Trey Drake Chuck Mortimore Morteza Ansari Kelly Grizzle Erik Wahlstroem Filename : draft-scim-api-01.txt Pages : 47 Date : 2012-08-02 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. 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. It's 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 standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-scim-api There's also a htmlized version available at: http://tools.ietf.org/html/draft-scim-api-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-scim-api-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAtHXcACgkQNL8k5A2w/vzVfwCgqFNk7zUacMsDowrcdg78gJCr B1wAn37KLJcHZbs9zIUZ3ofaDXOkfDxf =tTuQ -----END PGP SIGNATURE----- From tonynad@microsoft.com Thu Aug 16 09:42:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A613021F8498 for ; Thu, 16 Aug 2012 09:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.466 X-Spam-Level: X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5UAQBGJKA+X for ; Thu, 16 Aug 2012 09:42:56 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1141C21F85CD for ; Thu, 16 Aug 2012 09:42:55 -0700 (PDT) Received: from mail41-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Aug 2012 16:42:54 +0000 Received: from mail41-am1 (localhost [127.0.0.1]) by mail41-am1-R.bigfish.com (Postfix) with ESMTP id 8AE081C01A1 for ; Thu, 16 Aug 2012 16:42:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VS-34(zf7Izbb2dI154cP9371I936eIc85fh542Mzz1202h1082kzz1033IL8275dhz2fh2a8h683h839hd25hf0ah107ah1155h) Received-SPF: pass (mail41-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail41-am1 (localhost.localdomain [127.0.0.1]) by mail41-am1 (MessageSwitch) id 1345135372107418_10564; Thu, 16 Aug 2012 16:42:52 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.254]) by mail41-am1.bigfish.com (Postfix) with ESMTP id 94462E01F3 for ; Thu, 16 Aug 2012 16:42:51 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Aug 2012 16:42:46 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.309.3; Thu, 16 Aug 2012 16:42:40 +0000 Received: from mail139-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Aug 2012 16:42:07 +0000 Received: from mail139-ch1 (localhost [127.0.0.1]) by mail139-ch1-R.bigfish.com (Postfix) with ESMTP id 679722000AA for ; Thu, 16 Aug 2012 16:42:07 +0000 (UTC) Received: from mail139-ch1 (localhost.localdomain [127.0.0.1]) by mail139-ch1 (MessageSwitch) id 1345135325310036_28198; Thu, 16 Aug 2012 16:42:05 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail139-ch1.bigfish.com (Postfix) with ESMTP id 4957D340094; Thu, 16 Aug 2012 16:42:05 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Aug 2012 16:42:04 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.203]) by BL2PRD0310HT002.namprd03.prod.outlook.com ([10.255.97.37]) with mapi id 14.16.0190.008; Thu, 16 Aug 2012 16:42:02 +0000 From: Anthony Nadalin To: Peter Saint-Andre , "scim@ietf.org" Thread-Topic: [scim] Fwd: I-D Action: draft-scim-api-01.txt Thread-Index: AQHNe8ro+aOhWqXdd0KksUdX2y38B5dcpIn0 Date: Thu, 16 Aug 2012 16:42:01 +0000 Message-ID: References: <20120816161303.16998.66097.idtracker@ietfa.amsl.com>, <502D1D77.6080009@stpeter.im> In-Reply-To: <502D1D77.6080009@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.83.219] Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9EC812BL2PRD0310MB362_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%STPETER.IM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] Fwd: I-D Action: draft-scim-api-01.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 16:42:57 -0000 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9EC812BL2PRD0310MB362_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't believe there were or are wg adopted drafts so yes this very confus= ing Sent from my Windows Phone ________________________________ From: Peter Saint-Andre Sent: 8/16/2012 11:19 AM To: scim@ietf.org Subject: [scim] Fwd: I-D Action: draft-scim-api-01.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, please rename these files so they're easier to track. Either draft-drake-scim-api or (if you have approval from your WG chairs) draft-ietf-scim-api. - -------- Original Message -------- Subject: I-D Action: draft-scim-api-01.txt Date: Thu, 16 Aug 2012 09:13:03 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : System for Cross-Domain Identity Management:Protocol 1.1 Author(s) : Trey Drake Chuck Mortimore Morteza Ansari Kelly Grizzle Erik Wahlstroem Filename : draft-scim-api-01.txt Pages : 47 Date : 2012-08-02 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. 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. It's 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 standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-scim-api There's also a htmlized version available at: http://tools.ietf.org/html/draft-scim-api-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-scim-api-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAtHXcACgkQNL8k5A2w/vzVfwCgqFNk7zUacMsDowrcdg78gJCr B1wAn37KLJcHZbs9zIUZ3ofaDXOkfDxf =3DtTuQ -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9EC812BL2PRD0310MB362_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I don't belie= ve there were or are wg adopted drafts so yes this very confusing

Sent from my Windows Phone
From: Peter = Saint-Andre
Sent: 8/16/2= 012 11:19 AM
To: scim@i= etf.org
Subject: [scim]= Fwd: I-D Action: draft-scim-api-01.txt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Folks, please rename these files so they're easier to track. Either
draft-drake-scim-api or (if you have approval from your WG chairs)
draft-ietf-scim-api.


- -------- Original Message --------
Subject: I-D Action: draft-scim-api-01.txt
Date: Thu, 16 Aug 2012 09:13:03 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title    &nb= sp;      : System for Cross-Domain Identity
Management:Protocol 1.1
        Author(s)    = ;   : Trey Drake
            &nb= sp;            = Chuck Mortimore
            &nb= sp;            = Morteza Ansari
            &nb= sp;            = Kelly Grizzle
            &nb= sp;            = Erik Wahlstroem
        Filename    =     : draft-scim-api-01.txt
        Pages    &nb= sp;      : 47
        Date    &nbs= p;       : 2012-08-02

Abstract:
   The System for Cross-Domain Identity Management (SCIM) specifi= cation
   is designed to make managing user identity in cloud based
   applications and services easier.  The specification suit= e seeks to
   build upon experience with existing schemas and deployments, p= lacing
   specific emphasis on simplicity of development and integration= , while
   applying existing authentication, authorization, and privacy m= odels.
   It's intent is to reduce the cost and complexity of user manag= ement
   operations by providing a common user schema and extension mod= el, as
   well as binding documents to provide patterns for exchanging t= his
   schema using standard protocols.  In essence, make it fas= t, cheap,
   and easy to move users in to, out of, and around the cloud.

The IETF datatracker status page for this draft is:
https://datatra= cker.ietf.org/doc/draft-scim-api

There's also a htmlized version available at:
http://tools.ietf.= org/html/draft-scim-api-01

A diff from the previous version is available at:
http://www= .ietf.org/rfcdiff?url2=3Ddraft-scim-api-01


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: htt= p://www.ietf.org/shadow.html
or ftp://ftp.ietf.org= /ietf/1shadow-sites.txt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAtHXcACgkQNL8k5A2w/vzVfwCgqFNk7zUacMsDowrcdg78gJCr
B1wAn37KLJcHZbs9zIUZ3ofaDXOkfDxf
=3DtTuQ
-----END PGP SIGNATURE-----
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org= /mailman/listinfo/scim



 --_000_B26C1EF377CB694EAB6BDDC8E624B6E75E9EC812BL2PRD0310MB362_-- From phil.hunt@oracle.com Thu Aug 16 10:42:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4105521F853E for ; Thu, 16 Aug 2012 10:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.809 X-Spam-Level: X-Spam-Status: No, score=-9.809 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYLyc7yzatGz for ; Thu, 16 Aug 2012 10:42:26 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3576121F853C for ; Thu, 16 Aug 2012 10:42:26 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7GHgJIm002193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 17:42:20 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7GHgHR4023961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Aug 2012 17:42:18 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7GHgHdq010238; Thu, 16 Aug 2012 12:42:17 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 16 Aug 2012 10:42:13 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_AE4EDE21-1ECE-440A-B58B-A08229F6FBD5" From: Phil Hunt In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C34373302C5DD@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Thu, 16 Aug 2012 10:42:12 -0700 Message-Id: <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302C5DD@BY2PRD0410MB354.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: Emmanuel Dreux , Anthony Nadalin , Ganesh and Sashi Prasad , Melinda Shore , "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:42:31 -0000 --Apple-Mail=_AE4EDE21-1ECE-440A-B58B-A08229F6FBD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I do think we need to arrive at some consensus on this now because = Ganesh's proposal is a major "fork-in-the-road" decision. If we table = it, it will be hard to come back to. This is why I have engaged on the = subject with Ganesh so thoroughly. Never-the-less, I would like to = arrive at some conclusions here. My apologies, but I thought it was worth re-stating the problem for = those late to the discussion would be useful. Background: At present, the current spec does not allow you to change a specific = sub-attribute in a multi-valued complex attribute structure (e.g. = changing street name in a specific address value instance such as = "home"). The proposal is that each sub attribute in a multi-valued = structure gets its own unique identifier. Then you can directly = reference the specific complex attribute component in a complex value. The current draft proposal requires that complex-value (e.g. an address = value which is made up of number, street, city, etc) be changed if you = want to change any of the sub-attributes. The current approach seems a = reasonable compromise since it is likely the collection of attributes in = a complex "value" are often manipulated together. IOW. You tend to set = them all at once. Ganesh's proposal allows specific sub-attributes to = be directly addressable by giving each value instance a unique = identifier. =20 Another example of this is the group "member" attribute. In the current = draft, a member can have a value and a display name. In this case you = would usually change the value (object identifier) and the name as well. = Ganesh's proposal would allow "Display Name" to be changed or value to = be changed. Something, IMV, that doesn't occur nearly as often. IOW = members change group membership, but members rarely change names. My conclusion: If the client must first query (or have synchronized the value = identifiers), then the client has to do even more work than the current = proposal of replacing the enter complex value. Given such a choice I'm = really skeptical that the pattern proposed by Ganesh would be widely = used. While Ganesh's proposal may be "specific", the practical = simplicity of it is very much debatable. The benefit of specific sub-attribute identifiers needs to be = substantial. We're not only talking about changing how infrastructure = is done, but also how applications are written. This leaves out the = entire current adopters and all enterprise users. A big concern we have = obviously is we have to consider existing infrastructure and data stores = and be realistic. I don't think the benefit is worth the cost. I agree with the others that the current draft could be changed to make = patch operations more clear to the developer (simpler to read). While = this may not improve logic, it will improve understanding and = simplicity. The fact that certain operations may require an entire = complex attribute value to be replaced is a reasonable compromise and = should not be changed.=20 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote: > Hi Ganesh =85 your write-up concedes that this will be difficult to = implement for an existing service provider. I=92m not sure that I = understand the compromise. Are you still suggesting that SCIM move to = the unique-key-per-element strategy? > =20 > If so, the cost/benefit of this seems way off to me. You are gaining = a more elegant API by introducing an additional datastore and requiring = replication. I don=92t know of any service provider that would make = this trade-off. As you said, this is something that future service = providers can keep in mind, but it is not going to help existing = providers. > =20 > --Kelly > =20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Thursday, August 16, 2012 5:38 AM > To: Anthony Nadalin > Cc: Kelly Grizzle; Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil = Hunt > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > Hi all, > =20 > Would this hybrid architecture be a workable compromise? See diagram = towards the end: http://bit.ly/Rjc39Y > =20 > Regards, > Ganesh >=20 > On 15 August 2012 05:54, Anthony Nadalin = wrote: > We should not be constrained by LDAP restrictions, this would not be = productive. > =20 > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Ganesh and Sashi Prasad > Sent: Monday, August 13, 2012 2:07 PM > To: Kelly Grizzle > Cc: Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > Thanks, Kelly. You've been most patient in hearing me out, I must say. = I couldn't ask for more. > =20 > Replying to Chris Philips's mail: > > Given that you have a number of thoughts about what could be changed = in SCIM,Leif's recommendation to craft them in an Internet Draft may be = a better way to convey your thoughts. >=20 > I'm coming around to the same conclusion. Do you think such an = Internet Draft should be about changing SCIM, or should it propose a = complementary spec for SPs who use a "NoLDAP" data store? I think the = underlying problem is with LDAP, and unless we change that, these = proposals won't fly. > =20 > Regards, > Ganesh >=20 > On 14 August 2012 01:54, Kelly Grizzle = wrote: > There are really two implementation options for a uid per element =96 = either store the uids in the native underlying data store or have some = secondary data store that maps elements to their uids. The third option = is to hope that a service provider has a NoLDAP data store or its = equivalent. None of these are practical for rapid and wide-spread = adoption. > =20 > > put the two together to propose a solution. > =20 > As I said before, I am completely on board with cleaning up the PATCH = semantics (eg =96 the inconsistency between meta.attributes and = operation=3Ddelete, etc=85). Your suggestion of using different verbs = is a good option to consider. This cannot be based on a uid per = element, though. It seems as though you have admitted this in your = conclusion =96 =93As for LDAP and SCIM, I guess the best TLA is RIP.=94 > =20 > --Kelly > =20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 9:56 AM > To: Kelly Grizzle > Cc: Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > That was one suggestion. Another way could be container nodes with = their own "dn"s. If one suggestion won't work, tell me another way to = make it work. I'm waiting to hear a constructive suggestion that can = square an elegant API with the implementation constraints that come from = having to store multi-valued attributes in LDAP directories. > =20 > I've heard enough of WHY this won't work. For a change, tell me HOW it = can be made to work. Everyone now knows what the proposal means in terms = of the API, and implementors understand the constraints of legacy data = stores, so put the two together to propose a solution. C'mon, we have = the "smartest guys in the room" here, surely we should be able to crack = this. > =20 > Regards, > Ganesh > =20 > P.S. I'm rapidly reaching my own conclusions about what is to be done: > = http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-nol= dap.html=20 > =20 >=20 > On 14 August 2012 00:27, Kelly Grizzle = wrote: > > After all, no one has challenged the claim that this proposal = drastically simplifies the API for the client > =20 > I agree that your proposal makes PATCH semantics simpler and more = elegant. > =20 > =20 > > =85 so it would appear to be worth doing.=20 > =20 > I strongly disagree here. This statements assumes that simplicity of = the client API is the only factor that should be considered with the = spec. > =20 > Emmanuel=92s example is from a real-world service provider that would = not be able to implement the spec easily with a uid per element. He is = working on a SCIM interface that will help facilitate data exchange = between multiple Active Directory servers. Your solution was to change = the data model from this: > =20 > mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com > =20 > to this: > =20 > mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com > =20 > I do not know of a single organization that would change their Active = Directory data model to fit this. For one thing, it would be a huge = data migration effort (likely across other domain controllers, etc=85) = to assign these unique identifiers. This also assumes that SCIM is the = only reader/writer of this data, which will almost never be the case. = If the data model requires uids for every element, then every piece of = non-SCIM code that writes data into the directory will have to follow = this. Additionally, there are *many* tools and applications (eg =96 = address books) that rely on a certain data model in Active Directory, = and this would cause them to break. IMO this same argument holds true = for most service providers. > =20 > =20 > PATCH is an optional part of the spec. It was primarily introduced to = make modifying resources with large multi-valued lists more efficient. = It does not need to solve every problem (eg =96 modifying sub-elements = in nested arrays). Adding uids to every multi-valued element does not = strike the right balance between the needs of the client and the needs = of the service provider. > =20 > --Kelly > =20 > From: Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Sent: Monday, August 13, 2012 1:35 AM > To: Phil Hunt; Melinda Shore > Cc: Emmanuel Dreux; Kelly Grizzle; scim@ietf.org >=20 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > Responding to extract of Melinda Shore's mail from digest: > =20 > The issue being raised here isn't endpoint logic, but > network traffic, and I'm pretty sure it's not very helpful to > respond to the observation that your model requires more > messages with a complaint about what you seem to think is a > complex algorithm for attribute processing. > =20 > It depends on how it's implemented. I'm confident we can have the best = of both - simple API with low-overhead implementation. Can we brainstorm = HOW this proposal can be implemented rather than WHY it can't be = implemented (which is mostly what I've been hearing so far)? After all, = no one has challenged the claim that this proposal drastically = simplifies the API for the client, so it would appear to be worth doing. = I'm sure there's more than enough intellectual horsepower in this = working group to pull this off if we put our minds to it. > =20 > Regards, > Ganesh > =20 > On 13 August 2012 13:54, Ganesh and Sashi Prasad = wrote: > > I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty. >=20 > Sorry Phil, but you're contradicting yourself here. There seems to be = an awful lot of matching (i.e., reading) going on in the spec as it = stands, with if-then clauses to do one thing or another if the match = either succeeds or fails. This is a complex, chatty protocol right now! > =20 > Multi-valued attributes: An attribute value in the PATCH request > body is added to the value collection if the value does not = exist > and merged if a matching value is present. Values are matched = by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute; e.g., addresses, or do not have = unique > value Sub-Attributes cannot be matched and must instead be = deleted > then added. Specific values can be removed from a Resource by > adding an "operation" Sub-Attribute with the value "delete" to = the > attribute in the PATCH request body. As with adding/updating > attribute value collections, the value to delete is determined = by > comparing the value Sub-Attribute from the PATCH request body to > the value Sub-Attribute of the Resource. Attributes that do not > have a value Sub-Attribute or that have a non-unique value Sub- > Attribute are matched by comparing all Sub-Attribute values from > the PATCH request body to the Sub-Attribute values of the > Resource. A delete operation is ignored if the attribute's name > is in the meta.attributes list. If the requested value to = delete > does not match a unique value on the Resource the server MAY > return a HTTP 400 error. > =20 > For a spec that is supposed to be about simplicity, the above = description is anything but simple. I know you guys have worked hard on = this and I don't mean to disparage those efforts, but think about how = the above passage would appear to a new reader (i.e., a novice to the = spec, not a technology novice). > =20 > There is something fundamentally broken, and it is this: multi-valued = attributes without a unique identifier per value. If you don't fix that, = you won't get simplicity. > =20 > We know LDAP trees are broken for multi-valued attributes. As Mark = Wahl famously commented back in 2005, > =20 > "Unfortunately, some of the emerging protocols which also intend to = represent and transfer personal identity information have perhaps taken = a step backwards by not even considering these issues, perhaps sweeping = them under the rug in the guise of simplicity, XMLification, or "fix in = the next version", which only postpone finding interoperable solutions = to allowing applications to express the identity entries they want to = express." > =20 > SCIM is exactly one of these "emerging protocols" Wahl talks about, = and what I see now strikes me as "sweeping these issues under the rug in = the guise of simplicity". Apologies for the bluntness. > =20 > My take is that SPs are _already_ struggling to manage multi-valued = attributes, and existing mechanisms are clumsy. They would be grateful = for a specification that made operations easier at the cost of a = re-engineered schema. That calls for some thought leadership from this = working group. > =20 > Regards, > Ganesh > =20 >=20 > On 13 August 2012 10:13, Phil Hunt wrote: > I strongly object to anything that leads to a read before modify = requirement. Too complex and too chatty.=20 >=20 > Phil >=20 > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad = wrote: >=20 > > Would it have to be stored on the account database of the service = provider? > =20 > Yes. > =20 > > If so, I believe that this is impracticable in the core schema. = Indeed it implies that a service provider must extend the schema of his = account repository (LDAP partition, SQL db, =85) and =93prepare it=94 = for SCIM integration. > =20 > Why? That doesn't necessarily follow. Implementation is independent of = representation. We're talking about a change in representation to make = the API cleaner. > =20 > As a simple example, if an LDAP node is being used to hold a list of = comma-separated email addresses, it can just as easily store = comma-separated name-value pairs. > =20 > mail: john_smith@yahoo.com, john.smith@gmail.com, = jsmith1970@hotmail.com > can be changed to > =20 > mail: = aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gm= ail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com > =20 > That's why I asked if there was an SP representative on this working = group who could explain what such a change could mean for them. As of = now, it looks like other people are presuming that SPs will not be able = to implement these changes easily and are rejecting them for that = reason. > =20 > Regards, > Ganesh > =20 > On 13 August 2012 04:29, Emmanuel Dreux wrote: > =F0 addresses.3cbaaff8e84e.street-number =3D "243" >=20 > =20 > Where would 3cbaaff8e84e come from? Would it have to be stored on the = account database of the service provider? > =20 > If so, I believe that this is impracticable in the core schema. Indeed = it implies that a service provider must extend the schema of his account = repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM = integration. > This would be a show stopper. SCIM must be transparent, and must be = able to be put on top of an existing system to provide provisioning = apis. > =20 > Said differently, SCIM must not be intrusive for existing systems and = must not require modifications to allow its integration. > Correct me if I misunderstood your suggestion. > =20 > -- > Regards, > Emmanuel Dreux > http://www.cloudiway.com > Tel: +33 4 26 78 17 58 > Mobile: +33 6 47 81 26 70 > skype: Emmanuel.Dreux > =20 > De : Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=20 > Envoy=E9 : dimanche 12 ao=FBt 2012 04:53 > =C0 : Kelly Grizzle > Cc : scim@ietf.org; Phil Hunt > Objet : Re: [scim] scim Digest, Vol 8, Issue 24 > =20 > > Multi-valued attributes that don't have a value sub-attribute (eg - = address) have to specified completely for uniqueness. =20 > =20 > That's exactly the point. How do we "specify completely for = uniqueness"? > =20 > In the example below, how are you proposing that the following element = be updated if we can't use positional indexes? > =20 > addresses[1].street-number =3D "243" > =20 > User object: > =20 > { > ... > addresses: [ > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > ] > } > =20 > It's impractical to use the value because it's the whole dictionary = element: > =20 > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > =20 > With my proposal, the "addresses" array gets converted to a = dictionary, and then we have a stable way of referencing this element: > =20 > addresses.3cbaaff8e84e.street-number =3D "243" > =20 > { > ... > addresses: { > "d6ea365462f5" : > { > "type" : "home", > "street-number" : "35", > "street-name" : "High Road", > "suburb" : "East Camden", > "postcode" : "5346", > "state" : "SA", > "country" : "Australia" > }, > "3cbaaff8e84e" : > { > "type" : "office", > "street-number" : "213", > "street-name" : "Main Street", > "suburb" : "Adelaide", > "postcode" : "5000", > "state" : "SA", > "country" : "Australia" > } > } > } > =20 > If you're proposing one mechanism for composite attributes and another = mechanism for simple attributes, I would suggest that's actually more = complex than adopting a single mechanism that works the same way for = _all_ attributes. Remember that a lot of the administration is probably = going to be scripted rather than done by hand, and having two mechanisms = (depending on whether the attribute is simple or composite) will = complicate every script that has to be written. > =20 > There's a lot of talk about the "burden" on the SPs, but I believe = this is overblown. Is there any SP representative in this WG who can = tell us what this proposal will actually entail for them? > =20 > Regards, > Ganesh > =20 > On 12 August 2012 11:53, Kelly Grizzle = wrote: > Ganesh, > =20 > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes = that have a value sub-attribute can be removed by specifying only the = value since it is unique. Multi-valued attributes that don't have a = value sub-attribute (eg - address) have to specified completely for = uniqueness. As I have said before, I am very opposed to adding a unique = identifier to each element in a multi-valued collection due to the = burden it will put on SPs. Is it elegant? No. Is it functional? Yes. = Will this non-elegance affect adoption? My opinion is that adding = unique keys to each element will have a much more detrimental effect on = adoption. > =20 > I do believe that in general PATCH can be made more intuitive without = adding uids to each element. The verbs that you propose make sense. = There is also a JSON Patch informational draft in the IETF that is = interesting - = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies = on a JSON Pointer draft which uses index-based addressing for = multi-valued attributes. I think that this is something that should be = looked at within the WG and I would be willing to lead this effort. > =20 > I'm curious if anyone else in the WG is in favor of unique identifiers = for every multi-valued element. > =20 > --Kelly > =20 > From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of = Ganesh and Sashi Prasad [g.c.prasad@gmail.com] > Sent: Saturday, August 11, 2012 10:50 AM > To: Phil Hunt > Cc: scim@ietf.org > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > Phil, > =20 > The reason we cannot use the value itself to identify an element is = that this method will only work for simple elements, not for nested = structures. i.e., if we had an array of dictionaries (e.g., we had to = record an array of addresses for each customer, with each address = element having sub-elements like street number, street name, suburb, = etc.), then it would be clumsy to supply the entire value of the array = element because it's itself a dictionary. Creating a unique key for each = element scales better. > =20 > Regards, > Ganesh >=20 > On 12 August 2012 01:12, Phil Hunt wrote: > Ganesh, > =20 > Here's the sample that concerned me... > The two operations differ significantly, and it's not very intuitive.=20= > With my suggestion, here's how to delete a single member from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com = Accept: application/json Authorization: Bearer h480djs93hd8 ETag: = W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] } > =20 > =20 > You gave other examples of an attribute with an identifier that = matched that value or of identifiers that were additional unique keys. > =20 > Given that multi-values must be each unique, I don't see the point of = the extra indexing to support this. Just use the value as the item you = wish to delete. > =20 > I agree, the delete value operation could be more explicit and clear = in general. > =20 > Phil > =20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 > =20 > =20 >=20 > =20 > On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad wrote: > =20 >=20 > > For the multi-value example you gave you used the value as the = attribute name key.=20 > =20 > Now I'm confused :-). I don't believe any of my examples ever used a = value as the key. > =20 > Could you please show me which example you mean, and which parts of it = you believe to be the value? > =20 > Regards, > Ganesh=20 >=20 > On 11 August 2012 13:59, Phil Hunt wrote: >=20 > For the multi-value example you gave you used the value as the = attribute name key.=20 > =20 > That means a lot more complex indexing structure. Better to just say = delete a specific value.=20 > =20 > The spec already allows multiple values to have tags like home, work, = etc. > =20 > Phil >=20 > On 2012-08-10, at 21:45, Ganesh and Sashi Prasad = wrote: >=20 > > In your example you are conflating value with an attribute id.=20 >=20 > I don't believe so. > =20 > I'm adopting a model where every attribute of the resource is a = key-value pair. The key is a name or ID. > =20 > For non-repeating attributes (both simple and composite), the key is = the attribute name itself.=20 > =20 > Simple attribute: > =20 > Key: "dob" > Value: "01 Jan 1970" > =20 > For composite attributes, the key employs dot notation to specify the = fully-qualified attribute name, e.g., "address.postcode". > =20 > Composite attribute: > =20 > Key: "address.street-number" > Value: "10" > =20 > Key: "address.suburb" > Value: "East Camden" > =20 > For repeating (multi-valued) attributes, I'm suggesting that there be = new keys for each individual value, otherwise they are impossible to = distinguish, and a positional index is inadequate. So we convert the = array into a dictionary and this then becomes a composite attribute = using dot notation for the key. > =20 > Multi-valued attribute: > =20 > Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902" > Value: "john_smith@yahoo.com" > =20 > So this allows us to apply uniform treatment to any arbitrarily deep = resource structure. We can refer to every leaf value with a key that is = the fully-qualified name using dot notation. > =20 > The verbs are just unambiguous operations on these (now) explicitly = addressable attributes. > =20 > INCLUDE to a collection and specify only the value. The key is = generated and returned. The fully-qualified key is = . and the value is what was = specified in the INCLUDE. > =20 > REPLACE a fully-qualified key with a new value. If the key doesn't = exist, return a "404 Not Found". > =20 > PLACE a value at the logical location implied by the fully-qualified = key. If there is already a key with that name, return a "409 Conflict". > =20 > FORCE the fully-qualified key to hold the given value, regardless of = whether it existed before or not. Only errors possible are "400 Bad = Request" and "500 Internal Error". > =20 > RETIRE an attribute or a collection given its fully-qualified key. The = implementation will determine whether the attribute will disappear = entirely or will exist holding a null value (the blank string "" or the = empty object {} ). > =20 > I'll explain in a separate post why we need operation verbs like these = that are independent of the HTTP verbs. > =20 > Regards, > Ganesh > =20 > On 11 August 2012 10:38, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/scim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send scim mailing list submissions to > scim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org >=20 > You can reach the person managing the list at > scim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." >=20 > Today's Topics: >=20 > 1. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt) >=20 >=20 > ---------- Forwarded message ---------- > From: Phil Hunt > To: Ganesh and Sashi Prasad > Cc: "Diodati, Mark" , Emmanuel Dreux = , Trey Drake , Kelly = Grizzle , "scim@ietf.org" > Date: Fri, 10 Aug 2012 17:36:54 -0700 > Subject: Re: [scim] SCIM Protocol - 3 suggestions for improvement > Ganesh, > =20 > In your example you are conflating value with an attribute id. I find = that confusing.=20 > =20 > I agree though that operations in patch could be a lot more explicit.=20= > =20 > Eg explicitly deleting a value by saying delete or retire.=20 >=20 > Phil >=20 > On 2012-08-10, at 16:19, Ganesh and Sashi Prasad = wrote: >=20 > > I am concerned about your second suggestion:=20 > =20 > Let's discuss that now. > =20 > The trade-offs are very clear here. > =20 > Pros: > =20 > Pro 1. The API to manipulate resources becomes so much cleaner, = consistent and intuitive when every individual attribute value gets its = own ID. > =20 > Here's how to delete a single member from a Group, as per the current = spec: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "members": [ > { > "display": "Babs Jensen", > "value": "2819c223-7f76-453a-919d-413861904646" > "operation": "delete" > } > ] > } >=20 > Here's how to delete ALL members from a group according to the current = spec: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce > Host: example.com > Accept: application/json > Authorization: Bearer h480djs93hd8 > ETag: W/"a330bc54f0671c9" > =20 > { > "schemas": ["urn:scim:schemas:core:1.0"], > "meta": { > "attributes": [ > "members" > ] > } > } >=20 > The two operations differ significantly, and it's not very intuitive.=20= > With my suggestion, here's how to delete a single member from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: = example.comAccept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members.2819c223-7f76-453a-919d-413861904646" > } > } > ] }=20 > Here's how I suggest deleting ALL members from a group: > =20 > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: = example.comAccept: application/json Authorization: Bearer h480djs93hd8 = ETag: W/"a330bc54f0671c9" { > "operations" : [ > { > "RETIRE" : { > "key" : "members" > } > } > ] } >=20 > I'm sure you'll agree that this is simpler, more consistent and more = intuitive to a reader. > =20 > Pro 2: We can apply this mechanism consistently to three areas: > (a) Manipulating multi-valued attributes of a resource > (b) Manipulating members of a group > (c) Performing bulk operations, where we simply use HTTP verbs instead = of the specialised (and semantically less ambiguous) verbs I suggested = for attributes, the "key" becomes the URI, and the "value" becomes the = corresponding JSON object. > =20 > All of them return "207 Multi-Status" with the "results" array holding = individual status codes. > =20 > In the current spec, (a) and (b) are done similarly but (c) is very = different. > =20 > Pro 3: Adoption of the standard by clients is likely to be higher = because it's simpler for them. > =20 > Pro 4: New (not incumbent) cloud providers will probably find this = easier to implement because they have no legacy. They will probably use = some form of NoSQL database and won't be constrained by the limitations = of LDAP directories. > =20 > Cons: > =20 > Con 1: Incumbent cloud providers with existing data stores in a = directory format (where multi-valued attributes are stored as = comma-separated values under a single attribute node) will find it = difficult to migrate to this model and store each attribute value as a = sub-node with its own key. This will "hinder adoption of the spec", = which is what you fear. > =20 > Have I summed up the Pros and Cons correctly? I'm biased of course, so = I could have missed a Con or hyped a Pro :-). > =20 > In other words, we're debating interface complexity (current spec) = versus implementation complexity (my suggestion). Both can hinder = adoption of the spec by different parties. > =20 > Here's what we need to discuss - Do the Pros make the suggestio > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail=_AE4EDE21-1ECE-440A-B58B-A08229F6FBD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

My = apologies, but I thought it was worth re-stating the problem for those = late to the discussion would be = useful.

Background:
At present, the = current spec does not allow you to change a specific sub-attribute in a = multi-valued complex attribute structure (e.g. changing street name in a = specific address value instance such as "home").  The proposal is = that each sub attribute in a multi-valued structure gets its own unique = identifier.  Then you can directly reference the specific complex = attribute component in a complex value.

The = current draft proposal requires that complex-value (e.g. an address = value which is made up of number, street, city, etc) be changed if you = want to change any of the sub-attributes. The current approach seems a = reasonable compromise since it is likely the collection of attributes in = a complex "value" are often manipulated together. IOW. You tend to set = them all at once.  Ganesh's proposal allows specific sub-attributes = to be directly addressable by giving each value instance a unique = identifier.   

Another example of = this is the group "member" attribute.  In the current draft, a = member can have a value and a display name. In this case you would = usually change the value (object identifier) and the name as well. =  Ganesh's proposal would allow "Display Name" to be changed or = value to be changed.  Something, IMV, that doesn't occur nearly as = often.  IOW members change group membership, but members rarely = change names.

My conclusion:
If the = client must first query (or have synchronized the value identifiers), = then the client has to do even more work than the current proposal of = replacing the enter complex value.  Given such a choice I'm really = skeptical that the pattern proposed by Ganesh would be widely used. =  While Ganesh's proposal may be "specific", the practical = simplicity of it is very much debatable.

The benefit = of specific sub-attribute identifiers needs to be substantial. =  We're not only talking about changing how infrastructure is done, = but also how applications are written. This leaves out the entire = current adopters and all enterprise users.  A big concern we have = obviously is we have to consider existing infrastructure and data stores = and be realistic. I don't think the benefit is worth the = cost.

I agree with the others that the current = draft could be changed to make patch operations more clear to the = developer (simpler to read). While this may not improve logic, it will = improve understanding and simplicity. The fact that certain operations = may require an entire complex attribute value to be replaced is a = reasonable compromise and should not be = changed. 

Phil

On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote:

Hi Ganesh =85 your write-up concedes that this will = be difficult to implement for an existing service provider.  I=92m = not sure that I understand the compromise.  Are you still = suggesting that SCIM move to the unique-key-per-element = strategy?
 
If so, the cost/benefit of this = seems way off to me.  You are gaining a more elegant API by = introducing an additional datastore and requiring replication.  I = don=92t know of any service provider that would make this = trade-off.  As you said, this is something that future service = providers can keep in mind, but it is not going to help existing = providers.
 
 
 Ganesh = and Sashi Prasad [mailto:g.c.prasad@gmail.com] 
Sent: Thursday, August 16, 2012 = 5:38 AM
To: Anthony = Nadalin
Cc: Kelly Grizzle; Emmanuel = Dreux; Melinda Shore; scim@ietf.org; = Phil Hunt
Subject: Re: [scim] scim Digest, Vol = 8, Issue 24
Hi all,
 
Would this hybrid = architecture be a workable compromise? See diagram towards the end: http://bit.ly/Rjc39Y
 
Ganesh

From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ganesh and Sashi = Prasad
Sent: Monday, August 13, 2012 = 2:07 PM
To: Kelly = Grizzle
Cc: Emmanuel Dreux; Melinda = Shore; scim@ietf.org; Phil = Hunt
 Re: [scim] scim Digest, Vol = 8, Issue 24
 
Thanks, Kelly. You've = been most patient in hearing me out, I must say. I couldn't ask for = more.
 
Replying to Chris Philips's = mail:
> Given that you have a number of = thoughts about what could be changed in SCIM,Leif's recommendation to =  craft them in an Internet Draft may be a better way to convey your = thoughts.

I'm coming around to the same conclusion. Do you = think such an Internet Draft should be about changing SCIM, or should it = propose a complementary spec for SPs who use a "NoLDAP" data store? I = think the underlying problem is with LDAP, and unless we change that, = these proposals won't fly.
 
Ganesh

 

mail: john_smith@yahoo.com, john.smith@gmail.com, to this:
The issue being raised here isn't endpoint =
logic, but
network traffic, and I'm pretty sure it's =
not very helpful to
respond to the observation that your =
model requires more
messages with a complaint about what =
you seem to think is a
complex algorithm for attribute =
processing.
   Multi-valued =
attributes:  An attribute value in the PATCH =
request
      and =
merged if a matching value is present.  Values are matched =
by
      the value Sub-Attribute of the =
Resource.  Attributes that do not
      have =
a value Sub-Attribute; e.g., addresses, or do not have =
unique
      then =
added.  Specific values can be removed from a Resource =
by
      =
attribute in the PATCH request body.  As with =
adding/updating
      =
comparing the value Sub-Attribute from the PATCH request body =
to
      have =
a value Sub-Attribute or that have a non-unique value =
Sub-
      the PATCH request body to the =
Sub-Attribute values of the
      =
Resource.  A delete operation is ignored if the attribute's =
name
      does =
not match a unique value on the Resource the server =
MAY
For a spec that is =
supposed to be about simplicity, the above description is anything but =
simple. I know you guys have worked hard on this and I don't mean to =
disparage those efforts, but think about how the above passage would =
appear to a new reader (i.e., a novice to the spec, not a technology =
novice).
My take is that SPs = are _already_ struggling to manage multi-valued attributes, and existing mechanisms are clumsy. They = would be grateful for a specification that made operations easier at the = cost of a re-engineered schema. That calls for some thought leadership = from this working group.
 
 

On 13 August 2012 = 10:13, Phil Hunt <I strongly object to anything that leads to a read before = modify requirement. Too complex and too chatty. 
On 2012-08-12, at 15:29, Ganesh and Sashi = Prasad <
> Would it have = to be stored on the account database of the service = provider?
 
 
Why? That doesn't = necessarily follow. Implementation is independent of representation. = We're talking about a change in representation to make the API = cleaner.
As a simple example, = if an LDAP node is being used to hold a list of comma-separated email = addresses, it can just as easily store comma-separated name-value = pairs.
On 13 August 2012 = 04:29, Emmanuel Dreux <=F0  addresses.3cbaaff8e84e= .street-number =3D "243"

 
Where would 3cbaaff8e84e come from? Would it have to = be stored on the account database of the service = provider?
 
If so, I believe = that this is impracticable in the core schema. Indeed it implies that a = service provider must extend the schema of his account repository (LDAP = partition, SQL db, =85) and =93prepare it=94 for SCIM = integration.
This would be a show stopper. SCIM must be = transparent, and must be able to be put on top of an existing system to = provide provisioning apis.
Said differently, SCIM must not be intrusive for = existing systems and must not require modifications to allow its = integration.
Correct me if I misunderstood your = suggestion.
 
--
Emmanuel Dreux
skype: Emmanuel.Dreux
De : Ganesh and Sashi = Prasad [mailto: 
Envoy=E9 : dimanche 12 ao=FBt 2012 = 04:53
=C0 : Kelly = Grizzle
Cc : scim@ietf.org; Phil = Hunt
Objet : Re: [scim] scim Digest, Vol = 8, Issue 24
 
>  Multi-valued attributes that don't have a value sub-attribute = (eg - address) have to specified completely for = uniqueness.  
 
That's exactly the point. How do we = "specify completely for = uniqueness"?
 
In the example below, how are you = proposing that the following element be updated if we can't use = positional indexes?
 
addresses[1].street-number =3D = "243"
 
User = object:
 
{
  = ...
  addresses: [
    = {
      "type" : = "home",
      "street-number" : = "35",
      "street-name" : "High = Road",
      "suburb" : "East = Camden",
      "postcode" : = "5346",
      "state" : = "SA",
      "country" : = "Australia"
    },
    = {
      "type" : = "office",
      "street-number" : = "213",
      "street-name" : "Main = Street",
      "suburb" : = "Adelaide",
      "postcode" : = "5000",
      "state" : = "SA",
      "country" : = "Australia"
    }
  = ]
}
 
It's impractical to use the value because = it's the whole dictionary = element:
 
{
  "type" : = "office",
  "street-number" : = "213",
  "street-name" : "Main = Street",
  "suburb" : = "Adelaide",
  "postcode" : = "5000",
  "state" : = "SA",
  "country" : = "Australia"
}
 
With my proposal, the "addresses" array = gets converted to a dictionary, and then we have a stable way of = referencing this element:
 
addresses.3cbaaff8e84e.street-number =3D = "243"
 
{
  = ...
  addresses: {
    "d6ea365462f5" = :
    {
      "type" : = "home",
      "street-number" : = "35",
      "street-name" : "High = Road",
      "suburb" : "East = Camden",
      "postcode" : = "5346",
      "state" : = "SA",
      "country" : = "Australia"
    },
    "3cbaaff8e84e" = :
    {
      "type" : = "office",
      "street-number" : = "213",
      "street-name" : "Main = Street",
      "suburb" : = "Adelaide",
      "postcode" : = "5000",
      "state" : = "SA",
      "country" : = "Australia"
    }
  = }
}
 
If you're proposing one mechanism for = composite attributes and another mechanism for simple attributes, I = would suggest that's actually more complex than adopting a single = mechanism that works the same way for _all_ attributes. Remember that a = lot of the administration is probably going to be scripted rather than = done by hand, and having two mechanisms (depending on whether the = attribute is simple or composite) will complicate every script that has = to be written.
 
There's a lot of talk about the "burden" = on the SPs, but I believe this is overblown. Is there any SP = representative in this WG who can tell us what this proposal will = actually entail for them?
 
Regards,
Ganesh
 

 scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf = of Ganesh and Sashi Prasad [ Saturday, August 11, 2012 = 10:50 AM
To: Phil = Hunt
Cc: scim@ietf.org
Subject: Re: [scim] scim Digest, Vol = 8, Issue 24

Phil,
 
The reason we cannot use the value itself = to identify an element is that this method will only work for simple = elements, not for nested structures. i.e., if we had an array of = dictionaries (e.g., we had to record an array of addresses for each = customer, with each address element having sub-elements like street = number, street name, suburb, etc.), then it would be clumsy to supply = the entire value of the array element because it's itself a dictionary. = Creating a unique key for each element scales = better.
 
Regards,

Ganesh

On = 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> = wrote:
Ganesh,
 
Here's the sample that concerned = me...
The two operations differ significantly, = and it's not very = intuitive. 
With my suggestion, here's how to delete a = single member from a group:
 
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce = Host: example.com Accept: application/json = Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" = {
"operations" : = [
"RETIRE" : = {
"key" : = "members.2819c223-7f76-453a-919d-413861904646"
}
}
] = }
 
 
You gave other examples of an attribute with an = identifier that matched that value or of identifiers that were = additional unique keys.
 
Given that multi-values must be each unique, I don't = see the point of the extra indexing to support this. Just use the value = as the item you wish to delete.
 
I agree, the delete value operation could be more = explicit and clear in general.
 
<= div>

 

 

Ganesh 


For the multi-value example you gave you used the value = as the attribute name key. 
 
That means a lot more complex indexing = structure. Better to just say delete a specific = value. 
 
The spec already allows multiple values to = have tags like home, work, etc.

On 2012-08-10, at 21:45, Ganesh and Sashi = Prasad <
> In your example you are = conflating value with an attribute id. 

I don't believe = so.
 
I'm adopting a model where every attribute = of the resource is a key-value pair. The key is a name or = ID.
 
For non-repeating attributes (both simple = and composite), the key is the attribute name = itself. 
 
Simple = attribute:
 
Key: = "dob"
Value: "01 Jan 1970"
 
For composite attributes, the key employs = dot notation to specify the fully-qualified attribute name, e.g., = "address.postcode".
 
Composite = attribute:
 
Key: = "address.street-number"
Value: = "10"
 
Key: = "address.suburb"
Value: "East = Camden"
 
For repeating (multi-valued) attributes, = I'm suggesting that there be new keys for each individual value, = otherwise they are impossible to distinguish, and a positional index is = inadequate. So we convert the array into a dictionary and this then = becomes a composite attribute using dot notation for the = key.
 
Multi-valued = attribute:
 
Key: = "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd902"
If = you have received this digest without all the individual = message
attachments you will need to update your digest options in = your list
subscription.  To do so, go to

MIME or = Plain Text Digests?" to MIME.  You can set this option
globally = for all the list digests you receive at this point.



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

To subscribe or = unsubscribe via the World Wide Web, visit
      =    scim-request@ietf.org

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

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

Today's Topics:

  =  1. Re: SCIM Protocol - 3 suggestions for improvement (Phil = Hunt)


---------- Forwarded message = ----------
From: Phil Hunt <Mark.Diodati@gartner.com>, = Emmanuel Dreux <trey.drake@unboundid.com>, = Kelly Grizzle <Ganesh,


On 2012-08-10, at 16:19, = Ganesh and Sashi Prasad <

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce = Host: example.comAccept: application/json = Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" = {
"operations" : = [
"RETIRE" : = {
"key" : = "members.2819c223-7f76-453a-919d-413861904646"
}
}
] } 
Here's how I suggest deleting ALL members from a = group:
 
PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce = Host: example.comAccept: application/json = Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0671c9" = {
"operations" : = [
"RETIRE" : = {
"key" : = "members"
] = }

I'm sure you'll agree that this is simpler, more = consistent and more intuitive to a = reader.
 
Pro 2: We can apply this mechanism = consistently to three areas:
(a) Manipulating multi-valued attributes = of a resource
(b) Manipulating members of a = group
(c) = Performing bulk operations, where we simply use HTTP verbs instead of = the specialised (and semantically less ambiguous) verbs I suggested for = attributes, the "key" becomes the URI, and the "value" becomes the = corresponding JSON object.
 
All of them return "207 Multi-Status" with = the "results" array holding individual status = codes.
 
In the current spec, (a) and (b) are done = similarly but (c) is very = different.
 
Pro 3: Adoption of the standard by clients = is likely to be higher because it's simpler for = them.
 
Pro 4: New (not incumbent) cloud providers = will probably find this easier to implement because they have no legacy. = They will probably use some form of NoSQL database and won't be = constrained by the limitations of LDAP = directories.
 
Cons:
 
Con 1: Incumbent cloud providers with = existing data stores in a directory format (where multi-valued = attributes are stored as comma-separated values under a single attribute = node) will find it difficult to migrate to this model and store each = attribute value as a sub-node with its own key. This will "hinder = adoption of the spec", which is what you = fear.
 
Have I summed up the Pros and Cons = correctly? I'm biased of course, so I could have missed a Con or hyped a = Pro :-).
 
In = other words, we're debating interface complexity (current spec) versus = implementation complexity (my suggestion). Both can hinder adoption of = the spec by different parties.
 
Here's what we need to discuss - Do the = Pros make the = suggestio
<= /div>
 
 
 
 
 
_____________________________________= __________
scim mailing list
scim@ietf.org
https://www.ietf.org/ma= ilman/listinfo/scim
<= /div>= --Apple-Mail=_AE4EDE21-1ECE-440A-B58B-A08229F6FBD5-- From prvs=35750CA8FC=erik.wahlstrom@nexussafe.com Thu Aug 16 10:51:01 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1BF21F85E7 for ; Thu, 16 Aug 2012 10:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FvjX+k7Txtz for ; Thu, 16 Aug 2012 10:51:01 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6188B21F85DF for ; Thu, 16 Aug 2012 10:51:00 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.379.0; Thu, 16 Aug 2012 19:50:55 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Thu, 16 Aug 2012 19:50:57 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Phil Hunt Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNd3Pr44ExZuZhxUW/NPa2IcqvX5dT/IGAgABLt4CAAHBZgIAACouAgACi+YWAABY3AIABBZAAgAAyWwCAAC3NgIAAPeCAgAAs0YCAAHzV0IAADy0AgAAF2KCAAGG7AIABfhKAgAKJBYCAAE4yYIAABuwAgAACcIA= Date: Thu, 16 Aug 2012 17:50:56 +0000 Message-ID: <4AB854B9-BD20-4F04-A1FC-7920ABB7D544@nexussafe.com> References: <9287EF43-A692-45C8-B78F-9F8BE048C74B@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330257D6@BY2PRD0410MB354.namprd04.prod.outlook.com> <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302C5DD@BY2PRD0410MB354.namprd04.prod.outlook.com> <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> In-Reply-To: <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.4.60] Content-Type: multipart/alternative; boundary="_000_4AB854B9BD204F04A1FC7920ABB7D544nexussafecom_" MIME-Version: 1.0 Cc: Anthony Nadalin , Melinda Shore , Emmanuel Dreux , "scim@ietf.org" , Kelly Grizzle , Ganesh and Sashi Prasad Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:51:01 -0000 --_000_4AB854B9BD204F04A1FC7920ABB7D544nexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 My conclusion: If the client must first query (or have synchronized the value identifiers)= , then the client has to do even more work than the current proposal of rep= lacing the enter complex value. Given such a choice I'm really skeptical t= hat the pattern proposed by Ganesh would be widely used. While Ganesh's pr= oposal may be "specific", the practical simplicity of it is very much debat= able. The benefit of specific sub-attribute identifiers needs to be substantial. = We're not only talking about changing how infrastructure is done, but also= how applications are written. This leaves out the entire current adopters = and all enterprise users. A big concern we have obviously is we have to co= nsider existing infrastructure and data stores and be realistic. I don't th= ink the benefit is worth the cost. I agree with the others that the current draft could be changed to make pat= ch operations more clear to the developer (simpler to read). While this may= not improve logic, it will improve understanding and simplicity. The fact = that certain operations may require an entire complex attribute value to be= replaced is a reasonable compromise and should not be changed. Phil @independentid www.independentid.com phil.hunt@oracle.com --_000_4AB854B9BD204F04A1FC7920ABB7D544nexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
+1


My conclusion:
If the client must first query (or have synchronized the value identif= iers), then the client has to do even more work than the current proposal o= f replacing the enter complex value.  Given such a choice I'm really s= keptical that the pattern proposed by Ganesh would be widely used.  While Ganesh's proposal may be "sp= ecific", the practical simplicity of it is very much debatable.

The benefit of specific sub-attribute identifiers needs to be substantial. =  We're not only talking about changing how infrastructure is done, but= also how applications are written. This leaves out the entire current adop= ters and all enterprise users.  A big concern we have obviously is we have to consider existing infrastructure a= nd data stores and be realistic. I don't think the benefit is worth the cos= t.

I agree with the others that the current draft could be changed to mak= e patch operations more clear to the developer (simpler to read). While thi= s may not improve logic, it will improve understanding and simplicity. The = fact that certain operations may require an entire complex attribute value to be replaced is a reasonable c= ompromise and should not be changed. 

Phil


--_000_4AB854B9BD204F04A1FC7920ABB7D544nexussafecom_-- From melinda.shore@gmail.com Thu Aug 16 10:55:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC42821F84D4 for ; Thu, 16 Aug 2012 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.572 X-Spam-Level: X-Spam-Status: No, score=-3.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suL38NJiRB2F for ; Thu, 16 Aug 2012 10:55:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 322D921F84D2 for ; Thu, 16 Aug 2012 10:55:05 -0700 (PDT) Received: by yenm5 with SMTP id m5so3501790yen.31 for ; Thu, 16 Aug 2012 10:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=25NBvadbP3KILVnDQWMSsj0HiR7+fFMEzB39/zqu9Rw=; b=Bnvx762RaQSVQBOKZj3XNc7u2iMEmbbp6wcEWujqZLyjnbermht5HzT20cIErVZCTq ev7u0KKe8i1g26jXWXMFj6SlieeinPHBOrDzEPQqc6uPk5djPpb1UQJhEGXXT8fxTREB XyqZ2BArc9CRSdej2ZP7okeRWIqjeRNOZ6p4V6FFm0CXuejL3g++M2XPLJROZ28DGbKl 2QRP51GFJg6GfzxMTHmHwGK8KzRAIb6AmHboVFZz7LJwrbUjO01HiDkFH+tTeew8CPRg jjobsUSTGy25BmRug4ypHBsy6Pxr1gbEp0PZMYTsMekNLKDt/b/tONBjn4bKQcpU/TH4 5htw== Received: by 10.66.75.133 with SMTP id c5mr3806337paw.24.1345139704314; Thu, 16 Aug 2012 10:55:04 -0700 (PDT) Received: from spandex.local (66-230-81-200-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.200]) by mx.google.com with ESMTPS id wn1sm3086868pbc.57.2012.08.16.10.55.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 10:55:02 -0700 (PDT) Message-ID: <502D33F4.8060409@gmail.com> Date: Thu, 16 Aug 2012 09:55:00 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Phil Hunt References: <33F638A7-A7A6-475A-86BF-95F28A8F1C73@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330259C2@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C343733025AEA@BY2PRD0410MB354.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C34373302C5DD@BY2PRD0410MB354.namprd04.prod.outlook.com> <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@orac le.com> In-Reply-To: <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Nadalin , Ganesh and Sashi Prasad , Emmanuel Dreux , "scim@ietf.org" , Kelly Grizzle Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:55:05 -0000 On 8/16/12 9:42 AM, Phil Hunt wrote: > The current draft proposal requires that complex-value (e.g. an address > value which is made up of number, street, city, etc) be changed if you > want to change any of the sub-attributes. The current approach seems a > reasonable compromise since it is likely the collection of attributes in > a complex "value" are often manipulated together. IOW. You tend to set > them all at once. I can imagine scenarios in which you might want to set a "sub-attribute" (not sure I love this terminology) without knowing the sibling sub- attributes, but they strike me as contrived and rather uncommon. I don't think the complexity introduced by Ganesh's proposal is counter- weighted by any benefit that might come from it. I don't support the proposal. Melinda From Chris.Phillips@canarie.ca Thu Aug 16 12:23:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EABD21F8589 for ; Thu, 16 Aug 2012 12:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ2PltmGQiCj for ; Thu, 16 Aug 2012 12:23:36 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 0337A21F856F for ; Thu, 16 Aug 2012 12:23:34 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Thu, 16 Aug 2012 15:23:33 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Thu, 16 Aug 2012 15:23:29 -0400 Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: Ac175KALS1m3dk1dSDaL4iZbyZm8DA== Message-ID: In-Reply-To: <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC52BAF9BB125chrisphillipscanarieca_" MIME-Version: 1.0 Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 19:23:36 -0000 --_000_CC52BAF9BB125chrisphillipscanarieca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gUGhpbCdzIGNvbW1lbnRzLg0KDQpBcyB3ZWxsLCBhZGRpbmcgYSBnaG9zdCBkaXJlY3Rv cnkgdG8gW2RlfGVuXWNvZGUgdGhpbmdzIGlzIGp1c3QgdG9vIG11Y2ggb3ZlcmhlYWQgdG8gYnVp bGQgaW50byB0aGUgcHJvdG9jb2wuICBJZiBzb21lb25lIHdhbnRzIHRvIGJ1aWxkIHRoYXQgb24g VE9QIG9mIFNDSU0sIHRoYXQncyB1cCB0byB0aGVtLg0KDQpXaGlsZSBJIGFwcHJlY2lhdGUgdGhl IHRob3VnaHQgYW5kIHRpbWUgR2FuZXNoIGhhcyBwdXQgaW50byB0aGUgY29uY2VwdHMsIEkgYW0g bm90IGNvbnZpbmNlZCB0aGUgYXBwcm9hY2ggd291bGQgYmUgbmV0IGJldHRlciBhbmQgbGVzcyBj b21wbGV4IGFuZCBzbyBkbyBub3Qgc3VwcG9ydCBpdCBhbmQgd2VsY29tZSBtb3Zpbmcgb24gdG8g b3RoZXIgdG9waWNzLg0KDQpDLg0KDQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUu Y29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgMTYgQXVn dXN0LCAyMDEyIDE6NDIgUE0NClRvOiBLZWxseSBHcml6emxlIDxrZWxseS5ncml6emxlQHNhaWxw b2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+DQpDYzogRW1tYW51 ZWwgRHJldXggPGVkcmV1eEBjbG91ZGl3YXkuY29tPG1haWx0bzplZHJldXhAY2xvdWRpd2F5LmNv bT4+LCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tPj4sIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIDxnLmMucHJhc2FkQGdt YWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+PiwgTWVsaW5kYSBTaG9yZSA8bWVs aW5kYS5zaG9yZUBnbWFpbC5jb208bWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwuY29tPj4sICJz Y2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPiIgPHNjaW1AaWV0Zi5vcmc8bWFpbHRv OnNjaW1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgs IElzc3VlIDI0DQoNCkkgZG8gdGhpbmsgd2UgbmVlZCB0byBhcnJpdmUgYXQgc29tZSBjb25zZW5z dXMgb24gdGhpcyBub3cgYmVjYXVzZSBHYW5lc2gncyBwcm9wb3NhbCBpcyBhIG1ham9yICJmb3Jr LWluLXRoZS1yb2FkIiBkZWNpc2lvbi4gSWYgd2UgdGFibGUgaXQsIGl0IHdpbGwgYmUgaGFyZCB0 byBjb21lIGJhY2sgdG8uIFRoaXMgaXMgd2h5IEkgaGF2ZSBlbmdhZ2VkIG9uIHRoZSBzdWJqZWN0 IHdpdGggR2FuZXNoIHNvIHRob3JvdWdobHkuICBOZXZlci10aGUtbGVzcywgSSB3b3VsZCBsaWtl IHRvIGFycml2ZSBhdCBzb21lIGNvbmNsdXNpb25zIGhlcmUuDQoNCk15IGFwb2xvZ2llcywgYnV0 IEkgdGhvdWdodCBpdCB3YXMgd29ydGggcmUtc3RhdGluZyB0aGUgcHJvYmxlbSBmb3IgdGhvc2Ug bGF0ZSB0byB0aGUgZGlzY3Vzc2lvbiB3b3VsZCBiZSB1c2VmdWwuDQoNCkJhY2tncm91bmQ6DQpB dCBwcmVzZW50LCB0aGUgY3VycmVudCBzcGVjIGRvZXMgbm90IGFsbG93IHlvdSB0byBjaGFuZ2Ug YSBzcGVjaWZpYyBzdWItYXR0cmlidXRlIGluIGEgbXVsdGktdmFsdWVkIGNvbXBsZXggYXR0cmli dXRlIHN0cnVjdHVyZSAoZS5nLiBjaGFuZ2luZyBzdHJlZXQgbmFtZSBpbiBhIHNwZWNpZmljIGFk ZHJlc3MgdmFsdWUgaW5zdGFuY2Ugc3VjaCBhcyAiaG9tZSIpLiAgVGhlIHByb3Bvc2FsIGlzIHRo YXQgZWFjaCBzdWIgYXR0cmlidXRlIGluIGEgbXVsdGktdmFsdWVkIHN0cnVjdHVyZSBnZXRzIGl0 cyBvd24gdW5pcXVlIGlkZW50aWZpZXIuICBUaGVuIHlvdSBjYW4gZGlyZWN0bHkgcmVmZXJlbmNl IHRoZSBzcGVjaWZpYyBjb21wbGV4IGF0dHJpYnV0ZSBjb21wb25lbnQgaW4gYSBjb21wbGV4IHZh bHVlLg0KDQpUaGUgY3VycmVudCBkcmFmdCBwcm9wb3NhbCByZXF1aXJlcyB0aGF0IGNvbXBsZXgt dmFsdWUgKGUuZy4gYW4gYWRkcmVzcyB2YWx1ZSB3aGljaCBpcyBtYWRlIHVwIG9mIG51bWJlciwg c3RyZWV0LCBjaXR5LCBldGMpIGJlIGNoYW5nZWQgaWYgeW91IHdhbnQgdG8gY2hhbmdlIGFueSBv ZiB0aGUgc3ViLWF0dHJpYnV0ZXMuIFRoZSBjdXJyZW50IGFwcHJvYWNoIHNlZW1zIGEgcmVhc29u YWJsZSBjb21wcm9taXNlIHNpbmNlIGl0IGlzIGxpa2VseSB0aGUgY29sbGVjdGlvbiBvZiBhdHRy aWJ1dGVzIGluIGEgY29tcGxleCAidmFsdWUiIGFyZSBvZnRlbiBtYW5pcHVsYXRlZCB0b2dldGhl ci4gSU9XLiBZb3UgdGVuZCB0byBzZXQgdGhlbSBhbGwgYXQgb25jZS4gIEdhbmVzaCdzIHByb3Bv c2FsIGFsbG93cyBzcGVjaWZpYyBzdWItYXR0cmlidXRlcyB0byBiZSBkaXJlY3RseSBhZGRyZXNz YWJsZSBieSBnaXZpbmcgZWFjaCB2YWx1ZSBpbnN0YW5jZSBhIHVuaXF1ZSBpZGVudGlmaWVyLg0K DQpBbm90aGVyIGV4YW1wbGUgb2YgdGhpcyBpcyB0aGUgZ3JvdXAgIm1lbWJlciIgYXR0cmlidXRl LiAgSW4gdGhlIGN1cnJlbnQgZHJhZnQsIGEgbWVtYmVyIGNhbiBoYXZlIGEgdmFsdWUgYW5kIGEg ZGlzcGxheSBuYW1lLiBJbiB0aGlzIGNhc2UgeW91IHdvdWxkIHVzdWFsbHkgY2hhbmdlIHRoZSB2 YWx1ZSAob2JqZWN0IGlkZW50aWZpZXIpIGFuZCB0aGUgbmFtZSBhcyB3ZWxsLiAgR2FuZXNoJ3Mg cHJvcG9zYWwgd291bGQgYWxsb3cgIkRpc3BsYXkgTmFtZSIgdG8gYmUgY2hhbmdlZCBvciB2YWx1 ZSB0byBiZSBjaGFuZ2VkLiAgU29tZXRoaW5nLCBJTVYsIHRoYXQgZG9lc24ndCBvY2N1ciBuZWFy bHkgYXMgb2Z0ZW4uICBJT1cgbWVtYmVycyBjaGFuZ2UgZ3JvdXAgbWVtYmVyc2hpcCwgYnV0IG1l bWJlcnMgcmFyZWx5IGNoYW5nZSBuYW1lcy4NCg0KTXkgY29uY2x1c2lvbjoNCklmIHRoZSBjbGll bnQgbXVzdCBmaXJzdCBxdWVyeSAob3IgaGF2ZSBzeW5jaHJvbml6ZWQgdGhlIHZhbHVlIGlkZW50 aWZpZXJzKSwgdGhlbiB0aGUgY2xpZW50IGhhcyB0byBkbyBldmVuIG1vcmUgd29yayB0aGFuIHRo ZSBjdXJyZW50IHByb3Bvc2FsIG9mIHJlcGxhY2luZyB0aGUgZW50ZXIgY29tcGxleCB2YWx1ZS4g IEdpdmVuIHN1Y2ggYSBjaG9pY2UgSSdtIHJlYWxseSBza2VwdGljYWwgdGhhdCB0aGUgcGF0dGVy biBwcm9wb3NlZCBieSBHYW5lc2ggd291bGQgYmUgd2lkZWx5IHVzZWQuICBXaGlsZSBHYW5lc2gn cyBwcm9wb3NhbCBtYXkgYmUgInNwZWNpZmljIiwgdGhlIHByYWN0aWNhbCBzaW1wbGljaXR5IG9m IGl0IGlzIHZlcnkgbXVjaCBkZWJhdGFibGUuDQoNClRoZSBiZW5lZml0IG9mIHNwZWNpZmljIHN1 Yi1hdHRyaWJ1dGUgaWRlbnRpZmllcnMgbmVlZHMgdG8gYmUgc3Vic3RhbnRpYWwuICBXZSdyZSBu b3Qgb25seSB0YWxraW5nIGFib3V0IGNoYW5naW5nIGhvdyBpbmZyYXN0cnVjdHVyZSBpcyBkb25l LCBidXQgYWxzbyBob3cgYXBwbGljYXRpb25zIGFyZSB3cml0dGVuLiBUaGlzIGxlYXZlcyBvdXQg dGhlIGVudGlyZSBjdXJyZW50IGFkb3B0ZXJzIGFuZCBhbGwgZW50ZXJwcmlzZSB1c2Vycy4gIEEg YmlnIGNvbmNlcm4gd2UgaGF2ZSBvYnZpb3VzbHkgaXMgd2UgaGF2ZSB0byBjb25zaWRlciBleGlz dGluZyBpbmZyYXN0cnVjdHVyZSBhbmQgZGF0YSBzdG9yZXMgYW5kIGJlIHJlYWxpc3RpYy4gSSBk b24ndCB0aGluayB0aGUgYmVuZWZpdCBpcyB3b3J0aCB0aGUgY29zdC4NCg0KSSBhZ3JlZSB3aXRo IHRoZSBvdGhlcnMgdGhhdCB0aGUgY3VycmVudCBkcmFmdCBjb3VsZCBiZSBjaGFuZ2VkIHRvIG1h a2UgcGF0Y2ggb3BlcmF0aW9ucyBtb3JlIGNsZWFyIHRvIHRoZSBkZXZlbG9wZXIgKHNpbXBsZXIg dG8gcmVhZCkuIFdoaWxlIHRoaXMgbWF5IG5vdCBpbXByb3ZlIGxvZ2ljLCBpdCB3aWxsIGltcHJv dmUgdW5kZXJzdGFuZGluZyBhbmQgc2ltcGxpY2l0eS4gVGhlIGZhY3QgdGhhdCBjZXJ0YWluIG9w ZXJhdGlvbnMgbWF5IHJlcXVpcmUgYW4gZW50aXJlIGNvbXBsZXggYXR0cmlidXRlIHZhbHVlIHRv IGJlIHJlcGxhY2VkIGlzIGEgcmVhc29uYWJsZSBjb21wcm9taXNlIGFuZCBzaG91bGQgbm90IGJl IGNoYW5nZWQuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3dy5pbmRlcGVuZGVudGlkLmNv bTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0KcGhpbC5odW50QG9yYWNsZS5jb208bWFp bHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0KDQoNCk9uIDIwMTItMDgtMTYsIGF0IDg6 NTkgQU0sIEtlbGx5IEdyaXp6bGUgd3JvdGU6DQoNCkhpIEdhbmVzaCDigKYgeW91ciB3cml0ZS11 cCBjb25jZWRlcyB0aGF0IHRoaXMgd2lsbCBiZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50IGZvciBh biBleGlzdGluZyBzZXJ2aWNlIHByb3ZpZGVyLiAgSeKAmW0gbm90IHN1cmUgdGhhdCBJIHVuZGVy c3RhbmQgdGhlIGNvbXByb21pc2UuICBBcmUgeW91IHN0aWxsIHN1Z2dlc3RpbmcgdGhhdCBTQ0lN IG1vdmUgdG8gdGhlIHVuaXF1ZS1rZXktcGVyLWVsZW1lbnQgc3RyYXRlZ3k/DQoNCklmIHNvLCB0 aGUgY29zdC9iZW5lZml0IG9mIHRoaXMgc2VlbXMgd2F5IG9mZiB0byBtZS4gIFlvdSBhcmUgZ2Fp bmluZyBhIG1vcmUgZWxlZ2FudCBBUEkgYnkgaW50cm9kdWNpbmcgYW4gYWRkaXRpb25hbCBkYXRh c3RvcmUgYW5kIHJlcXVpcmluZyByZXBsaWNhdGlvbi4gIEkgZG9u4oCZdCBrbm93IG9mIGFueSBz ZXJ2aWNlIHByb3ZpZGVyIHRoYXQgd291bGQgbWFrZSB0aGlzIHRyYWRlLW9mZi4gIEFzIHlvdSBz YWlkLCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGZ1dHVyZSBzZXJ2aWNlIHByb3ZpZGVycyBjYW4g a2VlcCBpbiBtaW5kLCBidXQgaXQgaXMgbm90IGdvaW5nIHRvIGhlbHAgZXhpc3RpbmcgcHJvdmlk ZXJzLg0KDQotLUtlbGx5DQoNCkZyb206IEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIFttYWlsdG86 Zy5jLnByYXNhZEBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDE2LCAyMDEyIDU6 MzggQU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBLZWxseSBHcml6emxlOyBFbW1hbnVlbCBE cmV1eDsgTWVsaW5kYSBTaG9yZTsgc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz47 IFBoaWwgSHVudA0KU3ViamVjdDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3Vl IDI0DQoNCkhpIGFsbCwNCg0KV291bGQgdGhpcyBoeWJyaWQgYXJjaGl0ZWN0dXJlIGJlIGEgd29y a2FibGUgY29tcHJvbWlzZT8gU2VlIGRpYWdyYW0gdG93YXJkcyB0aGUgZW5kOiBodHRwOi8vYml0 Lmx5L1JqYzM5WQ0KDQpSZWdhcmRzLA0KR2FuZXNoDQpPbiAxNSBBdWd1c3QgMjAxMiAwNTo1NCwg QW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWlj cm9zb2Z0LmNvbT4+IHdyb3RlOg0KV2Ugc2hvdWxkIG5vdCBiZSBjb25zdHJhaW5lZCBieSBMREFQ IHJlc3RyaWN0aW9ucywgdGhpcyB3b3VsZCBub3QgYmUgcHJvZHVjdGl2ZS4NCg0KRnJvbTogc2Np bS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 c2NpbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBC ZWhhbGYgT2YgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQNClNlbnQ6IE1vbmRheSwgQXVndXN0IDEz LCAyMDEyIDI6MDcgUE0NClRvOiBLZWxseSBHcml6emxlDQpDYzogRW1tYW51ZWwgRHJldXg7IE1l bGluZGEgU2hvcmU7IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+OyBQaGlsIEh1 bnQNCg0KU3ViamVjdDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0DQoN ClRoYW5rcywgS2VsbHkuIFlvdSd2ZSBiZWVuIG1vc3QgcGF0aWVudCBpbiBoZWFyaW5nIG1lIG91 dCwgSSBtdXN0IHNheS4gSSBjb3VsZG4ndCBhc2sgZm9yIG1vcmUuDQoNClJlcGx5aW5nIHRvIENo cmlzIFBoaWxpcHMncyBtYWlsOg0KPiBHaXZlbiB0aGF0IHlvdSBoYXZlIGEgbnVtYmVyIG9mIHRo b3VnaHRzIGFib3V0IHdoYXQgY291bGQgYmUgY2hhbmdlZCBpbiBTQ0lNLExlaWYncyByZWNvbW1l bmRhdGlvbiB0byAgY3JhZnQgdGhlbSBpbiBhbiBJbnRlcm5ldCBEcmFmdCBtYXkgYmUgYSBiZXR0 ZXIgd2F5IHRvIGNvbnZleSB5b3VyIHRob3VnaHRzLg0KDQpJJ20gY29taW5nIGFyb3VuZCB0byB0 aGUgc2FtZSBjb25jbHVzaW9uLiBEbyB5b3UgdGhpbmsgc3VjaCBhbiBJbnRlcm5ldCBEcmFmdCBz aG91bGQgYmUgYWJvdXQgY2hhbmdpbmcgU0NJTSwgb3Igc2hvdWxkIGl0IHByb3Bvc2UgYSBjb21w bGVtZW50YXJ5IHNwZWMgZm9yIFNQcyB3aG8gdXNlIGEgIk5vTERBUCIgZGF0YSBzdG9yZT8gSSB0 aGluayB0aGUgdW5kZXJseWluZyBwcm9ibGVtIGlzIHdpdGggTERBUCwgYW5kIHVubGVzcyB3ZSBj aGFuZ2UgdGhhdCwgdGhlc2UgcHJvcG9zYWxzIHdvbid0IGZseS4NCg0KUmVnYXJkcywNCkdhbmVz aA0KT24gMTQgQXVndXN0IDIwMTIgMDE6NTQsIEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVA c2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4gd3JvdGU6 DQpUaGVyZSBhcmUgcmVhbGx5IHR3byBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIGZvciBhIHVpZCBw ZXIgZWxlbWVudCDigJMgZWl0aGVyIHN0b3JlIHRoZSB1aWRzIGluIHRoZSBuYXRpdmUgdW5kZXJs eWluZyBkYXRhIHN0b3JlIG9yIGhhdmUgc29tZSBzZWNvbmRhcnkgZGF0YSBzdG9yZSB0aGF0IG1h cHMgZWxlbWVudHMgdG8gdGhlaXIgdWlkcy4gIFRoZSB0aGlyZCBvcHRpb24gaXMgdG8gaG9wZSB0 aGF0IGEgc2VydmljZSBwcm92aWRlciBoYXMgYSBOb0xEQVAgZGF0YSBzdG9yZSBvciBpdHMgZXF1 aXZhbGVudC4gIE5vbmUgb2YgdGhlc2UgYXJlIHByYWN0aWNhbCBmb3IgcmFwaWQgYW5kIHdpZGUt c3ByZWFkIGFkb3B0aW9uLg0KDQo+IHB1dCB0aGUgdHdvIHRvZ2V0aGVyIHRvIHByb3Bvc2UgYSBz b2x1dGlvbi4NCg0KQXMgSSBzYWlkIGJlZm9yZSwgSSBhbSBjb21wbGV0ZWx5IG9uIGJvYXJkIHdp dGggY2xlYW5pbmcgdXAgdGhlIFBBVENIIHNlbWFudGljcyAoZWcg4oCTIHRoZSBpbmNvbnNpc3Rl bmN5IGJldHdlZW4gbWV0YS5hdHRyaWJ1dGVzIGFuZCBvcGVyYXRpb249ZGVsZXRlLCBldGPigKYp LiAgWW91ciBzdWdnZXN0aW9uIG9mIHVzaW5nIGRpZmZlcmVudCB2ZXJicyBpcyBhIGdvb2Qgb3B0 aW9uIHRvIGNvbnNpZGVyLiAgVGhpcyBjYW5ub3QgYmUgYmFzZWQgb24gYSB1aWQgcGVyIGVsZW1l bnQsIHRob3VnaC4gIEl0IHNlZW1zIGFzIHRob3VnaCB5b3UgaGF2ZSBhZG1pdHRlZCB0aGlzIGlu IHlvdXIgY29uY2x1c2lvbiDigJMg4oCcQXMgZm9yIExEQVAgYW5kIFNDSU0sIEkgZ3Vlc3MgdGhl IGJlc3QgVExBIGlzIFJJUC7igJ0NCg0KLS1LZWxseQ0KDQpGcm9tOiBHYW5lc2ggYW5kIFNhc2hp IFByYXNhZCBbbWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdt YWlsLmNvbT5dDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMywgMjAxMiA5OjU2IEFNDQpUbzogS2Vs bHkgR3JpenpsZQ0KQ2M6IFBoaWwgSHVudDsgTWVsaW5kYSBTaG9yZTsgRW1tYW51ZWwgRHJldXg7 IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbc2Np bV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAyNA0KDQpUaGF0IHdhcyBvbmUgc3VnZ2VzdGlv bi4gQW5vdGhlciB3YXkgY291bGQgYmUgY29udGFpbmVyIG5vZGVzIHdpdGggdGhlaXIgb3duICJk biJzLiBJZiBvbmUgc3VnZ2VzdGlvbiB3b24ndCB3b3JrLCB0ZWxsIG1lIGFub3RoZXIgd2F5IHRv IG1ha2UgaXQgd29yay4gSSdtIHdhaXRpbmcgdG8gaGVhciBhIGNvbnN0cnVjdGl2ZSBzdWdnZXN0 aW9uIHRoYXQgY2FuIHNxdWFyZSBhbiBlbGVnYW50IEFQSSB3aXRoIHRoZSBpbXBsZW1lbnRhdGlv biBjb25zdHJhaW50cyB0aGF0IGNvbWUgZnJvbSBoYXZpbmcgdG8gc3RvcmUgbXVsdGktdmFsdWVk IGF0dHJpYnV0ZXMgaW4gTERBUCBkaXJlY3Rvcmllcy4NCg0KSSd2ZSBoZWFyZCBlbm91Z2ggb2Yg V0hZIHRoaXMgd29uJ3Qgd29yay4gRm9yIGEgY2hhbmdlLCB0ZWxsIG1lIEhPVyBpdCBjYW4gYmUg bWFkZSB0byB3b3JrLiBFdmVyeW9uZSBub3cga25vd3Mgd2hhdCB0aGUgcHJvcG9zYWwgbWVhbnMg aW4gdGVybXMgb2YgdGhlIEFQSSwgYW5kIGltcGxlbWVudG9ycyB1bmRlcnN0YW5kIHRoZSBjb25z dHJhaW50cyBvZiBsZWdhY3kgZGF0YSBzdG9yZXMsIHNvIHB1dCB0aGUgdHdvIHRvZ2V0aGVyIHRv IHByb3Bvc2UgYSBzb2x1dGlvbi4gQydtb24sIHdlIGhhdmUgdGhlICJzbWFydGVzdCBndXlzIGlu IHRoZSByb29tIiBoZXJlLCBzdXJlbHkgd2Ugc2hvdWxkIGJlIGFibGUgdG8gY3JhY2sgdGhpcy4N Cg0KUmVnYXJkcywNCkdhbmVzaA0KDQpQLlMuIEknbSByYXBpZGx5IHJlYWNoaW5nIG15IG93biBj b25jbHVzaW9ucyBhYm91dCB3aGF0IGlzIHRvIGJlIGRvbmU6DQpodHRwOi8vd2lzZG9tb2ZnYW5l c2guYmxvZ3Nwb3QuY29tLmF1LzIwMTIvMDgvYWZ0ZXItbm9zcWwtaXRzLXRpbWUtZm9yLW5vbGRh cC5odG1sDQoNCk9uIDE0IEF1Z3VzdCAyMDEyIDAwOjI3LCBLZWxseSBHcml6emxlIDxrZWxseS5n cml6emxlQHNhaWxwb2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbT4+ IHdyb3RlOg0KPiBBZnRlciBhbGwsIG5vIG9uZSBoYXMgY2hhbGxlbmdlZCB0aGUgY2xhaW0gdGhh dCB0aGlzIHByb3Bvc2FsIGRyYXN0aWNhbGx5IHNpbXBsaWZpZXMgdGhlIEFQSSBmb3IgdGhlIGNs aWVudA0KDQpJIGFncmVlIHRoYXQgeW91ciBwcm9wb3NhbCBtYWtlcyBQQVRDSCBzZW1hbnRpY3Mg c2ltcGxlciBhbmQgbW9yZSBlbGVnYW50Lg0KDQoNCj4g4oCmIHNvIGl0IHdvdWxkIGFwcGVhciB0 byBiZSB3b3J0aCBkb2luZy4NCg0KSSBzdHJvbmdseSBkaXNhZ3JlZSBoZXJlLiAgVGhpcyBzdGF0 ZW1lbnRzIGFzc3VtZXMgdGhhdCBzaW1wbGljaXR5IG9mIHRoZSBjbGllbnQgQVBJIGlzIHRoZSBv bmx5IGZhY3RvciB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHdpdGggdGhlIHNwZWMuDQoNCkVt bWFudWVs4oCZcyBleGFtcGxlIGlzIGZyb20gYSByZWFsLXdvcmxkIHNlcnZpY2UgcHJvdmlkZXIg dGhhdCB3b3VsZCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlIHNwZWMgZWFzaWx5IHdpdGgg YSB1aWQgcGVyIGVsZW1lbnQuICBIZSBpcyB3b3JraW5nIG9uIGEgU0NJTSBpbnRlcmZhY2UgdGhh dCB3aWxsIGhlbHAgZmFjaWxpdGF0ZSBkYXRhIGV4Y2hhbmdlIGJldHdlZW4gbXVsdGlwbGUgQWN0 aXZlIERpcmVjdG9yeSBzZXJ2ZXJzLiAgWW91ciBzb2x1dGlvbiB3YXMgdG8gY2hhbmdlIHRoZSBk YXRhIG1vZGVsIGZyb20gdGhpczoNCg0KDQptYWlsOiBqb2huX3NtaXRoQHlhaG9vLmNvbTxtYWls dG86am9obl9zbWl0aEB5YWhvby5jb20+LCBqb2huLnNtaXRoQGdtYWlsLmNvbTxtYWlsdG86am9o bi5zbWl0aEBnbWFpbC5jb20+LCBqc21pdGgxOTcwQGhvdG1haWwuY29tPG1haWx0bzpqc21pdGgx OTcwQGhvdG1haWwuY29tPg0KDQoNCnRvIHRoaXM6DQoNCm1haWw6IGFhNjYtZGFmOWVhM2JkOTAy PWpvaG5fc21pdGhAeWFob28uY29tPG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sOWNkYS04 NjQ2YzMwODViYmY9am9obi5zbWl0aEBnbWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwu Y29tPiwgN2E2ZDFkZTY2NGUxPWpzbWl0aDE5NzBAaG90bWFpbC5jb208bWFpbHRvOmpzbWl0aDE5 NzBAaG90bWFpbC5jb20+DQoNCkkgZG8gbm90IGtub3cgb2YgYSBzaW5nbGUgb3JnYW5pemF0aW9u IHRoYXQgd291bGQgY2hhbmdlIHRoZWlyIEFjdGl2ZSBEaXJlY3RvcnkgZGF0YSBtb2RlbCB0byBm aXQgdGhpcy4gIEZvciBvbmUgdGhpbmcsIGl0IHdvdWxkIGJlIGEgaHVnZSBkYXRhIG1pZ3JhdGlv biBlZmZvcnQgKGxpa2VseSBhY3Jvc3Mgb3RoZXIgZG9tYWluIGNvbnRyb2xsZXJzLCBldGPigKYp IHRvIGFzc2lnbiB0aGVzZSB1bmlxdWUgaWRlbnRpZmllcnMuICBUaGlzIGFsc28gYXNzdW1lcyB0 aGF0IFNDSU0gaXMgdGhlIG9ubHkgcmVhZGVyL3dyaXRlciBvZiB0aGlzIGRhdGEsIHdoaWNoIHdp bGwgYWxtb3N0IG5ldmVyIGJlIHRoZSBjYXNlLiAgSWYgdGhlIGRhdGEgbW9kZWwgcmVxdWlyZXMg dWlkcyBmb3IgZXZlcnkgZWxlbWVudCwgdGhlbiBldmVyeSBwaWVjZSBvZiBub24tU0NJTSBjb2Rl IHRoYXQgd3JpdGVzIGRhdGEgaW50byB0aGUgZGlyZWN0b3J5IHdpbGwgaGF2ZSB0byBmb2xsb3cg dGhpcy4gIEFkZGl0aW9uYWxseSwgdGhlcmUgYXJlICptYW55KiB0b29scyBhbmQgYXBwbGljYXRp b25zICAoZWcg4oCTIGFkZHJlc3MgYm9va3MpIHRoYXQgcmVseSBvbiBhIGNlcnRhaW4gZGF0YSBt b2RlbCBpbiBBY3RpdmUgRGlyZWN0b3J5LCBhbmQgdGhpcyB3b3VsZCBjYXVzZSB0aGVtIHRvIGJy ZWFrLiAgSU1PIHRoaXMgc2FtZSBhcmd1bWVudCBob2xkcyB0cnVlIGZvciBtb3N0IHNlcnZpY2Ug cHJvdmlkZXJzLg0KDQoNClBBVENIIGlzIGFuIG9wdGlvbmFsIHBhcnQgb2YgdGhlIHNwZWMuICBJ dCB3YXMgcHJpbWFyaWx5IGludHJvZHVjZWQgdG8gbWFrZSBtb2RpZnlpbmcgcmVzb3VyY2VzIHdp dGggbGFyZ2UgbXVsdGktdmFsdWVkIGxpc3RzIG1vcmUgZWZmaWNpZW50LiAgSXQgZG9lcyBub3Qg bmVlZCB0byBzb2x2ZSBldmVyeSBwcm9ibGVtIChlZyDigJMgbW9kaWZ5aW5nIHN1Yi1lbGVtZW50 cyBpbiBuZXN0ZWQgYXJyYXlzKS4gIEFkZGluZyB1aWRzIHRvIGV2ZXJ5IG11bHRpLXZhbHVlZCBl bGVtZW50IGRvZXMgbm90IHN0cmlrZSB0aGUgcmlnaHQgYmFsYW5jZSBiZXR3ZWVuIHRoZSBuZWVk cyBvZiB0aGUgY2xpZW50IGFuZCB0aGUgbmVlZHMgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIuDQoN Ci0tS2VsbHkNCg0KRnJvbTogR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgW21haWx0bzpnLmMucHJh c2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+XQ0KU2VudDogTW9uZGF5 LCBBdWd1c3QgMTMsIDIwMTIgMTozNSBBTQ0KVG86IFBoaWwgSHVudDsgTWVsaW5kYSBTaG9yZQ0K Q2M6IEVtbWFudWVsIERyZXV4OyBLZWxseSBHcml6emxlOyBzY2ltQGlldGYub3JnPG1haWx0bzpz Y2ltQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwg SXNzdWUgMjQNCg0KUmVzcG9uZGluZyB0byBleHRyYWN0IG9mIE1lbGluZGEgU2hvcmUncyBtYWls IGZyb20gZGlnZXN0Og0KDQoNClRoZSBpc3N1ZSBiZWluZyByYWlzZWQgaGVyZSBpc24ndCBlbmRw b2ludCBsb2dpYywgYnV0DQoNCm5ldHdvcmsgdHJhZmZpYywgYW5kIEknbSBwcmV0dHkgc3VyZSBp dCdzIG5vdCB2ZXJ5IGhlbHBmdWwgdG8NCg0KcmVzcG9uZCB0byB0aGUgb2JzZXJ2YXRpb24gdGhh dCB5b3VyIG1vZGVsIHJlcXVpcmVzIG1vcmUNCg0KbWVzc2FnZXMgd2l0aCBhIGNvbXBsYWludCBh Ym91dCB3aGF0IHlvdSBzZWVtIHRvIHRoaW5rIGlzIGENCg0KY29tcGxleCBhbGdvcml0aG0gZm9y IGF0dHJpYnV0ZSBwcm9jZXNzaW5nLg0KDQoNCkl0IGRlcGVuZHMgb24gaG93IGl0J3MgaW1wbGVt ZW50ZWQuIEknbSBjb25maWRlbnQgd2UgY2FuIGhhdmUgdGhlIGJlc3Qgb2YgYm90aCAtIHNpbXBs ZSBBUEkgd2l0aCBsb3ctb3ZlcmhlYWQgaW1wbGVtZW50YXRpb24uIENhbiB3ZSBicmFpbnN0b3Jt IEhPVyB0aGlzIHByb3Bvc2FsIGNhbiBiZSBpbXBsZW1lbnRlZCByYXRoZXIgdGhhbiBXSFkgaXQg Y2FuJ3QgYmUgaW1wbGVtZW50ZWQgKHdoaWNoIGlzIG1vc3RseSB3aGF0IEkndmUgYmVlbiBoZWFy aW5nIHNvIGZhcik/IEFmdGVyIGFsbCwgbm8gb25lIGhhcyBjaGFsbGVuZ2VkIHRoZSBjbGFpbSB0 aGF0IHRoaXMgcHJvcG9zYWwgZHJhc3RpY2FsbHkgc2ltcGxpZmllcyB0aGUgQVBJIGZvciB0aGUg Y2xpZW50LCBzbyBpdCB3b3VsZCBhcHBlYXIgdG8gYmUgd29ydGggZG9pbmcuIEknbSBzdXJlIHRo ZXJlJ3MgbW9yZSB0aGFuIGVub3VnaCBpbnRlbGxlY3R1YWwgaG9yc2Vwb3dlciBpbiB0aGlzIHdv cmtpbmcgZ3JvdXAgdG8gcHVsbCB0aGlzIG9mZiBpZiB3ZSBwdXQgb3VyIG1pbmRzIHRvIGl0Lg0K DQpSZWdhcmRzLA0KR2FuZXNoDQoNCk9uIDEzIEF1Z3VzdCAyMDEyIDEzOjU0LCBHYW5lc2ggYW5k IFNhc2hpIFByYXNhZCA8Zy5jLnByYXNhZEBnbWFpbC5jb208bWFpbHRvOmcuYy5wcmFzYWRAZ21h aWwuY29tPj4gd3JvdGU6DQo+IEkgc3Ryb25nbHkgb2JqZWN0IHRvIGFueXRoaW5nIHRoYXQgbGVh ZHMgdG8gYSByZWFkIGJlZm9yZSBtb2RpZnkgcmVxdWlyZW1lbnQuIFRvbyBjb21wbGV4IGFuZCB0 b28gY2hhdHR5Lg0KU29ycnkgUGhpbCwgYnV0IHlvdSdyZSBjb250cmFkaWN0aW5nIHlvdXJzZWxm IGhlcmUuIFRoZXJlIHNlZW1zIHRvIGJlIGFuIGF3ZnVsIGxvdCBvZiBtYXRjaGluZyAoaS5lLiwg cmVhZGluZykgZ29pbmcgb24gaW4gdGhlIHNwZWMgYXMgaXQgc3RhbmRzLCB3aXRoIGlmLXRoZW4g Y2xhdXNlcyB0byBkbyBvbmUgdGhpbmcgb3IgYW5vdGhlciBpZiB0aGUgbWF0Y2ggZWl0aGVyIHN1 Y2NlZWRzIG9yIGZhaWxzLiBUaGlzIGlzIGEgY29tcGxleCwgY2hhdHR5IHByb3RvY29sIHJpZ2h0 IG5vdyENCg0KDQogICBNdWx0aS12YWx1ZWQgYXR0cmlidXRlczogIEFuIGF0dHJpYnV0ZSB2YWx1 ZSBpbiB0aGUgUEFUQ0ggcmVxdWVzdA0KDQogICAgICBib2R5IGlzIGFkZGVkIHRvIHRoZSB2YWx1 ZSBjb2xsZWN0aW9uIGlmIHRoZSB2YWx1ZSBkb2VzIG5vdCBleGlzdA0KDQogICAgICBhbmQgbWVy Z2VkIGlmIGEgbWF0Y2hpbmcgdmFsdWUgaXMgcHJlc2VudC4gIFZhbHVlcyBhcmUgbWF0Y2hlZCBi eQ0KDQogICAgICBjb21wYXJpbmcgdGhlIHZhbHVlIFN1Yi1BdHRyaWJ1dGUgZnJvbSB0aGUgUEFU Q0ggcmVxdWVzdCBib2R5IHRvDQoNCiAgICAgIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIG9mIHRo ZSBSZXNvdXJjZS4gIEF0dHJpYnV0ZXMgdGhhdCBkbyBub3QNCg0KICAgICAgaGF2ZSBhIHZhbHVl IFN1Yi1BdHRyaWJ1dGU7IGUuZy4sIGFkZHJlc3Nlcywgb3IgZG8gbm90IGhhdmUgdW5pcXVlDQoN CiAgICAgIHZhbHVlIFN1Yi1BdHRyaWJ1dGVzIGNhbm5vdCBiZSBtYXRjaGVkIGFuZCBtdXN0IGlu c3RlYWQgYmUgZGVsZXRlZA0KDQogICAgICB0aGVuIGFkZGVkLiAgU3BlY2lmaWMgdmFsdWVzIGNh biBiZSByZW1vdmVkIGZyb20gYSBSZXNvdXJjZSBieQ0KDQogICAgICBhZGRpbmcgYW4gIm9wZXJh dGlvbiIgU3ViLUF0dHJpYnV0ZSB3aXRoIHRoZSB2YWx1ZSAiZGVsZXRlIiB0byB0aGUNCg0KICAg ICAgYXR0cmlidXRlIGluIHRoZSBQQVRDSCByZXF1ZXN0IGJvZHkuICBBcyB3aXRoIGFkZGluZy91 cGRhdGluZw0KDQogICAgICBhdHRyaWJ1dGUgdmFsdWUgY29sbGVjdGlvbnMsIHRoZSB2YWx1ZSB0 byBkZWxldGUgaXMgZGV0ZXJtaW5lZCBieQ0KDQogICAgICBjb21wYXJpbmcgdGhlIHZhbHVlIFN1 Yi1BdHRyaWJ1dGUgZnJvbSB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5IHRvDQoNCiAgICAgIHRoZSB2 YWx1ZSBTdWItQXR0cmlidXRlIG9mIHRoZSBSZXNvdXJjZS4gIEF0dHJpYnV0ZXMgdGhhdCBkbyBu b3QNCg0KICAgICAgaGF2ZSBhIHZhbHVlIFN1Yi1BdHRyaWJ1dGUgb3IgdGhhdCBoYXZlIGEgbm9u LXVuaXF1ZSB2YWx1ZSBTdWItDQoNCiAgICAgIEF0dHJpYnV0ZSBhcmUgbWF0Y2hlZCBieSBjb21w YXJpbmcgYWxsIFN1Yi1BdHRyaWJ1dGUgdmFsdWVzIGZyb20NCg0KICAgICAgdGhlIFBBVENIIHJl cXVlc3QgYm9keSB0byB0aGUgU3ViLUF0dHJpYnV0ZSB2YWx1ZXMgb2YgdGhlDQoNCiAgICAgIFJl c291cmNlLiAgQSBkZWxldGUgb3BlcmF0aW9uIGlzIGlnbm9yZWQgaWYgdGhlIGF0dHJpYnV0ZSdz IG5hbWUNCg0KICAgICAgaXMgaW4gdGhlIG1ldGEuYXR0cmlidXRlcyBsaXN0LiAgSWYgdGhlIHJl cXVlc3RlZCB2YWx1ZSB0byBkZWxldGUNCg0KICAgICAgZG9lcyBub3QgbWF0Y2ggYSB1bmlxdWUg dmFsdWUgb24gdGhlIFJlc291cmNlIHRoZSBzZXJ2ZXIgTUFZDQoNCiAgICAgIHJldHVybiBhIEhU VFAgNDAwIGVycm9yLg0KDQoNCkZvciBhIHNwZWMgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSBhYm91 dCBzaW1wbGljaXR5LCB0aGUgYWJvdmUgZGVzY3JpcHRpb24gaXMgYW55dGhpbmcgYnV0IHNpbXBs ZS4gSSBrbm93IHlvdSBndXlzIGhhdmUgd29ya2VkIGhhcmQgb24gdGhpcyBhbmQgSSBkb24ndCBt ZWFuIHRvIGRpc3BhcmFnZSB0aG9zZSBlZmZvcnRzLCBidXQgdGhpbmsgYWJvdXQgaG93IHRoZSBh Ym92ZSBwYXNzYWdlIHdvdWxkIGFwcGVhciB0byBhIG5ldyByZWFkZXIgKGkuZS4sIGEgbm92aWNl IHRvIHRoZSBzcGVjLCBub3QgYSB0ZWNobm9sb2d5IG5vdmljZSkuDQoNClRoZXJlIGlzIHNvbWV0 aGluZyBmdW5kYW1lbnRhbGx5IGJyb2tlbiwgYW5kIGl0IGlzIHRoaXM6IG11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzIHdpdGhvdXQgYSB1bmlxdWUgaWRlbnRpZmllciBwZXIgdmFsdWUuIElmIHlvdSBk b24ndCBmaXggdGhhdCwgeW91IHdvbid0IGdldCBzaW1wbGljaXR5Lg0KDQpXZSBrbm93IExEQVAg dHJlZXMgYXJlIGJyb2tlbiBmb3IgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMuIEFzIE1hcmsgV2Fo bCBmYW1vdXNseSBjb21tZW50ZWQ8aHR0cDovL3d3dy5sZGFwLmNvbS8xL2NvbW1lbnRhcnkvd2Fo bC8yMDA1MDYxN18wMS5zaHRtbD4gYmFjayBpbiAyMDA1LA0KDQoiVW5mb3J0dW5hdGVseSwgc29t ZSBvZiB0aGUgZW1lcmdpbmcgcHJvdG9jb2xzIHdoaWNoIGFsc28gaW50ZW5kIHRvIHJlcHJlc2Vu dCBhbmQgdHJhbnNmZXIgcGVyc29uYWwgaWRlbnRpdHkgaW5mb3JtYXRpb24gaGF2ZSBwZXJoYXBz IHRha2VuIGEgc3RlcCBiYWNrd2FyZHMgYnkgbm90IGV2ZW4gY29uc2lkZXJpbmcgdGhlc2UgaXNz dWVzLCBwZXJoYXBzIHN3ZWVwaW5nIHRoZW0gdW5kZXIgdGhlIHJ1ZyBpbiB0aGUgZ3Vpc2Ugb2Yg c2ltcGxpY2l0eSwgWE1MaWZpY2F0aW9uLCBvciAiZml4IGluIHRoZSBuZXh0IHZlcnNpb24iLCB3 aGljaCBvbmx5IHBvc3Rwb25lIGZpbmRpbmcgaW50ZXJvcGVyYWJsZSBzb2x1dGlvbnMgdG8gYWxs b3dpbmcgYXBwbGljYXRpb25zIHRvIGV4cHJlc3MgdGhlIGlkZW50aXR5IGVudHJpZXMgdGhleSB3 YW50IHRvIGV4cHJlc3MuIg0KDQpTQ0lNIGlzIGV4YWN0bHkgb25lIG9mIHRoZXNlICJlbWVyZ2lu ZyBwcm90b2NvbHMiIFdhaGwgdGFsa3MgYWJvdXQsIGFuZCB3aGF0IEkgc2VlIG5vdyBzdHJpa2Vz IG1lIGFzICJzd2VlcGluZyB0aGVzZSBpc3N1ZXMgdW5kZXIgdGhlIHJ1ZyBpbiB0aGUgZ3Vpc2Ug b2Ygc2ltcGxpY2l0eSIuIEFwb2xvZ2llcyBmb3IgdGhlIGJsdW50bmVzcy4NCg0KTXkgdGFrZSBp cyB0aGF0IFNQcyBhcmUgX2FscmVhZHlfIHN0cnVnZ2xpbmcgdG8gbWFuYWdlIG11bHRpLXZhbHVl ZCBhdHRyaWJ1dGVzLCBhbmQgZXhpc3RpbmcgbWVjaGFuaXNtcyBhcmUgY2x1bXN5PGh0dHA6Ly9m ZjE5NTkud29yZHByZXNzLmNvbS8yMDExLzA3LzI4L3JlcGxhY2UtYS12YWx1ZS1vZi1hLW11bHRp LXZhbHVlZC1hdHRyaWJ1dGUvPi4gVGhleSB3b3VsZCBiZSBncmF0ZWZ1bCBmb3IgYSBzcGVjaWZp Y2F0aW9uIHRoYXQgbWFkZSBvcGVyYXRpb25zIGVhc2llciBhdCB0aGUgY29zdCBvZiBhIHJlLWVu Z2luZWVyZWQgc2NoZW1hLiBUaGF0IGNhbGxzIGZvciBzb21lIHRob3VnaHQgbGVhZGVyc2hpcCBm cm9tIHRoaXMgd29ya2luZyBncm91cC4NCg0KUmVnYXJkcywNCkdhbmVzaA0KDQpPbiAxMyBBdWd1 c3QgMjAxMiAxMDoxMywgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkkgc3Ryb25nbHkgb2JqZWN0IHRvIGFueXRoaW5n IHRoYXQgbGVhZHMgdG8gYSByZWFkIGJlZm9yZSBtb2RpZnkgcmVxdWlyZW1lbnQuIFRvbyBjb21w bGV4IGFuZCB0b28gY2hhdHR5Lg0KDQpQaGlsDQoNCk9uIDIwMTItMDgtMTIsIGF0IDE1OjI5LCBH YW5lc2ggYW5kIFNhc2hpIFByYXNhZCA8Zy5jLnByYXNhZEBnbWFpbC5jb208bWFpbHRvOmcuYy5w cmFzYWRAZ21haWwuY29tPj4gd3JvdGU6DQo+IFdvdWxkIGl0IGhhdmUgdG8gYmUgc3RvcmVkIG9u IHRoZSBhY2NvdW50IGRhdGFiYXNlIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyPw0KDQpZZXMuDQoN Cj4gSWYgc28sIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgaW1wcmFjdGljYWJsZSBpbiB0aGUgY29y ZSBzY2hlbWEuIEluZGVlZCBpdCBpbXBsaWVzIHRoYXQgYSBzZXJ2aWNlIHByb3ZpZGVyIG11c3Qg ZXh0ZW5kIHRoZSBzY2hlbWEgb2YgaGlzIGFjY291bnQgcmVwb3NpdG9yeSAoTERBUCBwYXJ0aXRp b24sIFNRTCBkYiwg4oCmKSBhbmQg4oCccHJlcGFyZSBpdOKAnSBmb3IgU0NJTSBpbnRlZ3JhdGlv bi4NCg0KV2h5PyBUaGF0IGRvZXNuJ3QgbmVjZXNzYXJpbHkgZm9sbG93LiBJbXBsZW1lbnRhdGlv biBpcyBpbmRlcGVuZGVudCBvZiByZXByZXNlbnRhdGlvbi4gV2UncmUgdGFsa2luZyBhYm91dCBh IGNoYW5nZSBpbiByZXByZXNlbnRhdGlvbiB0byBtYWtlIHRoZSBBUEkgY2xlYW5lci4NCg0KQXMg YSBzaW1wbGUgZXhhbXBsZSwgaWYgYW4gTERBUCBub2RlIGlzIGJlaW5nIHVzZWQgdG8gaG9sZCBh IGxpc3Qgb2YgY29tbWEtc2VwYXJhdGVkIGVtYWlsIGFkZHJlc3NlcywgaXQgY2FuIGp1c3QgYXMg ZWFzaWx5IHN0b3JlIGNvbW1hLXNlcGFyYXRlZCBuYW1lLXZhbHVlIHBhaXJzLg0KDQoNCm1haWw6 IGpvaG5fc21pdGhAeWFob28uY29tPG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sIGpvaG4u c21pdGhAZ21haWwuY29tPG1haWx0bzpqb2huLnNtaXRoQGdtYWlsLmNvbT4sIGpzbWl0aDE5NzBA aG90bWFpbC5jb208bWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20+DQoNCmNhbiBiZSBjaGFu Z2VkIHRvDQoNCm1haWw6IGFhNjYtZGFmOWVhM2JkOTAyPWpvaG5fc21pdGhAeWFob28uY29tPG1h aWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sOWNkYS04NjQ2YzMwODViYmY9am9obi5zbWl0aEBn bWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tPiwgN2E2ZDFkZTY2NGUxPWpzbWl0 aDE5NzBAaG90bWFpbC5jb208bWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20+DQoNClRoYXQn cyB3aHkgSSBhc2tlZCBpZiB0aGVyZSB3YXMgYW4gU1AgcmVwcmVzZW50YXRpdmUgb24gdGhpcyB3 b3JraW5nIGdyb3VwIHdobyBjb3VsZCBleHBsYWluIHdoYXQgc3VjaCBhIGNoYW5nZSBjb3VsZCBt ZWFuIGZvciB0aGVtLiBBcyBvZiBub3csIGl0IGxvb2tzIGxpa2Ugb3RoZXIgcGVvcGxlIGFyZSBw cmVzdW1pbmcgdGhhdCBTUHMgd2lsbCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlc2UgY2hh bmdlcyBlYXNpbHkgYW5kIGFyZSByZWplY3RpbmcgdGhlbSBmb3IgdGhhdCByZWFzb24uDQoNClJl Z2FyZHMsDQpHYW5lc2gNCg0KT24gMTMgQXVndXN0IDIwMTIgMDQ6MjksIEVtbWFudWVsIERyZXV4 IDxlZHJldXhAY2xvdWRpd2F5LmNvbTxtYWlsdG86ZWRyZXV4QGNsb3VkaXdheS5jb20+PiB3cm90 ZToNCg0KPT4gIGFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9ICIyNDMiDQoN Cg0KV2hlcmUgd291bGQgM2NiYWFmZjhlODRlIGNvbWUgZnJvbT8gV291bGQgaXQgaGF2ZSB0byBi ZSBzdG9yZWQgb24gdGhlIGFjY291bnQgZGF0YWJhc2Ugb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXI/ DQoNCklmIHNvLCBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIGltcHJhY3RpY2FibGUgaW4gdGhlIGNv cmUgc2NoZW1hLiBJbmRlZWQgaXQgaW1wbGllcyB0aGF0IGEgc2VydmljZSBwcm92aWRlciBtdXN0 IGV4dGVuZCB0aGUgc2NoZW1hIG9mIGhpcyBhY2NvdW50IHJlcG9zaXRvcnkgKExEQVAgcGFydGl0 aW9uLCBTUUwgZGIsIOKApikgYW5kIOKAnHByZXBhcmUgaXTigJ0gZm9yIFNDSU0gaW50ZWdyYXRp b24uDQpUaGlzIHdvdWxkIGJlIGEgc2hvdyBzdG9wcGVyLiBTQ0lNIG11c3QgYmUgdHJhbnNwYXJl bnQsIGFuZCBtdXN0IGJlIGFibGUgdG8gYmUgcHV0IG9uIHRvcCBvZiBhbiBleGlzdGluZyBzeXN0 ZW0gdG8gcHJvdmlkZSBwcm92aXNpb25pbmcgYXBpcy4NCg0KU2FpZCBkaWZmZXJlbnRseSwgU0NJ TSBtdXN0IG5vdCBiZSBpbnRydXNpdmUgZm9yIGV4aXN0aW5nIHN5c3RlbXMgYW5kIG11c3Qgbm90 IHJlcXVpcmUgbW9kaWZpY2F0aW9ucyB0byBhbGxvdyBpdHMgaW50ZWdyYXRpb24uDQpDb3JyZWN0 IG1lIGlmIEkgbWlzdW5kZXJzdG9vZCB5b3VyIHN1Z2dlc3Rpb24uDQoNCi0tDQpSZWdhcmRzLA0K RW1tYW51ZWwgRHJldXgNCmh0dHA6Ly93d3cuY2xvdWRpd2F5LmNvbTxodHRwOi8vd3d3LmNsb3Vk aXdheS5jb20vPg0KVGVsOiArMzMgNCAyNiA3OCAxNyA1ODx0ZWw6JTJCMzMlMjA0JTIwMjYlMjA3 OCUyMDE3JTIwNTg+DQpNb2JpbGU6ICszMyA2IDQ3IDgxIDI2IDcwPHRlbDolMkIzMyUyMDYlMjA0 NyUyMDgxJTIwMjYlMjA3MD4NCnNreXBlOiBFbW1hbnVlbC5EcmV1eA0KDQpEZSA6IEdhbmVzaCBh bmQgU2FzaGkgUHJhc2FkIFttYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb208bWFpbHRvOmcuYy5w cmFzYWRAZ21haWwuY29tPl0NCkVudm95w6kgOiBkaW1hbmNoZSAxMiBhb8O7dCAyMDEyIDA0OjUz DQrDgCA6IEtlbGx5IEdyaXp6bGUNCkNjIDogc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRm Lm9yZz47IFBoaWwgSHVudA0KT2JqZXQgOiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwg SXNzdWUgMjQNCg0KPiAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBkb24ndCBoYXZlIGEg dmFsdWUgc3ViLWF0dHJpYnV0ZSAoZWcgLSBhZGRyZXNzKSBoYXZlIHRvIHNwZWNpZmllZCBjb21w bGV0ZWx5IGZvciB1bmlxdWVuZXNzLg0KDQpUaGF0J3MgZXhhY3RseSB0aGUgcG9pbnQuIEhvdyBk byB3ZSAic3BlY2lmeSBjb21wbGV0ZWx5IGZvciB1bmlxdWVuZXNzIj8NCg0KSW4gdGhlIGV4YW1w bGUgYmVsb3csIGhvdyBhcmUgeW91IHByb3Bvc2luZyB0aGF0IHRoZSBmb2xsb3dpbmcgZWxlbWVu dCBiZSB1cGRhdGVkIGlmIHdlIGNhbid0IHVzZSBwb3NpdGlvbmFsIGluZGV4ZXM/DQoNCmFkZHJl c3Nlc1sxXS5zdHJlZXQtbnVtYmVyID0gIjI0MyINCg0KVXNlciBvYmplY3Q6DQoNCnsNCiAgLi4u DQogIGFkZHJlc3NlczogWw0KICAgIHsNCiAgICAgICJ0eXBlIiA6ICJob21lIiwNCiAgICAgICJz dHJlZXQtbnVtYmVyIiA6ICIzNSIsDQogICAgICAic3RyZWV0LW5hbWUiIDogIkhpZ2ggUm9hZCIs DQogICAgICAic3VidXJiIiA6ICJFYXN0IENhbWRlbiIsDQogICAgICAicG9zdGNvZGUiIDogIjUz NDYiLA0KICAgICAgInN0YXRlIiA6ICJTQSIsDQogICAgICAiY291bnRyeSIgOiAiQXVzdHJhbGlh Ig0KICAgIH0sDQogICAgew0KICAgICAgInR5cGUiIDogIm9mZmljZSIsDQogICAgICAic3RyZWV0 LW51bWJlciIgOiAiMjEzIiwNCiAgICAgICJzdHJlZXQtbmFtZSIgOiAiTWFpbiBTdHJlZXQiLA0K ICAgICAgInN1YnVyYiIgOiAiQWRlbGFpZGUiLA0KICAgICAgInBvc3Rjb2RlIiA6ICI1MDAwIiwN CiAgICAgICJzdGF0ZSIgOiAiU0EiLA0KICAgICAgImNvdW50cnkiIDogIkF1c3RyYWxpYSINCiAg ICB9DQogIF0NCn0NCg0KSXQncyBpbXByYWN0aWNhbCB0byB1c2UgdGhlIHZhbHVlIGJlY2F1c2Ug aXQncyB0aGUgd2hvbGUgZGljdGlvbmFyeSBlbGVtZW50Og0KDQp7DQogICJ0eXBlIiA6ICJvZmZp Y2UiLA0KICAic3RyZWV0LW51bWJlciIgOiAiMjEzIiwNCiAgInN0cmVldC1uYW1lIiA6ICJNYWlu IFN0cmVldCIsDQogICJzdWJ1cmIiIDogIkFkZWxhaWRlIiwNCiAgInBvc3Rjb2RlIiA6ICI1MDAw IiwNCiAgInN0YXRlIiA6ICJTQSIsDQogICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiDQp9DQoNCldp dGggbXkgcHJvcG9zYWwsIHRoZSAiYWRkcmVzc2VzIiBhcnJheSBnZXRzIGNvbnZlcnRlZCB0byBh IGRpY3Rpb25hcnksIGFuZCB0aGVuIHdlIGhhdmUgYSBzdGFibGUgd2F5IG9mIHJlZmVyZW5jaW5n IHRoaXMgZWxlbWVudDoNCg0KYWRkcmVzc2VzLjNjYmFhZmY4ZTg0ZS5zdHJlZXQtbnVtYmVyID0g IjI0MyINCg0Kew0KICAuLi4NCiAgYWRkcmVzc2VzOiB7DQogICAgImQ2ZWEzNjU0NjJmNSIgOg0K ICAgIHsNCiAgICAgICJ0eXBlIiA6ICJob21lIiwNCiAgICAgICJzdHJlZXQtbnVtYmVyIiA6ICIz NSIsDQogICAgICAic3RyZWV0LW5hbWUiIDogIkhpZ2ggUm9hZCIsDQogICAgICAic3VidXJiIiA6 ICJFYXN0IENhbWRlbiIsDQogICAgICAicG9zdGNvZGUiIDogIjUzNDYiLA0KICAgICAgInN0YXRl IiA6ICJTQSIsDQogICAgICAiY291bnRyeSIgOiAiQXVzdHJhbGlhIg0KICAgIH0sDQogICAgIjNj YmFhZmY4ZTg0ZSIgOg0KICAgIHsNCiAgICAgICJ0eXBlIiA6ICJvZmZpY2UiLA0KICAgICAgInN0 cmVldC1udW1iZXIiIDogIjIxMyIsDQogICAgICAic3RyZWV0LW5hbWUiIDogIk1haW4gU3RyZWV0 IiwNCiAgICAgICJzdWJ1cmIiIDogIkFkZWxhaWRlIiwNCiAgICAgICJwb3N0Y29kZSIgOiAiNTAw MCIsDQogICAgICAic3RhdGUiIDogIlNBIiwNCiAgICAgICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEi DQogICAgfQ0KICB9DQp9DQoNCklmIHlvdSdyZSBwcm9wb3Npbmcgb25lIG1lY2hhbmlzbSBmb3Ig Y29tcG9zaXRlIGF0dHJpYnV0ZXMgYW5kIGFub3RoZXIgbWVjaGFuaXNtIGZvciBzaW1wbGUgYXR0 cmlidXRlcywgSSB3b3VsZCBzdWdnZXN0IHRoYXQncyBhY3R1YWxseSBtb3JlIGNvbXBsZXggdGhh biBhZG9wdGluZyBhIHNpbmdsZSBtZWNoYW5pc20gdGhhdCB3b3JrcyB0aGUgc2FtZSB3YXkgZm9y IF9hbGxfIGF0dHJpYnV0ZXMuIFJlbWVtYmVyIHRoYXQgYSBsb3Qgb2YgdGhlIGFkbWluaXN0cmF0 aW9uIGlzIHByb2JhYmx5IGdvaW5nIHRvIGJlIHNjcmlwdGVkIHJhdGhlciB0aGFuIGRvbmUgYnkg aGFuZCwgYW5kIGhhdmluZyB0d28gbWVjaGFuaXNtcyAoZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhl IGF0dHJpYnV0ZSBpcyBzaW1wbGUgb3IgY29tcG9zaXRlKSB3aWxsIGNvbXBsaWNhdGUgZXZlcnkg c2NyaXB0IHRoYXQgaGFzIHRvIGJlIHdyaXR0ZW4uDQoNClRoZXJlJ3MgYSBsb3Qgb2YgdGFsayBh Ym91dCB0aGUgImJ1cmRlbiIgb24gdGhlIFNQcywgYnV0IEkgYmVsaWV2ZSB0aGlzIGlzIG92ZXJi bG93bi4gSXMgdGhlcmUgYW55IFNQIHJlcHJlc2VudGF0aXZlIGluIHRoaXMgV0cgd2hvIGNhbiB0 ZWxsIHVzIHdoYXQgdGhpcyBwcm9wb3NhbCB3aWxsIGFjdHVhbGx5IGVudGFpbCBmb3IgdGhlbT8N Cg0KUmVnYXJkcywNCkdhbmVzaA0KDQpPbiAxMiBBdWd1c3QgMjAxMiAxMTo1MywgS2VsbHkgR3Jp enpsZSA8a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxlQHNh aWxwb2ludC5jb20+PiB3cm90ZToNCkdhbmVzaCwNCg0KVGhpcyBpcyBleGFjdGx5IGhvdyBQQVRD SCB3b3JrcyBpbiBTQ0lNIDEuMC4gIE11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIHRoYXQgaGF2ZSBh IHZhbHVlIHN1Yi1hdHRyaWJ1dGUgY2FuIGJlIHJlbW92ZWQgYnkgc3BlY2lmeWluZyBvbmx5IHRo ZSB2YWx1ZSBzaW5jZSBpdCBpcyB1bmlxdWUuICBNdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB0aGF0 IGRvbid0IGhhdmUgYSB2YWx1ZSBzdWItYXR0cmlidXRlIChlZyAtIGFkZHJlc3MpIGhhdmUgdG8g c3BlY2lmaWVkIGNvbXBsZXRlbHkgZm9yIHVuaXF1ZW5lc3MuICBBcyBJIGhhdmUgc2FpZCBiZWZv cmUsIEkgYW0gdmVyeSBvcHBvc2VkIHRvIGFkZGluZyBhIHVuaXF1ZSBpZGVudGlmaWVyIHRvIGVh Y2ggZWxlbWVudCBpbiBhIG11bHRpLXZhbHVlZCBjb2xsZWN0aW9uIGR1ZSB0byB0aGUgYnVyZGVu IGl0IHdpbGwgcHV0IG9uIFNQcy4gIElzIGl0IGVsZWdhbnQ/ICBOby4gIElzIGl0IGZ1bmN0aW9u YWw/ICBZZXMuICBXaWxsIHRoaXMgbm9uLWVsZWdhbmNlIGFmZmVjdCBhZG9wdGlvbj8gIE15IG9w aW5pb24gaXMgdGhhdCBhZGRpbmcgdW5pcXVlIGtleXMgdG8gZWFjaCBlbGVtZW50IHdpbGwgaGF2 ZSBhIG11Y2ggbW9yZSBkZXRyaW1lbnRhbCBlZmZlY3Qgb24gYWRvcHRpb24uDQoNCkkgZG8gYmVs aWV2ZSB0aGF0IGluIGdlbmVyYWwgUEFUQ0ggY2FuIGJlIG1hZGUgbW9yZSBpbnR1aXRpdmUgd2l0 aG91dCBhZGRpbmcgdWlkcyB0byBlYWNoIGVsZW1lbnQuICBUaGUgdmVyYnMgdGhhdCB5b3UgcHJv cG9zZSBtYWtlIHNlbnNlLiAgVGhlcmUgaXMgYWxzbyBhIEpTT04gUGF0Y2ggaW5mb3JtYXRpb25h bCBkcmFmdCBpbiB0aGUgSUVURiB0aGF0IGlzIGludGVyZXN0aW5nIC0gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDIuICBJdCByZWxpZXMg b24gYSBKU09OIFBvaW50ZXIgZHJhZnQgd2hpY2ggdXNlcyBpbmRleC1iYXNlZCBhZGRyZXNzaW5n IGZvciBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcy4gIEkgdGhpbmsgdGhhdCB0aGlzIGlzIHNvbWV0 aGluZyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQgd2l0aGluIHRoZSBXRyBhbmQgSSB3b3VsZCBi ZSB3aWxsaW5nIHRvIGxlYWQgdGhpcyBlZmZvcnQuDQoNCkknbSBjdXJpb3VzIGlmIGFueW9uZSBl bHNlIGluIHRoZSBXRyBpcyBpbiBmYXZvciBvZiB1bmlxdWUgaWRlbnRpZmllcnMgZm9yIGV2ZXJ5 IG11bHRpLXZhbHVlZCBlbGVtZW50Lg0KDQotLUtlbGx5DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpGcm9tOiBzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91 bmNlc0BpZXRmLm9yZz4gW3NjaW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2NpbS1ib3VuY2Vz QGlldGYub3JnPl0gb24gYmVoYWxmIG9mIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIFtnLmMucHJh c2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+XQ0KU2VudDogU2F0dXJk YXksIEF1Z3VzdCAxMSwgMjAxMiAxMDo1MCBBTQ0KVG86IFBoaWwgSHVudA0KQ2M6IHNjaW1AaWV0 Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGln ZXN0LCBWb2wgOCwgSXNzdWUgMjQNClBoaWwsDQoNClRoZSByZWFzb24gd2UgY2Fubm90IHVzZSB0 aGUgdmFsdWUgaXRzZWxmIHRvIGlkZW50aWZ5IGFuIGVsZW1lbnQgaXMgdGhhdCB0aGlzIG1ldGhv ZCB3aWxsIG9ubHkgd29yayBmb3Igc2ltcGxlIGVsZW1lbnRzLCBub3QgZm9yIG5lc3RlZCBzdHJ1 Y3R1cmVzLiBpLmUuLCBpZiB3ZSBoYWQgYW4gYXJyYXkgb2YgZGljdGlvbmFyaWVzIChlLmcuLCB3 ZSBoYWQgdG8gcmVjb3JkIGFuIGFycmF5IG9mIGFkZHJlc3NlcyBmb3IgZWFjaCBjdXN0b21lciwg d2l0aCBlYWNoIGFkZHJlc3MgZWxlbWVudCBoYXZpbmcgc3ViLWVsZW1lbnRzIGxpa2Ugc3RyZWV0 IG51bWJlciwgc3RyZWV0IG5hbWUsIHN1YnVyYiwgZXRjLiksIHRoZW4gaXQgd291bGQgYmUgY2x1 bXN5IHRvIHN1cHBseSB0aGUgZW50aXJlIHZhbHVlIG9mIHRoZSBhcnJheSBlbGVtZW50IGJlY2F1 c2UgaXQncyBpdHNlbGYgYSBkaWN0aW9uYXJ5LiBDcmVhdGluZyBhIHVuaXF1ZSBrZXkgZm9yIGVh Y2ggZWxlbWVudCBzY2FsZXMgYmV0dGVyLg0KDQpSZWdhcmRzLA0KR2FuZXNoDQpPbiAxMiBBdWd1 c3QgMjAxMiAwMToxMiwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhp bC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCkdhbmVzaCwNCg0KSGVyZSdzIHRoZSBzYW1wbGUg dGhhdCBjb25jZXJuZWQgbWUuLi4NClRoZSB0d28gb3BlcmF0aW9ucyBkaWZmZXIgc2lnbmlmaWNh bnRseSwgYW5kIGl0J3Mgbm90IHZlcnkgaW50dWl0aXZlLg0KV2l0aCBteSBzdWdnZXN0aW9uLCBo ZXJlJ3MgaG93IHRvIGRlbGV0ZSBhIHNpbmdsZSBtZW1iZXIgZnJvbSBhIGdyb3VwOg0KDQpQQVRD SCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1iNGZkLTliNGRhM2Y5MDhjZSBIb3N0OiBleGFt cGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20vPiBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24gQXV0 aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOCBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzki IHsNCiJvcGVyYXRpb25zIiA6IFsNCnsNCiJSRVRJUkUiIDogew0KImtleSIgOiAibWVtYmVycy4y ODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiDQp9DQp9DQpdIH0NCg0KDQpZb3Ug Z2F2ZSBvdGhlciBleGFtcGxlcyBvZiBhbiBhdHRyaWJ1dGUgd2l0aCBhbiBpZGVudGlmaWVyIHRo YXQgbWF0Y2hlZCB0aGF0IHZhbHVlIG9yIG9mIGlkZW50aWZpZXJzIHRoYXQgd2VyZSBhZGRpdGlv bmFsIHVuaXF1ZSBrZXlzLg0KDQpHaXZlbiB0aGF0IG11bHRpLXZhbHVlcyBtdXN0IGJlIGVhY2gg dW5pcXVlLCBJIGRvbid0IHNlZSB0aGUgcG9pbnQgb2YgdGhlIGV4dHJhIGluZGV4aW5nIHRvIHN1 cHBvcnQgdGhpcy4gSnVzdCB1c2UgdGhlIHZhbHVlIGFzIHRoZSBpdGVtIHlvdSB3aXNoIHRvIGRl bGV0ZS4NCg0KSSBhZ3JlZSwgdGhlIGRlbGV0ZSB2YWx1ZSBvcGVyYXRpb24gY291bGQgYmUgbW9y ZSBleHBsaWNpdCBhbmQgY2xlYXIgaW4gZ2VuZXJhbC4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRp ZA0Kd3d3LmluZGVwZW5kZW50aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20vPg0K cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPg0KDQoNCg0K T24gMjAxMi0wOC0xMSwgYXQgMjozMCBBTSwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgd3JvdGU6 DQoNCj4gIEZvciB0aGUgbXVsdGktdmFsdWUgZXhhbXBsZSB5b3UgZ2F2ZSB5b3UgdXNlZCB0aGUg dmFsdWUgYXMgdGhlIGF0dHJpYnV0ZSBuYW1lIGtleS4NCg0KTm93IEknbSBjb25mdXNlZCA6LSku IEkgZG9uJ3QgYmVsaWV2ZSBhbnkgb2YgbXkgZXhhbXBsZXMgZXZlciB1c2VkIGEgdmFsdWUgYXMg dGhlIGtleS4NCg0KQ291bGQgeW91IHBsZWFzZSBzaG93IG1lIHdoaWNoIGV4YW1wbGUgeW91IG1l YW4sIGFuZCB3aGljaCBwYXJ0cyBvZiBpdCB5b3UgYmVsaWV2ZSB0byBiZSB0aGUgdmFsdWU/DQoN ClJlZ2FyZHMsDQpHYW5lc2gNCk9uIDExIEF1Z3VzdCAyMDEyIDEzOjU5LCBQaGlsIEh1bnQgPHBo aWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0K DQpGb3IgdGhlIG11bHRpLXZhbHVlIGV4YW1wbGUgeW91IGdhdmUgeW91IHVzZWQgdGhlIHZhbHVl IGFzIHRoZSBhdHRyaWJ1dGUgbmFtZSBrZXkuDQoNClRoYXQgbWVhbnMgYSBsb3QgbW9yZSBjb21w bGV4IGluZGV4aW5nIHN0cnVjdHVyZS4gQmV0dGVyIHRvIGp1c3Qgc2F5IGRlbGV0ZSBhIHNwZWNp ZmljIHZhbHVlLg0KDQpUaGUgc3BlYyBhbHJlYWR5IGFsbG93cyBtdWx0aXBsZSB2YWx1ZXMgdG8g aGF2ZSB0YWdzIGxpa2UgaG9tZSwgd29yaywgZXRjLg0KDQpQaGlsDQoNCk9uIDIwMTItMDgtMTAs IGF0IDIxOjQ1LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCA8Zy5jLnByYXNhZEBnbWFpbC5jb208 bWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPj4gd3JvdGU6DQo+IEluIHlvdXIgZXhhbXBsZSB5 b3UgYXJlIGNvbmZsYXRpbmcgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgaWQuDQoNCkkgZG9uJ3Qg YmVsaWV2ZSBzby4NCg0KSSdtIGFkb3B0aW5nIGEgbW9kZWwgd2hlcmUgZXZlcnkgYXR0cmlidXRl IG9mIHRoZSByZXNvdXJjZSBpcyBhIGtleS12YWx1ZSBwYWlyLiBUaGUga2V5IGlzIGEgbmFtZSBv ciBJRC4NCg0KRm9yIG5vbi1yZXBlYXRpbmcgYXR0cmlidXRlcyAoYm90aCBzaW1wbGUgYW5kIGNv bXBvc2l0ZSksIHRoZSBrZXkgaXMgdGhlIGF0dHJpYnV0ZSBuYW1lIGl0c2VsZi4NCg0KU2ltcGxl IGF0dHJpYnV0ZToNCg0KS2V5OiAiZG9iIg0KVmFsdWU6ICIwMSBKYW4gMTk3MCINCg0KRm9yIGNv bXBvc2l0ZSBhdHRyaWJ1dGVzLCB0aGUga2V5IGVtcGxveXMgZG90IG5vdGF0aW9uIHRvIHNwZWNp ZnkgdGhlIGZ1bGx5LXF1YWxpZmllZCBhdHRyaWJ1dGUgbmFtZSwgZS5nLiwgImFkZHJlc3MucG9z dGNvZGUiLg0KDQpDb21wb3NpdGUgYXR0cmlidXRlOg0KDQpLZXk6ICJhZGRyZXNzLnN0cmVldC1u dW1iZXIiDQpWYWx1ZTogIjEwIg0KDQpLZXk6ICJhZGRyZXNzLnN1YnVyYiINClZhbHVlOiAiRWFz dCBDYW1kZW4iDQoNCkZvciByZXBlYXRpbmcgKG11bHRpLXZhbHVlZCkgYXR0cmlidXRlcywgSSdt IHN1Z2dlc3RpbmcgdGhhdCB0aGVyZSBiZSBuZXcga2V5cyBmb3IgZWFjaCBpbmRpdmlkdWFsIHZh bHVlLCBvdGhlcndpc2UgdGhleSBhcmUgaW1wb3NzaWJsZSB0byBkaXN0aW5ndWlzaCwgYW5kIGEg cG9zaXRpb25hbCBpbmRleCBpcyBpbmFkZXF1YXRlLiBTbyB3ZSBjb252ZXJ0IHRoZSBhcnJheSBp bnRvIGEgZGljdGlvbmFyeSBhbmQgdGhpcyB0aGVuIGJlY29tZXMgYSBjb21wb3NpdGUgYXR0cmli dXRlIHVzaW5nIGRvdCBub3RhdGlvbiBmb3IgdGhlIGtleS4NCg0KTXVsdGktdmFsdWVkIGF0dHJp YnV0ZToNCg0KS2V5OiAiZW1haWxzLjdkZmNiNDQ0LTc0ZDgtNGYxNy1hYTY2LWRhZjllYTNiZDkw MiINClZhbHVlOiAiam9obl9zbWl0aEB5YWhvby5jb208bWFpbHRvOmpvaG5fc21pdGhAeWFob28u Y29tPiINCg0KU28gdGhpcyBhbGxvd3MgdXMgdG8gYXBwbHkgdW5pZm9ybSB0cmVhdG1lbnQgdG8g YW55IGFyYml0cmFyaWx5IGRlZXAgcmVzb3VyY2Ugc3RydWN0dXJlLiBXZSBjYW4gcmVmZXIgdG8g ZXZlcnkgbGVhZiB2YWx1ZSB3aXRoIGEga2V5IHRoYXQgaXMgdGhlIGZ1bGx5LXF1YWxpZmllZCBu YW1lIHVzaW5nIGRvdCBub3RhdGlvbi4NCg0KVGhlIHZlcmJzIGFyZSBqdXN0IHVuYW1iaWd1b3Vz IG9wZXJhdGlvbnMgb24gdGhlc2UgKG5vdykgZXhwbGljaXRseSBhZGRyZXNzYWJsZSBhdHRyaWJ1 dGVzLg0KDQpJTkNMVURFIHRvIGEgY29sbGVjdGlvbiBhbmQgc3BlY2lmeSBvbmx5IHRoZSB2YWx1 ZS4gVGhlIGtleSBpcyBnZW5lcmF0ZWQgYW5kIHJldHVybmVkLiBUaGUgZnVsbHktcXVhbGlmaWVk IGtleSBpcyA8Y29sbGVjdGlvbi1uYW1lPi48bmV3bHktZ2VuZXJhdGVkLUlEPiBhbmQgdGhlIHZh bHVlIGlzIHdoYXQgd2FzIHNwZWNpZmllZCBpbiB0aGUgSU5DTFVERS4NCg0KUkVQTEFDRSBhIGZ1 bGx5LXF1YWxpZmllZCBrZXkgd2l0aCBhIG5ldyB2YWx1ZS4gSWYgdGhlIGtleSBkb2Vzbid0IGV4 aXN0LCByZXR1cm4gYSAiNDA0IE5vdCBGb3VuZCIuDQoNClBMQUNFIGEgdmFsdWUgYXQgdGhlIGxv Z2ljYWwgbG9jYXRpb24gaW1wbGllZCBieSB0aGUgZnVsbHktcXVhbGlmaWVkIGtleS4gSWYgdGhl cmUgaXMgYWxyZWFkeSBhIGtleSB3aXRoIHRoYXQgbmFtZSwgcmV0dXJuIGEgIjQwOSBDb25mbGlj dCIuDQoNCkZPUkNFIHRoZSBmdWxseS1xdWFsaWZpZWQga2V5IHRvIGhvbGQgdGhlIGdpdmVuIHZh bHVlLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgZXhpc3RlZCBiZWZvcmUgb3Igbm90LiBPbmx5 IGVycm9ycyBwb3NzaWJsZSBhcmUgIjQwMCBCYWQgUmVxdWVzdCIgYW5kICI1MDAgSW50ZXJuYWwg RXJyb3IiLg0KDQpSRVRJUkUgYW4gYXR0cmlidXRlIG9yIGEgY29sbGVjdGlvbiBnaXZlbiBpdHMg ZnVsbHktcXVhbGlmaWVkIGtleS4gVGhlIGltcGxlbWVudGF0aW9uIHdpbGwgZGV0ZXJtaW5lIHdo ZXRoZXIgdGhlIGF0dHJpYnV0ZSB3aWxsIGRpc2FwcGVhciBlbnRpcmVseSBvciB3aWxsIGV4aXN0 IGhvbGRpbmcgYSBudWxsIHZhbHVlICh0aGUgYmxhbmsgc3RyaW5nICIiIG9yIHRoZSBlbXB0eSBv YmplY3Qge30gKS4NCg0KSSdsbCBleHBsYWluIGluIGEgc2VwYXJhdGUgcG9zdCB3aHkgd2UgbmVl ZCBvcGVyYXRpb24gdmVyYnMgbGlrZSB0aGVzZSB0aGF0IGFyZSBpbmRlcGVuZGVudCBvZiB0aGUg SFRUUCB2ZXJicy4NCg0KUmVnYXJkcywNCkdhbmVzaA0KDQpPbiAxMSBBdWd1c3QgMjAxMiAxMDoz OCwgPHNjaW0tcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86c2NpbS1yZXF1ZXN0QGlldGYub3JnPj4g d3JvdGU6DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUg aW5kaXZpZHVhbCBtZXNzYWdlDQphdHRhY2htZW50cyB5b3Ugd2lsbCBuZWVkIHRvIHVwZGF0ZSB5 b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlvdXIgbGlzdA0Kc3Vic2NyaXB0aW9uLiAgVG8gZG8gc28s IGdvIHRvDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0KDQpD bGljayB0aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dG9uLCBsb2cgaW4sIGFu ZCBzZXQgIkdldA0KTUlNRSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0byBNSU1FLiAgWW91IGNh biBzZXQgdGhpcyBvcHRpb24NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3Ug cmVjZWl2ZSBhdCB0aGlzIHBvaW50Lg0KDQoNCg0KU2VuZCBzY2ltIG1haWxpbmcgbGlzdCBzdWJt aXNzaW9ucyB0bw0KICAgICAgICBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPg0K DQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwgdmlz aXQNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQpv ciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcg dG8NCiAgICAgICAgc2NpbS1yZXF1ZXN0QGlldGYub3JnPG1haWx0bzpzY2ltLXJlcXVlc3RAaWV0 Zi5vcmc+DQoNCllvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0K ICAgICAgICBzY2ltLW93bmVyQGlldGYub3JnPG1haWx0bzpzY2ltLW93bmVyQGlldGYub3JnPg0K DQpXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBt b3JlIHNwZWNpZmljDQp0aGFuICJSZTogQ29udGVudHMgb2Ygc2NpbSBkaWdlc3QuLi4iDQoNClRv ZGF5J3MgVG9waWNzOg0KDQogICAxLiBSZTogU0NJTSBQcm90b2NvbCAtIDMgc3VnZ2VzdGlvbnMg Zm9yIGltcHJvdmVtZW50IChQaGlsIEh1bnQpDQoNCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVz c2FnZSAtLS0tLS0tLS0tDQpGcm9tOiBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1h aWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+DQpUbzogR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQg PGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbT4+DQpDYzog IkRpb2RhdGksIE1hcmsiIDxNYXJrLkRpb2RhdGlAZ2FydG5lci5jb208bWFpbHRvOk1hcmsuRGlv ZGF0aUBnYXJ0bmVyLmNvbT4+LCBFbW1hbnVlbCBEcmV1eCA8ZWRyZXV4QGNsb3VkaXdheS5jb208 bWFpbHRvOmVkcmV1eEBjbG91ZGl3YXkuY29tPj4sIFRyZXkgRHJha2UgPHRyZXkuZHJha2VAdW5i b3VuZGlkLmNvbTxtYWlsdG86dHJleS5kcmFrZUB1bmJvdW5kaWQuY29tPj4sIEtlbGx5IEdyaXp6 bGUgPGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWls cG9pbnQuY29tPj4sICJzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYub3JnPiIgPHNjaW1A aWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+Pg0KRGF0ZTogRnJpLCAxMCBBdWcgMjAxMiAx NzozNjo1NCAtMDcwMA0KU3ViamVjdDogUmU6IFtzY2ltXSBTQ0lNIFByb3RvY29sIC0gMyBzdWdn ZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQNCkdhbmVzaCwNCg0KSW4geW91ciBleGFtcGxlIHlvdSBh cmUgY29uZmxhdGluZyB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0ZSBpZC4gSSBmaW5kIHRoYXQgY29u ZnVzaW5nLg0KDQpJIGFncmVlIHRob3VnaCB0aGF0IG9wZXJhdGlvbnMgaW4gcGF0Y2ggY291bGQg YmUgYSBsb3QgbW9yZSBleHBsaWNpdC4NCg0KRWcgZXhwbGljaXRseSBkZWxldGluZyBhIHZhbHVl IGJ5IHNheWluZyBkZWxldGUgb3IgcmV0aXJlLg0KDQpQaGlsDQoNCk9uIDIwMTItMDgtMTAsIGF0 IDE2OjE5LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCA8Zy5jLnByYXNhZEBnbWFpbC5jb208bWFp bHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPj4gd3JvdGU6DQogPiAgSSBhbSBjb25jZXJuZWQgYWJv dXQgeW91ciBzZWNvbmQgc3VnZ2VzdGlvbjoNCg0KTGV0J3MgZGlzY3VzcyB0aGF0IG5vdy4NCg0K VGhlIHRyYWRlLW9mZnMgYXJlIHZlcnkgY2xlYXIgaGVyZS4NCg0KUHJvczoNCg0KUHJvIDEuIFRo ZSBBUEkgdG8gbWFuaXB1bGF0ZSByZXNvdXJjZXMgYmVjb21lcyBzbyBtdWNoIGNsZWFuZXIsIGNv bnNpc3RlbnQgYW5kIGludHVpdGl2ZSB3aGVuIGV2ZXJ5IGluZGl2aWR1YWwgYXR0cmlidXRlIHZh bHVlIGdldHMgaXRzIG93biBJRC4NCg0KSGVyZSdzIGhvdyB0byBkZWxldGUgYSBzaW5nbGUgbWVt YmVyIGZyb20gYSBHcm91cCwgYXMgcGVyIHRoZSBjdXJyZW50IHNwZWM6DQoNCg0KICAgUEFUQ0gg L0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4Y2UNCg0KICAgSG9zdDog ZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tLz4NCg0KICAgQWNjZXB0OiBhcHBsaWNhdGlv bi9qc29uDQoNCiAgIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDgNCg0KICAgRVRh ZzogVy8iYTMzMGJjNTRmMDY3MWM5Ig0KDQoNCg0KICAgew0KDQogICAgICJzY2hlbWFzIjogWyJ1 cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sDQoNCiAgICAgIm1lbWJlcnMiOiBbDQoNCiAgICAg ICB7DQoNCiAgICAgICAgICJkaXNwbGF5IjogIkJhYnMgSmVuc2VuIiwNCg0KICAgICAgICAgInZh bHVlIjogIjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NiINCg0KICAgICAgICAg Im9wZXJhdGlvbiI6ICJkZWxldGUiDQoNCiAgICAgICB9DQoNCiAgICAgXQ0KDQogICB9DQoNCkhl cmUncyBob3cgdG8gZGVsZXRlIEFMTCBtZW1iZXJzIGZyb20gYSBncm91cCBhY2NvcmRpbmcgdG8g dGhlIGN1cnJlbnQgc3BlYzoNCg0KDQogICBQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5 Mi1iNGZkLTliNGRhM2Y5MDhjZQ0KDQogICBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBs ZS5jb20vPg0KDQogICBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb24NCg0KICAgQXV0aG9yaXphdGlv bjogQmVhcmVyIGg0ODBkanM5M2hkOA0KDQogICBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzkiDQoN Cg0KDQogICB7DQoNCiAgICAgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAi XSwNCg0KICAgICAibWV0YSI6IHsNCg0KICAgICAgICJhdHRyaWJ1dGVzIjogWw0KDQogICAgICAg ICAibWVtYmVycyINCg0KICAgICAgIF0NCg0KICAgICB9DQoNCiAgIH0NCg0KVGhlIHR3byBvcGVy YXRpb25zIGRpZmZlciBzaWduaWZpY2FudGx5LCBhbmQgaXQncyBub3QgdmVyeSBpbnR1aXRpdmUu DQpXaXRoIG15IHN1Z2dlc3Rpb24sIGhlcmUncyBob3cgdG8gZGVsZXRlIGEgc2luZ2xlIG1lbWJl ciBmcm9tIGEgZ3JvdXA6DQoNClBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQt OWI0ZGEzZjkwOGNlIEhvc3Q6IGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+QWNjZXB0 OiBhcHBsaWNhdGlvbi9qc29uIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDggRVRh ZzogVy8iYTMzMGJjNTRmMDY3MWM5IiB7DQoib3BlcmF0aW9ucyIgOiBbDQp7DQoiUkVUSVJFIiA6 IHsNCiJrZXkiIDogIm1lbWJlcnMuMjgxOWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2 Ig0KfQ0KfQ0KXSB9DQpIZXJlJ3MgaG93IEkgc3VnZ2VzdCBkZWxldGluZyBBTEwgbWVtYmVycyBm cm9tIGEgZ3JvdXA6DQoNClBBVENIIC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0 ZGEzZjkwOGNlIEhvc3Q6IGV4YW1wbGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+QWNjZXB0OiBh cHBsaWNhdGlvbi9qc29uIEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDggRVRhZzog Vy8iYTMzMGJjNTRmMDY3MWM5IiB7DQoib3BlcmF0aW9ucyIgOiBbDQp7DQoiUkVUSVJFIiA6IHsN CiJrZXkiIDogIm1lbWJlcnMiDQp9DQp9DQpdIH0NCg0KSSdtIHN1cmUgeW91J2xsIGFncmVlIHRo YXQgdGhpcyBpcyBzaW1wbGVyLCBtb3JlIGNvbnNpc3RlbnQgYW5kIG1vcmUgaW50dWl0aXZlIHRv IGEgcmVhZGVyLg0KDQpQcm8gMjogV2UgY2FuIGFwcGx5IHRoaXMgbWVjaGFuaXNtIGNvbnNpc3Rl bnRseSB0byB0aHJlZSBhcmVhczoNCihhKSBNYW5pcHVsYXRpbmcgbXVsdGktdmFsdWVkIGF0dHJp YnV0ZXMgb2YgYSByZXNvdXJjZQ0KKGIpIE1hbmlwdWxhdGluZyBtZW1iZXJzIG9mIGEgZ3JvdXAN CihjKSBQZXJmb3JtaW5nIGJ1bGsgb3BlcmF0aW9ucywgd2hlcmUgd2Ugc2ltcGx5IHVzZSBIVFRQ IHZlcmJzIGluc3RlYWQgb2YgdGhlIHNwZWNpYWxpc2VkIChhbmQgc2VtYW50aWNhbGx5IGxlc3Mg YW1iaWd1b3VzKSB2ZXJicyBJIHN1Z2dlc3RlZCBmb3IgYXR0cmlidXRlcywgdGhlICJrZXkiIGJl Y29tZXMgdGhlIFVSSSwgYW5kIHRoZSAidmFsdWUiIGJlY29tZXMgdGhlIGNvcnJlc3BvbmRpbmcg SlNPTiBvYmplY3QuDQoNCkFsbCBvZiB0aGVtIHJldHVybiAiMjA3IE11bHRpLVN0YXR1cyIgd2l0 aCB0aGUgInJlc3VsdHMiIGFycmF5IGhvbGRpbmcgaW5kaXZpZHVhbCBzdGF0dXMgY29kZXMuDQoN CkluIHRoZSBjdXJyZW50IHNwZWMsIChhKSBhbmQgKGIpIGFyZSBkb25lIHNpbWlsYXJseSBidXQg KGMpIGlzIHZlcnkgZGlmZmVyZW50Lg0KDQpQcm8gMzogQWRvcHRpb24gb2YgdGhlIHN0YW5kYXJk IGJ5IGNsaWVudHMgaXMgbGlrZWx5IHRvIGJlIGhpZ2hlciBiZWNhdXNlIGl0J3Mgc2ltcGxlciBm b3IgdGhlbS4NCg0KUHJvIDQ6IE5ldyAobm90IGluY3VtYmVudCkgY2xvdWQgcHJvdmlkZXJzIHdp bGwgcHJvYmFibHkgZmluZCB0aGlzIGVhc2llciB0byBpbXBsZW1lbnQgYmVjYXVzZSB0aGV5IGhh dmUgbm8gbGVnYWN5LiBUaGV5IHdpbGwgcHJvYmFibHkgdXNlIHNvbWUgZm9ybSBvZiBOb1NRTCBk YXRhYmFzZSBhbmQgd29uJ3QgYmUgY29uc3RyYWluZWQgYnkgdGhlIGxpbWl0YXRpb25zIG9mIExE QVAgZGlyZWN0b3JpZXMuDQoNCkNvbnM6DQoNCkNvbiAxOiBJbmN1bWJlbnQgY2xvdWQgcHJvdmlk ZXJzIHdpdGggZXhpc3RpbmcgZGF0YSBzdG9yZXMgaW4gYSBkaXJlY3RvcnkgZm9ybWF0ICh3aGVy ZSBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcyBhcmUgc3RvcmVkIGFzIGNvbW1hLXNlcGFyYXRlZCB2 YWx1ZXMgdW5kZXIgYSBzaW5nbGUgYXR0cmlidXRlIG5vZGUpIHdpbGwgZmluZCBpdCBkaWZmaWN1 bHQgdG8gbWlncmF0ZSB0byB0aGlzIG1vZGVsIGFuZCBzdG9yZSBlYWNoIGF0dHJpYnV0ZSB2YWx1 ZSBhcyBhIHN1Yi1ub2RlIHdpdGggaXRzIG93biBrZXkuIFRoaXMgd2lsbCAiaGluZGVyIGFkb3B0 aW9uIG9mIHRoZSBzcGVjIiwgd2hpY2ggaXMgd2hhdCB5b3UgZmVhci4NCg0KSGF2ZSBJIHN1bW1l ZCB1cCB0aGUgUHJvcyBhbmQgQ29ucyBjb3JyZWN0bHk/IEknbSBiaWFzZWQgb2YgY291cnNlLCBz byBJIGNvdWxkIGhhdmUgbWlzc2VkIGEgQ29uIG9yIGh5cGVkIGEgUHJvIDotKS4NCg0KSW4gb3Ro ZXIgd29yZHMsIHdlJ3JlIGRlYmF0aW5nIGludGVyZmFjZSBjb21wbGV4aXR5IChjdXJyZW50IHNw ZWMpIHZlcnN1cyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IChteSBzdWdnZXN0aW9uKS4gQm90 aCBjYW4gaGluZGVyIGFkb3B0aW9uIG9mIHRoZSBzcGVjIGJ5IGRpZmZlcmVudCBwYXJ0aWVzLg0K DQpIZXJlJ3Mgd2hhdCB3ZSBuZWVkIHRvIGRpc2N1c3MgLSBEbyB0aGUgUHJvcyBtYWtlIHRoZSBz dWdnZXN0aW8NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2NpbSBtYWlsaW5nIGxpc3QNCnNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0K --_000_CC52BAF9BB125chrisphillipscanarieca_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgIj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPisxIHRvIFBoaWwncyBjb21tZW50 cy48L2Rpdj48ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPjxicj48L2Rpdj48ZGl2IHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyAiPkFzIHdlbGwsIGFkZGluZyBhIGdob3N0IGRpcmVjdG9yeSB0byBb ZGV8ZW5dY29kZSB0aGluZ3MgaXMganVzdCB0b28gbXVjaCBvdmVyaGVhZCB0byBidWlsZCBpbnRv IHRoZSBwcm90b2NvbC4gJm5ic3A7SWYgc29tZW9uZSB3YW50cyB0byBidWlsZCB0aGF0IG9uIFRP UCBvZiBTQ0lNLCB0aGF0J3MgdXAgdG8gdGhlbS4gJm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsgIj48YnI+PC9kaXY+PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3Bh biIgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5XaGlsZSBJIGFwcHJlY2lhdGUgdGhlIHRob3Vn aHQgYW5kIHRpbWUgR2FuZXNoIGhhcyBwdXQgaW50byB0aGUgY29uY2VwdHMsIEkgYW0gbm90IGNv bnZpbmNlZCB0aGUgYXBwcm9hY2ggd291bGQgYmUgbmV0IGJldHRlciBhbmQgbGVzcyBjb21wbGV4 IGFuZCBzbyBkbyBub3Qgc3VwcG9ydCBpdCZuYnNwO2FuZCB3ZWxjb21lIG1vdmluZyBvbiB0byZu YnNwO290aGVyIHRvcGljcy48L2ZvbnQ+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Ij48YnI+PC9kaXY+PGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj5DLjwvZGl2PjxkaXYgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7ICI+PGJyPjwvZGl2PjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRF Ui1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkct Qk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRF Ui1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURE SU5HLVRPUDogM3B0Ij48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFu PiBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSI+cGhp bC5odW50QG9yYWNsZS5jb208L2E+Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RGF0ZTogPC9zcGFuPiBUaHVyc2RheSwgMTYgQXVndXN0LCAyMDEyIDE6NDIgUE08YnI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+IEtlbGx5IEdyaXp6bGUgJmx0 OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iPmtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5DYzogPC9zcGFuPiBFbW1hbnVlbCBEcmV1eCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkcmV1eEBj bG91ZGl3YXkuY29tIj5lZHJldXhAY2xvdWRpd2F5LmNvbTwvYT4mZ3Q7LCBBbnRob255IE5hZGFs aW4gJmx0OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0i bWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7 LCBNZWxpbmRhIFNob3JlICZsdDs8YSBocmVmPSJtYWlsdG86bWVsaW5kYS5zaG9yZUBnbWFpbC5j b20iPm1lbGluZGEuc2hvcmVAZ21haWwuY29tPC9hPiZndDssICI8YSBocmVmPSJtYWlsdG86c2Np bUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPjxzcGFuIHN0eWxlPSJmb250LXdlaWdo dDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+IFJlOiBbc2NpbV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJ c3N1ZSAyNDxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxtZXRhIGh0dHAtZXF1aXY9IkNv bnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj48ZGl2PkkgZG8gdGhpbmsgd2UgbmVl ZCB0byBhcnJpdmUgYXQgc29tZSBjb25zZW5zdXMgb24gdGhpcyBub3cgYmVjYXVzZSBHYW5lc2gn cyBwcm9wb3NhbCBpcyBhIG1ham9yICJmb3JrLWluLXRoZS1yb2FkIiBkZWNpc2lvbi4gSWYgd2Ug dGFibGUgaXQsIGl0IHdpbGwgYmUgaGFyZCB0byBjb21lIGJhY2sgdG8uIFRoaXMgaXMgd2h5IEkg aGF2ZSBlbmdhZ2VkIG9uIHRoZSBzdWJqZWN0IHdpdGggR2FuZXNoIHNvIHRob3JvdWdobHkuICZu YnNwO05ldmVyLXRoZS1sZXNzLA0KIEkgd291bGQgbGlrZSB0byBhcnJpdmUgYXQgc29tZSBjb25j bHVzaW9ucyBoZXJlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TXkgYXBvbG9naWVzLCBidXQg SSB0aG91Z2h0IGl0IHdhcyB3b3J0aCByZS1zdGF0aW5nIHRoZSBwcm9ibGVtIGZvciB0aG9zZSBs YXRlIHRvIHRoZSBkaXNjdXNzaW9uIHdvdWxkIGJlIHVzZWZ1bC48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PkJhY2tncm91bmQ6PC9kaXY+PGRpdj5BdCBwcmVzZW50LCB0aGUgY3VycmVudCBzcGVj IGRvZXMgbm90IGFsbG93IHlvdSB0byBjaGFuZ2UgYSBzcGVjaWZpYyBzdWItYXR0cmlidXRlIGlu IGEgbXVsdGktdmFsdWVkIGNvbXBsZXggYXR0cmlidXRlIHN0cnVjdHVyZSAoZS5nLiBjaGFuZ2lu ZyBzdHJlZXQgbmFtZSBpbiBhIHNwZWNpZmljIGFkZHJlc3MgdmFsdWUgaW5zdGFuY2Ugc3VjaCBh cyAiaG9tZSIpLiAmbmJzcDtUaGUgcHJvcG9zYWwgaXMgdGhhdCBlYWNoIHN1YiBhdHRyaWJ1dGUg aW4NCiBhIG11bHRpLXZhbHVlZCBzdHJ1Y3R1cmUgZ2V0cyBpdHMgb3duIHVuaXF1ZSBpZGVudGlm aWVyLiAmbmJzcDtUaGVuIHlvdSBjYW4gZGlyZWN0bHkgcmVmZXJlbmNlIHRoZSBzcGVjaWZpYyBj b21wbGV4IGF0dHJpYnV0ZSBjb21wb25lbnQgaW4gYSBjb21wbGV4IHZhbHVlLjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+VGhlIGN1cnJlbnQgZHJhZnQgcHJvcG9zYWwgcmVxdWlyZXMgdGhhdCBj b21wbGV4LXZhbHVlIChlLmcuIGFuIGFkZHJlc3MgdmFsdWUgd2hpY2ggaXMgbWFkZSB1cCBvZiBu dW1iZXIsIHN0cmVldCwgY2l0eSwgZXRjKSBiZSBjaGFuZ2VkIGlmIHlvdSB3YW50IHRvIGNoYW5n ZSBhbnkgb2YgdGhlIHN1Yi1hdHRyaWJ1dGVzLiBUaGUgY3VycmVudCBhcHByb2FjaCBzZWVtcyBh IHJlYXNvbmFibGUgY29tcHJvbWlzZSBzaW5jZSBpdCBpcyBsaWtlbHkNCiB0aGUgY29sbGVjdGlv biBvZiBhdHRyaWJ1dGVzIGluIGEgY29tcGxleCAidmFsdWUiIGFyZSBvZnRlbiBtYW5pcHVsYXRl ZCB0b2dldGhlci4gSU9XLiBZb3UgdGVuZCB0byBzZXQgdGhlbSBhbGwgYXQgb25jZS4gJm5ic3A7 R2FuZXNoJ3MgcHJvcG9zYWwgYWxsb3dzIHNwZWNpZmljIHN1Yi1hdHRyaWJ1dGVzIHRvIGJlIGRp cmVjdGx5IGFkZHJlc3NhYmxlIGJ5IGdpdmluZyBlYWNoIHZhbHVlIGluc3RhbmNlIGEgdW5pcXVl IGlkZW50aWZpZXIuICZuYnNwOyZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QW5vdGhl ciBleGFtcGxlIG9mIHRoaXMgaXMgdGhlIGdyb3VwICJtZW1iZXIiIGF0dHJpYnV0ZS4gJm5ic3A7 SW4gdGhlIGN1cnJlbnQgZHJhZnQsIGEgbWVtYmVyIGNhbiBoYXZlIGEgdmFsdWUgYW5kIGEgZGlz cGxheSBuYW1lLiBJbiB0aGlzIGNhc2UgeW91IHdvdWxkIHVzdWFsbHkgY2hhbmdlIHRoZSB2YWx1 ZSAob2JqZWN0IGlkZW50aWZpZXIpIGFuZCB0aGUgbmFtZSBhcyB3ZWxsLiAmbmJzcDtHYW5lc2gn cyBwcm9wb3NhbCB3b3VsZCBhbGxvdyAiRGlzcGxheQ0KIE5hbWUiIHRvIGJlIGNoYW5nZWQgb3Ig dmFsdWUgdG8gYmUgY2hhbmdlZC4gJm5ic3A7U29tZXRoaW5nLCBJTVYsIHRoYXQgZG9lc24ndCBv Y2N1ciBuZWFybHkgYXMgb2Z0ZW4uICZuYnNwO0lPVyBtZW1iZXJzIGNoYW5nZSBncm91cCBtZW1i ZXJzaGlwLCBidXQgbWVtYmVycyByYXJlbHkgY2hhbmdlIG5hbWVzLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+TXkgY29uY2x1c2lvbjo8L2Rpdj48ZGl2PklmIHRoZSBjbGllbnQgbXVzdCBmaXJz dCBxdWVyeSAob3IgaGF2ZSBzeW5jaHJvbml6ZWQgdGhlIHZhbHVlIGlkZW50aWZpZXJzKSwgdGhl biB0aGUgY2xpZW50IGhhcyB0byBkbyBldmVuIG1vcmUgd29yayB0aGFuIHRoZSBjdXJyZW50IHBy b3Bvc2FsIG9mIHJlcGxhY2luZyB0aGUgZW50ZXIgY29tcGxleCB2YWx1ZS4gJm5ic3A7R2l2ZW4g c3VjaCBhIGNob2ljZSBJJ20gcmVhbGx5IHNrZXB0aWNhbCB0aGF0IHRoZSBwYXR0ZXJuIHByb3Bv c2VkIGJ5DQogR2FuZXNoIHdvdWxkIGJlIHdpZGVseSB1c2VkLiAmbmJzcDtXaGlsZSBHYW5lc2gn cyBwcm9wb3NhbCBtYXkgYmUgInNwZWNpZmljIiwgdGhlIHByYWN0aWNhbCBzaW1wbGljaXR5IG9m IGl0IGlzIHZlcnkgbXVjaCBkZWJhdGFibGUuPC9kaXY+PGRpdj48YnI+PC9kaXY+DQpUaGUgYmVu ZWZpdCBvZiBzcGVjaWZpYyBzdWItYXR0cmlidXRlIGlkZW50aWZpZXJzIG5lZWRzIHRvIGJlIHN1 YnN0YW50aWFsLiAmbmJzcDtXZSdyZSBub3Qgb25seSB0YWxraW5nIGFib3V0IGNoYW5naW5nIGhv dyBpbmZyYXN0cnVjdHVyZSBpcyBkb25lLCBidXQgYWxzbyBob3cgYXBwbGljYXRpb25zIGFyZSB3 cml0dGVuLiBUaGlzIGxlYXZlcyBvdXQgdGhlIGVudGlyZSBjdXJyZW50IGFkb3B0ZXJzIGFuZCBh bGwgZW50ZXJwcmlzZSB1c2Vycy4gJm5ic3A7QSBiaWcNCiBjb25jZXJuIHdlIGhhdmUgb2J2aW91 c2x5IGlzIHdlIGhhdmUgdG8gY29uc2lkZXIgZXhpc3RpbmcgaW5mcmFzdHJ1Y3R1cmUgYW5kIGRh dGEgc3RvcmVzIGFuZCBiZSByZWFsaXN0aWMuIEkgZG9uJ3QgdGhpbmsgdGhlIGJlbmVmaXQgaXMg d29ydGggdGhlIGNvc3QuDQo8ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+SSBhZ3JlZSB3aXRoIHRo ZSBvdGhlcnMgdGhhdCB0aGUgY3VycmVudCBkcmFmdCBjb3VsZCBiZSBjaGFuZ2VkIHRvIG1ha2Ug cGF0Y2ggb3BlcmF0aW9ucyBtb3JlIGNsZWFyIHRvIHRoZSBkZXZlbG9wZXIgKHNpbXBsZXIgdG8g cmVhZCkuIFdoaWxlIHRoaXMgbWF5IG5vdCBpbXByb3ZlIGxvZ2ljLCBpdCB3aWxsIGltcHJvdmUg dW5kZXJzdGFuZGluZyBhbmQgc2ltcGxpY2l0eS4gVGhlIGZhY3QgdGhhdCBjZXJ0YWluIG9wZXJh dGlvbnMgbWF5DQogcmVxdWlyZSBhbiBlbnRpcmUgY29tcGxleCBhdHRyaWJ1dGUgdmFsdWUgdG8g YmUgcmVwbGFjZWQgaXMgYSByZWFzb25hYmxlIGNvbXByb21pc2UgYW5kIHNob3VsZCBub3QgYmUg Y2hhbmdlZC4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPlBoaWw8L3NwYW4+PC9kaXY+ PGRpdj48ZGl2PjxkaXY+PGRpdiBhcHBsZS1jb250ZW50LWVkaXRlZD0idHJ1ZSI+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFs aWduOiBhdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3Jk ZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiBtZWRpdW07IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVj b3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5 bGU9ImJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAy OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRl Y29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7ICI+PGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0 eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IDI7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVj b3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgIj48ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj48ZGl2PjxkaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5AaW5k ZXBlbmRlbnRpZDwvZGl2PjxkaXY+PGEgaHJlZj0iaHR0cDovL3d3dy5pbmRlcGVuZGVudGlkLmNv bSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bh bj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUu Y29tPC9hPjxicj48YnI+PC9kaXY+PC9zcGFuPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2Ut bmV3bGluZSI+PC9kaXY+PC9zcGFuPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+PC9zcGFuPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PC9kaXY+PGJy PjxkaXY+PGRpdj5PbiAyMDEyLTA4LTE2LCBhdCA4OjU5IEFNLCBLZWxseSBHcml6emxlIHdyb3Rl OjwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXIt Y29sbGFwc2U6IHNlcGFyYXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFs aWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGlj YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25l OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgZm9udC1zaXplOiBtZWRpdW07ICI+PGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTog V29yZFNlY3Rpb24xOyAiPjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVm dDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkhpIEdhbmVzaCAmIzgyMzA7IHlvdXIgd3JpdGUt dXAgY29uY2VkZXMgdGhhdCB0aGlzIHdpbGwgYmUgZGlmZmljdWx0IHRvIGltcGxlbWVudCBmb3Ig YW4gZXhpc3Rpbmcgc2VydmljZSBwcm92aWRlci4mbmJzcDsgSSYjODIxNzttIG5vdCBzdXJlIHRo YXQgSSB1bmRlcnN0YW5kIHRoZSBjb21wcm9taXNlLiZuYnNwOyBBcmUgeW91DQogc3RpbGwgc3Vn Z2VzdGluZyB0aGF0IFNDSU0gbW92ZSB0byB0aGUgdW5pcXVlLWtleS1wZXItZWxlbWVudCBzdHJh dGVneT88bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JZiBzbywgdGhlIGNvc3QvYmVuZWZpdCBvZiB0aGlz IHNlZW1zIHdheSBvZmYgdG8gbWUuJm5ic3A7IFlvdSBhcmUgZ2FpbmluZyBhIG1vcmUgZWxlZ2Fu dCBBUEkgYnkgaW50cm9kdWNpbmcgYW4gYWRkaXRpb25hbCBkYXRhc3RvcmUgYW5kIHJlcXVpcmlu ZyByZXBsaWNhdGlvbi4mbmJzcDsgSSBkb24mIzgyMTc7dCBrbm93DQogb2YgYW55IHNlcnZpY2Ug cHJvdmlkZXIgdGhhdCB3b3VsZCBtYWtlIHRoaXMgdHJhZGUtb2ZmLiZuYnNwOyBBcyB5b3Ugc2Fp ZCwgdGhpcyBpcyBzb21ldGhpbmcgdGhhdCBmdXR1cmUgc2VydmljZSBwcm92aWRlcnMgY2FuIGtl ZXAgaW4gbWluZCwgYnV0IGl0IGlzIG5vdCBnb2luZyB0byBoZWxwIGV4aXN0aW5nIHByb3ZpZGVy cy48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4tLUtlbGx5PG86cD48L286cD48L3NwYW4+PC9kaXY+PGRp diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iYm9yZGVy LXJpZ2h0LXN0eWxlOiBub25lOyBib3JkZXItYm90dG9tLXN0eWxlOiBub25lOyBib3JkZXItbGVm dC1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiBpbml0aWFsOyBib3JkZXItY29sb3I6IGluaXRp YWw7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAx OTYsIDIyMyk7IGJvcmRlci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZy10b3A6IDNwdDsgcGFkZGlu Zy1yaWdodDogMGluOyBwYWRkaW5nLWJvdHRvbTogMGluOyBwYWRkaW5nLWxlZnQ6IDBpbjsgIj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPkdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIFs8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBn bWFpbC5jb20iPm1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50OjwvYj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEF1Z3Vz dCAxNiwgMjAxMiA1OjM4IEFNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QW50aG9ueSBOYWRhbGluPGJyPjxiPkNjOjwvYj48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+S2VsbHkgR3Jpenps ZTsgRW1tYW51ZWwgRHJldXg7IE1lbGluZGEgU2hvcmU7DQo8YSBocmVmPSJtYWlsdG86c2NpbUBp ZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT47IFBoaWwgSHVudDxicj48Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzY2lt XSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0PG86cD48L286cD48L3NwYW4+PC9kaXY+PC9k aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48bzpwPiZuYnNwOzwvbzpwPjwv ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpIaSBhbGwsPG86cD48L286 cD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PG86cD4mbmJz cDs8L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 ICI+DQpXb3VsZCB0aGlzIGh5YnJpZCBhcmNoaXRlY3R1cmUgYmUgYSB3b3JrYWJsZSBjb21wcm9t aXNlPyBTZWUgZGlhZ3JhbSB0b3dhcmRzIHRoZSBlbmQ6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9iaXQubHkvUmpjMzlZIiBz dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmh0dHA6Ly9i aXQubHkvUmpjMzlZPC9hPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KUmVnYXJkcyw8bzpwPjwvbzpwPjwv ZGl2PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMTJw dDsgIj4NCkdhbmVzaDxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj4NCk9uIDE1IEF1Z3VzdCAyMDEyIDA1OjU0LCBBbnRob255IE5hZGFsaW4gJmx0 OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIiBz dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnRvbnluYWRA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyAiPldlIHNob3VsZCBub3QgYmUgY29uc3RyYWluZWQgYnkgTERBUCByZXN0cmljdGlv bnMsIHRoaXMgd291bGQgbm90IGJlIHByb2R1Y3RpdmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRv cDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5zY2ltLWJvdW5jZXNAaWV0Zi5v cmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+c2Np bS1ib3VuY2VzQGlldGYub3JnPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkPGJyPjxi PlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5Nb25kYXksIEF1Z3VzdCAxMywgMjAxMiAyOjA3IFBNPGJyPjxiPlRvOjwvYj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+S2VsbHkgR3JpenpsZTxicj48 Yj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PkVtbWFudWVsIERyZXV4OyBNZWxpbmRhIFNob3JlOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7ICI+c2NpbUBpZXRmLm9yZzwvYT47IFBoaWwgSHVudDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2 PjxkaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxicj48Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0PG86cD48L286cD48L2Rpdj48 L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4N CiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij4NClRoYW5rcywgS2VsbHkuIFlvdSd2ZSBiZWVuIG1vc3QgcGF0aWVudCBpbiBoZWFyaW5nIG1l IG91dCwgSSBtdXN0IHNheS4gSSBjb3VsZG4ndCBhc2sgZm9yIG1vcmUuPG86cD48L286cD48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwv bzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4N ClJlcGx5aW5nIHRvIENocmlzIFBoaWxpcHMncyBtYWlsOjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJmd0OyZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgYmFja2dy b3VuZC1pbWFnZTogaW5pdGlhbDsgYmFja2dyb3VuZC1hdHRhY2htZW50OiBpbml0aWFsOyBiYWNr Z3JvdW5kLW9yaWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOyBiYWNrZ3Jv dW5kLWNvbG9yOiB3aGl0ZTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+R2l2 ZW4NCiB0aGF0IHlvdSBoYXZlIGEgbnVtYmVyIG9mIHRob3VnaHRzIGFib3V0IHdoYXQgY291bGQg YmUgY2hhbmdlZCBpbiBTQ0lNLExlaWYncyByZWNvbW1lbmRhdGlvbiB0byAmbmJzcDtjcmFmdCB0 aGVtIGluIGFuIEludGVybmV0IERyYWZ0IG1heSBiZSBhIGJldHRlciB3YXkgdG8gY29udmV5IHlv dXIgdGhvdWdodHMuPC9zcGFuPjxicj48YnI+DQpJJ20gY29taW5nIGFyb3VuZCB0byB0aGUgc2Ft ZSBjb25jbHVzaW9uLiBEbyB5b3UgdGhpbmsgc3VjaCBhbiBJbnRlcm5ldCBEcmFmdCBzaG91bGQg YmUgYWJvdXQgY2hhbmdpbmcgU0NJTSwgb3Igc2hvdWxkIGl0IHByb3Bvc2UgYSBjb21wbGVtZW50 YXJ5IHNwZWMgZm9yIFNQcyB3aG8gdXNlIGEgIk5vTERBUCIgZGF0YSBzdG9yZT8gSSB0aGluayB0 aGUgdW5kZXJseWluZyBwcm9ibGVtIGlzIHdpdGggTERBUCwgYW5kIHVubGVzcyB3ZSBjaGFuZ2Ug dGhhdCwNCiB0aGVzZSBwcm9wb3NhbHMgd29uJ3QgZmx5LjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpS ZWdhcmRzLDxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tYm90dG9tOiAxMnB0OyAiPg0KR2FuZXNoPG86cD48L286cD48L3A+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KT24gMTQgQXVndXN0IDIwMTIgMDE6NTQs IEtlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2lu dC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyAiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPlRoZXJlIGFyZSByZWFsbHkg dHdvIGltcGxlbWVudGF0aW9uIG9wdGlvbnMgZm9yIGEgdWlkIHBlciBlbGVtZW50ICYjODIxMTsg ZWl0aGVyIHN0b3JlIHRoZSB1aWRzIGluIHRoZSBuYXRpdmUgdW5kZXJseWluZyBkYXRhIHN0b3Jl IG9yIGhhdmUgc29tZSBzZWNvbmRhcnkgZGF0YSBzdG9yZSB0aGF0IG1hcHMNCiBlbGVtZW50cyB0 byB0aGVpciB1aWRzLiZuYnNwOyBUaGUgdGhpcmQgb3B0aW9uIGlzIHRvIGhvcGUgdGhhdCBhIHNl cnZpY2UgcHJvdmlkZXIgaGFzIGEgTm9MREFQIGRhdGEgc3RvcmUgb3IgaXRzIGVxdWl2YWxlbnQu Jm5ic3A7IE5vbmUgb2YgdGhlc2UgYXJlIHByYWN0aWNhbCBmb3IgcmFwaWQgYW5kIHdpZGUtc3By ZWFkIGFkb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+Jmd0OzxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+cHV0IHRoZSB0d28gdG9n ZXRoZXIgdG8gcHJvcG9zZSBhIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+QXMgSSBzYWlk IGJlZm9yZSwgSSBhbSBjb21wbGV0ZWx5IG9uIGJvYXJkIHdpdGggY2xlYW5pbmcgdXAgdGhlIFBB VENIIHNlbWFudGljcyAoZWcgJiM4MjExOyB0aGUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIG1ldGEu YXR0cmlidXRlcyBhbmQgb3BlcmF0aW9uPWRlbGV0ZSwgZXRjJiM4MjMwOykuJm5ic3A7IFlvdXIg c3VnZ2VzdGlvbg0KIG9mIHVzaW5nIGRpZmZlcmVudCB2ZXJicyBpcyBhIGdvb2Qgb3B0aW9uIHRv IGNvbnNpZGVyLiZuYnNwOyBUaGlzIGNhbm5vdCBiZSBiYXNlZCBvbiBhIHVpZCBwZXIgZWxlbWVu dCwgdGhvdWdoLiZuYnNwOyBJdCBzZWVtcyBhcyB0aG91Z2ggeW91IGhhdmUgYWRtaXR0ZWQgdGhp cyBpbiB5b3VyIGNvbmNsdXNpb24gJiM4MjExOyAmIzgyMjA7QXMgZm9yIExEQVAgYW5kIFNDSU0s IEkgZ3Vlc3MgdGhlIGJlc3QgVExBIGlzIFJJUC4mIzgyMjE7PC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ LS1LZWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsgYm9y ZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRlci13 aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxlOiBz b2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdp ZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1i b3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5HYW5lc2ggYW5kIFNhc2hpIFBy YXNhZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 ICI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDk6NTYg QU08YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5LZWxseSBHcml6emxlPGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50OyBNZWxpbmRhIFNob3JlOyBFbW1h bnVlbCBEcmV1eDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0i Y29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW1AaWV0Zi5vcmc8 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7ICI+PGJyPjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwg SXNzdWUgMjQ8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KVGhhdCB3YXMgb25lIHN1Z2dlc3Rp b24uIEFub3RoZXIgd2F5IGNvdWxkIGJlIGNvbnRhaW5lciBub2RlcyB3aXRoIHRoZWlyIG93biAi ZG4icy4gSWYgb25lIHN1Z2dlc3Rpb24gd29uJ3Qgd29yaywgdGVsbCBtZSBhbm90aGVyIHdheSB0 byBtYWtlIGl0IHdvcmsuIEknbSB3YWl0aW5nIHRvIGhlYXIgYSBjb25zdHJ1Y3RpdmUgc3VnZ2Vz dGlvbiB0aGF0IGNhbiBzcXVhcmUgYW4gZWxlZ2FudCBBUEkgd2l0aCB0aGUgaW1wbGVtZW50YXRp b24gY29uc3RyYWludHMNCiB0aGF0IGNvbWUgZnJvbSBoYXZpbmcgdG8gc3RvcmUgbXVsdGktdmFs dWVkIGF0dHJpYnV0ZXMgaW4gTERBUCBkaXJlY3Rvcmllcy48bzpwPjwvbzpwPjwvZGl2PjxkaXY+ PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRv cDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9k aXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KSSd2ZSBo ZWFyZCBlbm91Z2ggb2YgV0hZIHRoaXMgd29uJ3Qgd29yay4gRm9yIGEgY2hhbmdlLCB0ZWxsIG1l IEhPVyBpdCBjYW4gYmUgbWFkZSB0byB3b3JrLiBFdmVyeW9uZSBub3cga25vd3Mgd2hhdCB0aGUg cHJvcG9zYWwgbWVhbnMgaW4gdGVybXMgb2YgdGhlIEFQSSwgYW5kIGltcGxlbWVudG9ycyB1bmRl cnN0YW5kIHRoZSBjb25zdHJhaW50cyBvZiBsZWdhY3kgZGF0YSBzdG9yZXMsIHNvIHB1dCB0aGUg dHdvIHRvZ2V0aGVyIHRvIHByb3Bvc2UNCiBhIHNvbHV0aW9uLiBDJ21vbiwgd2UgaGF2ZSB0aGUg InNtYXJ0ZXN0IGd1eXMgaW4gdGhlIHJvb20iIGhlcmUsIHN1cmVseSB3ZSBzaG91bGQgYmUgYWJs ZSB0byBjcmFjayB0aGlzLjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpSZWdhcmRzLDxvOnA+PC9vOnA+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KR2Fu ZXNoPG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NClAuUy4gSSdtIHJhcGlkbHkgcmVhY2hpbmcgbXkgb3du IGNvbmNsdXNpb25zIGFib3V0IHdoYXQgaXMgdG8gYmUgZG9uZTo8bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48YSBocmVmPSJodHRw Oi8vd2lzZG9tb2ZnYW5lc2guYmxvZ3Nwb3QuY29tLmF1LzIwMTIvMDgvYWZ0ZXItbm9zcWwtaXRz LXRpbWUtZm9yLW5vbGRhcC5odG1sIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5odHRwOi8vd2lzZG9tb2ZnYW5lc2guYmxv Z3Nwb3QuY29tLmF1LzIwMTIvMDgvYWZ0ZXItbm9zcWwtaXRzLXRpbWUtZm9yLW5vbGRhcC5odG1s PC9hPiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAxMnB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L3A+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KT24gMTQgQXVndXN0IDIwMTIgMDA6 MjcsIEtlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxw b2ludC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyAiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj4NCiZndDsgQWZ0ZXIgYWxsLCBubyBvbmUgaGFzIGNoYWxsZW5nZWQgdGhl IGNsYWltIHRoYXQgdGhpcyBwcm9wb3NhbCBkcmFzdGljYWxseSBzaW1wbGlmaWVzIHRoZSBBUEkg Zm9yIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkkgYWdyZWUgdGhhdCB5b3VyIHByb3Bv c2FsIG1ha2VzIFBBVENIIHNlbWFudGljcyBzaW1wbGVyIGFuZCBtb3JlIGVsZWdhbnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgIj4mZ3Q7ICYjODIzMDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPnNvIGl0IHdvdWxkIGFwcGVhciB0byBiZSB3b3J0aCBkb2luZy4mbmJz cDs8bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv ZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyAiPkkgc3Ryb25nbHkgZGlzYWdyZWUgaGVyZS4mbmJzcDsgVGhp cyBzdGF0ZW1lbnRzIGFzc3VtZXMgdGhhdCBzaW1wbGljaXR5IG9mIHRoZSBjbGllbnQgQVBJIGlz IHRoZSBvbmx5IGZhY3RvciB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIHdpdGggdGhlIHNwZWMu PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+RW1tYW51ZWwmIzgyMTc7cyBleGFtcGxlIGlzIGZyb20gYSBy ZWFsLXdvcmxkIHNlcnZpY2UgcHJvdmlkZXIgdGhhdCB3b3VsZCBub3QgYmUgYWJsZSB0byBpbXBs ZW1lbnQgdGhlIHNwZWMgZWFzaWx5IHdpdGggYSB1aWQgcGVyIGVsZW1lbnQuJm5ic3A7IEhlIGlz IHdvcmtpbmcgb24gYSBTQ0lNIGludGVyZmFjZQ0KIHRoYXQgd2lsbCBoZWxwIGZhY2lsaXRhdGUg ZGF0YSBleGNoYW5nZSBiZXR3ZWVuIG11bHRpcGxlIEFjdGl2ZSBEaXJlY3Rvcnkgc2VydmVycy4m bmJzcDsgWW91ciBzb2x1dGlvbiB3YXMgdG8gY2hhbmdlIHRoZSBkYXRhIG1vZGVsIGZyb20gdGhp czo8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L2Rpdj48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPm1haWw6IDxhIGhyZWY9Im1haWx0bzpqb2huX3NtaXRo QHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7ICI+am9obl9zbWl0aEB5YWhvby5jb208L2E+LCA8YSBocmVmPSJt YWlsdG86am9obi5zbWl0aEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpvaG4uc21pdGhAZ21haWwuY29t PC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpz bWl0aDE5NzBAaG90bWFpbC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PGRpdiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+dG8gdGhpczo8L3Nw YW4+PG86cD48L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+bWFpbDombmJzcDthYTY2LWRhZjllYTNiZDkw Mj08YSBocmVmPSJtYWlsdG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIiBz dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpvaG5fc21p dGhAeWFob28uY29tPC9hPiw5Y2RhLTg2NDZjMzA4NWJiZj08YSBocmVmPSJtYWlsdG86am9obi5z bWl0aEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpvaG4uc21pdGhAZ21haWwuY29tPC9hPiwmbmJzcDs3 YTZkMWRlNjY0ZTE9PGEgaHJlZj0ibWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l OyAiPmpzbWl0aDE5NzBAaG90bWFpbC5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRp diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SSBkbyBu b3Qga25vdyBvZiBhIHNpbmdsZSBvcmdhbml6YXRpb24gdGhhdCB3b3VsZCBjaGFuZ2UgdGhlaXIg QWN0aXZlIERpcmVjdG9yeSBkYXRhIG1vZGVsIHRvIGZpdCB0aGlzLiZuYnNwOyBGb3Igb25lIHRo aW5nLCBpdCB3b3VsZCBiZSBhIGh1Z2UgZGF0YSBtaWdyYXRpb24gZWZmb3J0IChsaWtlbHkNCiBh Y3Jvc3Mgb3RoZXIgZG9tYWluIGNvbnRyb2xsZXJzLCBldGMmIzgyMzA7KSB0byBhc3NpZ24gdGhl c2UgdW5pcXVlIGlkZW50aWZpZXJzLiZuYnNwOyBUaGlzIGFsc28gYXNzdW1lcyB0aGF0IFNDSU0g aXMgdGhlIG9ubHkgcmVhZGVyL3dyaXRlciBvZiB0aGlzIGRhdGEsIHdoaWNoIHdpbGwgYWxtb3N0 IG5ldmVyIGJlIHRoZSBjYXNlLiZuYnNwOyBJZiB0aGUgZGF0YSBtb2RlbCByZXF1aXJlcyB1aWRz IGZvciBldmVyeSBlbGVtZW50LCB0aGVuIGV2ZXJ5IHBpZWNlIG9mIG5vbi1TQ0lNDQogY29kZSB0 aGF0IHdyaXRlcyBkYXRhIGludG8gdGhlIGRpcmVjdG9yeSB3aWxsIGhhdmUgdG8gZm9sbG93IHRo aXMuJm5ic3A7IEFkZGl0aW9uYWxseSwgdGhlcmUgYXJlICo8Yj5tYW55PC9iPiogdG9vbHMgYW5k IGFwcGxpY2F0aW9ucyAmbmJzcDsoZWcgJiM4MjExOyBhZGRyZXNzIGJvb2tzKSB0aGF0IHJlbHkg b24gYSBjZXJ0YWluIGRhdGEgbW9kZWwgaW4gQWN0aXZlIERpcmVjdG9yeSwgYW5kIHRoaXMgd291 bGQgY2F1c2UgdGhlbSB0byBicmVhay4mbmJzcDsgSU1PIHRoaXMgc2FtZQ0KIGFyZ3VtZW50IGhv bGRzIHRydWUgZm9yIG1vc3Qgc2VydmljZSBwcm92aWRlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+UEFUQ0ggaXMgYW4gb3B0 aW9uYWwgcGFydCBvZiB0aGUgc3BlYy4gJm5ic3A7SXQgd2FzIHByaW1hcmlseSBpbnRyb2R1Y2Vk IHRvIG1ha2UgbW9kaWZ5aW5nIHJlc291cmNlcyB3aXRoIGxhcmdlIG11bHRpLXZhbHVlZCBsaXN0 cyBtb3JlIGVmZmljaWVudC4mbmJzcDsgSXQgZG9lcyBub3QgbmVlZCB0byBzb2x2ZQ0KIGV2ZXJ5 IHByb2JsZW0gKGVnICYjODIxMTsgbW9kaWZ5aW5nIHN1Yi1lbGVtZW50cyBpbiBuZXN0ZWQgYXJy YXlzKS4mbmJzcDsgQWRkaW5nIHVpZHMgdG8gZXZlcnkgbXVsdGktdmFsdWVkIGVsZW1lbnQgZG9l cyBub3Qgc3RyaWtlIHRoZSByaWdodCBiYWxhbmNlIGJldHdlZW4gdGhlIG5lZWRzIG9mIHRoZSBj bGllbnQgYW5kIHRoZSBuZWVkcyBvZiB0aGUgc2VydmljZSBwcm92aWRlci48L3NwYW4+PG86cD48 L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgIj4tLUtlbGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0iYm9yZGVyLXJpZ2h0LXN0eWxlOiBu b25lOyBib3JkZXItYm90dG9tLXN0eWxlOiBub25lOyBib3JkZXItbGVmdC1zdHlsZTogbm9uZTsg Ym9yZGVyLXdpZHRoOiBpbml0aWFsOyBib3JkZXItY29sb3I6IGluaXRpYWw7IGJvcmRlci10b3At c3R5bGU6IHNvbGlkOyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRl ci10b3Atd2lkdGg6IDFwdDsgcGFkZGluZy10b3A6IDNwdDsgcGFkZGluZy1yaWdodDogMGluOyBw YWRkaW5nLWJvdHRvbTogMGluOyBwYWRkaW5nLWxlZnQ6IDBpbjsgIj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkdhbmVzaCBhbmQg U2FzaGkgUHJhc2FkIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsgIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBBdWd1c3QgMTMsIDIw MTIgMTozNSBBTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlBoaWwgSHVudDsgTWVsaW5kYSBTaG9yZTxicj48Yj5DYzo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkVtbWFudWVsIERy ZXV4OyBLZWxseSBHcml6emxlOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi IHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+c2NpbUBp ZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc2NpbV0gc2NpbSBEaWdlc3Qs IFZvbCA4LCBJc3N1ZSAyNDxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpw PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpSZXNwb25kaW5nIHRv IGV4dHJhY3Qgb2YgTWVsaW5kYSBTaG9yZSdzIG1haWwgZnJvbSBkaWdlc3Q6PG86cD48L286cD48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpw PjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyAiPlRoZSBpc3N1ZSBiZWluZyByYWlz ZWQgaGVyZSBpc24ndCBlbmRwb2ludCBsb2dpYywgYnV0PG86cD48L286cD48L3ByZT48cHJlIHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj5uZXR3b3JrIHRyYWZmaWMsIGFuZCBJJ20gcHJldHR5IHN1cmUgaXQn cyBub3QgdmVyeSBoZWxwZnVsIHRvPG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj5yZXNwb25kIHRvIHRoZSBvYnNlcnZhdGlvbiB0aGF0IHlvdXIgbW9kZWwgcmVxdWlyZXMg bW9yZTxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+bWVzc2FnZXMgd2l0 aCBhIGNvbXBsYWludCBhYm91dCB3aGF0IHlvdSBzZWVtIHRvIHRoaW5rIGlzIGE8bzpwPjwvbzpw PjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPmNvbXBsZXggYWxnb3JpdGhtIGZvciBhdHRy aWJ1dGUgcHJvY2Vzc2luZy48bzpwPjwvbzpwPjwvcHJlPjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KSXQgZGVwZW5kcyBvbiBob3cgaXQncyBp bXBsZW1lbnRlZC4gSSdtIGNvbmZpZGVudCB3ZSBjYW4gaGF2ZSB0aGUgYmVzdCBvZiBib3RoIC0g c2ltcGxlIEFQSSB3aXRoIGxvdy1vdmVyaGVhZCBpbXBsZW1lbnRhdGlvbi4gQ2FuIHdlIGJyYWlu c3Rvcm0gSE9XIHRoaXMgcHJvcG9zYWwgY2FuIGJlIGltcGxlbWVudGVkIHJhdGhlciB0aGFuIFdI WSBpdCBjYW4ndCBiZSBpbXBsZW1lbnRlZCAod2hpY2ggaXMgbW9zdGx5IHdoYXQgSSd2ZSBiZWVu IGhlYXJpbmcNCiBzbyBmYXIpPyBBZnRlciBhbGwsIG5vIG9uZSBoYXMgY2hhbGxlbmdlZCB0aGUg Y2xhaW0gdGhhdCB0aGlzIHByb3Bvc2FsIGRyYXN0aWNhbGx5IHNpbXBsaWZpZXMgdGhlIEFQSSBm b3IgdGhlIGNsaWVudCwgc28gaXQgd291bGQgYXBwZWFyIHRvIGJlIHdvcnRoIGRvaW5nLiZuYnNw O0knbSBzdXJlIHRoZXJlJ3MgbW9yZSB0aGFuIGVub3VnaCBpbnRlbGxlY3R1YWwgaG9yc2Vwb3dl ciBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gcHVsbCB0aGlzIG9mZiBpZg0KIHdlIHB1dCBvdXIg bWluZHMgdG8gaXQuPG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRp diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NClJlZ2FyZHMsPG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpHYW5lc2g8 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgIj4NCk9uIDEzIEF1Z3VzdCAyMDEyIDEzOjU0LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNh ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5nLmMu cHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAxMnB0OyAiPg0KJmd0OyZuYnNwO0kg c3Ryb25nbHkgb2JqZWN0IHRvIGFueXRoaW5nIHRoYXQgbGVhZHMgdG8gYSByZWFkIGJlZm9yZSBt b2RpZnkgcmVxdWlyZW1lbnQuIFRvbyBjb21wbGV4IGFuZCB0b28gY2hhdHR5LjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpTb3JyeSBQaGls LCBidXQgeW91J3JlIGNvbnRyYWRpY3RpbmcgeW91cnNlbGYgaGVyZS4mbmJzcDtUaGVyZSBzZWVt cyB0byBiZSBhbiBhd2Z1bCBsb3Qgb2YgbWF0Y2hpbmcgKGkuZS4sIHJlYWRpbmcpIGdvaW5nIG9u IGluIHRoZSBzcGVjIGFzIGl0IHN0YW5kcywgd2l0aCBpZi10aGVuIGNsYXVzZXMgdG8gZG8gb25l IHRoaW5nIG9yIGFub3RoZXIgaWYgdGhlIG1hdGNoIGVpdGhlciBzdWNjZWVkcyBvciBmYWlscy4g VGhpcyBpcyBhIGNvbXBsZXgsIGNoYXR0eQ0KIHByb3RvY29sIHJpZ2h0IG5vdyE8bzpwPjwvbzpw PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyBNdWx0aS12YWx1ZWQgYXR0cmli dXRlczombmJzcDsgQW4gYXR0cmlidXRlIHZhbHVlIGluIHRoZSBQQVRDSCByZXF1ZXN0PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9keSBpcyBh ZGRlZCB0byB0aGUgdmFsdWUgY29sbGVjdGlvbiBpZiB0aGUgdmFsdWUgZG9lcyBub3QgZXhpc3Q8 L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbmQg bWVyZ2VkIGlmIGEgbWF0Y2hpbmcgdmFsdWUgaXMgcHJlc2VudC4mbmJzcDsgVmFsdWVzIGFyZSBt YXRjaGVkIGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDog MGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgY29tcGFyaW5nIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIGZyb20gdGhlIFBBVENIIHJl cXVlc3QgYm9keSB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0 b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIG9mIHRoZSBSZXNvdXJjZS4mbmJzcDsg QXR0cmlidXRlcyB0aGF0IGRvIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9 Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlOyBlLmcuLCBhZGRy ZXNzZXMsIG9yIGRvIG5vdCBoYXZlIHVuaXF1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUg c3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlIFN1Yi1BdHRyaWJ1dGVzIGNhbm5vdCBiZSBt YXRjaGVkIGFuZCBtdXN0IGluc3RlYWQgYmUgZGVsZXRlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl PjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gYWRkZWQuJm5ic3A7IFNwZWNpZmlj IHZhbHVlcyBjYW4gYmUgcmVtb3ZlZCBmcm9tIGEgUmVzb3VyY2UgYnk8L3NwYW4+PG86cD48L286 cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRpbmcgYW4gIm9wZXJhdGlv biIgU3ViLUF0dHJpYnV0ZSB3aXRoIHRoZSB2YWx1ZSAiZGVsZXRlIiB0byB0aGU8L3NwYW4+PG86 cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgaW4g dGhlIFBBVENIIHJlcXVlc3QgYm9keS4mbmJzcDsgQXMgd2l0aCBhZGRpbmcvdXBkYXRpbmc8L3Nw YW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1 dGUgdmFsdWUgY29sbGVjdGlvbnMsIHRoZSB2YWx1ZSB0byBkZWxldGUgaXMgZGV0ZXJtaW5lZCBi eTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNv bXBhcmluZyB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBmcm9tIHRoZSBQQVRDSCByZXF1ZXN0IGJv ZHkgdG88L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuJm5ic3A7IEF0dHJpYnV0 ZXMgdGhhdCBkbyBub3Q8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBoYXZlIGEgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvciB0aGF0IGhhdmUgYSBub24t dW5pcXVlIHZhbHVlIFN1Yi08L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBdHRyaWJ1dGUgYXJlIG1hdGNoZWQgYnkgY29tcGFyaW5nIGFsbCBTdWIt QXR0cmlidXRlIHZhbHVlcyBmcm9tPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0i bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlIFBBVENIIHJlcXVlc3QgYm9keSB0byB0aGUgU3ViLUF0dHJp YnV0ZSB2YWx1ZXMgb2YgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFy Z2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgUmVzb3VyY2UuJm5ic3A7IEEgZGVsZXRlIG9wZXJhdGlvbiBpcyBpZ25v cmVkIGlmIHRoZSBhdHRyaWJ1dGUncyBuYW1lPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBz dHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgaW4gdGhlIG1ldGEuYXR0cmlidXRlcyBsaXN0LiZu YnNwOyBJZiB0aGUgcmVxdWVzdGVkIHZhbHVlIHRvIGRlbGV0ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7 ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRvZXMgbm90IG1hdGNoIGEgdW5pcXVl IHZhbHVlIG9uIHRoZSBSZXNvdXJjZSB0aGUgc2VydmVyIE1BWTwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7 ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiBhIEhUVFAgNDAwIGVycm9y Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KRm9yIGEgc3BlYyB0aGF0IGlzIHN1cHBvc2Vk IHRvIGJlIGFib3V0IHNpbXBsaWNpdHksIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiBpcyBhbnl0aGlu ZyBidXQgc2ltcGxlLiBJIGtub3cgeW91IGd1eXMgaGF2ZSB3b3JrZWQgaGFyZCBvbiB0aGlzIGFu ZCBJIGRvbid0IG1lYW4gdG8gZGlzcGFyYWdlIHRob3NlIGVmZm9ydHMsIGJ1dCB0aGluayBhYm91 dCBob3cgdGhlIGFib3ZlIHBhc3NhZ2Ugd291bGQgYXBwZWFyIHRvIGEgbmV3IHJlYWRlciAoaS5l LiwNCiBhIG5vdmljZSB0byB0aGUgc3BlYywgbm90IGEgdGVjaG5vbG9neSBub3ZpY2UpLjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi Pg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7ICI+DQpUaGVyZSBpcyBzb21ldGhpbmcgZnVuZGFtZW50YWxseSBicm9rZW4s IGFuZCBpdCBpcyB0aGlzOiBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB3aXRob3V0IGEgdW5pcXVl IGlkZW50aWZpZXIgcGVyIHZhbHVlLiBJZiB5b3UgZG9uJ3QgZml4IHRoYXQsIHlvdSB3b24ndCBn ZXQgc2ltcGxpY2l0eS48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KV2Uga25vdyBMREFQIHRyZWVzIGFy ZSBicm9rZW4gZm9yIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzLiBBcyBNYXJrIFdhaGw8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDov L3d3dy5sZGFwLmNvbS8xL2NvbW1lbnRhcnkvd2FobC8yMDA1MDYxN18wMS5zaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7 ICI+ZmFtb3VzbHkgY29tbWVudGVkPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5iYWNrDQogaW4gMjAwNSw8bzpwPjwvbzpwPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KIjxz cGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1l bnQ6IGluaXRpYWw7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6 IGluaXRpYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI1MCwgMjUzKTsgZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPlVuZm9ydHVuYXRlbHksDQogc29tZSBvZiB0aGUgZW1l cmdpbmcgcHJvdG9jb2xzIHdoaWNoIGFsc28gaW50ZW5kIHRvIHJlcHJlc2VudCBhbmQgdHJhbnNm ZXIgcGVyc29uYWwgaWRlbnRpdHkgaW5mb3JtYXRpb24gaGF2ZSBwZXJoYXBzIHRha2VuIGEgc3Rl cCBiYWNrd2FyZHMgYnkgbm90IGV2ZW4gY29uc2lkZXJpbmcgdGhlc2UgaXNzdWVzLCBwZXJoYXBz IHN3ZWVwaW5nIHRoZW0gdW5kZXIgdGhlIHJ1ZyBpbiB0aGUgZ3Vpc2Ugb2Ygc2ltcGxpY2l0eSwg WE1MaWZpY2F0aW9uLA0KIG9yICJmaXggaW4gdGhlIG5leHQgdmVyc2lvbiIsIHdoaWNoIG9ubHkg cG9zdHBvbmUgZmluZGluZyBpbnRlcm9wZXJhYmxlIHNvbHV0aW9ucyB0byBhbGxvd2luZyBhcHBs aWNhdGlvbnMgdG8gZXhwcmVzcyB0aGUgaWRlbnRpdHkgZW50cmllcyB0aGV5IHdhbnQgdG8gZXhw cmVzcy48L3NwYW4+IjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpTQ0lNIGlzIGV4YWN0bHkgb25lIG9m IHRoZXNlICJlbWVyZ2luZyBwcm90b2NvbHMiIFdhaGwgdGFsa3MgYWJvdXQsIGFuZCB3aGF0IEkg c2VlIG5vdyBzdHJpa2VzIG1lIGFzICJzd2VlcGluZyB0aGVzZSBpc3N1ZXMgdW5kZXIgdGhlIHJ1 ZyBpbiB0aGUgZ3Vpc2Ugb2Ygc2ltcGxpY2l0eSIuIEFwb2xvZ2llcyBmb3IgdGhlIGJsdW50bmVz cy48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPg0KTXkgdGFrZSBpcyB0aGF0IFNQcyBhcmUgX2FscmVhZHlf IHN0cnVnZ2xpbmcgdG8gbWFuYWdlIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzLCBhbmQ8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDov L2ZmMTk1OS53b3JkcHJlc3MuY29tLzIwMTEvMDcvMjgvcmVwbGFjZS1hLXZhbHVlLW9mLWEtbXVs dGktdmFsdWVkLWF0dHJpYnV0ZS8iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmV4aXN0aW5nDQogbWVjaGFuaXNtcyBhcmUg Y2x1bXN5PC9hPi4gVGhleSB3b3VsZCBiZSBncmF0ZWZ1bCBmb3IgYSBzcGVjaWZpY2F0aW9uIHRo YXQgbWFkZSBvcGVyYXRpb25zIGVhc2llciBhdCB0aGUgY29zdCBvZiBhIHJlLWVuZ2luZWVyZWQg c2NoZW1hLiBUaGF0IGNhbGxzIGZvciBzb21lIHRob3VnaHQgbGVhZGVyc2hpcCBmcm9tIHRoaXMg d29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KUmVnYXJkcyw8bzpwPjwvbzpwPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0 OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCkdhbmVz aDxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDEycHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpPbiAxMyBBdWd1c3QgMjAxMiAxMDoxMywgUGhpbCBI dW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L2Rpdj48ZGl2Pjxk aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCkkgc3Ryb25nbHkgb2JqZWN0 IHRvIGFueXRoaW5nIHRoYXQgbGVhZHMgdG8gYSByZWFkIGJlZm9yZSBtb2RpZnkgcmVxdWlyZW1l bnQuIFRvbyBjb21wbGV4IGFuZCB0b28gY2hhdHR5LiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDEzNiwgMTM2LCAxMzYpOyAiPjxicj48YnI+DQpQaGlsPC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMTJwdDsgIj48YnI+DQpPbiAyMDEyLTA4LTEyLCBhdCAxNToyOSwgR2FuZXNoIGFuZCBT YXNoaSBQcmFzYWQgJmx0OzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7ICI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48 L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1 cHQ7ICI+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxl PSJjb2xvcjogcmdiKDE1LCAzNiwgNjIpOyAiPiZndDsgV291bGQgaXQgaGF2ZSB0byBiZSBzdG9y ZWQgb24gdGhlIGFjY291bnQgZGF0YWJhc2Ugb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXI/PC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBzdHlsZT0iY29sb3I6IHJnYigxNSwgMzYsIDYyKTsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDE1LCAzNiwgNjIpOyAiPlllcy48L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi KDE1LCAzNiwgNjIpOyAiPiZndDsgSWYgc28sIEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgaW1wcmFj dGljYWJsZSBpbiB0aGUgY29yZSBzY2hlbWEuJm5ic3A7SW5kZWVkIGl0IGltcGxpZXMgdGhhdCBh IHNlcnZpY2UgcHJvdmlkZXIgbXVzdCBleHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCBy ZXBvc2l0b3J5IChMREFQIHBhcnRpdGlvbiwgU1FMIGRiLCAmIzgyMzA7KSBhbmQgJiM4MjIwO3By ZXBhcmUgaXQmIzgyMjE7IGZvciBTQ0lNIGludGVncmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi Pg0KV2h5PyBUaGF0IGRvZXNuJ3QgbmVjZXNzYXJpbHkgZm9sbG93LiBJbXBsZW1lbnRhdGlvbiBp cyBpbmRlcGVuZGVudCBvZiByZXByZXNlbnRhdGlvbi4gV2UncmUgdGFsa2luZyBhYm91dCBhIGNo YW5nZSBpbiByZXByZXNlbnRhdGlvbiB0byBtYWtlIHRoZSBBUEkgY2xlYW5lci48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZu YnNwOzxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPg0KQXMgYSBzaW1wbGUgZXhhbXBsZSwgaWYgYW4gTERBUCBub2RlIGlzIGJlaW5n IHVzZWQgdG8gaG9sZCBhIGxpc3Qgb2YgY29tbWEtc2VwYXJhdGVkIGVtYWlsIGFkZHJlc3Nlcywg aXQgY2FuIGp1c3QgYXMgZWFzaWx5IHN0b3JlIGNvbW1hLXNlcGFyYXRlZCBuYW1lLXZhbHVlIHBh aXJzLjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPg0KJm5ic3A7PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxwcmUgc3R5bGU9 Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5tYWlsOiA8YSBocmVmPSJtYWlsdG86am9obl9zbWl0 aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPmpvaG5fc21pdGhAeWFob28uY29tPC9hPiwgPGEgaHJlZj0i bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5qb2huLnNtaXRoQGdtYWlsLmNv bTwvYT4sIDxhIGhyZWY9Im1haWx0bzpqc21pdGgxOTcwQGhvdG1haWwuY29tIiB0YXJnZXQ9Il9i bGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5q c21pdGgxOTcwQGhvdG1haWwuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgIj5jYW4gYmUgY2hhbmdlZCB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+bWFpbDom bmJzcDthYTY2LWRhZjllYTNiZDkwMj08YSBocmVmPSJtYWlsdG86am9obl9zbWl0aEB5YWhvby5j b20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyAiPmpvaG5fc21pdGhAeWFob28uY29tPC9hPiw5Y2RhLTg2NDZjMzA4NWJiZj08 YSBocmVmPSJtYWlsdG86am9obi5zbWl0aEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHls ZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpvaG4uc21pdGhA Z21haWwuY29tPC9hPiwmbmJzcDs3YTZkMWRlNjY0ZTE9PGEgaHJlZj0ibWFpbHRvOmpzbWl0aDE5 NzBAaG90bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmpzbWl0aDE5NzBAaG90bWFpbC5jb208L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAi PlRoYXQncyB3aHkgSSBhc2tlZCBpZiB0aGVyZSB3YXMgYW4gU1AgcmVwcmVzZW50YXRpdmUgb24g dGhpcyB3b3JraW5nIGdyb3VwIHdobyBjb3VsZCBleHBsYWluIHdoYXQgc3VjaCBhIGNoYW5nZSBj b3VsZCBtZWFuIGZvciB0aGVtLiBBcyBvZiBub3csIGl0IGxvb2tzIGxpa2Ugb3RoZXIgcGVvcGxl IGFyZSBwcmVzdW1pbmcgdGhhdCBTUHMgd2lsbCBub3QgYmUgYWJsZQ0KIHRvIGltcGxlbWVudCB0 aGVzZSBjaGFuZ2VzIGVhc2lseSBhbmQgYXJlIHJlamVjdGluZyB0aGVtIGZvciB0aGF0IHJlYXNv bi48L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyAiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+R2FuZXNoPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPg0KJm5ic3A7PG86cD48 L286cD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVm dDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQpPbiAx MyBBdWd1c3QgMjAxMiAwNDoyOSwgRW1tYW51ZWwgRHJldXggJmx0OzxhIGhyZWY9Im1haWx0bzpl ZHJldXhAY2xvdWRpd2F5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ZWRyZXV4QGNsb3VkaXdheS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdj48cCBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IFdpbmdk aW5nczsgIj7DsDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3cHQ7ICI+Jm5ic3A7PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5hZGRy ZXNzZXMuM2NiYWFmZjhlODRlLnN0cmVldC1udW1iZXIgPSAiMjQzIjxvOnA+PC9vOnA+PC9wPjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigxNSwgMzYsIDYyKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+V2hlcmUg d291bGQ8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyAiPjNjYmFhZmY4ZTg0ZTwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigxNSwgMzYsIDYyKTsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Y29tZQ0KIGZyb20/IFdvdWxkIGl0IGhhdmUgdG8gYmUg c3RvcmVkIG9uIHRoZSBhY2NvdW50IGRhdGFiYXNlIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyPzwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTUsIDM2LCA2Mik7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHls ZT0iY29sb3I6IHJnYigxNSwgMzYsIDYyKTsgIj5JZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBp cyBpbXByYWN0aWNhYmxlIGluIHRoZSBjb3JlIHNjaGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhh dCBhIHNlcnZpY2UgcHJvdmlkZXIgbXVzdCBleHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3Vu dCByZXBvc2l0b3J5IChMREFQIHBhcnRpdGlvbiwgU1FMIGRiLCAmIzgyMzA7KSBhbmQgJiM4MjIw O3ByZXBhcmUgaXQmIzgyMjE7IGZvciBTQ0lNIGludGVncmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImNv bG9yOiByZ2IoMTUsIDM2LCA2Mik7ICI+VGhpcyB3b3VsZCBiZSBhIHNob3cgc3RvcHBlci4gU0NJ TSBtdXN0IGJlIHRyYW5zcGFyZW50LCBhbmQgbXVzdCBiZSBhYmxlIHRvIGJlIHB1dCBvbiB0b3Ag b2YgYW4gZXhpc3Rpbmcgc3lzdGVtIHRvIHByb3ZpZGUgcHJvdmlzaW9uaW5nIGFwaXMuPC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBzdHlsZT0iY29sb3I6IHJnYigxNSwgMzYsIDYyKTsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDE1LCAzNiwgNjIpOyAiPlNhaWQgZGlmZmVyZW50bHksIFNDSU0gbXVzdCBub3Qg YmUgaW50cnVzaXZlIGZvciBleGlzdGluZyBzeXN0ZW1zIGFuZCBtdXN0IG5vdCByZXF1aXJlIG1v ZGlmaWNhdGlvbnMgdG8gYWxsb3cgaXRzIGludGVncmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImNvbG9y OiByZ2IoMTUsIDM2LCA2Mik7ICI+Q29ycmVjdCBtZSBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBz dWdnZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7ICI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMTUsIDM2LCA2Mik7ICI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+LS08L3NwYW4+PG86cD48L286cD48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgIj5FbW1hbnVlbCBEcmV1eDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgIj48YSBocmVmPSJodHRwOi8vd3d3LmNsb3VkaXdheS5jb20vIiB0YXJn ZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu ZTsgIj5odHRwOi8vd3d3LmNsb3VkaXdheS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRv cDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyAiPlRlbDo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0idGVsOiUyQjMzJTIwNCUyMDI2JTIwNzglMjAxNyUy MDU4IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsgIj4rMzMNCiA0IDI2IDc4IDE3IDU4PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5Nb2JpbGU6PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9InRlbDolMkIzMyUyMDYlMjA0NyUyMDgx JTIwMjYlMjA3MCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7ICI+KzMzDQogNiA0NyA4MSAyNiA3MDwvYT48L3NwYW4+PG86cD48 L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+c2t5cGU6IEVtbWFudWVsLkRyZXV4PC9z cGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHlsZTogbm9uZTsgYm9y ZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5vbmU7IGJvcmRlci13 aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXItdG9wLXN0eWxlOiBz b2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9wLXdp ZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBpbjsgcGFkZGluZy1i b3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBz YW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5HYW5lc2ggYW5kIFNhc2hpIFByYXNhZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpnLmMu cHJhc2FkQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+XTxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGI+RW52b3nD qSZuYnNwOzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmRpbWFuY2hlIDEyIGFvw7t0IDIwMTIgMDQ6NTM8YnI+PGI+w4AmbmJzcDs6PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5LZWxseSBHcml6emxl PGJyPjxiPkNjJm5ic3A7OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW1A aWV0Zi5vcmc8L2E+OyBQaGlsIEh1bnQ8YnI+PGI+T2JqZXQmbmJzcDs6PC9iPjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NjaW1dIHNjaW0gRGln ZXN0LCBWb2wgOCwgSXNzdWUgMjQ8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFu IGxhbmc9IkZSIj4mZ3Q7Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiByZ2IoMzQs IDM0LCAzNCk7IGJhY2tncm91bmQtaW1hZ2U6IGluaXRpYWw7IGJhY2tncm91bmQtYXR0YWNobWVu dDogaW5pdGlhbDsgYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7IGJhY2tncm91bmQtY2xpcDog aW5pdGlhbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7ICI+TXVsdGktdmFsdWVkDQogYXR0cmlidXRlcyB0aGF0IGRvbid0IGhhdmUgYSB2 YWx1ZSBzdWItYXR0cmlidXRlIChlZyAtIGFkZHJlc3MpIGhhdmUgdG8gc3BlY2lmaWVkIGNvbXBs ZXRlbHkgZm9yIHVuaXF1ZW5lc3MuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+ VGhhdCdzIGV4YWN0bHkgdGhlIHBvaW50LiBIb3cgZG8gd2UgInNwZWNpZnkgY29tcGxldGVseSBm b3IgdW5pcXVlbmVzcyI/PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkluIHRoZSBleGFtcGxlIGJlbG93LCBob3cgYXJlIHlvdSBw cm9wb3NpbmcgdGhhdCB0aGUgZm9sbG93aW5nIGVsZW1lbnQgYmUgdXBkYXRlZCBpZiB3ZSBjYW4n dCB1c2UgcG9zaXRpb25hbCBpbmRleGVzPzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0 b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5hZGRyZXNzZXNbMV0uc3RyZWV0LW51bWJl ciA9ICIyNDMiPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ PHNwYW4gbGFuZz0iRlIiPlVzZXIgb2JqZWN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPns8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOyAuLi48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw OyBhZGRyZXNzZXM6IFs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsg ezwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInR5cGUi IDogImhvbWUiLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgInN0cmVldC1udW1iZXIiIDogIjM1Iiw8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICJzdHJlZXQtbmFtZSIgOiAiSGlnaCBSb2FkIiw8L3NwYW4+PG86 cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJzdWJ1cmIiIDogIkVhc3Qg Q2FtZGVuIiw8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICJwb3N0Y29kZSIgOiAiNTM0NiIsPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAic3RhdGUiIDogIlNBIiw8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiPC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7IH0sPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9 IkZSIj4mbmJzcDsgJm5ic3A7IHs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICJ0eXBlIiA6ICJvZmZpY2UiLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInN0cmVldC1udW1iZXIiIDogIjIxMyIsPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAic3RyZWV0LW5hbWUiIDog Ik1haW4gU3RyZWV0Iiw8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICJzdWJ1cmIiIDogIkFkZWxhaWRlIiw8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJwb3N0Y29kZSIgOiAiNTAwMCIsPC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAic3RhdGUiIDogIlNBIiw8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJjb3VudHJ5IiA6ICJB dXN0cmFsaWEiPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7IH08L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyBdPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9 IkZSIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPkl0J3MgaW1wcmFjdGljYWwgdG8gdXNlIHRoZSB2YWx1ZSBiZWNhdXNlIGl0 J3MgdGhlIHdob2xlIGRpY3Rpb25hcnkgZWxlbWVudDo8L3NwYW4+PG86cD48L286cD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj57PC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgInR5cGUiIDogIm9mZmljZSIsPC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsgInN0cmVldC1udW1iZXIiIDogIjIxMyIsPC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgInN0cmVldC1uYW1lIiA6ICJNYWluIFN0cmVldCIsPC9z cGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgInN1YnVyYiIgOiAiQWRlbGFpZGUiLDwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICJwb3N0Y29kZSIgOiAiNTAwMCIsPC9z cGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgInN0YXRlIiA6ICJTQSIsPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgImNvdW50cnkiIDogIkF1c3RyYWxpYSI8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPn08L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+V2l0aCBteSBwcm9wb3NhbCwgdGhl ICJhZGRyZXNzZXMiIGFycmF5IGdldHMgY29udmVydGVkIHRvIGEgZGljdGlvbmFyeSwgYW5kIHRo ZW4gd2UgaGF2ZSBhIHN0YWJsZSB3YXkgb2YgcmVmZXJlbmNpbmcgdGhpcyBlbGVtZW50Ojwvc3Bh bj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFu Zz0iRlIiPmFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9ICIyNDMiPC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi Pns8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1y aWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAuLi48L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOyBhZGRyZXNzZXM6IHs8L3NwYW4+PG86cD48L286cD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0i RlIiPiZuYnNwOyAmbmJzcDsgImQ2ZWEzNjU0NjJmNSIgOjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5n PSJGUiI+Jm5ic3A7ICZuYnNwOyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAidHlwZSIgOiAiaG9tZSIsPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAic3RyZWV0LW51bWJlciIgOiAiMzUiLDwvc3Bhbj48bzpw PjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInN0cmVldC1uYW1lIiA6ICJI aWdoIFJvYWQiLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgInN1YnVyYiIgOiAiRWFzdCBDYW1kZW4iLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgInBvc3Rjb2RlIiA6ICI1MzQ2Iiw8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJzdGF0ZSIgOiAiU0EiLDwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgImNvdW50cnkiIDogIkF1 c3RyYWxpYSI8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgfSw8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgIjNjYmFhZmY4ZTg0ZSIgOjwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyB7PC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAidHlwZSIgOiAib2ZmaWNlIiw8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICJzdHJlZXQtbnVt YmVyIiA6ICIyMTMiLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgInN0cmVldC1uYW1lIiA6ICJNYWluIFN0cmVldCIsPC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAic3VidXJiIiA6ICJBZGVsYWlkZSIsPC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAicG9zdGNvZGUiIDog IjUwMDAiLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg InN0YXRlIiA6ICJTQSIsPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAiY291bnRyeSIgOiAiQXVzdHJhbGlhIjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7ICZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsgfTwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UncmUgcHJvcG9zaW5nIG9u ZSBtZWNoYW5pc20gZm9yIGNvbXBvc2l0ZSBhdHRyaWJ1dGVzIGFuZCBhbm90aGVyIG1lY2hhbmlz bSBmb3Igc2ltcGxlIGF0dHJpYnV0ZXMsIEkgd291bGQgc3VnZ2VzdCB0aGF0J3MgYWN0dWFsbHkg bW9yZSBjb21wbGV4IHRoYW4gYWRvcHRpbmcgYSBzaW5nbGUgbWVjaGFuaXNtIHRoYXQgd29ya3Mg dGhlIHNhbWUgd2F5IGZvciBfYWxsXyBhdHRyaWJ1dGVzLiBSZW1lbWJlciB0aGF0DQogYSBsb3Qg b2YgdGhlIGFkbWluaXN0cmF0aW9uIGlzIHByb2JhYmx5IGdvaW5nIHRvIGJlIHNjcmlwdGVkIHJh dGhlciB0aGFuIGRvbmUgYnkgaGFuZCwgYW5kIGhhdmluZyB0d28gbWVjaGFuaXNtcyAoZGVwZW5k aW5nIG9uIHdoZXRoZXIgdGhlIGF0dHJpYnV0ZSBpcyBzaW1wbGUgb3IgY29tcG9zaXRlKSB3aWxs IGNvbXBsaWNhdGUgZXZlcnkgc2NyaXB0IHRoYXQgaGFzIHRvIGJlIHdyaXR0ZW4uPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0i RlIiPlRoZXJlJ3MgYSBsb3Qgb2YgdGFsayBhYm91dCB0aGUgImJ1cmRlbiIgb24gdGhlIFNQcywg YnV0IEkgYmVsaWV2ZSB0aGlzIGlzIG92ZXJibG93bi4gSXMgdGhlcmUgYW55IFNQIHJlcHJlc2Vu dGF0aXZlIGluIHRoaXMgV0cgd2hvIGNhbiB0ZWxsIHVzIHdoYXQgdGhpcyBwcm9wb3NhbCB3aWxs IGFjdHVhbGx5IGVudGFpbCBmb3IgdGhlbT88L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPkdhbmVzaDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48 c3BhbiBsYW5nPSJGUiI+T24gMTIgQXVndXN0IDIwMTIgMTE6NTMsIEtlbGx5IEdyaXp6bGUgJmx0 OzxhIGhyZWY9Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iIHRhcmdldD0iX2Js YW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmtl bGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhv bWEsIHNhbnMtc2VyaWY7ICI+R2FuZXNoLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2Pjxk aXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2lu LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+VGhpcyBpcyBleGFjdGx5IGhvdyBQ QVRDSCB3b3JrcyBpbiBTQ0lNIDEuMC4gJm5ic3A7TXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhh dCBoYXZlIGEgdmFsdWUgc3ViLWF0dHJpYnV0ZSBjYW4gYmUgcmVtb3ZlZCBieSBzcGVjaWZ5aW5n IG9ubHkgdGhlIHZhbHVlIHNpbmNlIGl0IGlzIHVuaXF1ZS4gJm5ic3A7TXVsdGktdmFsdWVkIGF0 dHJpYnV0ZXMNCiB0aGF0IGRvbid0IGhhdmUgYSB2YWx1ZSBzdWItYXR0cmlidXRlIChlZyAtIGFk ZHJlc3MpIGhhdmUgdG8gc3BlY2lmaWVkIGNvbXBsZXRlbHkgZm9yIHVuaXF1ZW5lc3MuICZuYnNw O0FzIEkgaGF2ZSBzYWlkIGJlZm9yZSwgSSBhbSB2ZXJ5IG9wcG9zZWQgdG8gYWRkaW5nIGEgdW5p cXVlIGlkZW50aWZpZXIgdG8gZWFjaCBlbGVtZW50IGluIGEgbXVsdGktdmFsdWVkIGNvbGxlY3Rp b24gZHVlIHRvIHRoZSBidXJkZW4gaXQgd2lsbCBwdXQgb24gU1BzLiAmbmJzcDtJcw0KIGl0IGVs ZWdhbnQ/ICZuYnNwO05vLiAmbmJzcDtJcyBpdCBmdW5jdGlvbmFsPyAmbmJzcDtZZXMuICZuYnNw O1dpbGwgdGhpcyBub24tZWxlZ2FuY2UgYWZmZWN0IGFkb3B0aW9uPyAmbmJzcDtNeSBvcGluaW9u IGlzIHRoYXQgYWRkaW5nIHVuaXF1ZSBrZXlzIHRvIGVhY2ggZWxlbWVudCB3aWxsIGhhdmUgYSBt dWNoIG1vcmUgZGV0cmltZW50YWwgZWZmZWN0IG9uIGFkb3B0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwg c2Fucy1zZXJpZjsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7ICI+SSBkbyBi ZWxpZXZlIHRoYXQgaW4gZ2VuZXJhbCBQQVRDSCBjYW4gYmUgbWFkZSBtb3JlIGludHVpdGl2ZSB3 aXRob3V0IGFkZGluZyB1aWRzIHRvIGVhY2ggZWxlbWVudC4gJm5ic3A7VGhlIHZlcmJzIHRoYXQg eW91IHByb3Bvc2UgbWFrZSBzZW5zZS4gJm5ic3A7VGhlcmUgaXMgYWxzbyBhIEpTT04gUGF0Y2gg aW5mb3JtYXRpb25hbCBkcmFmdA0KIGluIHRoZSBJRVRGIHRoYXQgaXMgaW50ZXJlc3RpbmcgLSZu YnNwOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3 Zy1qc29uLXBhdGNoLTAyIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wMjwvYT4uICZuYnNwO0l0IHJlbGllcyBvbiBhIEpT T04NCiBQb2ludGVyIGRyYWZ0IHdoaWNoIHVzZXMgaW5kZXgtYmFzZWQgYWRkcmVzc2luZyBmb3Ig bXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMuICZuYnNwO0kgdGhpbmsgdGhhdCB0aGlzIGlzIHNvbWV0 aGluZyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQgd2l0aGluIHRoZSBXRyBhbmQgSSB3b3VsZCBi ZSB3aWxsaW5nIHRvIGxlYWQgdGhpcyBlZmZvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlm OyAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5JJ20gY3VyaW91cyBpZiBh bnlvbmUgZWxzZSBpbiB0aGUgV0cgaXMgaW4gZmF2b3Igb2YgdW5pcXVlIGlkZW50aWZpZXJzIGZv ciBldmVyeSBtdWx0aS12YWx1ZWQgZWxlbWVudC48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7 ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdp bi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyAiPi0tS2VsbHk8L3NwYW4+PG86 cD48L286cD48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21h LCBzYW5zLXNlcmlmOyAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBt YXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgdGV4dC1hbGlnbjogY2VudGVyOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyAiPjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+PC9zcGFu PjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMTJwdDsg Ij48Yj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2Vy aWY7ICI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7ICI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bPGEgaHJlZj0ibWFpbHRvOnNjaW0tYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7ICI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCiBvbiBiZWhhbGYgb2Yg R2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgWzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7ICI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+XTxicj48Yj5TZW50OjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2F0dXJkYXks IEF1Z3VzdCAxMSwgMjAxMiAxMDo1MCBBTTxicj48Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWwgSHVudDxicj48Yj5DYzo8L2I+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5zY2ltQGlldGYub3JnPC9hPjxicj48Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ UmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 ICI+PHNwYW4gbGFuZz0iRlIiPlBoaWwsPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlRoZSByZWFzb24gd2UgY2Fubm90IHVzZSB0aGUgdmFs dWUgaXRzZWxmIHRvIGlkZW50aWZ5IGFuIGVsZW1lbnQgaXMgdGhhdCB0aGlzIG1ldGhvZCB3aWxs IG9ubHkgd29yayBmb3Igc2ltcGxlIGVsZW1lbnRzLCBub3QgZm9yIG5lc3RlZCBzdHJ1Y3R1cmVz LiBpLmUuLCBpZiB3ZSBoYWQgYW4gYXJyYXkgb2YgZGljdGlvbmFyaWVzIChlLmcuLCB3ZSBoYWQg dG8gcmVjb3JkIGFuIGFycmF5IG9mIGFkZHJlc3NlcyBmb3IgZWFjaA0KIGN1c3RvbWVyLCB3aXRo IGVhY2ggYWRkcmVzcyBlbGVtZW50IGhhdmluZyBzdWItZWxlbWVudHMgbGlrZSBzdHJlZXQgbnVt YmVyLCBzdHJlZXQgbmFtZSwgc3VidXJiLCBldGMuKSwgdGhlbiBpdCB3b3VsZCBiZSBjbHVtc3kg dG8gc3VwcGx5IHRoZSBlbnRpcmUgdmFsdWUgb2YgdGhlIGFycmF5IGVsZW1lbnQgYmVjYXVzZSBp dCdzIGl0c2VsZiBhIGRpY3Rpb25hcnkuIENyZWF0aW5nIGEgdW5pcXVlIGtleSBmb3IgZWFjaCBl bGVtZW50IHNjYWxlcw0KIGJldHRlci48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48 L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDEy cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkdhbmVzaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPk9uIDEyIEF1 Z3VzdCAyMDEyIDAxOjEyLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7ICI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8 L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkdhbmVzaCw8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+SGVyZSdzIHRoZSBzYW1wbGUgdGhhdCBjb25j ZXJuZWQgbWUuLi48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPjxkaXY+ PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRv cDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+VGhlIHR3 byBvcGVyYXRpb25zIGRpZmZlciBzaWduaWZpY2FudGx5LCBhbmQgaXQncyBub3QgdmVyeSBpbnR1 aXRpdmUuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxl PSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5XaXRoIG15IHN1Z2dlc3Rp b24sIGhlcmUncyBob3cgdG8gZGVsZXRlIGEgc2luZ2xlIG1lbWJlciBmcm9tIGEgZ3JvdXA6PC9z cGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48 L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg Ij5QQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1iNGZkLTliNGRhM2Y5MDhjZSBIb3N0 OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5leGFtcGxlLmNvbTwvYT48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QWNjZXB0Og0KIGFwcGxpY2F0 aW9uL2pzb24gQXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOCBFVGFnOiBXLyJhMzMw YmM1NGYwNjcxYzkiIHs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4ib3BlcmF0aW9ucyIgOiBb PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ezwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiJS RVRJUkUiIDogezwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTog OC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiJrZXkiIDogIm1lbWJlcnMuMjgx OWMyMjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2Ijwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyAiPn08L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0 OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 ICI+XSB9PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGRp dj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyAiPllvdSBnYXZlIG90aGVyIGV4YW1wbGVzIG9mIGFuIGF0dHJpYnV0 ZSB3aXRoIGFuIGlkZW50aWZpZXIgdGhhdCBtYXRjaGVkIHRoYXQgdmFsdWUgb3Igb2YgaWRlbnRp ZmllcnMgdGhhdCB3ZXJlIGFkZGl0aW9uYWwgdW5pcXVlIGtleXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFu IGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj5HaXZlbiB0aGF0IG11 bHRpLXZhbHVlcyBtdXN0IGJlIGVhY2ggdW5pcXVlLCBJIGRvbid0IHNlZSB0aGUgcG9pbnQgb2Yg dGhlIGV4dHJhIGluZGV4aW5nIHRvIHN1cHBvcnQgdGhpcy4gSnVzdCB1c2UgdGhlIHZhbHVlIGFz IHRoZSBpdGVtIHlvdSB3aXNoIHRvIGRlbGV0ZS48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41 cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPkkgYWdyZWUsIHRoZSBkZWxldGUgdmFs dWUgb3BlcmF0aW9uIGNvdWxkIGJlIG1vcmUgZXhwbGljaXQgYW5kIGNsZWFyIGluIGdlbmVyYWwu PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDlw dDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj5QaGlsPC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiA5cHQ7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 ICI+QGluZGVwZW5kZW50aWQ8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsgIj48YSBocmVm PSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJj b2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+d3d3LmluZGVwZW5kZW50 aWQuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDEzLjVwdDsgIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTMuNXB0OyBmb250LWZhbWlseTogSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyAiPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7ICI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6IDEzLjVwdDsgZm9udC1mYW1pbHk6IEhlbHZldGljYSwgc2Fucy1zZXJpZjsg Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAxMnB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjxk aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS Ij5PbiAyMDEyLTA4LTExLCBhdCAyOjMwIEFNLCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCB3cm90 ZTo8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAxMnB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+Jmd0OyZuYnNwOyBGb3IgdGhlIG11bHRpLXZhbHVlIGV4YW1wbGUgeW91IGdhdmUgeW91IHVz ZWQgdGhlIHZhbHVlIGFzIHRoZSBhdHRyaWJ1dGUgbmFtZSBrZXkuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxl ZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFu IGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPk5vdyBJJ20gY29u ZnVzZWQgOi0pLiBJIGRvbid0IGJlbGlldmUgYW55IG9mIG15IGV4YW1wbGVzIGV2ZXIgdXNlZCBh IHZhbHVlIGFzIHRoZSBrZXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkNvdWxkIHlvdSBwbGVhc2Ugc2hvdyBtZSB3aGljaCBl eGFtcGxlIHlvdSBtZWFuLCBhbmQgd2hpY2ggcGFydHMgb2YgaXQgeW91IGJlbGlldmUgdG8gYmUg dGhlIHZhbHVlPzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0i bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2Pjxk aXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMTJwdDsgIj48c3BhbiBs YW5nPSJGUiI+R2FuZXNoJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+T24gMTEgQXVndXN0IDIw MTIgMTM6NTksIFBoaWwgSHVudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsgIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj48YnI+DQpGb3IgdGhlIG11bHRpLXZhbHVlIGV4YW1wbGUgeW91 IGdhdmUgeW91IHVzZWQgdGhlIHZhbHVlIGFzIHRoZSBhdHRyaWJ1dGUgbmFtZSBrZXkuJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFu Zz0iRlIiPlRoYXQgbWVhbnMgYSBsb3QgbW9yZSBjb21wbGV4IGluZGV4aW5nIHN0cnVjdHVyZS4g QmV0dGVyIHRvIGp1c3Qgc2F5IGRlbGV0ZSBhIHNwZWNpZmljIHZhbHVlLiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5U aGUgc3BlYyBhbHJlYWR5IGFsbG93cyBtdWx0aXBsZSB2YWx1ZXMgdG8gaGF2ZSB0YWdzIGxpa2Ug aG9tZSwgd29yaywgZXRjLjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBz dHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9y OiByZ2IoMTM2LCAxMzYsIDEzNik7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iY29sb3I6IHJnYigxMzYsIDEzNiwgMTM2KTsgIj5QaGlsPC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLWJvdHRvbTogMTJwdDsgIj48c3BhbiBsYW5nPSJGUiI+PGJyPg0KT24gMjAxMi0wOC0xMCwg YXQgMjE6NDUsIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJtYWlsdG86Zy5j LnByYXNhZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDsg d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj48ZGl2PjxkaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4m Z3Q7Jm5ic3A7SW4geW91ciBleGFtcGxlIHlvdSBhcmUgY29uZmxhdGluZyB2YWx1ZSB3aXRoIGFu IGF0dHJpYnV0ZSBpZC4mbmJzcDs8YnI+PGJyPg0KSSBkb24ndCBiZWxpZXZlIHNvLjwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48 c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9w OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5JJ20gYWRv cHRpbmcgYSBtb2RlbCB3aGVyZSBldmVyeSBhdHRyaWJ1dGUgb2YgdGhlIHJlc291cmNlIGlzIGEg a2V5LXZhbHVlIHBhaXIuIFRoZSBrZXkgaXMgYSBuYW1lIG9yIElELjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5Gb3Igbm9uLXJl cGVhdGluZyBhdHRyaWJ1dGVzIChib3RoIHNpbXBsZSBhbmQgY29tcG9zaXRlKSwgdGhlIGtleSBp cyB0aGUgYXR0cmlidXRlIG5hbWUgaXRzZWxmLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2 PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5n PSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlNpbXBsZSBhdHRy aWJ1dGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPktleTogImRvYiI8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlZhbHVl OiAiMDEgSmFuIDE5NzAiPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkZvciBjb21wb3NpdGUgYXR0cmlidXRlcywgdGhl IGtleSBlbXBsb3lzIGRvdCBub3RhdGlvbiB0byBzcGVjaWZ5IHRoZSBmdWxseS1xdWFsaWZpZWQg YXR0cmlidXRlIG5hbWUsIGUuZy4sICJhZGRyZXNzLnBvc3Rjb2RlIi48L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRp diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Q29tcG9zaXRl IGF0dHJpYnV0ZTo8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBsYW5nPSJGUiI+S2V5OiAiYWRkcmVzcy5zdHJlZXQtbnVtYmVyIjwvc3Bhbj48bzpw PjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBsYW5nPSJGUiI+VmFsdWU6ICIxMCI8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4t Ym90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+S2V5OiAiYWRkcmVzcy5zdWJ1cmIi PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5WYWx1ZTogIkVhc3QgQ2FtZGVuIjwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47 IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5G b3IgcmVwZWF0aW5nIChtdWx0aS12YWx1ZWQpIGF0dHJpYnV0ZXMsIEknbSBzdWdnZXN0aW5nIHRo YXQgdGhlcmUgYmUgbmV3IGtleXMgZm9yIGVhY2ggaW5kaXZpZHVhbCB2YWx1ZSwgb3RoZXJ3aXNl IHRoZXkgYXJlIGltcG9zc2libGUgdG8gZGlzdGluZ3Vpc2gsIGFuZCBhIHBvc2l0aW9uYWwgaW5k ZXggaXMgaW5hZGVxdWF0ZS4gU28gd2UgY29udmVydCB0aGUgYXJyYXkgaW50byBhIGRpY3Rpb25h cnkgYW5kIHRoaXMNCiB0aGVuIGJlY29tZXMgYSBjb21wb3NpdGUgYXR0cmlidXRlIHVzaW5nIGRv dCBub3RhdGlvbiBmb3IgdGhlIGtleS48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+TXVsdGktdmFsdWVkIGF0dHJpYnV0ZTo8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+S2V5OiAiZW1haWxzLjdkZmNiNDQ0LTc0ZDgtNGYxNy1hYTY2LWRhZjllYTNiZDkwMiI8L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlZhbHVlOiAiPGEgaHJlZj0ibWFpbHRvOmpvaG5fc21p dGhAeWFob28uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj5qb2huX3NtaXRoQHlhaG9vLmNvbTwvYT4iPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlNv IHRoaXMgYWxsb3dzIHVzIHRvIGFwcGx5IHVuaWZvcm0gdHJlYXRtZW50IHRvIGFueSBhcmJpdHJh cmlseSBkZWVwIHJlc291cmNlIHN0cnVjdHVyZS4gV2UgY2FuIHJlZmVyIHRvIGV2ZXJ5IGxlYWYg dmFsdWUgd2l0aCBhIGtleSB0aGF0IGlzIHRoZSBmdWxseS1xdWFsaWZpZWQgbmFtZSB1c2luZyBk b3Qgbm90YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxl PSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7 ICI+PHNwYW4gbGFuZz0iRlIiPlRoZSB2ZXJicyBhcmUganVzdCB1bmFtYmlndW91cyBvcGVyYXRp b25zIG9uIHRoZXNlIChub3cpIGV4cGxpY2l0bHkgYWRkcmVzc2FibGUgYXR0cmlidXRlcy48L3Nw YW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDog MGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+SU5DTFVERSB0byBhIGNvbGxlY3Rpb24gYW5kIHNwZWNpZnkgb25seSB0aGUgdmFsdWUuIFRo ZSBrZXkgaXMgZ2VuZXJhdGVkIGFuZCByZXR1cm5lZC4gVGhlIGZ1bGx5LXF1YWxpZmllZCBrZXkg aXMgJmx0O2NvbGxlY3Rpb24tbmFtZSZndDsuJmx0O25ld2x5LWdlbmVyYXRlZC1JRCZndDsgYW5k IHRoZSB2YWx1ZSBpcyB3aGF0IHdhcyBzcGVjaWZpZWQgaW4gdGhlIElOQ0xVREUuPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlJF UExBQ0UgYSBmdWxseS1xdWFsaWZpZWQga2V5IHdpdGggYSBuZXcgdmFsdWUuIElmIHRoZSBrZXkg ZG9lc24ndCBleGlzdCwgcmV0dXJuIGEgIjQwNCBOb3QgRm91bmQiLjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5QTEFDRSBhIHZh bHVlIGF0IHRoZSBsb2dpY2FsIGxvY2F0aW9uIGltcGxpZWQgYnkgdGhlIGZ1bGx5LXF1YWxpZmll ZCBrZXkuIElmIHRoZXJlIGlzIGFscmVhZHkgYSBrZXkgd2l0aCB0aGF0IG5hbWUsIHJldHVybiBh ICI0MDkgQ29uZmxpY3QiLjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBz dHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5GT1JDRSB0aGUgZnVsbHktcXVhbGlmaWVkIGtleSB0byBo b2xkIHRoZSBnaXZlbiB2YWx1ZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGV4aXN0ZWQgYmVm b3JlIG9yIG5vdC4gT25seSBlcnJvcnMgcG9zc2libGUgYXJlICI0MDAgQmFkIFJlcXVlc3QiIGFu ZCAiNTAwIEludGVybmFsIEVycm9yIi48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+UkVUSVJFIGFuIGF0dHJpYnV0ZSBvciBhIGNv bGxlY3Rpb24gZ2l2ZW4gaXRzIGZ1bGx5LXF1YWxpZmllZCBrZXkuIFRoZSBpbXBsZW1lbnRhdGlv biB3aWxsIGRldGVybWluZSB3aGV0aGVyIHRoZSBhdHRyaWJ1dGUgd2lsbCBkaXNhcHBlYXIgZW50 aXJlbHkgb3Igd2lsbCBleGlzdCBob2xkaW5nIGEgbnVsbCB2YWx1ZSAodGhlIGJsYW5rIHN0cmlu ZyAiIiBvciB0aGUgZW1wdHkgb2JqZWN0IHt9ICkuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkknbGwgZXhwbGFpbiBpbiBhIHNl cGFyYXRlIHBvc3Qgd2h5IHdlIG5lZWQgb3BlcmF0aW9uIHZlcmJzIGxpa2UgdGhlc2UgdGhhdCBh cmUgaW5kZXBlbmRlbnQgb2YgdGhlIEhUVFAgdmVyYnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+ PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBp bjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9 IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9 Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlJlZ2FyZHMsPC9zcGFuPjxv OnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsg bWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyAiPjxzcGFuIGxhbmc9IkZSIj5HYW5lc2g8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+T24gMTEgQXVndXN0IDIwMTIgMTA6MzgsICZsdDs8 YSBocmVmPSJtYWlsdG86c2NpbS1yZXF1ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5 bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5zY2ltLXJlcXVl c3RAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGRpZ2VzdCB3aXRob3V0IGFsbCB0aGUgaW5kaXZpZHVhbCBtZXNzYWdlPGJy Pg0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBkaWdlc3Qgb3B0aW9u cyBpbiB5b3VyIGxpc3Q8YnI+DQpzdWJzY3JpcHRpb24uICZuYnNwO1RvIGRvIHNvLCBnbyB0bzxi cj48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2lt IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsgIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+ PGJyPjxicj4NCkNsaWNrIHRoZSAnVW5zdWJzY3JpYmUgb3IgZWRpdCBvcHRpb25zJyBidXR0b24s IGxvZyBpbiwgYW5kIHNldCAiR2V0PGJyPg0KTUlNRSBvciBQbGFpbiBUZXh0IERpZ2VzdHM/IiB0 byBNSU1FLiAmbmJzcDtZb3UgY2FuIHNldCB0aGlzIG9wdGlvbjxicj4NCmdsb2JhbGx5IGZvciBh bGwgdGhlIGxpc3QgZGlnZXN0cyB5b3UgcmVjZWl2ZSBhdCB0aGlzIHBvaW50Ljxicj48YnI+PGJy Pjxicj4NClNlbmQgc2NpbSBtYWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW1A aWV0Zi5vcmc8L2E+PGJyPjxicj4NClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhl IFdvcmxkIFdpZGUgV2ViLCB2aXNpdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5r IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbTwvYT48YnI+DQpvciwgdmlhIGVt YWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG88YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNjaW0tcmVxdWVzdEBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7ICI+c2NpbS1yZXF1ZXN0QGlldGYub3JnPC9hPjxicj48YnI+DQpZb3UgY2FuIHJlYWNo IHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnNjaW0tb3duZXJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHls ZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW0tb3duZXJA aWV0Zi5vcmc8L2E+PGJyPjxicj4NCldoZW4gcmVwbHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3Vi amVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWM8YnI+DQp0aGFuICJSZTogQ29udGVudHMg b2Ygc2NpbSBkaWdlc3QuLi4iPGJyPjxicj4NClRvZGF5J3MgVG9waWNzOjxicj48YnI+DQombmJz cDsgJm5ic3A7MS4gUmU6IFNDSU0gUHJvdG9jb2wgLSAzIHN1Z2dlc3Rpb25zIGZvciBpbXByb3Zl bWVudCAoUGhpbCBIdW50KTxicj48YnI+PGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0tPGJyPg0KRnJvbTombmJzcDtQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1 ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+cGhpbC5odW50QG9yYWNsZS5jb208L2E+ Jmd0Ozxicj4NClRvOiZuYnNwO0dhbmVzaCBhbmQgU2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJt YWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmcuYy5wcmFzYWRAZ21haWwuY29t PC9hPiZndDs8YnI+DQpDYzombmJzcDsiRGlvZGF0aSwgTWFyayIgJmx0OzxhIGhyZWY9Im1haWx0 bzpNYXJrLkRpb2RhdGlAZ2FydG5lci5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPk1hcmsuRGlvZGF0aUBnYXJ0bmVy LmNvbTwvYT4mZ3Q7LCBFbW1hbnVlbCBEcmV1eCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkcmV1eEBj bG91ZGl3YXkuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj5lZHJldXhAY2xvdWRpd2F5LmNvbTwvYT4mZ3Q7LA0KIFRy ZXkgRHJha2UgJmx0OzxhIGhyZWY9Im1haWx0bzp0cmV5LmRyYWtlQHVuYm91bmRpZC5jb20iIHRh cmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyAiPnRyZXkuZHJha2VAdW5ib3VuZGlkLmNvbTwvYT4mZ3Q7LCBLZWxseSBHcml6emxlICZs dDs8YSBocmVmPSJtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tIiB0YXJnZXQ9Il9i bGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5r ZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208L2E+Jmd0OywNCiAiPGEgaHJlZj0ibWFpbHRvOnNj aW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW1AaWV0Zi5vcmc8L2E+IiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnNjaW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRh dGU6Jm5ic3A7RnJpLCAxMCBBdWcgMjAxMiAxNzozNjo1NCAtMDcwMDxicj4NClN1YmplY3Q6Jm5i c3A7UmU6IFtzY2ltXSBTQ0lNIFByb3RvY29sIC0gMyBzdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1l bnQ8L3NwYW4+PG86cD48L286cD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5HYW5lc2gsPC9zcGFuPjxvOnA+PC9v OnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkluIHlvdXIg ZXhhbXBsZSB5b3UgYXJlIGNvbmZsYXRpbmcgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgaWQuIEkg ZmluZCB0aGF0IGNvbmZ1c2luZy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2lu LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+SSBhZ3JlZSB0aG91Z2ggdGhhdCBvcGVy YXRpb25zIGluIHBhdGNoIGNvdWxkIGJlIGEgbG90IG1vcmUgZXhwbGljaXQuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PkVnIGV4cGxpY2l0bHkgZGVsZXRpbmcgYSB2YWx1ZSBieSBzYXlpbmcgZGVsZXRlIG9yIHJldGly ZS4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPjxicj4NClBoaWw8L3NwYW4+PG86 cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDEycHQ7ICI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCk9uIDIwMTItMDgtMTAsIGF0IDE2 OjE5LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFz YWRAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsgIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7ICI+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMS41cHQ7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JIGFtIGNvbmNl cm5lZCBhYm91dCB5b3VyIHNlY29uZCBzdWdnZXN0aW9uOjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206 IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFu Zz0iRlIiPkxldCdzIGRpc2N1c3MgdGhhdCBub3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlRoZSB0cmFkZS1vZmZzIGFyZSB2 ZXJ5IGNsZWFyIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0 eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlByb3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPlBybyAxLiBUaGUgQVBJIHRvIG1hbmlw dWxhdGUgcmVzb3VyY2VzIGJlY29tZXMgc28gbXVjaCBjbGVhbmVyLCBjb25zaXN0ZW50IGFuZCBp bnR1aXRpdmUgd2hlbiBldmVyeSBpbmRpdmlkdWFsIGF0dHJpYnV0ZSB2YWx1ZSBnZXRzIGl0cyBv d24gSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPkhlcmUncyBob3cgdG8gZGVsZXRlIGEgc2luZ2xlIG1lbWJlciBmcm9tIGEg R3JvdXAsIGFzIHBlciB0aGUgY3VycmVudCBzcGVjOjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48cHJlIHN0eWxlPSJt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJn aW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJp ZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJz cDsmbmJzcDsgUEFUQ0ggL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4 Y2U8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsgSG9zdDogPGEg aHJlZj0iaHR0cDovL2V4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ZXhhbXBsZS5jb208L2E+PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmln aHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7IEFjY2VwdDogYXBwbGljYXRp b24vanNvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyBBdXRo b3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHBy ZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7ICI+Jm5ic3A7Jm5ic3A7IEVUYWc6IFcvImEzMzBiYzU0ZjA2NzFjOSI8L3NwYW4+PG86cD48 L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0 eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGlu OyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsg Ij4mbmJzcDsmbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAic2NoZW1hcyI6IFsidXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCJd LDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFy Z2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0 OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAibWVtYmVycyI6IFs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4t dG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90 dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUg c3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0 OyAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZGlz cGxheSI6ICJCYWJzIEplbnNlbiIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0i bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFy Z2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJ2YWx1ZSI6ICIy ODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu LWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICJvcGVyYXRpb24iOiAiZGVsZXRlIjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5 bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IF08L3NwYW4+PG86cD48L286 cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGluOyBt YXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxk aXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPjxicj4NCkhl cmUncyBob3cgdG8gZGVsZXRlIEFMTCBtZW1iZXJzIGZyb20gYSBncm91cCBhY2NvcmRpbmcgdG8g dGhlIGN1cnJlbnQgc3BlYzo8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGlu OyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7IFBBVENI IC9Hcm91cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7IEhvc3Q6IDxhIGhyZWY9Imh0dHA6Ly9l eGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPmV4YW1wbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPjxwcmUgc3R5bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdp bi1sZWZ0OiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1z aXplOiAxMnB0OyAiPiZuYnNwOyZuYnNwOyBBY2NlcHQ6IGFwcGxpY2F0aW9uL2pzb248L3NwYW4+ PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsgQXV0aG9yaXphdGlvbjogQmVh cmVyIGg0ODBkanM5M2hkODwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZu YnNwOyBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzkiPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHBy ZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7ICI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRv cDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRv bTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7 IHs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgInNjaGVtYXMiOiBbInVybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAiXSw8L3NwYW4+PG86cD48 L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIm1ldGEiOiB7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFyZ2luLXRvcDogMGluOyBtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICJhdHRyaWJ1dGVzIjogWzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5 bGU9Im1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAibWVtYmVy cyI8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSJtYXJnaW4tdG9wOiAwaW47IG1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgXTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmUgc3R5bGU9Im1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBO ZXcnOyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHlsZT0ibWFy Z2luLXRvcDogMGluOyBtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7ICI+Jm5ic3A7 Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3ByZT48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj48YnI+DQpUaGUgdHdvIG9wZXJhdGlvbnMgZGlmZmVy IHNpZ25pZmljYW50bHksIGFuZCBpdCdzIG5vdCB2ZXJ5IGludHVpdGl2ZS4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPldpdGggbXkgc3VnZ2VzdGlvbiwgaGVyZSdzIGhvdyB0byBk ZWxldGUgYSBzaW5nbGUgbWVtYmVyIGZyb20gYSBncm91cDo8L3NwYW4+PG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPlBBVENIIC9Hcm91cHMvYWNi ZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlIEhvc3Q6PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNv bS8iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyAiPmV4YW1wbGUuY29tPC9hPkFjY2VwdDoNCiBhcHBsaWNhdGlvbi9qc29uIEF1 dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDggRVRhZzogVy8iYTMzMGJjNTRmMDY3MWM5 IiB7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0 b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsg Zm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Im9wZXJhdGlvbnMiIDogWzwvc3Bhbj48bzpw PjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsg Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyAiPns8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4iUkVUSVJFIiA6IHs8 L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250 LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4ia2V5IiA6ICJtZW1iZXJzLjI4MTljMjIzLTdmNzYt NDUzYS05MTlkLTQxMzg2MTkwNDY0NiI8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj59PC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1p bHk6ICdDb3VyaWVyIE5ldyc7ICI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+ PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRv cDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPl0gfTxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxicj4NCkhlcmUncyBob3cgSSBzdWdnZXN0IGRlbGV0aW5nIEFMTCBtZW1iZXJz IGZyb20gYSBncm91cDo8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6 IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAu MDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1m YW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+UEFUQ0ggL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTIt YjRmZC05YjRkYTNmOTA4Y2UgSG9zdDo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxh bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+ZXhh bXBsZS5jb208L2E+QWNjZXB0Og0KIGFwcGxpY2F0aW9uL2pzb24gQXV0aG9yaXphdGlvbjogQmVh cmVyIGg0ODBkanM5M2hkOCBFVGFnOiBXLyJhMzMwYmM1NGYwNjcxYzkiIHs8L3NwYW4+PG86cD48 L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0Nv dXJpZXIgTmV3JzsgIj4ib3BlcmF0aW9ucyIgOiBbPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9k aXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBt YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+ ezwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZv bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiJSRVRJUkUiIDogezwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmll ciBOZXcnOyAiPiJrZXkiIDogIm1lbWJlcnMiPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOiA4LjVwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+fTwv c3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0 OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAw LjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogOC41cHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPn08L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48 ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdp bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6IDguNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj5dIH08 L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIj48YnI+DQpJJ20gc3VyZSB5b3UnbGwgYWdyZWUgdGhhdCB0 aGlzIGlzIHNpbXBsZXIsIG1vcmUgY29uc2lzdGVudCBhbmQgbW9yZSBpbnR1aXRpdmUgdG8gYSBy ZWFkZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJn aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw YW4gbGFuZz0iRlIiPlBybyAyOiBXZSBjYW4gYXBwbHkgdGhpcyBtZWNoYW5pc20gY29uc2lzdGVu dGx5IHRvIHRocmVlIGFyZWFzOjwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRp diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDog MGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+KGEpIE1hbmlw dWxhdGluZyBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcyBvZiBhIHJlc291cmNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFy Z2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAi PjxzcGFuIGxhbmc9IkZSIj4oYikgTWFuaXB1bGF0aW5nIG1lbWJlcnMgb2YgYSBncm91cDwvc3Bh bj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw MDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+KGMpIFBlcmZvcm1pbmcgYnVsayBvcGVyYXRpb25zLCB3 aGVyZSB3ZSBzaW1wbHkgdXNlIEhUVFAgdmVyYnMgaW5zdGVhZCBvZiB0aGUgc3BlY2lhbGlzZWQg KGFuZCBzZW1hbnRpY2FsbHkgbGVzcyBhbWJpZ3VvdXMpIHZlcmJzIEkgc3VnZ2VzdGVkIGZvciBh dHRyaWJ1dGVzLCB0aGUgImtleSIgYmVjb21lcyB0aGUgVVJJLCBhbmQgdGhlICJ2YWx1ZSIgYmVj b21lcyB0aGUgY29ycmVzcG9uZGluZyBKU09OIG9iamVjdC48L3NwYW4+PG86cD48L286cD48L2Rp dj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFu Zz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHls ZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+QWxsIG9mIHRoZW0gcmV0 dXJuICIyMDcgTXVsdGktU3RhdHVzIiB3aXRoIHRoZSAicmVzdWx0cyIgYXJyYXkgaG9sZGluZyBp bmRpdmlkdWFsIHN0YXR1cyBjb2Rlcy48L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2 PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10 b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJp Z2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t OiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+SW4gdGhlIGN1cnJlbnQgc3BlYywgKGEpIGFu ZCAoYikgYXJlIGRvbmUgc2ltaWxhcmx5IGJ1dCAoYykgaXMgdmVyeSBkaWZmZXJlbnQuPC9zcGFu PjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBp bjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAw MXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rp dj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1h cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIi PlBybyAzOiBBZG9wdGlvbiBvZiB0aGUgc3RhbmRhcmQgYnkgY2xpZW50cyBpcyBsaWtlbHkgdG8g YmUgaGlnaGVyIGJlY2F1c2UgaXQncyBzaW1wbGVyIGZvciB0aGVtLjwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAw aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5Qcm8gNDogTmV3 IChub3QgaW5jdW1iZW50KSBjbG91ZCBwcm92aWRlcnMgd2lsbCBwcm9iYWJseSBmaW5kIHRoaXMg ZWFzaWVyIHRvIGltcGxlbWVudCBiZWNhdXNlIHRoZXkgaGF2ZSBubyBsZWdhY3kuIFRoZXkgd2ls bCBwcm9iYWJseSB1c2Ugc29tZSBmb3JtIG9mIE5vU1FMIGRhdGFiYXNlIGFuZCB3b24ndCBiZSBj b25zdHJhaW5lZCBieSB0aGUgbGltaXRhdGlvbnMgb2YgTERBUCBkaXJlY3Rvcmllcy48L3NwYW4+ PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx cHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWFy Z2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJGUiI+ Q29uczo8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3Bh biBsYW5nPSJGUiI+Q29uIDE6IEluY3VtYmVudCBjbG91ZCBwcm92aWRlcnMgd2l0aCBleGlzdGlu ZyBkYXRhIHN0b3JlcyBpbiBhIGRpcmVjdG9yeSBmb3JtYXQgKHdoZXJlIG11bHRpLXZhbHVlZCBh dHRyaWJ1dGVzIGFyZSBzdG9yZWQgYXMgY29tbWEtc2VwYXJhdGVkIHZhbHVlcyB1bmRlciBhIHNp bmdsZSBhdHRyaWJ1dGUgbm9kZSkgd2lsbCBmaW5kIGl0IGRpZmZpY3VsdCB0byBtaWdyYXRlIHRv IHRoaXMgbW9kZWwgYW5kIHN0b3JlIGVhY2gNCiBhdHRyaWJ1dGUgdmFsdWUgYXMgYSBzdWItbm9k ZSB3aXRoIGl0cyBvd24ga2V5LiBUaGlzIHdpbGwgImhpbmRlciBhZG9wdGlvbiBvZiB0aGUgc3Bl YyIsIHdoaWNoIGlzIHdoYXQgeW91IGZlYXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC9kaXY+ PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJn aW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdp bi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv dHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkhhdmUgSSBzdW1tZWQgdXAgdGhlIFBy b3MgYW5kIENvbnMgY29ycmVjdGx5PyBJJ20gYmlhc2VkIG9mIGNvdXJzZSwgc28gSSBjb3VsZCBo YXZlIG1pc3NlZCBhIENvbiBvciBoeXBlZCBhIFBybyA6LSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsg bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBsYW5nPSJG UiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4t cmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0 b206IDAuMDAwMXB0OyAiPjxzcGFuIGxhbmc9IkZSIj5JbiBvdGhlciB3b3Jkcywgd2UncmUgZGVi YXRpbmcgaW50ZXJmYWNlIGNvbXBsZXhpdHkgKGN1cnJlbnQgc3BlYykgdmVyc3VzIGltcGxlbWVu dGF0aW9uIGNvbXBsZXhpdHkgKG15IHN1Z2dlc3Rpb24pLiBCb3RoIGNhbiBoaW5kZXIgYWRvcHRp b24gb2YgdGhlIHNwZWMgYnkgZGlmZmVyZW50IHBhcnRpZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9k aXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6 IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsg bWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gbGFuZz0iRlIiPkhlcmUncyB3aGF0IHdl IG5lZWQgdG8gZGlzY3VzcyAtIERvIHRoZSBQcm9zIG1ha2UgdGhlIHN1Z2dlc3Rpbzwvc3Bhbj48 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1h cmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu LWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8 bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBp bjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdo dDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTog MC4wMDAxcHQ7ICI+DQombmJzcDs8bzpwPjwvbzpwPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv ZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVm dDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PG86cD4m bmJzcDs8L286cD48L2Rpdj48L2Rpdj48L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2NpbSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0i bWFpbHRvOnNjaW1AaWV0Zi5vcmciPnNjaW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PC9kaXY+PC9zcGFuPjwvYmxvY2txdW90ZT48 L2Rpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjwvYm9k eT48L2h0bWw+DQo= --_000_CC52BAF9BB125chrisphillipscanarieca_-- From leifj@mnt.se Thu Aug 16 13:09:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8C521F858A for ; Thu, 16 Aug 2012 13:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii3ItxZ-pFO0 for ; Thu, 16 Aug 2012 13:09:43 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 98D1021F852E for ; Thu, 16 Aug 2012 13:09:43 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7GK9bw3004146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 22:09:41 +0200 (CEST) Message-ID: <502D5381.6060103@mnt.se> Date: Thu, 16 Aug 2012 22:09:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <20120816161303.16998.66097.idtracker@ietfa.amsl.com> <502D1D77.6080009@stpeter.im> In-Reply-To: <502D1D77.6080009@stpeter.im> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] Fwd: I-D Action: draft-scim-api-01.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 20:09:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/16/2012 06:19 PM, Peter Saint-Andre wrote: > Folks, please rename these files so they're easier to track. > Either draft-drake-scim-api or (if you have approval from your WG > chairs) draft-ietf-scim-api. > Peter, the WG is about to do a call for adoption but we're also in the middle of a discussion around direction so renaming them right now would just add to the confusion. They will either be adopted very soon or we can re-adress the naming in a bit. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAtU30ACgkQ8Jx8FtbMZneeWgCfaAXjA3PU2FhLG2Yd+eJVFcVb 0DYAn0mKJYLbbYLy6iC22h3nmirT4kzM =fj2Z -----END PGP SIGNATURE----- From leifj@mnt.se Thu Aug 16 13:22:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6218021F8620 for ; Thu, 16 Aug 2012 13:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0vsz0hSBaop for ; Thu, 16 Aug 2012 13:22:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 489D921F84EE for ; Thu, 16 Aug 2012 13:22:26 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7GKMLWY022309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Aug 2012 22:22:25 +0200 (CEST) Message-ID: <502D567D.5080005@mnt.se> Date: Thu, 16 Aug 2012 22:22:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] upcoming consensus-call on initial documents. X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 20:22:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, As chair I've privately urged Ganesh to produce an I-D describing his proposal and I now repeat this publicly. In situations like this an IETF WG really needs a clearly described set of (competing) proposals to choose from. However given the response to Ganesh comments I am not willing to hold up the WG much longer on this issue. The chairs will issue a consensus call for adoption of initial WG documents around COB (EST) tomorrow (Friday). Right now the proposal on the table are the two documents (which don't show up on the wg page because of the way there were named): http://datatracker.ietf.org/doc/draft-scim-api http://datatracker.ietf.org/doc/draft-scim-core-schema/ If there are any other reasonably complete proposals on hand tomorrow those will also be included in the consensus call and the WG will choose which one to adopt. Best R Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAtVn0ACgkQ8Jx8FtbMZnf1LwCeP1rUOTJDOvh5JARo9hGMgU6E 7bYAniDMZlbwY54TytD/aA+OJKSUxn1Y =bl+K -----END PGP SIGNATURE----- From g.c.prasad@gmail.com Thu Aug 16 14:20:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACC921F848A for ; Thu, 16 Aug 2012 14:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5EVV1BW1t42 for ; Thu, 16 Aug 2012 14:20:05 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02FF821F867E for ; Thu, 16 Aug 2012 14:20:03 -0700 (PDT) Received: by bkty7 with SMTP id y7so1284589bkt.31 for ; Thu, 16 Aug 2012 14:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=YjUduR1+ri9RHBxuz4mmisJYMbXkZLpCljUfRCwOazY=; b=wByS42Krmi3alTPlrGrWTFNeeqqIXCdPf1YUoQEQ2KPqsChBTsW5VJI6826wMpvuex JQBBg8Z7IYpB0cA3X295S7T9MGXQo15h6L4lY8R4JnpNhhZwOb56wLcXnRRNTlgX4plF 72P+Rp7ju0TQaU1QUwFEdLsNVEsP0++/5bfUwt2h18JA/tG2g12y6l/bofsIWDrnCNq3 8QxZ3rLGOX1u2lk4ypemETocHUtq/zqbgOC6+/X3Fb+YFn/KrvyoKUf1CVv0R40RVjLr izfDSzqFE+YvkCnatNgvQRX5kQmYxZRU4Va8qxmitME4B2Q+2hftK0aP8NCF+yYdEbCJ j7JA== Received: by 10.204.130.211 with SMTP id u19mr1195018bks.24.1345152002540; Thu, 16 Aug 2012 14:20:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Thu, 16 Aug 2012 14:19:42 -0700 (PDT) In-Reply-To: References: From: Ganesh and Sashi Prasad Date: Fri, 17 Aug 2012 07:19:42 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=0015173fe60247c6cd04c7689b5b Subject: Re: [scim] scim Digest, Vol 8, Issue 70 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:20:08 -0000 --0015173fe60247c6cd04c7689b5b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > While I appreciate the thought and time Ganesh has put into the concepts, I am not convinced the approach would be net better and less complex and so do not support it and welcome moving on to other topics. I agree. Perhaps it would be best for the spec committee to move on to tackling other issues. The approach I'm proposing has been well-understood already, so I don't think anything would be gained by me putting it into an Internet Draft at this stage. Just out of interest, my current employer (a major telco with about 10 million subscribers) adopts the approach of using a relational database as the "source of truth" to which all updates are applied, and then writes out the "de-normalised" subscriber records to a geographically-dispersed LDAP cluster. I was speaking to one of the technical leads in charge of that area (since I am the architect for Identity and Access Management) and he believed that this two-phase approach was operationally simpler and more robust, not more complex! Personally, I'm gratified that my proposal has been taken seriously and evaluated on its merits, so here's a heartfelt "thank you" from me to all of you who have taken the time to examine it. I believe this approach of being able to address individual elements of a multi-valued attribute has application even beyond SCIM, so I will be pursuing it as a generic set of patterns ("resource" defined as a Nested Dictionary, "NDAP directory" as a resource datastore, "NDAP" as a RESTful API with well-defined sub-operations, etc.) Who knows, some day that set of patterns may be re-applied to user provisioning because "that's how it's done elsewhere" :-). Thanks and regards, Ganesh On 17 August 2012 05:23, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/scim > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send scim mailing list submissions to > scim@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/scim > or, via email, send a message with subject or body 'help' to > scim-request@ietf.org > > You can reach the person managing the list at > scim-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of scim digest..." > > Today's Topics: > > 1. Re: scim Digest, Vol 8, Issue 24 (Chris Phillips) > > > ---------- Forwarded message ---------- > From: Chris Phillips > To: "scim@ietf.org" > Cc: > Date: Thu, 16 Aug 2012 15:23:29 -0400 > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > +1 to Phil's comments. > > As well, adding a ghost directory to [de|en]code things is just too much > overhead to build into the protocol. If someone wants to build that on T= OP > of SCIM, that's up to them. > > While I appreciate the thought and time Ganesh has put into the concepts, > I am not convinced the approach would be net better and less complex and = so > do not support it and welcome moving on to other topics. > > C. > > From: Phil Hunt > Date: Thursday, 16 August, 2012 1:42 PM > To: Kelly Grizzle > Cc: Emmanuel Dreux , Anthony Nadalin < > tonynad@microsoft.com>, Ganesh and Sashi Prasad , > Melinda Shore , "scim@ietf.org" > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 > > I do think we need to arrive at some consensus on this now because > Ganesh's proposal is a major "fork-in-the-road" decision. If we table it, > it will be hard to come back to. This is why I have engaged on the subjec= t > with Ganesh so thoroughly. Never-the-less, I would like to arrive at som= e > conclusions here. > > My apologies, but I thought it was worth re-stating the problem for those > late to the discussion would be useful. > > Background: > At present, the current spec does not allow you to change a specific > sub-attribute in a multi-valued complex attribute structure (e.g. changin= g > street name in a specific address value instance such as "home"). The > proposal is that each sub attribute in a multi-valued structure gets its > own unique identifier. Then you can directly reference the specific > complex attribute component in a complex value. > > The current draft proposal requires that complex-value (e.g. an address > value which is made up of number, street, city, etc) be changed if you wa= nt > to change any of the sub-attributes. The current approach seems a > reasonable compromise since it is likely the collection of attributes in = a > complex "value" are often manipulated together. IOW. You tend to set them > all at once. Ganesh's proposal allows specific sub-attributes to be > directly addressable by giving each value instance a unique identifier. > > Another example of this is the group "member" attribute. In the current > draft, a member can have a value and a display name. In this case you wou= ld > usually change the value (object identifier) and the name as well. > Ganesh's proposal would allow "Display Name" to be changed or value to b= e > changed. Something, IMV, that doesn't occur nearly as often. IOW member= s > change group membership, but members rarely change names. > > My conclusion: > If the client must first query (or have synchronized the value > identifiers), then the client has to do even more work than the current > proposal of replacing the enter complex value. Given such a choice I'm > really skeptical that the pattern proposed by Ganesh would be widely used= . > While Ganesh's proposal may be "specific", the practical simplicity of i= t > is very much debatable. > > The benefit of specific sub-attribute identifiers needs to be substantial= . > We're not only talking about changing how infrastructure is done, but al= so > how applications are written. This leaves out the entire current adopters > and all enterprise users. A big concern we have obviously is we have to > consider existing infrastructure and data stores and be realistic. I don'= t > think the benefit is worth the cost. > > I agree with the others that the current draft could be changed to make > patch operations more clear to the developer (simpler to read). While thi= s > may not improve logic, it will improve understanding and simplicity. The > fact that certain operations may require an entire complex attribute valu= e > to be replaced is a reasonable compromise and should not be changed. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote: > > Hi Ganesh =85 your write-up concedes that this will be difficult to > implement for an existing service provider. I=92m not sure that I unders= tand > the compromise. Are you still suggesting that SCIM move to the > unique-key-per-element strategy?**** > ** ** > If so, the cost/benefit of this seems way off to me. You are gaining a > more elegant API by introducing an additional datastore and requiring > replication. I don=92t know of any service provider that would make this > trade-off. As you said, this is something that future service providers > can keep in mind, but it is not going to help existing providers.**** > ** ** > --Kelly**** > ** ** > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com > ] > *Sent:* Thursday, August 16, 2012 5:38 AM > *To:* Anthony Nadalin > *Cc:* Kelly Grizzle; Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil > Hunt > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > ** ** > Hi all,**** > ** ** > Would this hybrid architecture be a workable compromise? See diagram > towards the end: http://bit.ly/Rjc39Y**** > ** ** > Regards,**** > > Ganesh**** > On 15 August 2012 05:54, Anthony Nadalin wrote:**= * > * > We should not be constrained by LDAP restrictions, this would not be > productive.**** > **** > *From:* scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] *On Behalf O= f > *Ganesh and Sashi Prasad > *Sent:* Monday, August 13, 2012 2:07 PM > *To:* Kelly Grizzle > *Cc:* Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil Hunt**** > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > **** > Thanks, Kelly. You've been most patient in hearing me out, I must say. I > couldn't ask for more.**** > **** > Replying to Chris Philips's mail:**** > > Given that you have a number of thoughts about what could be changed in > SCIM,Leif's recommendation to craft them in an Internet Draft may be a > better way to convey your thoughts. > > I'm coming around to the same conclusion. Do you think such an Internet > Draft should be about changing SCIM, or should it propose a complementary > spec for SPs who use a "NoLDAP" data store? I think the underlying proble= m > is with LDAP, and unless we change that, these proposals won't fly.**** > **** > Regards,**** > > Ganesh**** > On 14 August 2012 01:54, Kelly Grizzle > wrote:**** > There are really two implementation options for a uid per element =96 eit= her > store the uids in the native underlying data store or have some secondary > data store that maps elements to their uids. The third option is to hope > that a service provider has a NoLDAP data store or its equivalent. None = of > these are practical for rapid and wide-spread adoption.**** > **** > > put the two together to propose a solution.**** > **** > As I said before, I am completely on board with cleaning up the PATCH > semantics (eg =96 the inconsistency between meta.attributes and > operation=3Ddelete, etc=85). Your suggestion of using different verbs is= a > good option to consider. This cannot be based on a uid per element, > though. It seems as though you have admitted this in your conclusion =96= =93As > for LDAP and SCIM, I guess the best TLA is RIP.=94**** > **** > --Kelly**** > **** > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 9:56 AM > *To:* Kelly Grizzle > *Cc:* Phil Hunt; Melinda Shore; Emmanuel Dreux; scim@ietf.org**** > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > **** > That was one suggestion. Another way could be container nodes with their > own "dn"s. If one suggestion won't work, tell me another way to make it > work. I'm waiting to hear a constructive suggestion that can square an > elegant API with the implementation constraints that come from having to > store multi-valued attributes in LDAP directories.**** > **** > I've heard enough of WHY this won't work. For a change, tell me HOW it ca= n > be made to work. Everyone now knows what the proposal means in terms of t= he > API, and implementors understand the constraints of legacy data stores, s= o > put the two together to propose a solution. C'mon, we have the "smartest > guys in the room" here, surely we should be able to crack this.**** > **** > Regards,**** > Ganesh**** > **** > P.S. I'm rapidly reaching my own conclusions about what is to be done:***= * > > http://wisdomofganesh.blogspot.com.au/2012/08/after-nosql-its-time-for-no= ldap.html > **** > > **** > On 14 August 2012 00:27, Kelly Grizzle > wrote:**** > > After all, no one has challenged the claim that this proposal > drastically simplifies the API for the client**** > **** > I agree that your proposal makes PATCH semantics simpler and more elegant= . > **** > **** > **** > > =85 so it would appear to be worth doing. **** > **** > I strongly disagree here. This statements assumes that simplicity of the > client API is the only factor that should be considered with the spec.***= * > **** > Emmanuel=92s example is from a real-world service provider that would not= be > able to implement the spec easily with a uid per element. He is working = on > a SCIM interface that will help facilitate data exchange between multiple > Active Directory servers. Your solution was to change the data model fro= m > this:**** > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > **** > to this:**** > **** > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > **** > I do not know of a single organization that would change their Active > Directory data model to fit this. For one thing, it would be a huge data > migration effort (likely across other domain controllers, etc=85) to assi= gn > these unique identifiers. This also assumes that SCIM is the only > reader/writer of this data, which will almost never be the case. If the > data model requires uids for every element, then every piece of non-SCIM > code that writes data into the directory will have to follow this. > Additionally, there are **many** tools and applications (eg =96 address > books) that rely on a certain data model in Active Directory, and this > would cause them to break. IMO this same argument holds true for most > service providers.**** > **** > **** > PATCH is an optional part of the spec. It was primarily introduced to > make modifying resources with large multi-valued lists more efficient. I= t > does not need to solve every problem (eg =96 modifying sub-elements in ne= sted > arrays). Adding uids to every multi-valued element does not strike the > right balance between the needs of the client and the needs of the servic= e > provider.**** > **** > --Kelly**** > **** > *From:* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Sent:* Monday, August 13, 2012 1:35 AM > *To:* Phil Hunt; Melinda Shore > *Cc:* Emmanuel Dreux; Kelly Grizzle; scim@ietf.org**** > > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > **** > Responding to extract of Melinda Shore's mail from digest:**** > **** > > The issue being raised here isn't endpoint logic, but**** > > network traffic, and I'm pretty sure it's not very helpful to**** > > respond to the observation that your model requires more**** > > > messages with a complaint about what you seem to think is a**** > > complex algorithm for attribute processing.**** > > **** > It depends on how it's implemented. I'm confident we can have the best of > both - simple API with low-overhead implementation. Can we brainstorm HOW > this proposal can be implemented rather than WHY it can't be implemented > (which is mostly what I've been hearing so far)? After all, no one has > challenged the claim that this proposal drastically simplifies the API fo= r > the client, so it would appear to be worth doing. I'm sure there's more > than enough intellectual horsepower in this working group to pull this of= f > if we put our minds to it.**** > **** > Regards,**** > Ganesh**** > **** > On 13 August 2012 13:54, Ganesh and Sashi Prasad > wrote:**** > > > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty.**** > Sorry Phil, but you're contradicting yourself here. There seems to be an > awful lot of matching (i.e., reading) going on in the spec as it stands, > with if-then clauses to do one thing or another if the match either > succeeds or fails. This is a complex, chatty protocol right now!**** > **** > > Multi-valued attributes: An attribute value in the PATCH request**** > > body is added to the value collection if the value does not exist**= ** > > and merged if a matching value is present. Values are matched by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute; e.g., addresses, or do not have unique*= *** > > value Sub-Attributes cannot be matched and must instead be deleted*= *** > > then added. Specific values can be removed from a Resource by**** > > adding an "operation" Sub-Attribute with the value "delete" to the*= *** > > attribute in the PATCH request body. As with adding/updating**** > > attribute value collections, the value to delete is determined by**= ** > > comparing the value Sub-Attribute from the PATCH request body to***= * > > the value Sub-Attribute of the Resource. Attributes that do not***= * > > have a value Sub-Attribute or that have a non-unique value Sub-**** > > Attribute are matched by comparing all Sub-Attribute values from***= * > > the PATCH request body to the Sub-Attribute values of the**** > > Resource. A delete operation is ignored if the attribute's name***= * > > is in the meta.attributes list. If the requested value to delete**= ** > > does not match a unique value on the Resource the server MAY**** > > return a HTTP 400 error.**** > > **** > For a spec that is supposed to be about simplicity, the above description > is anything but simple. I know you guys have worked hard on this and I > don't mean to disparage those efforts, but think about how the above > passage would appear to a new reader (i.e., a novice to the spec, not a > technology novice).**** > **** > There is something fundamentally broken, and it is this: multi-valued > attributes without a unique identifier per value. If you don't fix that, > you won't get simplicity.**** > **** > We know LDAP trees are broken for multi-valued attributes. As Mark Wahl f= amously > commented back > in 2005,**** > **** > "Unfortunately, some of the emerging protocols which also intend to > represent and transfer personal identity information have perhaps taken a > step backwards by not even considering these issues, perhaps sweeping the= m > under the rug in the guise of simplicity, XMLification, or "fix in the ne= xt > version", which only postpone finding interoperable solutions to allowing > applications to express the identity entries they want to express."**** > **** > SCIM is exactly one of these "emerging protocols" Wahl talks about, and > what I see now strikes me as "sweeping these issues under the rug in the > guise of simplicity". Apologies for the bluntness.**** > **** > My take is that SPs are _already_ struggling to manage multi-valued > attributes, and existing mechanisms are clumsy. > They would be grateful for a specification that made operations easier at > the cost of a re-engineered schema. That calls for some thought leadershi= p > from this working group.**** > **** > Regards,**** > Ganesh**** > > **** > On 13 August 2012 10:13, Phil Hunt wrote:**** > I strongly object to anything that leads to a read before modify > requirement. Too complex and too chatty. > > Phil**** > > > On 2012-08-12, at 15:29, Ganesh and Sashi Prasad > wrote:**** > > > Would it have to be stored on the account database of the service > provider?**** > **** > Yes.**** > **** > > If so, I believe that this is impracticable in the core schema. Indeed > it implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > **** > Why? That doesn't necessarily follow. Implementation is independent of > representation. We're talking about a change in representation to make th= e > API cleaner.**** > **** > As a simple example, if an LDAP node is being used to hold a list of > comma-separated email addresses, it can just as easily store > comma-separated name-value pairs.**** > **** > > mail: john_smith@yahoo.com, john.smith@gmail.com, jsmith1970@hotmail.com*= *** > > can be changed to**** > **** > mail: aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3D > john.smith@gmail.com, 7a6d1de664e1=3Djsmith1970@hotmail.com**** > **** > That's why I asked if there was an SP representative on this working grou= p > who could explain what such a change could mean for them. As of now, it > looks like other people are presuming that SPs will not be able to > implement these changes easily and are rejecting them for that reason.***= * > **** > Regards,**** > Ganesh**** > **** > On 13 August 2012 04:29, Emmanuel Dreux wrote:**** > > =F0 addresses.3cbaaff8e84e.street-number =3D "243"**** > **** > Where would 3cbaaff8e84e come from? Would it have to be stored on the > account database of the service provider?**** > **** > If so, I believe that this is impracticable in the core schema. Indeed it > implies that a service provider must extend the schema of his account > repository (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM > integration.**** > This would be a show stopper. SCIM must be transparent, and must be able > to be put on top of an existing system to provide provisioning apis.**** > **** > Said differently, SCIM must not be intrusive for existing systems and mus= t > not require modifications to allow its integration.**** > Correct me if I misunderstood your suggestion.**** > **** > --**** > Regards,**** > Emmanuel Dreux**** > http://www.cloudiway.com**** > Tel: +33 4 26 78 17 58 <%2B33%204%2026%2078%2017%2058>**** > Mobile: +33 6 47 81 26 70 <%2B33%206%2047%2081%2026%2070>**** > skype: Emmanuel.Dreux**** > **** > *De :* Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com] > *Envoy=E9 :* dimanche 12 ao=FBt 2012 04:53 > *=C0 :* Kelly Grizzle > *Cc :* scim@ietf.org; Phil Hunt > *Objet :* Re: [scim] scim Digest, Vol 8, Issue 24**** > **** > > Multi-valued attributes that don't have a value sub-attribute (eg - > address) have to specified completely for uniqueness. **** > **** > That's exactly the point. How do we "specify completely for uniqueness"?*= * > ** > **** > In the example below, how are you proposing that the following element be > updated if we can't use positional indexes?**** > **** > addresses[1].street-number =3D "243"**** > **** > User object:**** > **** > {**** > ...**** > addresses: [**** > {**** > "type" : "home",**** > "street-number" : "35",**** > "street-name" : "High Road",**** > "suburb" : "East Camden",**** > "postcode" : "5346",**** > "state" : "SA",**** > "country" : "Australia"**** > },**** > {**** > "type" : "office",**** > "street-number" : "213",**** > "street-name" : "Main Street",**** > "suburb" : "Adelaide",**** > "postcode" : "5000",**** > "state" : "SA",**** > "country" : "Australia"**** > }**** > ]**** > }**** > **** > It's impractical to use the value because it's the whole dictionary > element:**** > **** > {**** > "type" : "office",**** > "street-number" : "213",**** > "street-name" : "Main Street",**** > "suburb" : "Adelaide",**** > "postcode" : "5000",**** > "state" : "SA",**** > "country" : "Australia"**** > }**** > **** > With my proposal, the "addresses" array gets converted to a dictionary, > and then we have a stable way of referencing this element:**** > **** > addresses.3cbaaff8e84e.street-number =3D "243"**** > **** > {**** > ...**** > addresses: {**** > "d6ea365462f5" :**** > {**** > "type" : "home",**** > "street-number" : "35",**** > "street-name" : "High Road",**** > "suburb" : "East Camden",**** > "postcode" : "5346",**** > "state" : "SA",**** > "country" : "Australia"**** > },**** > "3cbaaff8e84e" :**** > {**** > "type" : "office",**** > "street-number" : "213",**** > "street-name" : "Main Street",**** > "suburb" : "Adelaide",**** > "postcode" : "5000",**** > "state" : "SA",**** > "country" : "Australia"**** > }**** > }**** > }**** > **** > If you're proposing one mechanism for composite attributes and another > mechanism for simple attributes, I would suggest that's actually more > complex than adopting a single mechanism that works the same way for _all= _ > attributes. Remember that a lot of the administration is probably going t= o > be scripted rather than done by hand, and having two mechanisms (dependin= g > on whether the attribute is simple or composite) will complicate every > script that has to be written.**** > **** > There's a lot of talk about the "burden" on the SPs, but I believe this i= s > overblown. Is there any SP representative in this WG who can tell us what > this proposal will actually entail for them?**** > **** > Regards,**** > Ganesh**** > **** > On 12 August 2012 11:53, Kelly Grizzle > wrote:**** > Ganesh,**** > **** > This is exactly how PATCH works in SCIM 1.0. Multi-valued attributes tha= t > have a value sub-attribute can be removed by specifying only the value > since it is unique. Multi-valued attributes that don't have a value > sub-attribute (eg - address) have to specified completely for uniqueness. > As I have said before, I am very opposed to adding a unique identifier t= o > each element in a multi-valued collection due to the burden it will put o= n > SPs. Is it elegant? No. Is it functional? Yes. Will this non-eleganc= e > affect adoption? My opinion is that adding unique keys to each element > will have a much more detrimental effect on adoption.**** > **** > I do believe that in general PATCH can be made more intuitive without > adding uids to each element. The verbs that you propose make sense. The= re > is also a JSON Patch informational draft in the IETF that is interesting = - > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02. It relies > on a JSON Pointer draft which uses index-based addressing for multi-value= d > attributes. I think that this is something that should be looked at with= in > the WG and I would be willing to lead this effort.**** > **** > I'm curious if anyone else in the WG is in favor of unique identifiers fo= r > every multi-valued element.**** > **** > --Kelly**** > **** > ------------------------------ > > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Ganesh > and Sashi Prasad [g.c.prasad@gmail.com] > *Sent:* Saturday, August 11, 2012 10:50 AM > *To:* Phil Hunt > *Cc:* scim@ietf.org > *Subject:* Re: [scim] scim Digest, Vol 8, Issue 24**** > Phil,**** > **** > The reason we cannot use the value itself to identify an element is that > this method will only work for simple elements, not for nested structures= . > i.e., if we had an array of dictionaries (e.g., we had to record an array > of addresses for each customer, with each address element having > sub-elements like street number, street name, suburb, etc.), then it woul= d > be clumsy to supply the entire value of the array element because it's > itself a dictionary. Creating a unique key for each element scales better= . > **** > **** > Regards,**** > > Ganesh**** > On 12 August 2012 01:12, Phil Hunt wrote:**** > Ganesh,**** > **** > Here's the sample that concerned me...**** > > The two operations differ significantly, and it's not very intuitive. ***= * > With my suggestion, here's how to delete a single member from a group:***= * > **** > PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Acce= pt: > application/json Authorization: Bearer h480djs93hd8 ETag: > W/"a330bc54f0671c9" {**** > "operations" : [**** > {**** > "RETIRE" : {**** > "key" : "members.2819c223-7f76-453a-919d-413861904646"**** > }**** > }**** > ] }**** > > **** > **** > You gave other examples of an attribute with an identifier that matched > that value or of identifiers that were additional unique keys.**** > **** > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --0015173fe60247c6cd04c7689b5b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >=A0While I appreciate the thou= ght and time Ganesh has put into the concepts, I am not convinced the appro= ach would be net better and less complex and so do not support it=A0and wel= come moving on to=A0other topics.

I agree. Perhaps it would be best f= or the spec committee to move on to tackling other issues. The approach I&#= 39;m proposing has been well-understood already, so I don't think anyth= ing would be gained by me putting it into an Internet Draft at this stage.<= div>
Just out of interest, my current employer (a major telco wit= h about 10 million subscribers) adopts the approach of using a relational d= atabase as the "source of truth" to which all updates are applied= , and then writes out the "de-normalised" subscriber records to a= geographically-dispersed LDAP cluster. I was speaking to one of the techni= cal leads in charge of that area (since I am the architect for Identity and= Access Management) and he believed that this two-phase approach was operat= ionally simpler and more robust, not more complex!

Personally, I'm gratified that my proposal has been= taken seriously and evaluated on its merits, so here's a heartfelt &qu= ot;thank you" from me to all of you who have taken the time to examine= it. I believe this approach of being able to address individual elements o= f a multi-valued attribute has application even beyond SCIM, so I will be p= ursuing it as a generic set of patterns ("resource" defined as a = Nested Dictionary, "NDAP directory" as a resource datastore, &quo= t;NDAP" as a RESTful API with well-defined sub-operations, etc.) Who k= nows, some day that set of patterns may be re-applied to user provisioning = because "that's how it's done elsewhere" :-).

Thanks and regards,
Ganesh

=


On 17 August 2012 05:23, <sci= m-request@ietf.org> wrote:
If you have received this digest without all= the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



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

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

You can reach the person managing the list at
=A0 =A0 =A0 =A0 scim-owner@ietf.org<= /a>

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

Today's Topics:

=A0 =A01. Re: scim Digest, Vol 8, Issue 24 (Chris Phillips)


---------- Forwarded message ----------
From:=A0Chris Phillips &= lt;Chris.Phillips@canarie.ca>
To:=A0"scim@ietf.org&qu= ot; <scim@ietf.org>
Cc:=A0
Date:=A0Thu, 16 Aug 2012 15:23:29 -0400
Subject:=A0Re: [scim] = scim Digest, Vol 8, Issue 24
+1 to Phil's comm= ents.

As well, adding a = ghost directory to [de|en]code things is just too much overhead to build in= to the protocol. =A0If someone wants to build that on TOP of SCIM, that'= ;s up to them. =A0

While I appreciate the thought and time = Ganesh has put into the concepts, I am not convinced the approach would be = net better and less complex and so do not support it=A0and welcome moving o= n to=A0other topics.

C.

From: Phil Hunt <phil.hunt@oracle.com>Date: Thursday, 16 August, 2012 1= :42 PM
To: Kelly Grizzle <kelly.grizzle@sailpoin= t.com>
Cc: Emmanuel Dreu= x <edreux@clou= diway.com>, Anthony Nadalin <tonynad@microsoft.com>, Ganesh and Sashi Pras= ad <g.c.prasad= @gmail.com>, Melinda Shore <melinda.shore@gmail.com>, "scim@ietf.org" <scim@ietf.org>
Subject: Re: [scim] scim Digest, V= ol 8, Issue 24

I do think we need to arrive at some consensus on this now becaus= e Ganesh's proposal is a major "fork-in-the-road" decision. I= f we table it, it will be hard to come back to. This is why I have engaged = on the subject with Ganesh so thoroughly. =A0Never-the-less, I would like to arrive at some conclusions here.

= My apologies, but I thought it was worth re-stating the problem for those l= ate to the discussion would be useful.

Background:=
At present, the current spec does not allow you to change a specific s= ub-attribute in a multi-valued complex attribute structure (e.g. changing s= treet name in a specific address value instance such as "home"). = =A0The proposal is that each sub attribute in a multi-valued structure gets its own unique identifier. =A0Then you can d= irectly reference the specific complex attribute component in a complex val= ue.

The current draft proposal requires that compl= ex-value (e.g. an address value which is made up of number, street, city, e= tc) be changed if you want to change any of the sub-attributes. The current= approach seems a reasonable compromise since it is likely the collection of attributes in a complex "value" are often mani= pulated together. IOW. You tend to set them all at once. =A0Ganesh's pr= oposal allows specific sub-attributes to be directly addressable by giving = each value instance a unique identifier. =A0=A0

Another example of this is the group "member"= attribute. =A0In the current draft, a member can have a value and a displa= y name. In this case you would usually change the value (object identifier)= and the name as well. =A0Ganesh's proposal would allow "Display Name" to be changed or value to be changed. =A0Something, IMV, that d= oesn't occur nearly as often. =A0IOW members change group membership, b= ut members rarely change names.

My conclusion:
If the client must first query (or have synchronized the value identif= iers), then the client has to do even more work than the current proposal o= f replacing the enter complex value. =A0Given such a choice I'm really = skeptical that the pattern proposed by Ganesh would be widely used. =A0While Ganesh's proposal may be "s= pecific", the practical simplicity of it is very much debatable.
=

The benefit of specific sub-attribute identifiers needs to be substantial. = =A0We're not only talking about changing how infrastructure is done, bu= t also how applications are written. This leaves out the entire current ado= pters and all enterprise users. =A0A big concern we have obviously is we have to consider existing infrastructure a= nd data stores and be realistic. I don't think the benefit is worth the= cost.

I agree with the others that the current draft cou= ld be changed to make patch operations more clear to the developer (simpler= to read). While this may not improve logic, it will improve understanding = and simplicity. The fact that certain operations may require an entire complex attribute value to be replaced is a reasonable c= ompromise and should not be changed.=A0

Phil

On 201= 2-08-16, at 8:59 AM, Kelly Grizzle wrote:

= Hi Ganesh =85 your write-up concedes that this will be difficult to= implement for an existing service provider.=A0 I=92m not sure that I under= stand the compromise.=A0 Are you still suggesting that SCIM move to the unique-key-per-element strategy?=
=A0
If so, the cost/benefit of this seems way off to me.=A0 You are gai= ning a more elegant API by introducing an additional datastore and requirin= g replication.=A0 I don=92t know of any service provider that would make this trade-off.=A0 As you said, th= is is something that future service providers can keep in mind, but it is n= ot going to help existing providers.
=A0
--Kelly
=A0
From:= =A0Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=A0
Sent:=A0Thursday, August 16, 2012 5:38 AM
To:= =A0Anthony Nadalin
Cc:=A0Kelly Grizzle;= Emmanuel Dreux; Melinda Shore; scim@ietf.org; Phil = Hunt
Subject:=A0Re: [scim] scim Digest, Vol 8, Issue= 24
=A0
Hi all,
=A0
Would this hybrid architecture be a workable compromise? See diagram toward= s the end:=A0http://bit.ly/Rjc39Y
=A0
Regards,

Ganesh

On 15 August 2012 05:54, Anthony Nadalin <tonynad@microsoft.com> wrote:
We should not be constrained by LDAP restrictions, this would not b= e productive.
=A0
From:=A0= scim-bounces@ietf.org=A0[mailto:scim-bounces@ietf.org]= =A0On Behalf Of=A0Ganesh and Sashi Prasad
Sent:= =A0Monday, August 13, 2012 2:07 PM
To:=A0Kell= y Grizzle
Cc:=A0Emmanuel Dreux; Melinda Shore;= =A0scim@ietf.org; Phil Hunt=

Subject:=A0Re: [scim] scim Digest, Vol 8, Issu= e 24
=A0
Thanks, Kelly. You've been most patient in hearing me out, I must say. = I couldn't ask for more.
=A0
Replying to Chris Philips's mail:
>=A0Given that you have a number of thoughts about what could be changed in SCIM,Lei= f's recommendation to =A0craft them in an Internet Draft may be a bette= r way to convey your thoughts.

I'm coming around to the same conclusion. Do you think such an Internet= Draft should be about changing SCIM, or should it propose a complementary = spec for SPs who use a "NoLDAP" data store? I think the underlyin= g problem is with LDAP, and unless we change that, these proposals won't fly.
=A0
Regards,

Ganesh

On 14 August 2012 01:54, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
There are really two implementation options for a uid per element =96 ei= ther store the uids in the native underlying data store or have some second= ary data store that maps elements to their uids.=A0 The third option is to hope that a service prov= ider has a NoLDAP data store or its equivalent.=A0 None of these are practi= cal for rapid and wide-spread adoption.
=A0
>=A0put the two together to propose a soluti= on.
=A0
As I said before, I am completely on board with cleaning up the PAT= CH semantics (eg =96 the inconsistency between meta.attributes and operatio= n=3Ddelete, etc=85).=A0 Your suggestion of using different verbs is a good option to consider.=A0 This cannot be b= ased on a uid per element, though.=A0 It seems as though you have admitted = this in your conclusion =96 =93As for LDAP and SCIM, I guess the best TLA i= s RIP.=94
=A0
--Kelly
=A0
From:= =A0Ganesh and Sashi Prasad [mailto:g.c.prasad@= gmail.com]=A0
Sent:=A0Monday, August 13, 2012 9:56 AM
To:=A0Kelly Grizzle
Cc:=A0Phil Hunt; Melinda= Shore; Emmanuel Dreux;=A0scim@ietf.org=

Subject:=A0Re: [scim] scim Digest, Vol 8, Issu= e 24
=A0
That was one suggestion. Another way could be container nodes with their ow= n "dn"s. If one suggestion won't work, tell me another way to= make it work. I'm waiting to hear a constructive suggestion that can s= quare an elegant API with the implementation constraints that come from having to store multi-valued attributes in LDAP directories= .
=A0
I've heard enough of WHY this won't work. For a change, tell me HOW= it can be made to work. Everyone now knows what the proposal means in term= s of the API, and implementors understand the constraints of legacy data st= ores, so put the two together to propose a solution. C'mon, we have the "smartest guys in the room" h= ere, surely we should be able to crack this.
=
=A0
Regards,
Ganesh
=A0
P.S. I'm rapidly reaching my own conclusions about what is to be done:<= u>

=A0

On 14 August 2012 00:27, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:
> After all, no one has challenged the claim that this proposal drastica= lly simplifies the API for the client
=A0
I agree that your proposal makes PATCH semantics simpler and more e= legant.
=A0
=A0
> =85=A0so it would appear to be worth doing= .=A0
=A0
I strongly disagree here.=A0 This statements assumes that simplicit= y of the client API is the only factor that should be considered with the s= pec.
=A0
Emmanuel=92s example is from a real-world service provider that would no= t be able to implement the spec easily with a uid per element.=A0 He is wor= king on a SCIM interface that will help facilitate data exchange between multiple Active Directory = servers.=A0 Your solution was to change the data model from this:=
=A0

mail: john_smith@yahoo.com, john.smith@gm=
ail.com, jsmith1970@hotmail.com
=A0
to this:
=A0
mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com,9cda-8646c3085bbf=3Djohn.smith@gmail.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com
=A0
I do not know of a single organization that would change their Active Di= rectory data model to fit this.=A0 For one thing, it would be a huge data m= igration effort (likely across other domain controllers, etc=85) to assign these unique identifier= s.=A0 This also assumes that SCIM is the only reader/writer of this data, w= hich will almost never be the case.=A0 If the data model requires uids for = every element, then every piece of non-SCIM code that writes data into the directory will have to follow this.=A0 Addi= tionally, there are *many* tools and applications =A0(eg =96 address= books) that rely on a certain data model in Active Directory, and this wou= ld cause them to break.=A0 IMO this same argument holds true for most service providers.
=
=A0
=A0
PATCH is an optional part of the spec. =A0It was primarily introduced to= make modifying resources with large multi-valued lists more efficient.=A0 = It does not need to solve every problem (eg =96 modifying sub-elements in nested arrays).=A0 Adding = uids to every multi-valued element does not strike the right balance betwee= n the needs of the client and the needs of the service provider.<= /u>
=A0
--Kelly
=A0
From:= =A0Ganesh and Sashi Prasad [mailto:g.c.prasad@= gmail.com]=A0
Sent:=A0Monday, August 13, 2012 1:35 AM
To:=A0Phil Hunt; Melinda Shore
Cc:=A0Emmanue= l Dreux; Kelly Grizzle;=A0scim@ietf.org=

Subject:=A0Re: [scim] scim Digest, Vol 8, Issu= e 24
=A0
Responding to extract of Melinda Shore's mail from digest:
=A0
The issue bein=
g raised here isn't endpoint logic, but
network traffic=
, and I'm pretty sure it's not very helpful to
respond to the =
observation that your model requires more

messages with a complaint about what you seem to think is a
complex alg=
orithm for attribute processing.




=A0

It depends on how it's implemented. I'm confident we can have the b=
est of both - simple API with low-overhead implementation. Can we brainstor=
m HOW this proposal can be implemented rather than WHY it can't be impl=
emented (which is mostly what I've been hearing
 so far)? After all, no one has challenged the claim that this proposal dra=
stically simplifies the API for the client, so it would appear to be worth =
doing.=A0I'm sure there's more than enough intellectual horsepower =
in this working group to pull this off if
 we put our minds to it.

=A0

Regards,

Ganesh

=A0

On 13 August 2012 13:54, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:



Sorry Phil, but you're contradicting yourself here.=A0There seems to be=
 an awful lot of matching (i.e., reading) going on in the spec as it stands=
, with if-then clauses to do one thing or another if the match either succe=
eds or fails. This is a complex, chatty
 protocol right now!

=A0
=A0=A0 Multi-valued attri=
butes:=A0 An attribute value in the PATCH request


=A0=A0=A0=A0=A0 body is added to the value collection if th=
e value does not exist



=A0=A0=A0=A0=A0 and merged if a matching value is present.=
=A0 Values are matched by



=A0=A0=A0=A0=A0 comparing the value Sub-Attribute from the =
PATCH request body to



=A0=A0=A0=A0=A0 the value Sub-Attribute of the Resource.=A0=
 Attributes that do not



=A0=A0=A0=A0=A0 have a value Sub-Attribute; e.g., addresses=
, or do not have unique



=A0=A0=A0=A0=A0 value Sub-Attributes cannot be matched and =
must instead be deleted



=A0=A0=A0=A0=A0 then added.=A0 Specific values can be remov=
ed from a Resource by



=A0=A0=A0=A0=A0 adding an "operation" Sub-Attribu=
te with the value "delete" to the



=A0=A0=A0=A0=A0 attribute in the PATCH request body.=A0 As =
with adding/updating



=A0=A0=A0=A0=A0 attribute value collections, the value to d=
elete is determined by



=A0=A0=A0=A0=A0 comparing the value Sub-Attribute from the =
PATCH request body to



=A0=A0=A0=A0=A0 the value Sub-Attribute of the Resource.=A0=
 Attributes that do not



=A0=A0=A0=A0=A0 have a value Sub-Attribute or that have a n=
on-unique value Sub-



=A0=A0=A0=A0=A0 Attribute are matched by comparing all Sub-=
Attribute values from



=A0=A0=A0=A0=A0 the PATCH request body to the Sub-Attribute=
 values of the



=A0=A0=A0=A0=A0 Resource.=A0 A delete operation is ignored =
if the attribute's name



=A0=A0=A0=A0=A0 is in the meta.attributes list.=A0 If the r=
equested value to delete



=A0=A0=A0=A0=A0 does not match a unique value on the Resour=
ce the server MAY



=A0=A0=A0=A0=A0 return a HTTP 400 error.




=A0

For a spec that is supposed to be about simplicity, the above description i=
s anything but simple. I know you guys have worked hard on this and I don&#=
39;t mean to disparage those efforts, but think about how the above passage=
 would appear to a new reader (i.e.,
 a novice to the spec, not a technology novice).
<=
div>



=A0

There is something fundamentally broken, and it is this: multi-valued attri=
butes without a unique identifier per value. If you don't fix that, you=
 won't get simplicity.



=A0

We know LDAP trees are broken for multi-valued attributes. As Mark Wahl=A0famou=
sly commented=A0back
 in 2005,

=A0

"Unfortunately,
 some of the emerging protocols which also intend to represent and transfer=
 personal identity information have perhaps taken a step backwards by not e=
ven considering these issues, perhaps sweeping them under the rug in the gu=
ise of simplicity, XMLification,
 or "fix in the next version", which only postpone finding intero=
perable solutions to allowing applications to express the identity entries =
they want to express."



=A0

SCIM is exactly one of these "emerging protocols" Wahl talks abou=
t, and what I see now strikes me as "sweeping these issues under the r=
ug in the guise of simplicity". Apologies for the bluntness.=





=A0

My take is that SPs are _already_ struggling to manage multi-valued attribu=
tes, and=A0existing
 mechanisms are clumsy. They would be grateful for a specification that=
 made operations easier at the cost of a re-engineered schema. That calls f=
or some thought leadership from this working group.




=A0

Regards,

Ganesh

=A0

On 13 August 2012 10:13, Phil Hunt <phil.h=
unt@oracle.com> wrote:



I strongly object to anything that leads to a read before modify requiremen=
t. Too complex and too chatty.=A0

Phil


On 2012-08-12, at 15:29, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:



=
> Would it have to be stored on the =
account database of the service provider?



=A0


Yes.

=A0
> If so, I believe=
 that this is impracticable in the core schema.=A0Indeed it implies that a =
service provider must extend the schema of his account repository (LDAP par=
tition, SQL db, =85) and =93prepare it=94 for SCIM integration.




=A0

Why? That doesn't necessarily follow. Implementation is independent of =
representation. We're talking about a change in representation to make =
the API cleaner.



=A0

As a simple example, if an LDAP node is being used to hold a list of comma-=
separated email addresses, it can just as easily store comma-separated name=
-value pairs.



=A0

=A0
m=
ail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.c=
om,9cda-8646c3085bbf=3Djohn.smith@gmail.c=
om,=A07a6d1de664e1=3Djsmith1970@hotmail=
.com



=A0=




That's why I asked if the=
re was an SP representative on this working group who could explain what su=
ch a change could mean for them. As of now, it looks like other people are =
presuming that SPs will not be able
 to implement these changes easily and are rejecting them for that reason.<=
/span>



=A0
R=
egards,



Ganesh<=
/u>




=A0

On 13 August 2012 04:29, Emmanuel Dreux <e=
dreux@cloudiway.com> wrote:


=F0=A0=A0addresses.3cbaaff8e84e.street-number =3D "=
;243"


=A0


Where would=A03cbaaff8=
e84e=A0come
 from? Would it have to be stored on the account database of the service pr=
ovider?


=A0
If so, I believe that this is impracticable in the co=
re schema. Indeed it implies that a service provider must extend the schema=
 of his account repository (LDAP partition, SQL db, =85) and =93prepare it=
=94 for SCIM integration.



This would be a show stopper. SCIM must be t=
ransparent, and must be able to be put on top of an existing system to prov=
ide provisioning apis.



=A0


Said differently, SCIM must not be intr=
usive for existing systems and must not require modifications to allow its =
integration.


Correct me if I misunderstood your sugg=
estion.


=A0
--



Regards,



Emmanuel Dreux





Mobile:=
=A0+33
 6 47 81 26 70
skype: Emmanuel=
.Dreux



=A0






De=
=A0:=A0Ganesh and Sashi Prasad [mailto:g.c.prasad@gmail.com]=A0


Envoy=E9=A0:=A0dimanche 12 ao=FBt 2012 04:53
=C0=
=A0:=A0Kelly Grizzle
Cc=A0:=A0scim@ietf.org; Phil Hunt


Objet=A0:=A0Re: [scim] scim Digest, Vol 8, Issue 24


=A0
>=A0=
=A0Multi-valued
 attributes that don't have a value sub-attribute (eg - address) have t=
o specified completely for uniqueness.=A0=A0


=A0
Tha=
t's exactly the point. How do we "specify completely for uniquenes=
s"?



=A0


In the example below, how are you proposing that the foll=
owing element be updated if we can't use positional indexes?<=
/u>


=A0
add=
resses[1].street-number =3D "243"



=A0


User object:
=A0



{


=A0 ...
=A0 addresses: [



=A0 =A0 {


=A0 =A0 =A0 "type" : "home",


=A0 =A0 =A0 "street-number" : "35",


=A0 =A0 =A0 "street-name" : "High Road&quo=
t;,


=A0 =A0 =A0 "suburb" : "East Camden",=



=A0 =A0 =A0 "postcode" : "5346",


=A0 =A0 =A0 "state" : "SA",=



=A0 =A0 =A0 "country" : "Australia"


=A0 =A0 },
=A0 =A0 {



=A0 =A0 =A0 "type" : "office",<=
/span>



=A0 =A0 =A0 "street-number" : "213&q=
uot;,



=A0 =A0 =A0 "street-name" : "Main St=
reet",



=A0 =A0 =A0 "suburb" : "Adelaide&quo=
t;,



=A0 =A0 =A0 "postcode" : "5000"=
,



=A0 =A0 =A0 "state" : "SA",



=A0 =A0 =A0 "country" : "Australia&q=
uot;



=A0 =A0 }


=A0 ]
}=




=A0


It's impractical to use the value because it's th=
e whole dictionary element:


=A0
{



=A0 "type" : "office",



=A0 "street-number" : "213",



=A0 "street-name" : "Main Street&quo=
t;,



=A0 "suburb" : "Adelaide",



=A0 "postcode" : "5000",=




=A0 "state" : "SA",



=A0 "country" : "Australia"



}


=A0
Wit=
h my proposal, the "addresses" array gets converted to a dictiona=
ry, and then we have a stable way of referencing this element:



=A0


addresses.3cbaaff8e84e.street-number =3D "243"<=
/span>


=A0
{



=A0 ...


=A0 addresses: {
=A0 =A0 "d6ea365462f5" :



=A0 =A0 {


=A0 =A0 =A0 "type" : "home",


=A0 =A0 =A0 "street-number" : "35",


=A0 =A0 =A0 "street-name" : "High Road&quo=
t;,


=A0 =A0 =A0 "suburb" : "East Camden",=



=A0 =A0 =A0 "postcode" : "5346",


=A0 =A0 =A0 "state" : "SA",=



=A0 =A0 =A0 "country" : "Australia"


=A0 =A0 },
=A0 =A0 "3cbaaff8e84e" :



=A0 =A0 {


=A0 =A0 =A0 "type" : "office",=



=A0 =A0 =A0 "street-number" : "213",<=
/span>


=A0 =A0 =A0 "street-name" : "Main Street&q=
uot;,


=A0 =A0 =A0 "suburb" : "Adelaide",


=A0 =A0 =A0 "postcode" : "5000",


=A0 =A0 =A0 "state" : "SA",=



=A0 =A0 =A0 "country" : "Australia"


=A0 =A0 }
=A0 }



}


=A0
If =
you're proposing one mechanism for composite attributes and another mec=
hanism for simple attributes, I would suggest that's actually more comp=
lex than adopting a single mechanism that works the same way for _all_ attr=
ibutes. Remember that
 a lot of the administration is probably going to be scripted rather than d=
one by hand, and having two mechanisms (depending on whether the attribute =
is simple or composite) will complicate every script that has to be written=
.



=A0


There's a lot of talk about the "burden" on=
 the SPs, but I believe this is overblown. Is there any SP representative i=
n this WG who can tell us what this proposal will actually entail for them?=




=A0


Regards,
Ganesh



=A0


On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sailpoint.com> wrote:=




Ganesh,



=A0



This is exactly how PATCH works in SCIM 1.0. =A0Multi-valued attributes=
 that have a value sub-attribute can be removed by specifying only the valu=
e since it is unique. =A0Multi-valued attributes
 that don't have a value sub-attribute (eg - address) have to specified=
 completely for uniqueness. =A0As I have said before, I am very opposed to =
adding a unique identifier to each element in a multi-valued collection due=
 to the burden it will put on SPs. =A0Is
 it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this non-elegance =
affect adoption? =A0My opinion is that adding unique keys to each element w=
ill have a much more detrimental effect on adoption.



=
=
=A0



I do believe that in general PATCH can be made more intuitive without a=
dding uids to each element. =A0The verbs that you propose make sense. =A0Th=
ere is also a JSON Patch informational draft
 in the IETF that is interesting -=A0http://tools.ietf.org/html/draft-ietf-appsawg-json-=
patch-02. =A0It relies on a JSON
 Pointer draft which uses index-based addressing for multi-valued attribute=
s. =A0I think that this is something that should be looked at within the WG=
 and I would be willing to lead this effort.



=
=
=A0



I'm curious if anyone else in the WG is in favor of unique identifi=
ers for every multi-valued element.



=A0



--Kelly



=
=A0






From:=A0scim-bounces@ie=
tf.org=A0[scim-bounces@ie=
tf.org]
 on behalf of Ganesh and Sashi Prasad [g.c.pr=
asad@gmail.com]
Sent:=A0Saturday, August 11, 201=
2 10:50 AM


To:=A0Phil Hunt
Cc:=A0scim@ietf.org
Subject:=A0Re: [scim]=
 scim Digest, Vol 8, Issue 24



Phil,


=A0
The=
 reason we cannot use the value itself to identify an element is that this =
method will only work for simple elements, not for nested structures. i.e.,=
 if we had an array of dictionaries (e.g., we had to record an array of add=
resses for each
 customer, with each address element having sub-elements like street number=
, street name, suburb, etc.), then it would be clumsy to supply the entire =
value of the array element because it's itself a dictionary. Creating a=
 unique key for each element scales
 better.
=A0



Regards,


Ganesh
On 12 Au=
gust 2012 01:12, Phil Hunt <phil.hunt@orac=
le.com> wrote:



=
Ganesh,


=A0
Her=
e's the sample that concerned me...



The two operations differ significantly, and it's not ver=
y intuitive.=A0



With my suggestion, here's how to delete a sing=
le member from a group:



=A0


PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host:=A0=
example.com=A0Accept:
 application/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54=
f0671c9" {


"operations" : [


{


"RETIRE" : {


"key" : "members.2819c223-7f76-453a-919d-413861904646&quo=
t;


}


}


] }
=A0
=A0
You gave other examples of an attribute with an identifier t= hat matched that value or of identifiers that were additional unique keys.<= /span>
=A0
<= /div>
_______________________= ________________________
scim mailing list
scim@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/scim


--0015173fe60247c6cd04c7689b5b-- From melinda.shore@gmail.com Thu Aug 16 14:23:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF1F21E8042 for ; Thu, 16 Aug 2012 14:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a+AfO3+TjNu for ; Thu, 16 Aug 2012 14:23:57 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA2821E803F for ; Thu, 16 Aug 2012 14:23:57 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so2185294pbb.31 for ; Thu, 16 Aug 2012 14:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uJqZ6urMKUJtpRzcJ8NwFc/DbSw3H2NSikAXk5y1m4E=; b=xCfiZbutAKAV9gCwSzsaPqk8jUe6txYVqRJ4iloCbOf+dZS+1A4UCGYKd64HgXWKbI aj5CIwWs2k76TEdQPHa2hmm2GGHoRBdGD8GGYGuxO/Xv+C19a3fvUlXqFPxSEOL6R22+ +4nYoEzSnLgcV27D5hOp/ryhiAZnehqN+aOByMsvjqR9/zjoOjZf/eCLZlOhRQ2UBZ64 Q2d+JKXuOWEidx+EGI+wA9toSdcJdSUl4fpJFZVwekqjCuex8kZ2WyUsWp0becQUOgyU OtqAeRaMAsvpSdludhIj/sXeJxHUTQ2ED5ShWkIZSE/XUN/RgJxOC1bcsrmsbuuSVMSk FZeA== Received: by 10.68.218.163 with SMTP id ph3mr495400pbc.58.1345152236774; Thu, 16 Aug 2012 14:23:56 -0700 (PDT) Received: from spandex.local (66-230-81-200-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.200]) by mx.google.com with ESMTPS id pt1sm3395871pbc.4.2012.08.16.14.23.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Aug 2012 14:23:55 -0700 (PDT) Message-ID: <502D64EA.2010807@gmail.com> Date: Thu, 16 Aug 2012 13:23:54 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] scim Digest, Vol 8, Issue 70 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 21:23:57 -0000 On 8/16/12 1:19 PM, Ganesh and Sashi Prasad wrote: > Just out of interest, my current employer (a major telco with about 10 > million subscribers) adopts the approach of using a relational database > as the "source of truth" to which all updates are applied, and then > writes out the "de-normalised" subscriber records to a > geographically-dispersed LDAP cluster. I was speaking to one of the > technical leads in charge of that area (since I am the architect for > Identity and Access Management) and he believed that this two-phase > approach was operationally simpler and more robust, not more complex! We did something similar at a previous employer. I think the answer to that sort of thing is that what you know is always simpler than what you don't know. Be that as it may, I think the issue here is the impact of your proposal on the data structures, not processes. Melinda From edreux@cloudiway.com Fri Aug 17 03:42:16 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3A321F8525 for ; Fri, 17 Aug 2012 03:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.614 X-Spam-Level: X-Spam-Status: No, score=-4.614 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWvV4JbIt7U5 for ; Fri, 17 Aug 2012 03:42:09 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 472E121F850D for ; Fri, 17 Aug 2012 03:42:07 -0700 (PDT) Received: from mail91-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 Aug 2012 10:42:06 +0000 Received: from mail91-va3 (localhost [127.0.0.1]) by mail91-va3-R.bigfish.com (Postfix) with ESMTP id CF352C0320 for ; Fri, 17 Aug 2012 10:42:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT001.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -91 X-BigFish: PS-91(z73eW41dR21cRz98dI9371Ic89bh8f9Re6eL936eI1432I1418Ic857hac5W4015I9d9R14ffIc0c9kzz1202hzz1033IL8275bh8275dh46309nf3c47iz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail91-va3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT001.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail91-va3 (localhost.localdomain [127.0.0.1]) by mail91-va3 (MessageSwitch) id 1345200120788014_25039; Fri, 17 Aug 2012 10:42:00 +0000 (UTC) Received: from VA3EHSMHS001.bigfish.com (unknown [10.7.14.242]) by mail91-va3.bigfish.com (Postfix) with ESMTP id B3A1E440141 for ; Fri, 17 Aug 2012 10:42:00 +0000 (UTC) Received: from AMXPRD0610HT001.eurprd06.prod.outlook.com (157.56.248.213) by VA3EHSMHS001.bigfish.com (10.7.99.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 Aug 2012 10:41:58 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.209]) by AMXPRD0610HT001.eurprd06.prod.outlook.com ([10.255.58.36]) with mapi id 14.16.0190.008; Fri, 17 Aug 2012 10:41:45 +0000 From: Emmanuel Dreux To: "scim@ietf.org" Thread-Topic: [scim] scim Digest, Vol 8, Issue 24 Thread-Index: AQHNeDWynYh07cptlESyDB67eV+Ku5ddzcig Date: Fri, 17 Aug 2012 10:41:35 +0000 Message-ID: References: <8BE84C1D-ED3E-4FCE-8623-B2CBCE974D17@oracle.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.14.240.38] Content-Type: multipart/alternative; boundary="_000_DF63ACC82673DB40A7AAC08FFA71DFBD274190A0AMXPRD0610MB353_" MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 10:42:16 -0000 --_000_DF63ACC82673DB40A7AAC08FFA71DFBD274190A0AMXPRD0610MB353_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbyBhZ3JlZSB0byBub3QgZm9sbG93IEdhbmVzaOKAmXMgcHJvcG9zaXRpb24uDQpBcyBhbiBJ QU0gZWRpdG9yIGFuZCB0ZWNobm9sb2d5IHByb3ZpZGVyIGZvciBTQUFTIHByb3ZpZGVycywgSSB3 b3VsZCBiZSB1bmFibGUgdG8gcHVzaCBzb2x1dGlvbnMgdGhhdCB3b3VsZCByZXF1aXJlIHRvIGNo YW5nZSB0aGUgcHJvdmlkZXLigJlzIGRhdGEgbW9kZWwuICg5MCUgd291bGQgbm90IGFjY2VwdCBz dWNoIGludHJ1c2lvbikuDQoNCkZvciBpbmZvcm1hdGlvbiwgd2UgYXJlIGRvaW5nIDIgU0NJTSAg aW50ZWdyYXRpb25zIHRoaXMgbW9udGgsIGZvciAyIFNBQVMgcHJvdmlkZXJzIHdobyBoYXZlIDIg bGFyZ2UgY3VzdG9tZXLigJlzIEFjdGl2ZSBEaXJlY3RvcmllcyB0byBzeW5jaHJvbml6ZSAoMTAg MDAwIGFuZCAxNSAwMDAgdXNlcnMpLiBEZWFkbGluZSBTZXB0ZW1iZXIgMTUuDQoNClRoYXQgc2Fp ZCwgdGhlIHByb2JsZW0gb2YgbXVsdGkgdmFsdWVzIGlzIHJlYWwgYW5kIHJlbWFpbnMgYW4gaXNz dWUgZm9yIG1lLg0KSW1hZ2luZSB0aGF0IEkgY2F0Y2ggQWN0aXZlIERpcmVjdG9yeSBjaGFuZ2Vz IChmb3IgZXhhbXBsZSBhIGNoYW5nZSBpbiBhIHN0cmVldCBmaWVsZDogaXQgbWlnaHQgY29tZSBm cm9tIGFuIGFkbWluaXN0cmF0b3Igd2hubyBmaXhlcyB0aGlzIGZpZWxkLCBvciBhIHVzZXIgdGhh dCBjaGFuZ2VzIGEgdmFsdWUgdGhyb3VnaCBhIHNlbGYgc2VydmljZSBwb3J0YWwpLg0KSWYgb3Vy IElBTSBwcm9kdWN0IHNlbmRzIHRoZSBjaGFuZ2UgdGhyb3VnaCBhIHByb3ByaWV0YXJ5IEFQSSAo ZXggR29vZ2xlLCBTYWxlc2ZvcmNlLCBPZmZpY2UzNjUgYXBpKSwgdGhlbiB0aGVyZSBpcyBubyBw cm9ibGVtLg0KSWYgaXQgc2VuZCB0aGUgY2hhbmdlIHRocm91Z2ggU0NJTSwgSSB3aWxsIGhhdmUg dG8ga25vdyBhbmQgbWFpbnRhaW4gc29tZXdoZXJlIHRoYXQgYWRkaXRpb25hbCBmaWVsZHMgYXJl IGxpbmtlZCB0b2dldGhlciBhbmQgSSB3aWxsIGhhdmUgdG8gZ2V0IHRoZSB2YWx1ZXMgb2YgYWxs IHRoZXNlIGZpZWxkcyBpbiBvcmRlciB0byBidWlsZCB0aGUgZnVsbCBTQ0lNIG9iamVjdCB0byBw YXRjaCBpdC4NCg0KSWYgeW91IGFncmVlIHRoYXQgdGhpcyBpcyBhbiBpc3N1ZSwgd291bGQgaXQg YmUgZmFpciB0byB0cnkgdG8gaW1wcm92ZSB0aGlzIGFyZWEgaW4gdGhlIHNwZWNzPw0KLS0NClJl Z2FyZHMsDQpFbW1hbnVlbCBEcmV1eA0KaHR0cDovL3d3dy5jbG91ZGl3YXkuY29tDQpUZWw6ICsz MyA0IDI2IDc4IDE3IDU4DQpNb2JpbGU6ICszMyA2IDQ3IDgxIDI2IDcwDQpza3lwZTogRW1tYW51 ZWwuRHJldXgNCg0KRGUgOiBDaHJpcyBQaGlsbGlwcyBbbWFpbHRvOkNocmlzLlBoaWxsaXBzQGNh bmFyaWUuY2FdDQpFbnZvecOpIDogamV1ZGkgMTYgYW/Du3QgMjAxMiAyMToyMw0Kw4AgOiBzY2lt QGlldGYub3JnDQpPYmpldCA6IFJlOiBbc2NpbV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAy NA0KDQorMSB0byBQaGlsJ3MgY29tbWVudHMuDQoNCkFzIHdlbGwsIGFkZGluZyBhIGdob3N0IGRp cmVjdG9yeSB0byBbZGV8ZW5dY29kZSB0aGluZ3MgaXMganVzdCB0b28gbXVjaCBvdmVyaGVhZCB0 byBidWlsZCBpbnRvIHRoZSBwcm90b2NvbC4gIElmIHNvbWVvbmUgd2FudHMgdG8gYnVpbGQgdGhh dCBvbiBUT1Agb2YgU0NJTSwgdGhhdCdzIHVwIHRvIHRoZW0uDQoNCldoaWxlIEkgYXBwcmVjaWF0 ZSB0aGUgdGhvdWdodCBhbmQgdGltZSBHYW5lc2ggaGFzIHB1dCBpbnRvIHRoZSBjb25jZXB0cywg SSBhbSBub3QgY29udmluY2VkIHRoZSBhcHByb2FjaCB3b3VsZCBiZSBuZXQgYmV0dGVyIGFuZCBs ZXNzIGNvbXBsZXggYW5kIHNvIGRvIG5vdCBzdXBwb3J0IGl0IGFuZCB3ZWxjb21lIG1vdmluZyBv biB0byBvdGhlciB0b3BpY3MuDQoNCkMuDQoNCkZyb206IFBoaWwgSHVudCA8cGhpbC5odW50QG9y YWNsZS5jb208bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tPj4NCkRhdGU6IFRodXJzZGF5LCAx NiBBdWd1c3QsIDIwMTIgMTo0MiBQTQ0KVG86IEtlbGx5IEdyaXp6bGUgPGtlbGx5LmdyaXp6bGVA c2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPj4NCkNjOiBF bW1hbnVlbCBEcmV1eCA8ZWRyZXV4QGNsb3VkaXdheS5jb208bWFpbHRvOmVkcmV1eEBjbG91ZGl3 YXkuY29tPj4sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0 b255bmFkQG1pY3Jvc29mdC5jb20+PiwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgPGcuYy5wcmFz YWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbT4+LCBNZWxpbmRhIFNob3Jl IDxtZWxpbmRhLnNob3JlQGdtYWlsLmNvbTxtYWlsdG86bWVsaW5kYS5zaG9yZUBnbWFpbC5jb20+ PiwgInNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+IiA8c2NpbUBpZXRmLm9yZzxt YWlsdG86c2NpbUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBW b2wgOCwgSXNzdWUgMjQNCg0KSSBkbyB0aGluayB3ZSBuZWVkIHRvIGFycml2ZSBhdCBzb21lIGNv bnNlbnN1cyBvbiB0aGlzIG5vdyBiZWNhdXNlIEdhbmVzaCdzIHByb3Bvc2FsIGlzIGEgbWFqb3Ig ImZvcmstaW4tdGhlLXJvYWQiIGRlY2lzaW9uLiBJZiB3ZSB0YWJsZSBpdCwgaXQgd2lsbCBiZSBo YXJkIHRvIGNvbWUgYmFjayB0by4gVGhpcyBpcyB3aHkgSSBoYXZlIGVuZ2FnZWQgb24gdGhlIHN1 YmplY3Qgd2l0aCBHYW5lc2ggc28gdGhvcm91Z2hseS4gIE5ldmVyLXRoZS1sZXNzLCBJIHdvdWxk IGxpa2UgdG8gYXJyaXZlIGF0IHNvbWUgY29uY2x1c2lvbnMgaGVyZS4NCg0KTXkgYXBvbG9naWVz LCBidXQgSSB0aG91Z2h0IGl0IHdhcyB3b3J0aCByZS1zdGF0aW5nIHRoZSBwcm9ibGVtIGZvciB0 aG9zZSBsYXRlIHRvIHRoZSBkaXNjdXNzaW9uIHdvdWxkIGJlIHVzZWZ1bC4NCg0KQmFja2dyb3Vu ZDoNCkF0IHByZXNlbnQsIHRoZSBjdXJyZW50IHNwZWMgZG9lcyBub3QgYWxsb3cgeW91IHRvIGNo YW5nZSBhIHNwZWNpZmljIHN1Yi1hdHRyaWJ1dGUgaW4gYSBtdWx0aS12YWx1ZWQgY29tcGxleCBh dHRyaWJ1dGUgc3RydWN0dXJlIChlLmcuIGNoYW5naW5nIHN0cmVldCBuYW1lIGluIGEgc3BlY2lm aWMgYWRkcmVzcyB2YWx1ZSBpbnN0YW5jZSBzdWNoIGFzICJob21lIikuICBUaGUgcHJvcG9zYWwg aXMgdGhhdCBlYWNoIHN1YiBhdHRyaWJ1dGUgaW4gYSBtdWx0aS12YWx1ZWQgc3RydWN0dXJlIGdl dHMgaXRzIG93biB1bmlxdWUgaWRlbnRpZmllci4gIFRoZW4geW91IGNhbiBkaXJlY3RseSByZWZl cmVuY2UgdGhlIHNwZWNpZmljIGNvbXBsZXggYXR0cmlidXRlIGNvbXBvbmVudCBpbiBhIGNvbXBs ZXggdmFsdWUuDQoNClRoZSBjdXJyZW50IGRyYWZ0IHByb3Bvc2FsIHJlcXVpcmVzIHRoYXQgY29t cGxleC12YWx1ZSAoZS5nLiBhbiBhZGRyZXNzIHZhbHVlIHdoaWNoIGlzIG1hZGUgdXAgb2YgbnVt YmVyLCBzdHJlZXQsIGNpdHksIGV0YykgYmUgY2hhbmdlZCBpZiB5b3Ugd2FudCB0byBjaGFuZ2Ug YW55IG9mIHRoZSBzdWItYXR0cmlidXRlcy4gVGhlIGN1cnJlbnQgYXBwcm9hY2ggc2VlbXMgYSBy ZWFzb25hYmxlIGNvbXByb21pc2Ugc2luY2UgaXQgaXMgbGlrZWx5IHRoZSBjb2xsZWN0aW9uIG9m IGF0dHJpYnV0ZXMgaW4gYSBjb21wbGV4ICJ2YWx1ZSIgYXJlIG9mdGVuIG1hbmlwdWxhdGVkIHRv Z2V0aGVyLiBJT1cuIFlvdSB0ZW5kIHRvIHNldCB0aGVtIGFsbCBhdCBvbmNlLiAgR2FuZXNoJ3Mg cHJvcG9zYWwgYWxsb3dzIHNwZWNpZmljIHN1Yi1hdHRyaWJ1dGVzIHRvIGJlIGRpcmVjdGx5IGFk ZHJlc3NhYmxlIGJ5IGdpdmluZyBlYWNoIHZhbHVlIGluc3RhbmNlIGEgdW5pcXVlIGlkZW50aWZp ZXIuDQoNCkFub3RoZXIgZXhhbXBsZSBvZiB0aGlzIGlzIHRoZSBncm91cCAibWVtYmVyIiBhdHRy aWJ1dGUuICBJbiB0aGUgY3VycmVudCBkcmFmdCwgYSBtZW1iZXIgY2FuIGhhdmUgYSB2YWx1ZSBh bmQgYSBkaXNwbGF5IG5hbWUuIEluIHRoaXMgY2FzZSB5b3Ugd291bGQgdXN1YWxseSBjaGFuZ2Ug dGhlIHZhbHVlIChvYmplY3QgaWRlbnRpZmllcikgYW5kIHRoZSBuYW1lIGFzIHdlbGwuICBHYW5l c2gncyBwcm9wb3NhbCB3b3VsZCBhbGxvdyAiRGlzcGxheSBOYW1lIiB0byBiZSBjaGFuZ2VkIG9y IHZhbHVlIHRvIGJlIGNoYW5nZWQuICBTb21ldGhpbmcsIElNViwgdGhhdCBkb2Vzbid0IG9jY3Vy IG5lYXJseSBhcyBvZnRlbi4gIElPVyBtZW1iZXJzIGNoYW5nZSBncm91cCBtZW1iZXJzaGlwLCBi dXQgbWVtYmVycyByYXJlbHkgY2hhbmdlIG5hbWVzLg0KDQpNeSBjb25jbHVzaW9uOg0KSWYgdGhl IGNsaWVudCBtdXN0IGZpcnN0IHF1ZXJ5IChvciBoYXZlIHN5bmNocm9uaXplZCB0aGUgdmFsdWUg aWRlbnRpZmllcnMpLCB0aGVuIHRoZSBjbGllbnQgaGFzIHRvIGRvIGV2ZW4gbW9yZSB3b3JrIHRo YW4gdGhlIGN1cnJlbnQgcHJvcG9zYWwgb2YgcmVwbGFjaW5nIHRoZSBlbnRlciBjb21wbGV4IHZh bHVlLiAgR2l2ZW4gc3VjaCBhIGNob2ljZSBJJ20gcmVhbGx5IHNrZXB0aWNhbCB0aGF0IHRoZSBw YXR0ZXJuIHByb3Bvc2VkIGJ5IEdhbmVzaCB3b3VsZCBiZSB3aWRlbHkgdXNlZC4gIFdoaWxlIEdh bmVzaCdzIHByb3Bvc2FsIG1heSBiZSAic3BlY2lmaWMiLCB0aGUgcHJhY3RpY2FsIHNpbXBsaWNp dHkgb2YgaXQgaXMgdmVyeSBtdWNoIGRlYmF0YWJsZS4NCg0KVGhlIGJlbmVmaXQgb2Ygc3BlY2lm aWMgc3ViLWF0dHJpYnV0ZSBpZGVudGlmaWVycyBuZWVkcyB0byBiZSBzdWJzdGFudGlhbC4gIFdl J3JlIG5vdCBvbmx5IHRhbGtpbmcgYWJvdXQgY2hhbmdpbmcgaG93IGluZnJhc3RydWN0dXJlIGlz IGRvbmUsIGJ1dCBhbHNvIGhvdyBhcHBsaWNhdGlvbnMgYXJlIHdyaXR0ZW4uIFRoaXMgbGVhdmVz IG91dCB0aGUgZW50aXJlIGN1cnJlbnQgYWRvcHRlcnMgYW5kIGFsbCBlbnRlcnByaXNlIHVzZXJz LiAgQSBiaWcgY29uY2VybiB3ZSBoYXZlIG9idmlvdXNseSBpcyB3ZSBoYXZlIHRvIGNvbnNpZGVy IGV4aXN0aW5nIGluZnJhc3RydWN0dXJlIGFuZCBkYXRhIHN0b3JlcyBhbmQgYmUgcmVhbGlzdGlj LiBJIGRvbid0IHRoaW5rIHRoZSBiZW5lZml0IGlzIHdvcnRoIHRoZSBjb3N0Lg0KDQpJIGFncmVl IHdpdGggdGhlIG90aGVycyB0aGF0IHRoZSBjdXJyZW50IGRyYWZ0IGNvdWxkIGJlIGNoYW5nZWQg dG8gbWFrZSBwYXRjaCBvcGVyYXRpb25zIG1vcmUgY2xlYXIgdG8gdGhlIGRldmVsb3BlciAoc2lt cGxlciB0byByZWFkKS4gV2hpbGUgdGhpcyBtYXkgbm90IGltcHJvdmUgbG9naWMsIGl0IHdpbGwg aW1wcm92ZSB1bmRlcnN0YW5kaW5nIGFuZCBzaW1wbGljaXR5LiBUaGUgZmFjdCB0aGF0IGNlcnRh aW4gb3BlcmF0aW9ucyBtYXkgcmVxdWlyZSBhbiBlbnRpcmUgY29tcGxleCBhdHRyaWJ1dGUgdmFs dWUgdG8gYmUgcmVwbGFjZWQgaXMgYSByZWFzb25hYmxlIGNvbXByb21pc2UgYW5kIHNob3VsZCBu b3QgYmUgY2hhbmdlZC4NCg0KUGhpbA0KDQpAaW5kZXBlbmRlbnRpZA0Kd3d3LmluZGVwZW5kZW50 aWQuY29tPGh0dHA6Ly93d3cuaW5kZXBlbmRlbnRpZC5jb20+DQpwaGlsLmh1bnRAb3JhY2xlLmNv bTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIDIwMTItMDgtMTYsIGF0 IDg6NTkgQU0sIEtlbGx5IEdyaXp6bGUgd3JvdGU6DQoNCg0KSGkgR2FuZXNoIOKApiB5b3VyIHdy aXRlLXVwIGNvbmNlZGVzIHRoYXQgdGhpcyB3aWxsIGJlIGRpZmZpY3VsdCB0byBpbXBsZW1lbnQg Zm9yIGFuIGV4aXN0aW5nIHNlcnZpY2UgcHJvdmlkZXIuICBJ4oCZbSBub3Qgc3VyZSB0aGF0IEkg dW5kZXJzdGFuZCB0aGUgY29tcHJvbWlzZS4gIEFyZSB5b3Ugc3RpbGwgc3VnZ2VzdGluZyB0aGF0 IFNDSU0gbW92ZSB0byB0aGUgdW5pcXVlLWtleS1wZXItZWxlbWVudCBzdHJhdGVneT8NCg0KSWYg c28sIHRoZSBjb3N0L2JlbmVmaXQgb2YgdGhpcyBzZWVtcyB3YXkgb2ZmIHRvIG1lLiAgWW91IGFy ZSBnYWluaW5nIGEgbW9yZSBlbGVnYW50IEFQSSBieSBpbnRyb2R1Y2luZyBhbiBhZGRpdGlvbmFs IGRhdGFzdG9yZSBhbmQgcmVxdWlyaW5nIHJlcGxpY2F0aW9uLiAgSSBkb27igJl0IGtub3cgb2Yg YW55IHNlcnZpY2UgcHJvdmlkZXIgdGhhdCB3b3VsZCBtYWtlIHRoaXMgdHJhZGUtb2ZmLiAgQXMg eW91IHNhaWQsIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgZnV0dXJlIHNlcnZpY2UgcHJvdmlkZXJz IGNhbiBrZWVwIGluIG1pbmQsIGJ1dCBpdCBpcyBub3QgZ29pbmcgdG8gaGVscCBleGlzdGluZyBw cm92aWRlcnMuDQoNCi0tS2VsbHkNCg0KRnJvbTogR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgW21h aWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTYsIDIw MTIgNTozOCBBTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IEtlbGx5IEdyaXp6bGU7IEVtbWFu dWVsIERyZXV4OyBNZWxpbmRhIFNob3JlOyBzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPjsgUGhpbCBIdW50DQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwg SXNzdWUgMjQNCg0KSGkgYWxsLA0KDQpXb3VsZCB0aGlzIGh5YnJpZCBhcmNoaXRlY3R1cmUgYmUg YSB3b3JrYWJsZSBjb21wcm9taXNlPyBTZWUgZGlhZ3JhbSB0b3dhcmRzIHRoZSBlbmQ6IGh0dHA6 Ly9iaXQubHkvUmpjMzlZDQoNClJlZ2FyZHMsDQpHYW5lc2gNCk9uIDE1IEF1Z3VzdCAyMDEyIDA1 OjU0LCBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbTxtYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpXZSBzaG91bGQgbm90IGJlIGNvbnN0cmFpbmVkIGJ5 IExEQVAgcmVzdHJpY3Rpb25zLCB0aGlzIHdvdWxkIG5vdCBiZSBwcm9kdWN0aXZlLg0KDQpGcm9t OiBzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZA0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMTMsIDIwMTIgMjowNyBQTQ0KVG86IEtlbGx5IEdyaXp6bGUNCkNjOiBFbW1hbnVlbCBEcmV1 eDsgTWVsaW5kYSBTaG9yZTsgc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz47IFBo aWwgSHVudA0KDQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwgSXNzdWUg MjQNCg0KVGhhbmtzLCBLZWxseS4gWW91J3ZlIGJlZW4gbW9zdCBwYXRpZW50IGluIGhlYXJpbmcg bWUgb3V0LCBJIG11c3Qgc2F5LiBJIGNvdWxkbid0IGFzayBmb3IgbW9yZS4NCg0KUmVwbHlpbmcg dG8gQ2hyaXMgUGhpbGlwcydzIG1haWw6DQo+IEdpdmVuIHRoYXQgeW91IGhhdmUgYSBudW1iZXIg b2YgdGhvdWdodHMgYWJvdXQgd2hhdCBjb3VsZCBiZSBjaGFuZ2VkIGluIFNDSU0sTGVpZidzIHJl Y29tbWVuZGF0aW9uIHRvICBjcmFmdCB0aGVtIGluIGFuIEludGVybmV0IERyYWZ0IG1heSBiZSBh IGJldHRlciB3YXkgdG8gY29udmV5IHlvdXIgdGhvdWdodHMuDQoNCkknbSBjb21pbmcgYXJvdW5k IHRvIHRoZSBzYW1lIGNvbmNsdXNpb24uIERvIHlvdSB0aGluayBzdWNoIGFuIEludGVybmV0IERy YWZ0IHNob3VsZCBiZSBhYm91dCBjaGFuZ2luZyBTQ0lNLCBvciBzaG91bGQgaXQgcHJvcG9zZSBh IGNvbXBsZW1lbnRhcnkgc3BlYyBmb3IgU1BzIHdobyB1c2UgYSAiTm9MREFQIiBkYXRhIHN0b3Jl PyBJIHRoaW5rIHRoZSB1bmRlcmx5aW5nIHByb2JsZW0gaXMgd2l0aCBMREFQLCBhbmQgdW5sZXNz IHdlIGNoYW5nZSB0aGF0LCB0aGVzZSBwcm9wb3NhbHMgd29uJ3QgZmx5Lg0KDQpSZWdhcmRzLA0K R2FuZXNoDQpPbiAxNCBBdWd1c3QgMjAxMiAwMTo1NCwgS2VsbHkgR3JpenpsZSA8a2VsbHkuZ3Jp enpsZUBzYWlscG9pbnQuY29tPG1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20+PiB3 cm90ZToNClRoZXJlIGFyZSByZWFsbHkgdHdvIGltcGxlbWVudGF0aW9uIG9wdGlvbnMgZm9yIGEg dWlkIHBlciBlbGVtZW50IOKAkyBlaXRoZXIgc3RvcmUgdGhlIHVpZHMgaW4gdGhlIG5hdGl2ZSB1 bmRlcmx5aW5nIGRhdGEgc3RvcmUgb3IgaGF2ZSBzb21lIHNlY29uZGFyeSBkYXRhIHN0b3JlIHRo YXQgbWFwcyBlbGVtZW50cyB0byB0aGVpciB1aWRzLiAgVGhlIHRoaXJkIG9wdGlvbiBpcyB0byBo b3BlIHRoYXQgYSBzZXJ2aWNlIHByb3ZpZGVyIGhhcyBhIE5vTERBUCBkYXRhIHN0b3JlIG9yIGl0 cyBlcXVpdmFsZW50LiAgTm9uZSBvZiB0aGVzZSBhcmUgcHJhY3RpY2FsIGZvciByYXBpZCBhbmQg d2lkZS1zcHJlYWQgYWRvcHRpb24uDQoNCj4gcHV0IHRoZSB0d28gdG9nZXRoZXIgdG8gcHJvcG9z ZSBhIHNvbHV0aW9uLg0KDQpBcyBJIHNhaWQgYmVmb3JlLCBJIGFtIGNvbXBsZXRlbHkgb24gYm9h cmQgd2l0aCBjbGVhbmluZyB1cCB0aGUgUEFUQ0ggc2VtYW50aWNzIChlZyDigJMgdGhlIGluY29u c2lzdGVuY3kgYmV0d2VlbiBtZXRhLmF0dHJpYnV0ZXMgYW5kIG9wZXJhdGlvbj1kZWxldGUsIGV0 Y+KApikuICBZb3VyIHN1Z2dlc3Rpb24gb2YgdXNpbmcgZGlmZmVyZW50IHZlcmJzIGlzIGEgZ29v ZCBvcHRpb24gdG8gY29uc2lkZXIuICBUaGlzIGNhbm5vdCBiZSBiYXNlZCBvbiBhIHVpZCBwZXIg ZWxlbWVudCwgdGhvdWdoLiAgSXQgc2VlbXMgYXMgdGhvdWdoIHlvdSBoYXZlIGFkbWl0dGVkIHRo aXMgaW4geW91ciBjb25jbHVzaW9uIOKAkyDigJxBcyBmb3IgTERBUCBhbmQgU0NJTSwgSSBndWVz cyB0aGUgYmVzdCBUTEEgaXMgUklQLuKAnQ0KDQotLUtlbGx5DQoNCkZyb206IEdhbmVzaCBhbmQg U2FzaGkgUHJhc2FkIFttYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb208bWFpbHRvOmcuYy5wcmFz YWRAZ21haWwuY29tPl0NClNlbnQ6IE1vbmRheSwgQXVndXN0IDEzLCAyMDEyIDk6NTYgQU0NClRv OiBLZWxseSBHcml6emxlDQpDYzogUGhpbCBIdW50OyBNZWxpbmRhIFNob3JlOyBFbW1hbnVlbCBE cmV1eDsgc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6 IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0DQoNClRoYXQgd2FzIG9uZSBzdWdn ZXN0aW9uLiBBbm90aGVyIHdheSBjb3VsZCBiZSBjb250YWluZXIgbm9kZXMgd2l0aCB0aGVpciBv d24gImRuInMuIElmIG9uZSBzdWdnZXN0aW9uIHdvbid0IHdvcmssIHRlbGwgbWUgYW5vdGhlciB3 YXkgdG8gbWFrZSBpdCB3b3JrLiBJJ20gd2FpdGluZyB0byBoZWFyIGEgY29uc3RydWN0aXZlIHN1 Z2dlc3Rpb24gdGhhdCBjYW4gc3F1YXJlIGFuIGVsZWdhbnQgQVBJIHdpdGggdGhlIGltcGxlbWVu dGF0aW9uIGNvbnN0cmFpbnRzIHRoYXQgY29tZSBmcm9tIGhhdmluZyB0byBzdG9yZSBtdWx0aS12 YWx1ZWQgYXR0cmlidXRlcyBpbiBMREFQIGRpcmVjdG9yaWVzLg0KDQpJJ3ZlIGhlYXJkIGVub3Vn aCBvZiBXSFkgdGhpcyB3b24ndCB3b3JrLiBGb3IgYSBjaGFuZ2UsIHRlbGwgbWUgSE9XIGl0IGNh biBiZSBtYWRlIHRvIHdvcmsuIEV2ZXJ5b25lIG5vdyBrbm93cyB3aGF0IHRoZSBwcm9wb3NhbCBt ZWFucyBpbiB0ZXJtcyBvZiB0aGUgQVBJLCBhbmQgaW1wbGVtZW50b3JzIHVuZGVyc3RhbmQgdGhl IGNvbnN0cmFpbnRzIG9mIGxlZ2FjeSBkYXRhIHN0b3Jlcywgc28gcHV0IHRoZSB0d28gdG9nZXRo ZXIgdG8gcHJvcG9zZSBhIHNvbHV0aW9uLiBDJ21vbiwgd2UgaGF2ZSB0aGUgInNtYXJ0ZXN0IGd1 eXMgaW4gdGhlIHJvb20iIGhlcmUsIHN1cmVseSB3ZSBzaG91bGQgYmUgYWJsZSB0byBjcmFjayB0 aGlzLg0KDQpSZWdhcmRzLA0KR2FuZXNoDQoNClAuUy4gSSdtIHJhcGlkbHkgcmVhY2hpbmcgbXkg b3duIGNvbmNsdXNpb25zIGFib3V0IHdoYXQgaXMgdG8gYmUgZG9uZToNCmh0dHA6Ly93aXNkb21v ZmdhbmVzaC5ibG9nc3BvdC5jb20uYXUvMjAxMi8wOC9hZnRlci1ub3NxbC1pdHMtdGltZS1mb3It bm9sZGFwLmh0bWwNCg0KT24gMTQgQXVndXN0IDIwMTIgMDA6MjcsIEtlbGx5IEdyaXp6bGUgPGtl bGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQu Y29tPj4gd3JvdGU6DQo+IEFmdGVyIGFsbCwgbm8gb25lIGhhcyBjaGFsbGVuZ2VkIHRoZSBjbGFp bSB0aGF0IHRoaXMgcHJvcG9zYWwgZHJhc3RpY2FsbHkgc2ltcGxpZmllcyB0aGUgQVBJIGZvciB0 aGUgY2xpZW50DQoNCkkgYWdyZWUgdGhhdCB5b3VyIHByb3Bvc2FsIG1ha2VzIFBBVENIIHNlbWFu dGljcyBzaW1wbGVyIGFuZCBtb3JlIGVsZWdhbnQuDQoNCg0KPiDigKYgc28gaXQgd291bGQgYXBw ZWFyIHRvIGJlIHdvcnRoIGRvaW5nLg0KDQpJIHN0cm9uZ2x5IGRpc2FncmVlIGhlcmUuICBUaGlz IHN0YXRlbWVudHMgYXNzdW1lcyB0aGF0IHNpbXBsaWNpdHkgb2YgdGhlIGNsaWVudCBBUEkgaXMg dGhlIG9ubHkgZmFjdG9yIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgd2l0aCB0aGUgc3BlYy4N Cg0KRW1tYW51ZWzigJlzIGV4YW1wbGUgaXMgZnJvbSBhIHJlYWwtd29ybGQgc2VydmljZSBwcm92 aWRlciB0aGF0IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGltcGxlbWVudCB0aGUgc3BlYyBlYXNpbHkg d2l0aCBhIHVpZCBwZXIgZWxlbWVudC4gIEhlIGlzIHdvcmtpbmcgb24gYSBTQ0lNIGludGVyZmFj ZSB0aGF0IHdpbGwgaGVscCBmYWNpbGl0YXRlIGRhdGEgZXhjaGFuZ2UgYmV0d2VlbiBtdWx0aXBs ZSBBY3RpdmUgRGlyZWN0b3J5IHNlcnZlcnMuICBZb3VyIHNvbHV0aW9uIHdhcyB0byBjaGFuZ2Ug dGhlIGRhdGEgbW9kZWwgZnJvbSB0aGlzOg0KDQoNCm1haWw6IGpvaG5fc21pdGhAeWFob28uY29t PG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sIGpvaG4uc21pdGhAZ21haWwuY29tPG1haWx0 bzpqb2huLnNtaXRoQGdtYWlsLmNvbT4sIGpzbWl0aDE5NzBAaG90bWFpbC5jb208bWFpbHRvOmpz bWl0aDE5NzBAaG90bWFpbC5jb20+DQoNCnRvIHRoaXM6DQoNCm1haWw6IGFhNjYtZGFmOWVhM2Jk OTAyPWpvaG5fc21pdGhAeWFob28uY29tPG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sOWNk YS04NjQ2YzMwODViYmY9am9obi5zbWl0aEBnbWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21h aWwuY29tPiwgN2E2ZDFkZTY2NGUxPWpzbWl0aDE5NzBAaG90bWFpbC5jb208bWFpbHRvOmpzbWl0 aDE5NzBAaG90bWFpbC5jb20+DQoNCkkgZG8gbm90IGtub3cgb2YgYSBzaW5nbGUgb3JnYW5pemF0 aW9uIHRoYXQgd291bGQgY2hhbmdlIHRoZWlyIEFjdGl2ZSBEaXJlY3RvcnkgZGF0YSBtb2RlbCB0 byBmaXQgdGhpcy4gIEZvciBvbmUgdGhpbmcsIGl0IHdvdWxkIGJlIGEgaHVnZSBkYXRhIG1pZ3Jh dGlvbiBlZmZvcnQgKGxpa2VseSBhY3Jvc3Mgb3RoZXIgZG9tYWluIGNvbnRyb2xsZXJzLCBldGPi gKYpIHRvIGFzc2lnbiB0aGVzZSB1bmlxdWUgaWRlbnRpZmllcnMuICBUaGlzIGFsc28gYXNzdW1l cyB0aGF0IFNDSU0gaXMgdGhlIG9ubHkgcmVhZGVyL3dyaXRlciBvZiB0aGlzIGRhdGEsIHdoaWNo IHdpbGwgYWxtb3N0IG5ldmVyIGJlIHRoZSBjYXNlLiAgSWYgdGhlIGRhdGEgbW9kZWwgcmVxdWly ZXMgdWlkcyBmb3IgZXZlcnkgZWxlbWVudCwgdGhlbiBldmVyeSBwaWVjZSBvZiBub24tU0NJTSBj b2RlIHRoYXQgd3JpdGVzIGRhdGEgaW50byB0aGUgZGlyZWN0b3J5IHdpbGwgaGF2ZSB0byBmb2xs b3cgdGhpcy4gIEFkZGl0aW9uYWxseSwgdGhlcmUgYXJlICptYW55KiB0b29scyBhbmQgYXBwbGlj YXRpb25zICAoZWcg4oCTIGFkZHJlc3MgYm9va3MpIHRoYXQgcmVseSBvbiBhIGNlcnRhaW4gZGF0 YSBtb2RlbCBpbiBBY3RpdmUgRGlyZWN0b3J5LCBhbmQgdGhpcyB3b3VsZCBjYXVzZSB0aGVtIHRv IGJyZWFrLiAgSU1PIHRoaXMgc2FtZSBhcmd1bWVudCBob2xkcyB0cnVlIGZvciBtb3N0IHNlcnZp Y2UgcHJvdmlkZXJzLg0KDQoNClBBVENIIGlzIGFuIG9wdGlvbmFsIHBhcnQgb2YgdGhlIHNwZWMu ICBJdCB3YXMgcHJpbWFyaWx5IGludHJvZHVjZWQgdG8gbWFrZSBtb2RpZnlpbmcgcmVzb3VyY2Vz IHdpdGggbGFyZ2UgbXVsdGktdmFsdWVkIGxpc3RzIG1vcmUgZWZmaWNpZW50LiAgSXQgZG9lcyBu b3QgbmVlZCB0byBzb2x2ZSBldmVyeSBwcm9ibGVtIChlZyDigJMgbW9kaWZ5aW5nIHN1Yi1lbGVt ZW50cyBpbiBuZXN0ZWQgYXJyYXlzKS4gIEFkZGluZyB1aWRzIHRvIGV2ZXJ5IG11bHRpLXZhbHVl ZCBlbGVtZW50IGRvZXMgbm90IHN0cmlrZSB0aGUgcmlnaHQgYmFsYW5jZSBiZXR3ZWVuIHRoZSBu ZWVkcyBvZiB0aGUgY2xpZW50IGFuZCB0aGUgbmVlZHMgb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIu DQoNCi0tS2VsbHkNCg0KRnJvbTogR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgW21haWx0bzpnLmMu cHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+XQ0KU2VudDogTW9u ZGF5LCBBdWd1c3QgMTMsIDIwMTIgMTozNSBBTQ0KVG86IFBoaWwgSHVudDsgTWVsaW5kYSBTaG9y ZQ0KQ2M6IEVtbWFudWVsIERyZXV4OyBLZWxseSBHcml6emxlOyBzY2ltQGlldGYub3JnPG1haWx0 bzpzY2ltQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wg OCwgSXNzdWUgMjQNCg0KUmVzcG9uZGluZyB0byBleHRyYWN0IG9mIE1lbGluZGEgU2hvcmUncyBt YWlsIGZyb20gZGlnZXN0Og0KDQoNClRoZSBpc3N1ZSBiZWluZyByYWlzZWQgaGVyZSBpc24ndCBl bmRwb2ludCBsb2dpYywgYnV0DQoNCm5ldHdvcmsgdHJhZmZpYywgYW5kIEknbSBwcmV0dHkgc3Vy ZSBpdCdzIG5vdCB2ZXJ5IGhlbHBmdWwgdG8NCg0KcmVzcG9uZCB0byB0aGUgb2JzZXJ2YXRpb24g dGhhdCB5b3VyIG1vZGVsIHJlcXVpcmVzIG1vcmUNCg0KbWVzc2FnZXMgd2l0aCBhIGNvbXBsYWlu dCBhYm91dCB3aGF0IHlvdSBzZWVtIHRvIHRoaW5rIGlzIGENCg0KY29tcGxleCBhbGdvcml0aG0g Zm9yIGF0dHJpYnV0ZSBwcm9jZXNzaW5nLg0KDQpJdCBkZXBlbmRzIG9uIGhvdyBpdCdzIGltcGxl bWVudGVkLiBJJ20gY29uZmlkZW50IHdlIGNhbiBoYXZlIHRoZSBiZXN0IG9mIGJvdGggLSBzaW1w bGUgQVBJIHdpdGggbG93LW92ZXJoZWFkIGltcGxlbWVudGF0aW9uLiBDYW4gd2UgYnJhaW5zdG9y bSBIT1cgdGhpcyBwcm9wb3NhbCBjYW4gYmUgaW1wbGVtZW50ZWQgcmF0aGVyIHRoYW4gV0hZIGl0 IGNhbid0IGJlIGltcGxlbWVudGVkICh3aGljaCBpcyBtb3N0bHkgd2hhdCBJJ3ZlIGJlZW4gaGVh cmluZyBzbyBmYXIpPyBBZnRlciBhbGwsIG5vIG9uZSBoYXMgY2hhbGxlbmdlZCB0aGUgY2xhaW0g dGhhdCB0aGlzIHByb3Bvc2FsIGRyYXN0aWNhbGx5IHNpbXBsaWZpZXMgdGhlIEFQSSBmb3IgdGhl IGNsaWVudCwgc28gaXQgd291bGQgYXBwZWFyIHRvIGJlIHdvcnRoIGRvaW5nLiBJJ20gc3VyZSB0 aGVyZSdzIG1vcmUgdGhhbiBlbm91Z2ggaW50ZWxsZWN0dWFsIGhvcnNlcG93ZXIgaW4gdGhpcyB3 b3JraW5nIGdyb3VwIHRvIHB1bGwgdGhpcyBvZmYgaWYgd2UgcHV0IG91ciBtaW5kcyB0byBpdC4N Cg0KUmVnYXJkcywNCkdhbmVzaA0KDQpPbiAxMyBBdWd1c3QgMjAxMiAxMzo1NCwgR2FuZXNoIGFu ZCBTYXNoaSBQcmFzYWQgPGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2FkQGdt YWlsLmNvbT4+IHdyb3RlOg0KPiBJIHN0cm9uZ2x5IG9iamVjdCB0byBhbnl0aGluZyB0aGF0IGxl YWRzIHRvIGEgcmVhZCBiZWZvcmUgbW9kaWZ5IHJlcXVpcmVtZW50LiBUb28gY29tcGxleCBhbmQg dG9vIGNoYXR0eS4NClNvcnJ5IFBoaWwsIGJ1dCB5b3UncmUgY29udHJhZGljdGluZyB5b3Vyc2Vs ZiBoZXJlLiBUaGVyZSBzZWVtcyB0byBiZSBhbiBhd2Z1bCBsb3Qgb2YgbWF0Y2hpbmcgKGkuZS4s IHJlYWRpbmcpIGdvaW5nIG9uIGluIHRoZSBzcGVjIGFzIGl0IHN0YW5kcywgd2l0aCBpZi10aGVu IGNsYXVzZXMgdG8gZG8gb25lIHRoaW5nIG9yIGFub3RoZXIgaWYgdGhlIG1hdGNoIGVpdGhlciBz dWNjZWVkcyBvciBmYWlscy4gVGhpcyBpcyBhIGNvbXBsZXgsIGNoYXR0eSBwcm90b2NvbCByaWdo dCBub3chDQoNCg0KICAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXM6ICBBbiBhdHRyaWJ1dGUgdmFs dWUgaW4gdGhlIFBBVENIIHJlcXVlc3QNCg0KICAgICAgYm9keSBpcyBhZGRlZCB0byB0aGUgdmFs dWUgY29sbGVjdGlvbiBpZiB0aGUgdmFsdWUgZG9lcyBub3QgZXhpc3QNCg0KICAgICAgYW5kIG1l cmdlZCBpZiBhIG1hdGNoaW5nIHZhbHVlIGlzIHByZXNlbnQuICBWYWx1ZXMgYXJlIG1hdGNoZWQg YnkNCg0KICAgICAgY29tcGFyaW5nIHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIGZyb20gdGhlIFBB VENIIHJlcXVlc3QgYm9keSB0bw0KDQogICAgICB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0 aGUgUmVzb3VyY2UuICBBdHRyaWJ1dGVzIHRoYXQgZG8gbm90DQoNCiAgICAgIGhhdmUgYSB2YWx1 ZSBTdWItQXR0cmlidXRlOyBlLmcuLCBhZGRyZXNzZXMsIG9yIGRvIG5vdCBoYXZlIHVuaXF1ZQ0K DQogICAgICB2YWx1ZSBTdWItQXR0cmlidXRlcyBjYW5ub3QgYmUgbWF0Y2hlZCBhbmQgbXVzdCBp bnN0ZWFkIGJlIGRlbGV0ZWQNCg0KICAgICAgdGhlbiBhZGRlZC4gIFNwZWNpZmljIHZhbHVlcyBj YW4gYmUgcmVtb3ZlZCBmcm9tIGEgUmVzb3VyY2UgYnkNCg0KICAgICAgYWRkaW5nIGFuICJvcGVy YXRpb24iIFN1Yi1BdHRyaWJ1dGUgd2l0aCB0aGUgdmFsdWUgImRlbGV0ZSIgdG8gdGhlDQoNCiAg ICAgIGF0dHJpYnV0ZSBpbiB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5LiAgQXMgd2l0aCBhZGRpbmcv dXBkYXRpbmcNCg0KICAgICAgYXR0cmlidXRlIHZhbHVlIGNvbGxlY3Rpb25zLCB0aGUgdmFsdWUg dG8gZGVsZXRlIGlzIGRldGVybWluZWQgYnkNCg0KICAgICAgY29tcGFyaW5nIHRoZSB2YWx1ZSBT dWItQXR0cmlidXRlIGZyb20gdGhlIFBBVENIIHJlcXVlc3QgYm9keSB0bw0KDQogICAgICB0aGUg dmFsdWUgU3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuICBBdHRyaWJ1dGVzIHRoYXQgZG8g bm90DQoNCiAgICAgIGhhdmUgYSB2YWx1ZSBTdWItQXR0cmlidXRlIG9yIHRoYXQgaGF2ZSBhIG5v bi11bmlxdWUgdmFsdWUgU3ViLQ0KDQogICAgICBBdHRyaWJ1dGUgYXJlIG1hdGNoZWQgYnkgY29t cGFyaW5nIGFsbCBTdWItQXR0cmlidXRlIHZhbHVlcyBmcm9tDQoNCiAgICAgIHRoZSBQQVRDSCBy ZXF1ZXN0IGJvZHkgdG8gdGhlIFN1Yi1BdHRyaWJ1dGUgdmFsdWVzIG9mIHRoZQ0KDQogICAgICBS ZXNvdXJjZS4gIEEgZGVsZXRlIG9wZXJhdGlvbiBpcyBpZ25vcmVkIGlmIHRoZSBhdHRyaWJ1dGUn cyBuYW1lDQoNCiAgICAgIGlzIGluIHRoZSBtZXRhLmF0dHJpYnV0ZXMgbGlzdC4gIElmIHRoZSBy ZXF1ZXN0ZWQgdmFsdWUgdG8gZGVsZXRlDQoNCiAgICAgIGRvZXMgbm90IG1hdGNoIGEgdW5pcXVl IHZhbHVlIG9uIHRoZSBSZXNvdXJjZSB0aGUgc2VydmVyIE1BWQ0KDQogICAgICByZXR1cm4gYSBI VFRQIDQwMCBlcnJvci4NCg0KRm9yIGEgc3BlYyB0aGF0IGlzIHN1cHBvc2VkIHRvIGJlIGFib3V0 IHNpbXBsaWNpdHksIHRoZSBhYm92ZSBkZXNjcmlwdGlvbiBpcyBhbnl0aGluZyBidXQgc2ltcGxl LiBJIGtub3cgeW91IGd1eXMgaGF2ZSB3b3JrZWQgaGFyZCBvbiB0aGlzIGFuZCBJIGRvbid0IG1l YW4gdG8gZGlzcGFyYWdlIHRob3NlIGVmZm9ydHMsIGJ1dCB0aGluayBhYm91dCBob3cgdGhlIGFi b3ZlIHBhc3NhZ2Ugd291bGQgYXBwZWFyIHRvIGEgbmV3IHJlYWRlciAoaS5lLiwgYSBub3ZpY2Ug dG8gdGhlIHNwZWMsIG5vdCBhIHRlY2hub2xvZ3kgbm92aWNlKS4NCg0KVGhlcmUgaXMgc29tZXRo aW5nIGZ1bmRhbWVudGFsbHkgYnJva2VuLCBhbmQgaXQgaXMgdGhpczogbXVsdGktdmFsdWVkIGF0 dHJpYnV0ZXMgd2l0aG91dCBhIHVuaXF1ZSBpZGVudGlmaWVyIHBlciB2YWx1ZS4gSWYgeW91IGRv bid0IGZpeCB0aGF0LCB5b3Ugd29uJ3QgZ2V0IHNpbXBsaWNpdHkuDQoNCldlIGtub3cgTERBUCB0 cmVlcyBhcmUgYnJva2VuIGZvciBtdWx0aS12YWx1ZWQgYXR0cmlidXRlcy4gQXMgTWFyayBXYWhs IGZhbW91c2x5IGNvbW1lbnRlZDxodHRwOi8vd3d3LmxkYXAuY29tLzEvY29tbWVudGFyeS93YWhs LzIwMDUwNjE3XzAxLnNodG1sPiBiYWNrIGluIDIwMDUsDQoNCiJVbmZvcnR1bmF0ZWx5LCBzb21l IG9mIHRoZSBlbWVyZ2luZyBwcm90b2NvbHMgd2hpY2ggYWxzbyBpbnRlbmQgdG8gcmVwcmVzZW50 IGFuZCB0cmFuc2ZlciBwZXJzb25hbCBpZGVudGl0eSBpbmZvcm1hdGlvbiBoYXZlIHBlcmhhcHMg dGFrZW4gYSBzdGVwIGJhY2t3YXJkcyBieSBub3QgZXZlbiBjb25zaWRlcmluZyB0aGVzZSBpc3N1 ZXMsIHBlcmhhcHMgc3dlZXBpbmcgdGhlbSB1bmRlciB0aGUgcnVnIGluIHRoZSBndWlzZSBvZiBz aW1wbGljaXR5LCBYTUxpZmljYXRpb24sIG9yICJmaXggaW4gdGhlIG5leHQgdmVyc2lvbiIsIHdo aWNoIG9ubHkgcG9zdHBvbmUgZmluZGluZyBpbnRlcm9wZXJhYmxlIHNvbHV0aW9ucyB0byBhbGxv d2luZyBhcHBsaWNhdGlvbnMgdG8gZXhwcmVzcyB0aGUgaWRlbnRpdHkgZW50cmllcyB0aGV5IHdh bnQgdG8gZXhwcmVzcy4iDQoNClNDSU0gaXMgZXhhY3RseSBvbmUgb2YgdGhlc2UgImVtZXJnaW5n IHByb3RvY29scyIgV2FobCB0YWxrcyBhYm91dCwgYW5kIHdoYXQgSSBzZWUgbm93IHN0cmlrZXMg bWUgYXMgInN3ZWVwaW5nIHRoZXNlIGlzc3VlcyB1bmRlciB0aGUgcnVnIGluIHRoZSBndWlzZSBv ZiBzaW1wbGljaXR5Ii4gQXBvbG9naWVzIGZvciB0aGUgYmx1bnRuZXNzLg0KDQpNeSB0YWtlIGlz IHRoYXQgU1BzIGFyZSBfYWxyZWFkeV8gc3RydWdnbGluZyB0byBtYW5hZ2UgbXVsdGktdmFsdWVk IGF0dHJpYnV0ZXMsIGFuZCBleGlzdGluZyBtZWNoYW5pc21zIGFyZSBjbHVtc3k8aHR0cDovL2Zm MTk1OS53b3JkcHJlc3MuY29tLzIwMTEvMDcvMjgvcmVwbGFjZS1hLXZhbHVlLW9mLWEtbXVsdGkt dmFsdWVkLWF0dHJpYnV0ZS8+LiBUaGV5IHdvdWxkIGJlIGdyYXRlZnVsIGZvciBhIHNwZWNpZmlj YXRpb24gdGhhdCBtYWRlIG9wZXJhdGlvbnMgZWFzaWVyIGF0IHRoZSBjb3N0IG9mIGEgcmUtZW5n aW5lZXJlZCBzY2hlbWEuIFRoYXQgY2FsbHMgZm9yIHNvbWUgdGhvdWdodCBsZWFkZXJzaGlwIGZy b20gdGhpcyB3b3JraW5nIGdyb3VwLg0KDQpSZWdhcmRzLA0KR2FuZXNoDQoNCk9uIDEzIEF1Z3Vz dCAyMDEyIDEwOjEzLCBQaGlsIEh1bnQgPHBoaWwuaHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGls Lmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KSSBzdHJvbmdseSBvYmplY3QgdG8gYW55dGhpbmcg dGhhdCBsZWFkcyB0byBhIHJlYWQgYmVmb3JlIG1vZGlmeSByZXF1aXJlbWVudC4gVG9vIGNvbXBs ZXggYW5kIHRvbyBjaGF0dHkuDQoNClBoaWwNCg0KT24gMjAxMi0wOC0xMiwgYXQgMTU6MjksIEdh bmVzaCBhbmQgU2FzaGkgUHJhc2FkIDxnLmMucHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnBy YXNhZEBnbWFpbC5jb20+PiB3cm90ZToNCj4gV291bGQgaXQgaGF2ZSB0byBiZSBzdG9yZWQgb24g dGhlIGFjY291bnQgZGF0YWJhc2Ugb2YgdGhlIHNlcnZpY2UgcHJvdmlkZXI/DQoNClllcy4NCg0K PiBJZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbXByYWN0aWNhYmxlIGluIHRoZSBjb3Jl IHNjaGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhhdCBhIHNlcnZpY2UgcHJvdmlkZXIgbXVzdCBl eHRlbmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCByZXBvc2l0b3J5IChMREFQIHBhcnRpdGlv biwgU1FMIGRiLCDigKYpIGFuZCDigJxwcmVwYXJlIGl04oCdIGZvciBTQ0lNIGludGVncmF0aW9u Lg0KDQpXaHk/IFRoYXQgZG9lc24ndCBuZWNlc3NhcmlseSBmb2xsb3cuIEltcGxlbWVudGF0aW9u IGlzIGluZGVwZW5kZW50IG9mIHJlcHJlc2VudGF0aW9uLiBXZSdyZSB0YWxraW5nIGFib3V0IGEg Y2hhbmdlIGluIHJlcHJlc2VudGF0aW9uIHRvIG1ha2UgdGhlIEFQSSBjbGVhbmVyLg0KDQpBcyBh IHNpbXBsZSBleGFtcGxlLCBpZiBhbiBMREFQIG5vZGUgaXMgYmVpbmcgdXNlZCB0byBob2xkIGEg bGlzdCBvZiBjb21tYS1zZXBhcmF0ZWQgZW1haWwgYWRkcmVzc2VzLCBpdCBjYW4ganVzdCBhcyBl YXNpbHkgc3RvcmUgY29tbWEtc2VwYXJhdGVkIG5hbWUtdmFsdWUgcGFpcnMuDQoNCg0KbWFpbDog am9obl9zbWl0aEB5YWhvby5jb208bWFpbHRvOmpvaG5fc21pdGhAeWFob28uY29tPiwgam9obi5z bWl0aEBnbWFpbC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tPiwganNtaXRoMTk3MEBo b3RtYWlsLmNvbTxtYWlsdG86anNtaXRoMTk3MEBob3RtYWlsLmNvbT4NCmNhbiBiZSBjaGFuZ2Vk IHRvDQoNCm1haWw6IGFhNjYtZGFmOWVhM2JkOTAyPWpvaG5fc21pdGhAeWFob28uY29tPG1haWx0 bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4sOWNkYS04NjQ2YzMwODViYmY9am9obi5zbWl0aEBnbWFp bC5jb208bWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tPiwgN2E2ZDFkZTY2NGUxPWpzbWl0aDE5 NzBAaG90bWFpbC5jb208bWFpbHRvOmpzbWl0aDE5NzBAaG90bWFpbC5jb20+DQoNClRoYXQncyB3 aHkgSSBhc2tlZCBpZiB0aGVyZSB3YXMgYW4gU1AgcmVwcmVzZW50YXRpdmUgb24gdGhpcyB3b3Jr aW5nIGdyb3VwIHdobyBjb3VsZCBleHBsYWluIHdoYXQgc3VjaCBhIGNoYW5nZSBjb3VsZCBtZWFu IGZvciB0aGVtLiBBcyBvZiBub3csIGl0IGxvb2tzIGxpa2Ugb3RoZXIgcGVvcGxlIGFyZSBwcmVz dW1pbmcgdGhhdCBTUHMgd2lsbCBub3QgYmUgYWJsZSB0byBpbXBsZW1lbnQgdGhlc2UgY2hhbmdl cyBlYXNpbHkgYW5kIGFyZSByZWplY3RpbmcgdGhlbSBmb3IgdGhhdCByZWFzb24uDQoNClJlZ2Fy ZHMsDQpHYW5lc2gNCg0KT24gMTMgQXVndXN0IDIwMTIgMDQ6MjksIEVtbWFudWVsIERyZXV4IDxl ZHJldXhAY2xvdWRpd2F5LmNvbTxtYWlsdG86ZWRyZXV4QGNsb3VkaXdheS5jb20+PiB3cm90ZToN Cg0KPT4gIGFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9ICIyNDMiDQoNCldo ZXJlIHdvdWxkIDNjYmFhZmY4ZTg0ZSBjb21lIGZyb20/IFdvdWxkIGl0IGhhdmUgdG8gYmUgc3Rv cmVkIG9uIHRoZSBhY2NvdW50IGRhdGFiYXNlIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyPw0KDQpJ ZiBzbywgSSBiZWxpZXZlIHRoYXQgdGhpcyBpcyBpbXByYWN0aWNhYmxlIGluIHRoZSBjb3JlIHNj aGVtYS4gSW5kZWVkIGl0IGltcGxpZXMgdGhhdCBhIHNlcnZpY2UgcHJvdmlkZXIgbXVzdCBleHRl bmQgdGhlIHNjaGVtYSBvZiBoaXMgYWNjb3VudCByZXBvc2l0b3J5IChMREFQIHBhcnRpdGlvbiwg U1FMIGRiLCDigKYpIGFuZCDigJxwcmVwYXJlIGl04oCdIGZvciBTQ0lNIGludGVncmF0aW9uLg0K VGhpcyB3b3VsZCBiZSBhIHNob3cgc3RvcHBlci4gU0NJTSBtdXN0IGJlIHRyYW5zcGFyZW50LCBh bmQgbXVzdCBiZSBhYmxlIHRvIGJlIHB1dCBvbiB0b3Agb2YgYW4gZXhpc3Rpbmcgc3lzdGVtIHRv IHByb3ZpZGUgcHJvdmlzaW9uaW5nIGFwaXMuDQoNClNhaWQgZGlmZmVyZW50bHksIFNDSU0gbXVz dCBub3QgYmUgaW50cnVzaXZlIGZvciBleGlzdGluZyBzeXN0ZW1zIGFuZCBtdXN0IG5vdCByZXF1 aXJlIG1vZGlmaWNhdGlvbnMgdG8gYWxsb3cgaXRzIGludGVncmF0aW9uLg0KQ29ycmVjdCBtZSBp ZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBzdWdnZXN0aW9uLg0KDQotLQ0KUmVnYXJkcywNCkVtbWFu dWVsIERyZXV4DQpodHRwOi8vd3d3LmNsb3VkaXdheS5jb208aHR0cDovL3d3dy5jbG91ZGl3YXku Y29tLz4NClRlbDogKzMzIDQgMjYgNzggMTcgNTg8dGVsOiUyQjMzJTIwNCUyMDI2JTIwNzglMjAx NyUyMDU4Pg0KTW9iaWxlOiArMzMgNiA0NyA4MSAyNiA3MDx0ZWw6JTJCMzMlMjA2JTIwNDclMjA4 MSUyMDI2JTIwNzA+DQpza3lwZTogRW1tYW51ZWwuRHJldXgNCg0KRGUgOiBHYW5lc2ggYW5kIFNh c2hpIFByYXNhZCBbbWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpnLmMucHJhc2Fk QGdtYWlsLmNvbT5dDQpFbnZvecOpIDogZGltYW5jaGUgMTIgYW/Du3QgMjAxMiAwNDo1Mw0Kw4Ag OiBLZWxseSBHcml6emxlDQpDYyA6IHNjaW1AaWV0Zi5vcmc8bWFpbHRvOnNjaW1AaWV0Zi5vcmc+ OyBQaGlsIEh1bnQNCk9iamV0IDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3Vl IDI0DQoNCj4gIE11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIHRoYXQgZG9uJ3QgaGF2ZSBhIHZhbHVl IHN1Yi1hdHRyaWJ1dGUgKGVnIC0gYWRkcmVzcykgaGF2ZSB0byBzcGVjaWZpZWQgY29tcGxldGVs eSBmb3IgdW5pcXVlbmVzcy4NCg0KVGhhdCdzIGV4YWN0bHkgdGhlIHBvaW50LiBIb3cgZG8gd2Ug InNwZWNpZnkgY29tcGxldGVseSBmb3IgdW5pcXVlbmVzcyI/DQoNCkluIHRoZSBleGFtcGxlIGJl bG93LCBob3cgYXJlIHlvdSBwcm9wb3NpbmcgdGhhdCB0aGUgZm9sbG93aW5nIGVsZW1lbnQgYmUg dXBkYXRlZCBpZiB3ZSBjYW4ndCB1c2UgcG9zaXRpb25hbCBpbmRleGVzPw0KDQphZGRyZXNzZXNb MV0uc3RyZWV0LW51bWJlciA9ICIyNDMiDQoNClVzZXIgb2JqZWN0Og0KDQp7DQogIC4uLg0KICBh ZGRyZXNzZXM6IFsNCiAgICB7DQogICAgICAidHlwZSIgOiAiaG9tZSIsDQogICAgICAic3RyZWV0 LW51bWJlciIgOiAiMzUiLA0KICAgICAgInN0cmVldC1uYW1lIiA6ICJIaWdoIFJvYWQiLA0KICAg ICAgInN1YnVyYiIgOiAiRWFzdCBDYW1kZW4iLA0KICAgICAgInBvc3Rjb2RlIiA6ICI1MzQ2IiwN CiAgICAgICJzdGF0ZSIgOiAiU0EiLA0KICAgICAgImNvdW50cnkiIDogIkF1c3RyYWxpYSINCiAg ICB9LA0KICAgIHsNCiAgICAgICJ0eXBlIiA6ICJvZmZpY2UiLA0KICAgICAgInN0cmVldC1udW1i ZXIiIDogIjIxMyIsDQogICAgICAic3RyZWV0LW5hbWUiIDogIk1haW4gU3RyZWV0IiwNCiAgICAg ICJzdWJ1cmIiIDogIkFkZWxhaWRlIiwNCiAgICAgICJwb3N0Y29kZSIgOiAiNTAwMCIsDQogICAg ICAic3RhdGUiIDogIlNBIiwNCiAgICAgICJjb3VudHJ5IiA6ICJBdXN0cmFsaWEiDQogICAgfQ0K ICBdDQp9DQoNCkl0J3MgaW1wcmFjdGljYWwgdG8gdXNlIHRoZSB2YWx1ZSBiZWNhdXNlIGl0J3Mg dGhlIHdob2xlIGRpY3Rpb25hcnkgZWxlbWVudDoNCg0Kew0KICAidHlwZSIgOiAib2ZmaWNlIiwN CiAgInN0cmVldC1udW1iZXIiIDogIjIxMyIsDQogICJzdHJlZXQtbmFtZSIgOiAiTWFpbiBTdHJl ZXQiLA0KICAic3VidXJiIiA6ICJBZGVsYWlkZSIsDQogICJwb3N0Y29kZSIgOiAiNTAwMCIsDQog ICJzdGF0ZSIgOiAiU0EiLA0KICAiY291bnRyeSIgOiAiQXVzdHJhbGlhIg0KfQ0KDQpXaXRoIG15 IHByb3Bvc2FsLCB0aGUgImFkZHJlc3NlcyIgYXJyYXkgZ2V0cyBjb252ZXJ0ZWQgdG8gYSBkaWN0 aW9uYXJ5LCBhbmQgdGhlbiB3ZSBoYXZlIGEgc3RhYmxlIHdheSBvZiByZWZlcmVuY2luZyB0aGlz IGVsZW1lbnQ6DQoNCmFkZHJlc3Nlcy4zY2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9ICIyNDMi DQoNCnsNCiAgLi4uDQogIGFkZHJlc3Nlczogew0KICAgICJkNmVhMzY1NDYyZjUiIDoNCiAgICB7 DQogICAgICAidHlwZSIgOiAiaG9tZSIsDQogICAgICAic3RyZWV0LW51bWJlciIgOiAiMzUiLA0K ICAgICAgInN0cmVldC1uYW1lIiA6ICJIaWdoIFJvYWQiLA0KICAgICAgInN1YnVyYiIgOiAiRWFz dCBDYW1kZW4iLA0KICAgICAgInBvc3Rjb2RlIiA6ICI1MzQ2IiwNCiAgICAgICJzdGF0ZSIgOiAi U0EiLA0KICAgICAgImNvdW50cnkiIDogIkF1c3RyYWxpYSINCiAgICB9LA0KICAgICIzY2JhYWZm OGU4NGUiIDoNCiAgICB7DQogICAgICAidHlwZSIgOiAib2ZmaWNlIiwNCiAgICAgICJzdHJlZXQt bnVtYmVyIiA6ICIyMTMiLA0KICAgICAgInN0cmVldC1uYW1lIiA6ICJNYWluIFN0cmVldCIsDQog ICAgICAic3VidXJiIiA6ICJBZGVsYWlkZSIsDQogICAgICAicG9zdGNvZGUiIDogIjUwMDAiLA0K ICAgICAgInN0YXRlIiA6ICJTQSIsDQogICAgICAiY291bnRyeSIgOiAiQXVzdHJhbGlhIg0KICAg IH0NCiAgfQ0KfQ0KDQpJZiB5b3UncmUgcHJvcG9zaW5nIG9uZSBtZWNoYW5pc20gZm9yIGNvbXBv c2l0ZSBhdHRyaWJ1dGVzIGFuZCBhbm90aGVyIG1lY2hhbmlzbSBmb3Igc2ltcGxlIGF0dHJpYnV0 ZXMsIEkgd291bGQgc3VnZ2VzdCB0aGF0J3MgYWN0dWFsbHkgbW9yZSBjb21wbGV4IHRoYW4gYWRv cHRpbmcgYSBzaW5nbGUgbWVjaGFuaXNtIHRoYXQgd29ya3MgdGhlIHNhbWUgd2F5IGZvciBfYWxs XyBhdHRyaWJ1dGVzLiBSZW1lbWJlciB0aGF0IGEgbG90IG9mIHRoZSBhZG1pbmlzdHJhdGlvbiBp cyBwcm9iYWJseSBnb2luZyB0byBiZSBzY3JpcHRlZCByYXRoZXIgdGhhbiBkb25lIGJ5IGhhbmQs IGFuZCBoYXZpbmcgdHdvIG1lY2hhbmlzbXMgKGRlcGVuZGluZyBvbiB3aGV0aGVyIHRoZSBhdHRy aWJ1dGUgaXMgc2ltcGxlIG9yIGNvbXBvc2l0ZSkgd2lsbCBjb21wbGljYXRlIGV2ZXJ5IHNjcmlw dCB0aGF0IGhhcyB0byBiZSB3cml0dGVuLg0KDQpUaGVyZSdzIGEgbG90IG9mIHRhbGsgYWJvdXQg dGhlICJidXJkZW4iIG9uIHRoZSBTUHMsIGJ1dCBJIGJlbGlldmUgdGhpcyBpcyBvdmVyYmxvd24u IElzIHRoZXJlIGFueSBTUCByZXByZXNlbnRhdGl2ZSBpbiB0aGlzIFdHIHdobyBjYW4gdGVsbCB1 cyB3aGF0IHRoaXMgcHJvcG9zYWwgd2lsbCBhY3R1YWxseSBlbnRhaWwgZm9yIHRoZW0/DQoNClJl Z2FyZHMsDQpHYW5lc2gNCg0KT24gMTIgQXVndXN0IDIwMTIgMTE6NTMsIEtlbGx5IEdyaXp6bGUg PGtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTxtYWlsdG86a2VsbHkuZ3JpenpsZUBzYWlscG9p bnQuY29tPj4gd3JvdGU6DQpHYW5lc2gsDQoNClRoaXMgaXMgZXhhY3RseSBob3cgUEFUQ0ggd29y a3MgaW4gU0NJTSAxLjAuICBNdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB0aGF0IGhhdmUgYSB2YWx1 ZSBzdWItYXR0cmlidXRlIGNhbiBiZSByZW1vdmVkIGJ5IHNwZWNpZnlpbmcgb25seSB0aGUgdmFs dWUgc2luY2UgaXQgaXMgdW5pcXVlLiAgTXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBkb24n dCBoYXZlIGEgdmFsdWUgc3ViLWF0dHJpYnV0ZSAoZWcgLSBhZGRyZXNzKSBoYXZlIHRvIHNwZWNp ZmllZCBjb21wbGV0ZWx5IGZvciB1bmlxdWVuZXNzLiAgQXMgSSBoYXZlIHNhaWQgYmVmb3JlLCBJ IGFtIHZlcnkgb3Bwb3NlZCB0byBhZGRpbmcgYSB1bmlxdWUgaWRlbnRpZmllciB0byBlYWNoIGVs ZW1lbnQgaW4gYSBtdWx0aS12YWx1ZWQgY29sbGVjdGlvbiBkdWUgdG8gdGhlIGJ1cmRlbiBpdCB3 aWxsIHB1dCBvbiBTUHMuICBJcyBpdCBlbGVnYW50PyAgTm8uICBJcyBpdCBmdW5jdGlvbmFsPyAg WWVzLiAgV2lsbCB0aGlzIG5vbi1lbGVnYW5jZSBhZmZlY3QgYWRvcHRpb24/ICBNeSBvcGluaW9u IGlzIHRoYXQgYWRkaW5nIHVuaXF1ZSBrZXlzIHRvIGVhY2ggZWxlbWVudCB3aWxsIGhhdmUgYSBt dWNoIG1vcmUgZGV0cmltZW50YWwgZWZmZWN0IG9uIGFkb3B0aW9uLg0KDQpJIGRvIGJlbGlldmUg dGhhdCBpbiBnZW5lcmFsIFBBVENIIGNhbiBiZSBtYWRlIG1vcmUgaW50dWl0aXZlIHdpdGhvdXQg YWRkaW5nIHVpZHMgdG8gZWFjaCBlbGVtZW50LiAgVGhlIHZlcmJzIHRoYXQgeW91IHByb3Bvc2Ug bWFrZSBzZW5zZS4gIFRoZXJlIGlzIGFsc28gYSBKU09OIFBhdGNoIGluZm9ybWF0aW9uYWwgZHJh ZnQgaW4gdGhlIElFVEYgdGhhdCBpcyBpbnRlcmVzdGluZyAtIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTAyLiAgSXQgcmVsaWVzIG9uIGEg SlNPTiBQb2ludGVyIGRyYWZ0IHdoaWNoIHVzZXMgaW5kZXgtYmFzZWQgYWRkcmVzc2luZyBmb3Ig bXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMuICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBzb21ldGhpbmcg dGhhdCBzaG91bGQgYmUgbG9va2VkIGF0IHdpdGhpbiB0aGUgV0cgYW5kIEkgd291bGQgYmUgd2ls bGluZyB0byBsZWFkIHRoaXMgZWZmb3J0Lg0KDQpJJ20gY3VyaW91cyBpZiBhbnlvbmUgZWxzZSBp biB0aGUgV0cgaXMgaW4gZmF2b3Igb2YgdW5pcXVlIGlkZW50aWZpZXJzIGZvciBldmVyeSBtdWx0 aS12YWx1ZWQgZWxlbWVudC4NCg0KLS1LZWxseQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRnJvbTogc2NpbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzY2ltLWJvdW5jZXNA aWV0Zi5vcmc+IFtzY2ltLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tYm91bmNlc0BpZXRm Lm9yZz5dIG9uIGJlaGFsZiBvZiBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCBbZy5jLnByYXNhZEBn bWFpbC5jb208bWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tPl0NClNlbnQ6IFNhdHVyZGF5LCBB dWd1c3QgMTEsIDIwMTIgMTA6NTAgQU0NClRvOiBQaGlsIEh1bnQNCkNjOiBzY2ltQGlldGYub3Jn PG1haWx0bzpzY2ltQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwg Vm9sIDgsIElzc3VlIDI0DQpQaGlsLA0KDQpUaGUgcmVhc29uIHdlIGNhbm5vdCB1c2UgdGhlIHZh bHVlIGl0c2VsZiB0byBpZGVudGlmeSBhbiBlbGVtZW50IGlzIHRoYXQgdGhpcyBtZXRob2Qgd2ls bCBvbmx5IHdvcmsgZm9yIHNpbXBsZSBlbGVtZW50cywgbm90IGZvciBuZXN0ZWQgc3RydWN0dXJl cy4gaS5lLiwgaWYgd2UgaGFkIGFuIGFycmF5IG9mIGRpY3Rpb25hcmllcyAoZS5nLiwgd2UgaGFk IHRvIHJlY29yZCBhbiBhcnJheSBvZiBhZGRyZXNzZXMgZm9yIGVhY2ggY3VzdG9tZXIsIHdpdGgg ZWFjaCBhZGRyZXNzIGVsZW1lbnQgaGF2aW5nIHN1Yi1lbGVtZW50cyBsaWtlIHN0cmVldCBudW1i ZXIsIHN0cmVldCBuYW1lLCBzdWJ1cmIsIGV0Yy4pLCB0aGVuIGl0IHdvdWxkIGJlIGNsdW1zeSB0 byBzdXBwbHkgdGhlIGVudGlyZSB2YWx1ZSBvZiB0aGUgYXJyYXkgZWxlbWVudCBiZWNhdXNlIGl0 J3MgaXRzZWxmIGEgZGljdGlvbmFyeS4gQ3JlYXRpbmcgYSB1bmlxdWUga2V5IGZvciBlYWNoIGVs ZW1lbnQgc2NhbGVzIGJldHRlci4NCg0KUmVnYXJkcywNCkdhbmVzaA0KT24gMTIgQXVndXN0IDIw MTIgMDE6MTIsIFBoaWwgSHVudCA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQpHYW5lc2gsDQoNCkhlcmUncyB0aGUgc2FtcGxlIHRoYXQg Y29uY2VybmVkIG1lLi4uDQpUaGUgdHdvIG9wZXJhdGlvbnMgZGlmZmVyIHNpZ25pZmljYW50bHks IGFuZCBpdCdzIG5vdCB2ZXJ5IGludHVpdGl2ZS4NCldpdGggbXkgc3VnZ2VzdGlvbiwgaGVyZSdz IGhvdyB0byBkZWxldGUgYSBzaW5nbGUgbWVtYmVyIGZyb20gYSBncm91cDoNCg0KUEFUQ0ggL0dy b3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRmZC05YjRkYTNmOTA4Y2UgSG9zdDogZXhhbXBsZS5j b208aHR0cDovL2V4YW1wbGUuY29tLz4gQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uIEF1dGhvcml6 YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDggRVRhZzogVy8iYTMzMGJjNTRmMDY3MWM5IiB7DQoi b3BlcmF0aW9ucyIgOiBbDQp7DQoiUkVUSVJFIiA6IHsNCiJrZXkiIDogIm1lbWJlcnMuMjgxOWMy MjMtN2Y3Ni00NTNhLTkxOWQtNDEzODYxOTA0NjQ2Ig0KfQ0KfQ0KXSB9DQoNCg0KWW91IGdhdmUg b3RoZXIgZXhhbXBsZXMgb2YgYW4gYXR0cmlidXRlIHdpdGggYW4gaWRlbnRpZmllciB0aGF0IG1h dGNoZWQgdGhhdCB2YWx1ZSBvciBvZiBpZGVudGlmaWVycyB0aGF0IHdlcmUgYWRkaXRpb25hbCB1 bmlxdWUga2V5cy4NCg0KR2l2ZW4gdGhhdCBtdWx0aS12YWx1ZXMgbXVzdCBiZSBlYWNoIHVuaXF1 ZSwgSSBkb24ndCBzZWUgdGhlIHBvaW50IG9mIHRoZSBleHRyYSBpbmRleGluZyB0byBzdXBwb3J0 IHRoaXMuIEp1c3QgdXNlIHRoZSB2YWx1ZSBhcyB0aGUgaXRlbSB5b3Ugd2lzaCB0byBkZWxldGUu DQoNCkkgYWdyZWUsIHRoZSBkZWxldGUgdmFsdWUgb3BlcmF0aW9uIGNvdWxkIGJlIG1vcmUgZXhw bGljaXQgYW5kIGNsZWFyIGluIGdlbmVyYWwuDQoNClBoaWwNCg0KQGluZGVwZW5kZW50aWQNCnd3 dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLz4NCnBoaWwu aHVudEBvcmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4NCg0KDQoNCk9uIDIw MTItMDgtMTEsIGF0IDI6MzAgQU0sIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIHdyb3RlOg0KDQo+ ICBGb3IgdGhlIG11bHRpLXZhbHVlIGV4YW1wbGUgeW91IGdhdmUgeW91IHVzZWQgdGhlIHZhbHVl IGFzIHRoZSBhdHRyaWJ1dGUgbmFtZSBrZXkuDQoNCk5vdyBJJ20gY29uZnVzZWQgOi0pLiBJIGRv bid0IGJlbGlldmUgYW55IG9mIG15IGV4YW1wbGVzIGV2ZXIgdXNlZCBhIHZhbHVlIGFzIHRoZSBr ZXkuDQoNCkNvdWxkIHlvdSBwbGVhc2Ugc2hvdyBtZSB3aGljaCBleGFtcGxlIHlvdSBtZWFuLCBh bmQgd2hpY2ggcGFydHMgb2YgaXQgeW91IGJlbGlldmUgdG8gYmUgdGhlIHZhbHVlPw0KDQpSZWdh cmRzLA0KR2FuZXNoDQpPbiAxMSBBdWd1c3QgMjAxMiAxMzo1OSwgUGhpbCBIdW50IDxwaGlsLmh1 bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCg0KRm9y IHRoZSBtdWx0aS12YWx1ZSBleGFtcGxlIHlvdSBnYXZlIHlvdSB1c2VkIHRoZSB2YWx1ZSBhcyB0 aGUgYXR0cmlidXRlIG5hbWUga2V5Lg0KDQpUaGF0IG1lYW5zIGEgbG90IG1vcmUgY29tcGxleCBp bmRleGluZyBzdHJ1Y3R1cmUuIEJldHRlciB0byBqdXN0IHNheSBkZWxldGUgYSBzcGVjaWZpYyB2 YWx1ZS4NCg0KVGhlIHNwZWMgYWxyZWFkeSBhbGxvd3MgbXVsdGlwbGUgdmFsdWVzIHRvIGhhdmUg dGFncyBsaWtlIGhvbWUsIHdvcmssIGV0Yy4NCg0KUGhpbA0KDQpPbiAyMDEyLTA4LTEwLCBhdCAy MTo0NSwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgPGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0 bzpnLmMucHJhc2FkQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBJbiB5b3VyIGV4YW1wbGUgeW91IGFy ZSBjb25mbGF0aW5nIHZhbHVlIHdpdGggYW4gYXR0cmlidXRlIGlkLg0KDQpJIGRvbid0IGJlbGll dmUgc28uDQoNCkknbSBhZG9wdGluZyBhIG1vZGVsIHdoZXJlIGV2ZXJ5IGF0dHJpYnV0ZSBvZiB0 aGUgcmVzb3VyY2UgaXMgYSBrZXktdmFsdWUgcGFpci4gVGhlIGtleSBpcyBhIG5hbWUgb3IgSUQu DQoNCkZvciBub24tcmVwZWF0aW5nIGF0dHJpYnV0ZXMgKGJvdGggc2ltcGxlIGFuZCBjb21wb3Np dGUpLCB0aGUga2V5IGlzIHRoZSBhdHRyaWJ1dGUgbmFtZSBpdHNlbGYuDQoNClNpbXBsZSBhdHRy aWJ1dGU6DQoNCktleTogImRvYiINClZhbHVlOiAiMDEgSmFuIDE5NzAiDQoNCkZvciBjb21wb3Np dGUgYXR0cmlidXRlcywgdGhlIGtleSBlbXBsb3lzIGRvdCBub3RhdGlvbiB0byBzcGVjaWZ5IHRo ZSBmdWxseS1xdWFsaWZpZWQgYXR0cmlidXRlIG5hbWUsIGUuZy4sICJhZGRyZXNzLnBvc3Rjb2Rl Ii4NCg0KQ29tcG9zaXRlIGF0dHJpYnV0ZToNCg0KS2V5OiAiYWRkcmVzcy5zdHJlZXQtbnVtYmVy Ig0KVmFsdWU6ICIxMCINCg0KS2V5OiAiYWRkcmVzcy5zdWJ1cmIiDQpWYWx1ZTogIkVhc3QgQ2Ft ZGVuIg0KDQpGb3IgcmVwZWF0aW5nIChtdWx0aS12YWx1ZWQpIGF0dHJpYnV0ZXMsIEknbSBzdWdn ZXN0aW5nIHRoYXQgdGhlcmUgYmUgbmV3IGtleXMgZm9yIGVhY2ggaW5kaXZpZHVhbCB2YWx1ZSwg b3RoZXJ3aXNlIHRoZXkgYXJlIGltcG9zc2libGUgdG8gZGlzdGluZ3Vpc2gsIGFuZCBhIHBvc2l0 aW9uYWwgaW5kZXggaXMgaW5hZGVxdWF0ZS4gU28gd2UgY29udmVydCB0aGUgYXJyYXkgaW50byBh IGRpY3Rpb25hcnkgYW5kIHRoaXMgdGhlbiBiZWNvbWVzIGEgY29tcG9zaXRlIGF0dHJpYnV0ZSB1 c2luZyBkb3Qgbm90YXRpb24gZm9yIHRoZSBrZXkuDQoNCk11bHRpLXZhbHVlZCBhdHRyaWJ1dGU6 DQoNCktleTogImVtYWlscy43ZGZjYjQ0NC03NGQ4LTRmMTctYWE2Ni1kYWY5ZWEzYmQ5MDIiDQpW YWx1ZTogImpvaG5fc21pdGhAeWFob28uY29tPG1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbT4i DQoNClNvIHRoaXMgYWxsb3dzIHVzIHRvIGFwcGx5IHVuaWZvcm0gdHJlYXRtZW50IHRvIGFueSBh cmJpdHJhcmlseSBkZWVwIHJlc291cmNlIHN0cnVjdHVyZS4gV2UgY2FuIHJlZmVyIHRvIGV2ZXJ5 IGxlYWYgdmFsdWUgd2l0aCBhIGtleSB0aGF0IGlzIHRoZSBmdWxseS1xdWFsaWZpZWQgbmFtZSB1 c2luZyBkb3Qgbm90YXRpb24uDQoNClRoZSB2ZXJicyBhcmUganVzdCB1bmFtYmlndW91cyBvcGVy YXRpb25zIG9uIHRoZXNlIChub3cpIGV4cGxpY2l0bHkgYWRkcmVzc2FibGUgYXR0cmlidXRlcy4N Cg0KSU5DTFVERSB0byBhIGNvbGxlY3Rpb24gYW5kIHNwZWNpZnkgb25seSB0aGUgdmFsdWUuIFRo ZSBrZXkgaXMgZ2VuZXJhdGVkIGFuZCByZXR1cm5lZC4gVGhlIGZ1bGx5LXF1YWxpZmllZCBrZXkg aXMgPGNvbGxlY3Rpb24tbmFtZT4uPG5ld2x5LWdlbmVyYXRlZC1JRD4gYW5kIHRoZSB2YWx1ZSBp cyB3aGF0IHdhcyBzcGVjaWZpZWQgaW4gdGhlIElOQ0xVREUuDQoNClJFUExBQ0UgYSBmdWxseS1x dWFsaWZpZWQga2V5IHdpdGggYSBuZXcgdmFsdWUuIElmIHRoZSBrZXkgZG9lc24ndCBleGlzdCwg cmV0dXJuIGEgIjQwNCBOb3QgRm91bmQiLg0KDQpQTEFDRSBhIHZhbHVlIGF0IHRoZSBsb2dpY2Fs IGxvY2F0aW9uIGltcGxpZWQgYnkgdGhlIGZ1bGx5LXF1YWxpZmllZCBrZXkuIElmIHRoZXJlIGlz IGFscmVhZHkgYSBrZXkgd2l0aCB0aGF0IG5hbWUsIHJldHVybiBhICI0MDkgQ29uZmxpY3QiLg0K DQpGT1JDRSB0aGUgZnVsbHktcXVhbGlmaWVkIGtleSB0byBob2xkIHRoZSBnaXZlbiB2YWx1ZSwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGV4aXN0ZWQgYmVmb3JlIG9yIG5vdC4gT25seSBlcnJv cnMgcG9zc2libGUgYXJlICI0MDAgQmFkIFJlcXVlc3QiIGFuZCAiNTAwIEludGVybmFsIEVycm9y Ii4NCg0KUkVUSVJFIGFuIGF0dHJpYnV0ZSBvciBhIGNvbGxlY3Rpb24gZ2l2ZW4gaXRzIGZ1bGx5 LXF1YWxpZmllZCBrZXkuIFRoZSBpbXBsZW1lbnRhdGlvbiB3aWxsIGRldGVybWluZSB3aGV0aGVy IHRoZSBhdHRyaWJ1dGUgd2lsbCBkaXNhcHBlYXIgZW50aXJlbHkgb3Igd2lsbCBleGlzdCBob2xk aW5nIGEgbnVsbCB2YWx1ZSAodGhlIGJsYW5rIHN0cmluZyAiIiBvciB0aGUgZW1wdHkgb2JqZWN0 IHt9ICkuDQoNCkknbGwgZXhwbGFpbiBpbiBhIHNlcGFyYXRlIHBvc3Qgd2h5IHdlIG5lZWQgb3Bl cmF0aW9uIHZlcmJzIGxpa2UgdGhlc2UgdGhhdCBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlIEhUVFAg dmVyYnMuDQoNClJlZ2FyZHMsDQpHYW5lc2gNCg0KT24gMTEgQXVndXN0IDIwMTIgMTA6MzgsIDxz Y2ltLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOnNjaW0tcmVxdWVzdEBpZXRmLm9yZz4+IHdyb3Rl Og0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2 aWR1YWwgbWVzc2FnZQ0KYXR0YWNobWVudHMgeW91IHdpbGwgbmVlZCB0byB1cGRhdGUgeW91ciBk aWdlc3Qgb3B0aW9ucyBpbiB5b3VyIGxpc3QNCnN1YnNjcmlwdGlvbi4gIFRvIGRvIHNvLCBnbyB0 bw0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg0KQ2xpY2sg dGhlICdVbnN1YnNjcmliZSBvciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0 ICJHZXQNCk1JTUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0 IHRoaXMgb3B0aW9uDQpnbG9iYWxseSBmb3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2Vp dmUgYXQgdGhpcyBwb2ludC4NCg0KDQoNClNlbmQgc2NpbSBtYWlsaW5nIGxpc3Qgc3VibWlzc2lv bnMgdG8NCiAgICAgICAgc2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4NCg0KVG8g c3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQog ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2NpbQ0Kb3IsIHZp YSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQog ICAgICAgIHNjaW0tcmVxdWVzdEBpZXRmLm9yZzxtYWlsdG86c2NpbS1yZXF1ZXN0QGlldGYub3Jn Pg0KDQpZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCiAgICAg ICAgc2NpbS1vd25lckBpZXRmLm9yZzxtYWlsdG86c2NpbS1vd25lckBpZXRmLm9yZz4NCg0KV2hl biByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBz cGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIHNjaW0gZGlnZXN0Li4uIg0KDQpUb2RheSdz IFRvcGljczoNCg0KICAgMS4gUmU6IFNDSU0gUHJvdG9jb2wgLSAzIHN1Z2dlc3Rpb25zIGZvciBp bXByb3ZlbWVudCAoUGhpbCBIdW50KQ0KDQoNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2Ug LS0tLS0tLS0tLQ0KRnJvbTogUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+Pg0KVG86IEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkIDxnLmMu cHJhc2FkQGdtYWlsLmNvbTxtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20+Pg0KQ2M6ICJEaW9k YXRpLCBNYXJrIiA8TWFyay5EaW9kYXRpQGdhcnRuZXIuY29tPG1haWx0bzpNYXJrLkRpb2RhdGlA Z2FydG5lci5jb20+PiwgRW1tYW51ZWwgRHJldXggPGVkcmV1eEBjbG91ZGl3YXkuY29tPG1haWx0 bzplZHJldXhAY2xvdWRpd2F5LmNvbT4+LCBUcmV5IERyYWtlIDx0cmV5LmRyYWtlQHVuYm91bmRp ZC5jb208bWFpbHRvOnRyZXkuZHJha2VAdW5ib3VuZGlkLmNvbT4+LCBLZWxseSBHcml6emxlIDxr ZWxseS5ncml6emxlQHNhaWxwb2ludC5jb208bWFpbHRvOmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50 LmNvbT4+LCAic2NpbUBpZXRmLm9yZzxtYWlsdG86c2NpbUBpZXRmLm9yZz4iIDxzY2ltQGlldGYu b3JnPG1haWx0bzpzY2ltQGlldGYub3JnPj4NCkRhdGU6IEZyaSwgMTAgQXVnIDIwMTIgMTc6MzY6 NTQgLTA3MDANClN1YmplY3Q6IFJlOiBbc2NpbV0gU0NJTSBQcm90b2NvbCAtIDMgc3VnZ2VzdGlv bnMgZm9yIGltcHJvdmVtZW50DQpHYW5lc2gsDQoNCkluIHlvdXIgZXhhbXBsZSB5b3UgYXJlIGNv bmZsYXRpbmcgdmFsdWUgd2l0aCBhbiBhdHRyaWJ1dGUgaWQuIEkgZmluZCB0aGF0IGNvbmZ1c2lu Zy4NCg0KSSBhZ3JlZSB0aG91Z2ggdGhhdCBvcGVyYXRpb25zIGluIHBhdGNoIGNvdWxkIGJlIGEg bG90IG1vcmUgZXhwbGljaXQuDQoNCkVnIGV4cGxpY2l0bHkgZGVsZXRpbmcgYSB2YWx1ZSBieSBz YXlpbmcgZGVsZXRlIG9yIHJldGlyZS4NCg0KUGhpbA0KDQpPbiAyMDEyLTA4LTEwLCBhdCAxNjox OSwgR2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgPGcuYy5wcmFzYWRAZ21haWwuY29tPG1haWx0bzpn LmMucHJhc2FkQGdtYWlsLmNvbT4+IHdyb3RlOg0KID4gIEkgYW0gY29uY2VybmVkIGFib3V0IHlv dXIgc2Vjb25kIHN1Z2dlc3Rpb246DQoNCkxldCdzIGRpc2N1c3MgdGhhdCBub3cuDQoNClRoZSB0 cmFkZS1vZmZzIGFyZSB2ZXJ5IGNsZWFyIGhlcmUuDQoNClByb3M6DQoNClBybyAxLiBUaGUgQVBJ IHRvIG1hbmlwdWxhdGUgcmVzb3VyY2VzIGJlY29tZXMgc28gbXVjaCBjbGVhbmVyLCBjb25zaXN0 ZW50IGFuZCBpbnR1aXRpdmUgd2hlbiBldmVyeSBpbmRpdmlkdWFsIGF0dHJpYnV0ZSB2YWx1ZSBn ZXRzIGl0cyBvd24gSUQuDQoNCkhlcmUncyBob3cgdG8gZGVsZXRlIGEgc2luZ2xlIG1lbWJlciBm cm9tIGEgR3JvdXAsIGFzIHBlciB0aGUgY3VycmVudCBzcGVjOg0KDQoNCiAgIFBBVENIIC9Hcm91 cHMvYWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlDQoNCiAgIEhvc3Q6IGV4YW1w bGUuY29tPGh0dHA6Ly9leGFtcGxlLmNvbS8+DQoNCiAgIEFjY2VwdDogYXBwbGljYXRpb24vanNv bg0KDQogICBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4DQoNCiAgIEVUYWc6IFcv ImEzMzBiYzU0ZjA2NzFjOSINCg0KDQoNCiAgIHsNCg0KICAgICAic2NoZW1hcyI6IFsidXJuOnNj aW06c2NoZW1hczpjb3JlOjEuMCJdLA0KDQogICAgICJtZW1iZXJzIjogWw0KDQogICAgICAgew0K DQogICAgICAgICAiZGlzcGxheSI6ICJCYWJzIEplbnNlbiIsDQoNCiAgICAgICAgICJ2YWx1ZSI6 ICIyODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYiDQoNCiAgICAgICAgICJvcGVy YXRpb24iOiAiZGVsZXRlIg0KDQogICAgICAgfQ0KDQogICAgIF0NCg0KICAgfQ0KDQpIZXJlJ3Mg aG93IHRvIGRlbGV0ZSBBTEwgbWVtYmVycyBmcm9tIGEgZ3JvdXAgYWNjb3JkaW5nIHRvIHRoZSBj dXJyZW50IHNwZWM6DQoNCg0KICAgUEFUQ0ggL0dyb3Vwcy9hY2JmM2FlNy04NDYzLTQ2OTItYjRm ZC05YjRkYTNmOTA4Y2UNCg0KICAgSG9zdDogZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29t Lz4NCg0KICAgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uDQoNCiAgIEF1dGhvcml6YXRpb246IEJl YXJlciBoNDgwZGpzOTNoZDgNCg0KICAgRVRhZzogVy8iYTMzMGJjNTRmMDY3MWM5Ig0KDQoNCg0K ICAgew0KDQogICAgICJzY2hlbWFzIjogWyJ1cm46c2NpbTpzY2hlbWFzOmNvcmU6MS4wIl0sDQoN CiAgICAgIm1ldGEiOiB7DQoNCiAgICAgICAiYXR0cmlidXRlcyI6IFsNCg0KICAgICAgICAgIm1l bWJlcnMiDQoNCiAgICAgICBdDQoNCiAgICAgfQ0KDQogICB9DQoNClRoZSB0d28gb3BlcmF0aW9u cyBkaWZmZXIgc2lnbmlmaWNhbnRseSwgYW5kIGl0J3Mgbm90IHZlcnkgaW50dWl0aXZlLg0KV2l0 aCBteSBzdWdnZXN0aW9uLCBoZXJlJ3MgaG93IHRvIGRlbGV0ZSBhIHNpbmdsZSBtZW1iZXIgZnJv bSBhIGdyb3VwOg0KDQpQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1iNGZkLTliNGRh M2Y5MDhjZSBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20vPkFjY2VwdDogYXBw bGljYXRpb24vanNvbiBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4IEVUYWc6IFcv ImEzMzBiYzU0ZjA2NzFjOSIgew0KIm9wZXJhdGlvbnMiIDogWw0Kew0KIlJFVElSRSIgOiB7DQoi a2V5IiA6ICJtZW1iZXJzLjI4MTljMjIzLTdmNzYtNDUzYS05MTlkLTQxMzg2MTkwNDY0NiINCn0N Cn0NCl0gfQ0KSGVyZSdzIGhvdyBJIHN1Z2dlc3QgZGVsZXRpbmcgQUxMIG1lbWJlcnMgZnJvbSBh IGdyb3VwOg0KDQpQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1iNGZkLTliNGRhM2Y5 MDhjZSBIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20vPkFjY2VwdDogYXBwbGlj YXRpb24vanNvbiBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4IEVUYWc6IFcvImEz MzBiYzU0ZjA2NzFjOSIgew0KIm9wZXJhdGlvbnMiIDogWw0Kew0KIlJFVElSRSIgOiB7DQoia2V5 IiA6ICJtZW1iZXJzIg0KfQ0KfQ0KXSB9DQoNCkknbSBzdXJlIHlvdSdsbCBhZ3JlZSB0aGF0IHRo aXMgaXMgc2ltcGxlciwgbW9yZSBjb25zaXN0ZW50IGFuZCBtb3JlIGludHVpdGl2ZSB0byBhIHJl YWRlci4NCg0KUHJvIDI6IFdlIGNhbiBhcHBseSB0aGlzIG1lY2hhbmlzbSBjb25zaXN0ZW50bHkg dG8gdGhyZWUgYXJlYXM6DQooYSkgTWFuaXB1bGF0aW5nIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVz IG9mIGEgcmVzb3VyY2UNCihiKSBNYW5pcHVsYXRpbmcgbWVtYmVycyBvZiBhIGdyb3VwDQooYykg UGVyZm9ybWluZyBidWxrIG9wZXJhdGlvbnMsIHdoZXJlIHdlIHNpbXBseSB1c2UgSFRUUCB2ZXJi cyBpbnN0ZWFkIG9mIHRoZSBzcGVjaWFsaXNlZCAoYW5kIHNlbWFudGljYWxseSBsZXNzIGFtYmln dW91cykgdmVyYnMgSSBzdWdnZXN0ZWQgZm9yIGF0dHJpYnV0ZXMsIHRoZSAia2V5IiBiZWNvbWVz IHRoZSBVUkksIGFuZCB0aGUgInZhbHVlIiBiZWNvbWVzIHRoZSBjb3JyZXNwb25kaW5nIEpTT04g b2JqZWN0Lg0KDQpBbGwgb2YgdGhlbSByZXR1cm4gIjIwNyBNdWx0aS1TdGF0dXMiIHdpdGggdGhl ICJyZXN1bHRzIiBhcnJheSBob2xkaW5nIGluZGl2aWR1YWwgc3RhdHVzIGNvZGVzLg0KDQpJbiB0 aGUgY3VycmVudCBzcGVjLCAoYSkgYW5kIChiKSBhcmUgZG9uZSBzaW1pbGFybHkgYnV0IChjKSBp cyB2ZXJ5IGRpZmZlcmVudC4NCg0KUHJvIDM6IEFkb3B0aW9uIG9mIHRoZSBzdGFuZGFyZCBieSBj bGllbnRzIGlzIGxpa2VseSB0byBiZSBoaWdoZXIgYmVjYXVzZSBpdCdzIHNpbXBsZXIgZm9yIHRo ZW0uDQoNClBybyA0OiBOZXcgKG5vdCBpbmN1bWJlbnQpIGNsb3VkIHByb3ZpZGVycyB3aWxsIHBy b2JhYmx5IGZpbmQgdGhpcyBlYXNpZXIgdG8gaW1wbGVtZW50IGJlY2F1c2UgdGhleSBoYXZlIG5v IGxlZ2FjeS4gVGhleSB3aWxsIHByb2JhYmx5IHVzZSBzb21lIGZvcm0gb2YgTm9TUUwgZGF0YWJh c2UgYW5kIHdvbid0IGJlIGNvbnN0cmFpbmVkIGJ5IHRoZSBsaW1pdGF0aW9ucyBvZiBMREFQIGRp cmVjdG9yaWVzLg0KDQpDb25zOg0KDQpDb24gMTogSW5jdW1iZW50IGNsb3VkIHByb3ZpZGVycyB3 aXRoIGV4aXN0aW5nIGRhdGEgc3RvcmVzIGluIGEgZGlyZWN0b3J5IGZvcm1hdCAod2hlcmUgbXVs dGktdmFsdWVkIGF0dHJpYnV0ZXMgYXJlIHN0b3JlZCBhcyBjb21tYS1zZXBhcmF0ZWQgdmFsdWVz IHVuZGVyIGEgc2luZ2xlIGF0dHJpYnV0ZSBub2RlKSB3aWxsIGZpbmQgaXQgZGlmZmljdWx0IHRv IG1pZ3JhdGUgdG8gdGhpcyBtb2RlbCBhbmQgc3RvcmUgZWFjaCBhdHRyaWJ1dGUgdmFsdWUgYXMg YSBzdWItbm9kZSB3aXRoIGl0cyBvd24ga2V5LiBUaGlzIHdpbGwgImhpbmRlciBhZG9wdGlvbiBv ZiB0aGUgc3BlYyIsIHdoaWNoIGlzIHdoYXQgeW91IGZlYXIuDQoNCkhhdmUgSSBzdW1tZWQgdXAg dGhlIFByb3MgYW5kIENvbnMgY29ycmVjdGx5PyBJJ20gYmlhc2VkIG9mIGNvdXJzZSwgc28gSSBj b3VsZCBoYXZlIG1pc3NlZCBhIENvbiBvciBoeXBlZCBhIFBybyA6LSkuDQoNCkluIG90aGVyIHdv cmRzLCB3ZSdyZSBkZWJhdGluZyBpbnRlcmZhY2UgY29tcGxleGl0eSAoY3VycmVudCBzcGVjKSB2 ZXJzdXMgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSAobXkgc3VnZ2VzdGlvbikuIEJvdGggY2Fu IGhpbmRlciBhZG9wdGlvbiBvZiB0aGUgc3BlYyBieSBkaWZmZXJlbnQgcGFydGllcy4NCg0KSGVy ZSdzIHdoYXQgd2UgbmVlZCB0byBkaXNjdXNzIC0gRG8gdGhlIFByb3MgbWFrZSB0aGUgc3VnZ2Vz dGlvDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3JnPG1haWx0bzpzY2ltQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltDQoNCg== --_000_DF63ACC82673DB40A7AAC08FFA71DFBD274190A0AMXPRD0610MB353_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtc3R5bGUt c3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtY29u dmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpz cGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwg Q2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3Jt YXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlRleHRlZGVidWxsZXND YXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWxzbyBhZ3JlZSB0byBu b3QgZm9sbG93IEdhbmVzaOKAmXMgcHJvcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5BcyBhbiBJQU0gZWRpdG9yIGFuZCB0ZWNobm9sb2d5IHByb3Zp ZGVyIGZvciBTQUFTIHByb3ZpZGVycywgSSB3b3VsZCBiZSB1bmFibGUgdG8gcHVzaCBzb2x1dGlv bnMgdGhhdCB3b3VsZCByZXF1aXJlIHRvIGNoYW5nZSB0aGUgcHJvdmlkZXLigJlzIGRhdGENCiBt b2RlbC4gKDkwJSB3b3VsZCBub3QgYWNjZXB0IHN1Y2ggaW50cnVzaW9uKS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIGluZm9ybWF0aW9uLCB3ZSBhcmUgZG9pbmcgMiBT Q0lNICZuYnNwO2ludGVncmF0aW9ucyB0aGlzIG1vbnRoLCBmb3IgMiBTQUFTIHByb3ZpZGVycyB3 aG8gaGF2ZSAyIGxhcmdlIGN1c3RvbWVy4oCZcyBBY3RpdmUgRGlyZWN0b3JpZXMgdG8gc3luY2hy b25pemUNCiAoMTAmbmJzcDswMDAgYW5kIDE1Jm5ic3A7MDAwIHVzZXJzKS4gRGVhZGxpbmUgU2Vw dGVtYmVyIDE1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0IHNhaWQs IHRoZSBwcm9ibGVtIG9mIG11bHRpIHZhbHVlcyBpcyByZWFsIGFuZCByZW1haW5zIGFuIGlzc3Vl IGZvciBtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkltYWdp bmUgdGhhdCBJIGNhdGNoIEFjdGl2ZSBEaXJlY3RvcnkgY2hhbmdlcyAoZm9yIGV4YW1wbGUgYSBj aGFuZ2UgaW4gYSBzdHJlZXQgZmllbGQ6IGl0IG1pZ2h0IGNvbWUgZnJvbSBhbiBhZG1pbmlzdHJh dG9yIHdobm8gZml4ZXMgdGhpcyBmaWVsZCwNCiBvciBhIHVzZXIgdGhhdCBjaGFuZ2VzIGEgdmFs dWUgdGhyb3VnaCBhIHNlbGYgc2VydmljZSBwb3J0YWwpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgb3VyIElBTSBwcm9kdWN0IHNlbmRzIHRoZSBjaGFuZ2Ug dGhyb3VnaCBhIHByb3ByaWV0YXJ5IEFQSSAoZXggR29vZ2xlLCBTYWxlc2ZvcmNlLCBPZmZpY2Uz NjUgYXBpKSwgdGhlbiB0aGVyZSBpcyBubyBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgaXQgc2VuZCB0aGUgY2hhbmdlIHRocm91Z2ggU0NJTSwg SSB3aWxsIGhhdmUgdG8ga25vdyBhbmQgbWFpbnRhaW4gc29tZXdoZXJlIHRoYXQgYWRkaXRpb25h bCBmaWVsZHMgYXJlIGxpbmtlZCB0b2dldGhlciBhbmQgSSB3aWxsIGhhdmUgdG8gZ2V0DQogdGhl IHZhbHVlcyBvZiBhbGwgdGhlc2UgZmllbGRzIGluIG9yZGVyIHRvIGJ1aWxkIHRoZSBmdWxsIFND SU0gb2JqZWN0IHRvIHBhdGNoIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JZiB5b3UgYWdyZWUgdGhhdCB0aGlzIGlzIGFuIGlzc3VlLCB3b3VsZCBpdCBiZSBmYWlyIHRv IHRyeSB0byBpbXByb3ZlIHRoaXMgYXJlYSBpbiB0aGUgc3BlY3M/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVtbWFudWVsIERyZXV4PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmh0dHA6Ly93d3cuY2xvdWRpd2F5LmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UZWw6ICYjNDM7MzMgNCAyNiA3OCAxNyA1ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Nb2JpbGU6ICYjNDM7MzMgNiA0NyA4MSAyNiA3MDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5za3lwZTogRW1tYW51ZWwuRHJldXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBDaHJpcyBQaGlsbGlwcyBbbWFpbHRvOkNocmlzLlBoaWxsaXBzQGNhbmFyaWUuY2Fd DQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTYgYW/Du3QgMjAxMiAyMToyMzxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gc2NpbUBpZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7Ojwv Yj4gUmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+JiM0MzsxIHRvIFBoaWwncyBjb21tZW50cy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QXMgd2VsbCwgYWRkaW5nIGEgZ2hvc3QgZGly ZWN0b3J5IHRvIFtkZXxlbl1jb2RlIHRoaW5ncyBpcyBqdXN0IHRvbyBtdWNoIG92ZXJoZWFkIHRv IGJ1aWxkIGludG8gdGhlIHByb3RvY29sLiAmbmJzcDtJZiBzb21lb25lIHdhbnRzIHRvIGJ1aWxk IHRoYXQgb24gVE9QIG9mIFNDSU0sDQogdGhhdCdzIHVwIHRvIHRoZW0uICZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ V2hpbGUgSSBhcHByZWNpYXRlIHRoZSB0aG91Z2h0IGFuZCB0aW1lIEdhbmVzaCBoYXMgcHV0IGlu dG8gdGhlIGNvbmNlcHRzLCBJIGFtIG5vdCBjb252aW5jZWQgdGhlIGFwcHJvYWNoIHdvdWxkIGJl IG5ldCBiZXR0ZXIgYW5kIGxlc3MgY29tcGxleCBhbmQgc28gZG8gbm90IHN1cHBvcnQgaXQmbmJz cDthbmQgd2VsY29tZSBtb3ZpbmcNCiBvbiB0byZuYnNwO290aGVyIHRvcGljcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Qy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWwgSHVudCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCAxNiBBdWd1c3QsIDIwMTIgMTo0MiBQTTxicj4N CjxiPlRvOiA8L2I+S2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbSI+a2VsbHkuZ3JpenpsZUBzYWlscG9pbnQuY29tPC9hPiZndDs8YnI+ DQo8Yj5DYzogPC9iPkVtbWFudWVsIERyZXV4ICZsdDs8YSBocmVmPSJtYWlsdG86ZWRyZXV4QGNs b3VkaXdheS5jb20iPmVkcmV1eEBjbG91ZGl3YXkuY29tPC9hPiZndDssIEFudGhvbnkgTmFkYWxp biAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNy b3NvZnQuY29tPC9hPiZndDssIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJt YWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDss DQogTWVsaW5kYSBTaG9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lbGluZGEuc2hvcmVAZ21haWwu Y29tIj5tZWxpbmRhLnNob3JlQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtzY2ltXSBzY2ltIERpZ2VzdCwgVm9sIDgsIElzc3VlIDI0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSBkbyB0aGluayB3ZSBuZWVk IHRvIGFycml2ZSBhdCBzb21lIGNvbnNlbnN1cyBvbiB0aGlzIG5vdyBiZWNhdXNlIEdhbmVzaCdz IHByb3Bvc2FsIGlzIGEgbWFqb3IgJnF1b3Q7Zm9yay1pbi10aGUtcm9hZCZxdW90OyBkZWNpc2lv bi4gSWYgd2UgdGFibGUgaXQsIGl0IHdpbGwgYmUgaGFyZCB0bw0KIGNvbWUgYmFjayB0by4gVGhp cyBpcyB3aHkgSSBoYXZlIGVuZ2FnZWQgb24gdGhlIHN1YmplY3Qgd2l0aCBHYW5lc2ggc28gdGhv cm91Z2hseS4gJm5ic3A7TmV2ZXItdGhlLWxlc3MsIEkgd291bGQgbGlrZSB0byBhcnJpdmUgYXQg c29tZSBjb25jbHVzaW9ucyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5NeSBhcG9sb2dpZXMsIGJ1dCBJIHRob3VnaHQgaXQgd2FzIHdvcnRoIHJlLXN0YXRpbmcgdGhl IHByb2JsZW0gZm9yIHRob3NlIGxhdGUgdG8gdGhlIGRpc2N1c3Npb24gd291bGQgYmUgdXNlZnVs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CYWNrZ3JvdW5kOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QXQgcHJlc2VudCwgdGhlIGN1cnJl bnQgc3BlYyBkb2VzIG5vdCBhbGxvdyB5b3UgdG8gY2hhbmdlIGEgc3BlY2lmaWMgc3ViLWF0dHJp YnV0ZSBpbiBhIG11bHRpLXZhbHVlZCBjb21wbGV4IGF0dHJpYnV0ZSBzdHJ1Y3R1cmUgKGUuZy4g Y2hhbmdpbmcgc3RyZWV0IG5hbWUgaW4NCiBhIHNwZWNpZmljIGFkZHJlc3MgdmFsdWUgaW5zdGFu Y2Ugc3VjaCBhcyAmcXVvdDtob21lJnF1b3Q7KS4gJm5ic3A7VGhlIHByb3Bvc2FsIGlzIHRoYXQg ZWFjaCBzdWIgYXR0cmlidXRlIGluIGEgbXVsdGktdmFsdWVkIHN0cnVjdHVyZSBnZXRzIGl0cyBv d24gdW5pcXVlIGlkZW50aWZpZXIuICZuYnNwO1RoZW4geW91IGNhbiBkaXJlY3RseSByZWZlcmVu Y2UgdGhlIHNwZWNpZmljIGNvbXBsZXggYXR0cmlidXRlIGNvbXBvbmVudCBpbiBhIGNvbXBsZXgg dmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoZSBjdXJyZW50IGRy YWZ0IHByb3Bvc2FsIHJlcXVpcmVzIHRoYXQgY29tcGxleC12YWx1ZSAoZS5nLiBhbiBhZGRyZXNz IHZhbHVlIHdoaWNoIGlzIG1hZGUgdXAgb2YgbnVtYmVyLCBzdHJlZXQsIGNpdHksIGV0YykgYmUg Y2hhbmdlZCBpZiB5b3Ugd2FudCB0byBjaGFuZ2UNCiBhbnkgb2YgdGhlIHN1Yi1hdHRyaWJ1dGVz LiBUaGUgY3VycmVudCBhcHByb2FjaCBzZWVtcyBhIHJlYXNvbmFibGUgY29tcHJvbWlzZSBzaW5j ZSBpdCBpcyBsaWtlbHkgdGhlIGNvbGxlY3Rpb24gb2YgYXR0cmlidXRlcyBpbiBhIGNvbXBsZXgg JnF1b3Q7dmFsdWUmcXVvdDsgYXJlIG9mdGVuIG1hbmlwdWxhdGVkIHRvZ2V0aGVyLiBJT1cuIFlv dSB0ZW5kIHRvIHNldCB0aGVtIGFsbCBhdCBvbmNlLiAmbmJzcDtHYW5lc2gncyBwcm9wb3NhbCBh bGxvd3Mgc3BlY2lmaWMgc3ViLWF0dHJpYnV0ZXMNCiB0byBiZSBkaXJlY3RseSBhZGRyZXNzYWJs ZSBieSBnaXZpbmcgZWFjaCB2YWx1ZSBpbnN0YW5jZSBhIHVuaXF1ZSBpZGVudGlmaWVyLiAmbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QW5vdGhlciBleGFt cGxlIG9mIHRoaXMgaXMgdGhlIGdyb3VwICZxdW90O21lbWJlciZxdW90OyBhdHRyaWJ1dGUuICZu YnNwO0luIHRoZSBjdXJyZW50IGRyYWZ0LCBhIG1lbWJlciBjYW4gaGF2ZSBhIHZhbHVlIGFuZCBh IGRpc3BsYXkgbmFtZS4gSW4gdGhpcyBjYXNlIHlvdSB3b3VsZCB1c3VhbGx5IGNoYW5nZQ0KIHRo ZSB2YWx1ZSAob2JqZWN0IGlkZW50aWZpZXIpIGFuZCB0aGUgbmFtZSBhcyB3ZWxsLiAmbmJzcDtH YW5lc2gncyBwcm9wb3NhbCB3b3VsZCBhbGxvdyAmcXVvdDtEaXNwbGF5IE5hbWUmcXVvdDsgdG8g YmUgY2hhbmdlZCBvciB2YWx1ZSB0byBiZSBjaGFuZ2VkLiAmbmJzcDtTb21ldGhpbmcsIElNViwg dGhhdCBkb2Vzbid0IG9jY3VyIG5lYXJseSBhcyBvZnRlbi4gJm5ic3A7SU9XIG1lbWJlcnMgY2hh bmdlIGdyb3VwIG1lbWJlcnNoaXAsIGJ1dCBtZW1iZXJzIHJhcmVseSBjaGFuZ2UgbmFtZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk15IGNvbmNsdXNpb246PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JZiB0aGUgY2xpZW50IG11c3QgZmly c3QgcXVlcnkgKG9yIGhhdmUgc3luY2hyb25pemVkIHRoZSB2YWx1ZSBpZGVudGlmaWVycyksIHRo ZW4gdGhlIGNsaWVudCBoYXMgdG8gZG8gZXZlbiBtb3JlIHdvcmsgdGhhbiB0aGUgY3VycmVudCBw cm9wb3NhbCBvZiByZXBsYWNpbmcgdGhlDQogZW50ZXIgY29tcGxleCB2YWx1ZS4gJm5ic3A7R2l2 ZW4gc3VjaCBhIGNob2ljZSBJJ20gcmVhbGx5IHNrZXB0aWNhbCB0aGF0IHRoZSBwYXR0ZXJuIHBy b3Bvc2VkIGJ5IEdhbmVzaCB3b3VsZCBiZSB3aWRlbHkgdXNlZC4gJm5ic3A7V2hpbGUgR2FuZXNo J3MgcHJvcG9zYWwgbWF5IGJlICZxdW90O3NwZWNpZmljJnF1b3Q7LCB0aGUgcHJhY3RpY2FsIHNp bXBsaWNpdHkgb2YgaXQgaXMgdmVyeSBtdWNoIGRlYmF0YWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UaGUgYmVuZWZpdCBvZiBzcGVjaWZpYyBzdWItYXR0cmlidXRlIGlkZW50aWZp ZXJzIG5lZWRzIHRvIGJlIHN1YnN0YW50aWFsLiAmbmJzcDtXZSdyZSBub3Qgb25seSB0YWxraW5n IGFib3V0IGNoYW5naW5nIGhvdyBpbmZyYXN0cnVjdHVyZSBpcyBkb25lLCBidXQgYWxzbyBob3cg YXBwbGljYXRpb25zDQogYXJlIHdyaXR0ZW4uIFRoaXMgbGVhdmVzIG91dCB0aGUgZW50aXJlIGN1 cnJlbnQgYWRvcHRlcnMgYW5kIGFsbCBlbnRlcnByaXNlIHVzZXJzLiAmbmJzcDtBIGJpZyBjb25j ZXJuIHdlIGhhdmUgb2J2aW91c2x5IGlzIHdlIGhhdmUgdG8gY29uc2lkZXIgZXhpc3RpbmcgaW5m cmFzdHJ1Y3R1cmUgYW5kIGRhdGEgc3RvcmVzIGFuZCBiZSByZWFsaXN0aWMuIEkgZG9uJ3QgdGhp bmsgdGhlIGJlbmVmaXQgaXMgd29ydGggdGhlIGNvc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5JIGFncmVlIHdpdGggdGhlIG90aGVycyB0aGF0IHRoZSBjdXJyZW50IGRy YWZ0IGNvdWxkIGJlIGNoYW5nZWQgdG8gbWFrZSBwYXRjaCBvcGVyYXRpb25zIG1vcmUgY2xlYXIg dG8gdGhlIGRldmVsb3BlciAoc2ltcGxlciB0byByZWFkKS4gV2hpbGUgdGhpcyBtYXkgbm90IGlt cHJvdmUNCiBsb2dpYywgaXQgd2lsbCBpbXByb3ZlIHVuZGVyc3RhbmRpbmcgYW5kIHNpbXBsaWNp dHkuIFRoZSBmYWN0IHRoYXQgY2VydGFpbiBvcGVyYXRpb25zIG1heSByZXF1aXJlIGFuIGVudGly ZSBjb21wbGV4IGF0dHJpYnV0ZSB2YWx1ZSB0byBiZSByZXBsYWNlZCBpcyBhIHJlYXNvbmFibGUg Y29tcHJvbWlzZSBhbmQgc2hvdWxkIG5vdCBiZSBjaGFuZ2VkLiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5QaGls PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkBpbmRlcGVuZGVudGlk PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0 cDovL3d3dy5pbmRlcGVuZGVudGlkLmNvbSI+d3d3LmluZGVwZW5kZW50aWQuY29tPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTMuNXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnBoaWwuaHVudEBv cmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk9uIDIwMTItMDgtMTYsIGF0IDg6 NTkgQU0sIEtlbGx5IEdyaXp6bGUgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBHYW5lc2gg4oCmIHlvdXIgd3JpdGUtdXAgY29uY2VkZXMg dGhhdCB0aGlzIHdpbGwgYmUgZGlmZmljdWx0IHRvIGltcGxlbWVudCBmb3IgYW4gZXhpc3Rpbmcg c2VydmljZSBwcm92aWRlci4mbmJzcDsgSeKAmW0gbm90IHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQg dGhlDQogY29tcHJvbWlzZS4mbmJzcDsgQXJlIHlvdSBzdGlsbCBzdWdnZXN0aW5nIHRoYXQgU0NJ TSBtb3ZlIHRvIHRoZSB1bmlxdWUta2V5LXBlci1lbGVtZW50IHN0cmF0ZWd5Pzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHNvLCB0aGUgY29zdC9iZW5lZml0 IG9mIHRoaXMgc2VlbXMgd2F5IG9mZiB0byBtZS4mbmJzcDsgWW91IGFyZSBnYWluaW5nIGEgbW9y ZSBlbGVnYW50IEFQSSBieSBpbnRyb2R1Y2luZyBhbiBhZGRpdGlvbmFsIGRhdGFzdG9yZSBhbmQg cmVxdWlyaW5nIHJlcGxpY2F0aW9uLiZuYnNwOw0KIEkgZG9u4oCZdCBrbm93IG9mIGFueSBzZXJ2 aWNlIHByb3ZpZGVyIHRoYXQgd291bGQgbWFrZSB0aGlzIHRyYWRlLW9mZi4mbmJzcDsgQXMgeW91 IHNhaWQsIHRoaXMgaXMgc29tZXRoaW5nIHRoYXQgZnV0dXJlIHNlcnZpY2UgcHJvdmlkZXJzIGNh biBrZWVwIGluIG1pbmQsIGJ1dCBpdCBpcyBub3QgZ29pbmcgdG8gaGVscCBleGlzdGluZyBwcm92 aWRlcnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS1LZWxs eTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci13aWR0aDpp bml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5HYW5lc2gNCiBhbmQgU2FzaGkgUHJhc2FkIFs8YSBocmVmPSJtYWlsdG86Zy5jLnBy YXNhZEBnbWFpbC5jb20iPm1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2Rh eSwgQXVndXN0IDE2LCAyMDEyIDU6MzggQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFudGhvbnkgTmFkYWxpbjxicj4NCjxi PkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ S2VsbHkgR3JpenpsZTsgRW1tYW51ZWwgRHJldXg7IE1lbGluZGEgU2hvcmU7DQo8YSBocmVmPSJt YWlsdG86c2NpbUBpZXRmLm9yZyI+c2NpbUBpZXRmLm9yZzwvYT47IFBoaWwgSHVudDxicj4NCjxi PlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5SZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwgSXNzdWUgMjQ8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPldvdWxkIHRoaXMgaHlicmlkIGFyY2hpdGVjdHVyZSBiZSBh IHdvcmthYmxlIGNvbXByb21pc2U/IFNlZSBkaWFncmFtIHRvd2FyZHMgdGhlIGVuZDo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDov L2JpdC5seS9SamMzOVkiPmh0dHA6Ly9iaXQubHkvUmpjMzlZPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPkdhbmVzaDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+T24gMTUgQXVndXN0IDIwMTIgMDU6NTQsIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnlu YWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQg bm90IGJlIGNvbnN0cmFpbmVkIGJ5IExEQVAgcmVzdHJpY3Rpb25zLCB0aGlzIHdvdWxkIG5vdCBi ZSBwcm9kdWN0aXZlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzY2ltLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJl aGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 L2I+R2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQ8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TW9uZGF5LCBBdWd1c3QgMTMsIDIw MTIgMjowNyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+S2VsbHkgR3JpenpsZTxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RW1tYW51ZWwgRHJldXg7IE1l bGluZGEgU2hvcmU7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2NpbUBp ZXRmLm9yZzwvYT47IFBoaWwgSHVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW3NjaW1dIHNjaW0gRGlnZXN0LCBWb2wgOCwgSXNz dWUgMjQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGFua3MsIEtlbGx5LiBZb3UndmUgYmVlbiBtb3N0IHBhdGllbnQgaW4gaGVh cmluZyBtZSBvdXQsIEkgbXVzdCBzYXkuIEkgY291bGRuJ3QgYXNrIGZvciBtb3JlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXBseWluZyB0 byBDaHJpcyBQaGlsaXBzJ3MgbWFpbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5H aXZlbiB0aGF0IHlvdSBoYXZlIGEgbnVtYmVyIG9mIHRob3VnaHRzIGFib3V0IHdoYXQgY291bGQg YmUgY2hhbmdlZCBpbiBTQ0lNLExlaWYncw0KIHJlY29tbWVuZGF0aW9uIHRvICZuYnNwO2NyYWZ0 IHRoZW0gaW4gYW4gSW50ZXJuZXQgRHJhZnQgbWF5IGJlIGEgYmV0dGVyIHdheSB0byBjb252ZXkg eW91ciB0aG91Z2h0cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PGJyPg0KPGJyPg0KSSdtIGNvbWluZyBhcm91bmQgdG8gdGhlIHNhbWUgY29uY2x1c2lvbi4g RG8geW91IHRoaW5rIHN1Y2ggYW4gSW50ZXJuZXQgRHJhZnQgc2hvdWxkIGJlIGFib3V0IGNoYW5n aW5nIFNDSU0sIG9yIHNob3VsZCBpdCBwcm9wb3NlIGEgY29tcGxlbWVudGFyeSBzcGVjIGZvciBT UHMgd2hvIHVzZSBhICZxdW90O05vTERBUCZxdW90OyBkYXRhIHN0b3JlPyBJIHRoaW5rIHRoZSB1 bmRlcmx5aW5nIHByb2JsZW0gaXMgd2l0aCBMREFQLCBhbmQgdW5sZXNzIHdlIGNoYW5nZSB0aGF0 LA0KIHRoZXNlIHByb3Bvc2FscyB3b24ndCBmbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+R2FuZXNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5P biAxNCBBdWd1c3QgMjAxMiAwMTo1NCwgS2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtlbGx5LmdyaXp6 bGVAc2FpbHBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBhcmUg cmVhbGx5IHR3byBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIGZvciBhIHVpZCBwZXIgZWxlbWVudCDi gJMgZWl0aGVyIHN0b3JlIHRoZSB1aWRzIGluIHRoZSBuYXRpdmUgdW5kZXJseWluZyBkYXRhIHN0 b3JlIG9yIGhhdmUgc29tZSBzZWNvbmRhcnkNCiBkYXRhIHN0b3JlIHRoYXQgbWFwcyBlbGVtZW50 cyB0byB0aGVpciB1aWRzLiZuYnNwOyBUaGUgdGhpcmQgb3B0aW9uIGlzIHRvIGhvcGUgdGhhdCBh IHNlcnZpY2UgcHJvdmlkZXIgaGFzIGEgTm9MREFQIGRhdGEgc3RvcmUgb3IgaXRzIGVxdWl2YWxl bnQuJm5ic3A7IE5vbmUgb2YgdGhlc2UgYXJlIHByYWN0aWNhbCBmb3IgcmFwaWQgYW5kIHdpZGUt c3ByZWFkIGFkb3B0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5wdXQg dGhlIHR3byB0b2dldGhlciB0byBwcm9wb3NlIGEgc29sdXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIEkgc2FpZCBi ZWZvcmUsIEkgYW0gY29tcGxldGVseSBvbiBib2FyZCB3aXRoIGNsZWFuaW5nIHVwIHRoZSBQQVRD SCBzZW1hbnRpY3MgKGVnIOKAkyB0aGUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIG1ldGEuYXR0cmli dXRlcyBhbmQgb3BlcmF0aW9uPWRlbGV0ZSwNCiBldGPigKYpLiZuYnNwOyBZb3VyIHN1Z2dlc3Rp b24gb2YgdXNpbmcgZGlmZmVyZW50IHZlcmJzIGlzIGEgZ29vZCBvcHRpb24gdG8gY29uc2lkZXIu Jm5ic3A7IFRoaXMgY2Fubm90IGJlIGJhc2VkIG9uIGEgdWlkIHBlciBlbGVtZW50LCB0aG91Z2gu Jm5ic3A7IEl0IHNlZW1zIGFzIHRob3VnaCB5b3UgaGF2ZSBhZG1pdHRlZCB0aGlzIGluIHlvdXIg Y29uY2x1c2lvbiDigJMg4oCcQXMgZm9yIExEQVAgYW5kIFNDSU0sIEkgZ3Vlc3MgdGhlIGJlc3Qg VExBIGlzIFJJUC7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4tLUtlbGx5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVy LXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkdhbmVzaA0KIGFuZCBTYXNoaSBQcmFzYWQgW21haWx0bzo8YSBocmVm PSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nLmMucHJhc2Fk QGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEF1Z3VzdCAxMywgMjAxMiA5OjU2IEFNPGJyPg0KPGI+ VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5L ZWxseSBHcml6emxlPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQ7IE1lbGluZGEgU2hvcmU7IEVtbWFudWVsIERy ZXV4OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+ U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlJlOiBbc2NpbV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAyNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhhdCB3YXMgb25lIHN1Z2dlc3Rpb24uIEFub3RoZXIgd2F5IGNvdWxkIGJlIGNvbnRhaW5lciBu b2RlcyB3aXRoIHRoZWlyIG93biAmcXVvdDtkbiZxdW90O3MuIElmIG9uZSBzdWdnZXN0aW9uIHdv bid0IHdvcmssIHRlbGwgbWUgYW5vdGhlciB3YXkgdG8gbWFrZSBpdCB3b3JrLiBJJ20gd2FpdGlu ZyB0byBoZWFyIGEgY29uc3RydWN0aXZlIHN1Z2dlc3Rpb24NCiB0aGF0IGNhbiBzcXVhcmUgYW4g ZWxlZ2FudCBBUEkgd2l0aCB0aGUgaW1wbGVtZW50YXRpb24gY29uc3RyYWludHMgdGhhdCBjb21l IGZyb20gaGF2aW5nIHRvIHN0b3JlIG11bHRpLXZhbHVlZCBhdHRyaWJ1dGVzIGluIExEQVAgZGly ZWN0b3JpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPkkndmUgaGVhcmQgZW5vdWdoIG9mIFdIWSB0aGlzIHdvbid0IHdvcmsuIEZvciBhIGNo YW5nZSwgdGVsbCBtZSBIT1cgaXQgY2FuIGJlIG1hZGUgdG8gd29yay4gRXZlcnlvbmUgbm93IGtu b3dzIHdoYXQgdGhlIHByb3Bvc2FsIG1lYW5zIGluIHRlcm1zIG9mIHRoZSBBUEksIGFuZCBpbXBs ZW1lbnRvcnMgdW5kZXJzdGFuZCB0aGUgY29uc3RyYWludHMNCiBvZiBsZWdhY3kgZGF0YSBzdG9y ZXMsIHNvIHB1dCB0aGUgdHdvIHRvZ2V0aGVyIHRvIHByb3Bvc2UgYSBzb2x1dGlvbi4gQydtb24s IHdlIGhhdmUgdGhlICZxdW90O3NtYXJ0ZXN0IGd1eXMgaW4gdGhlIHJvb20mcXVvdDsgaGVyZSwg c3VyZWx5IHdlIHNob3VsZCBiZSBhYmxlIHRvIGNyYWNrIHRoaXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5HYW5l c2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5QLlMuIEknbSByYXBpZGx5IHJlYWNoaW5nIG15IG93biBjb25jbHVzaW9ucyBhYm91 dCB3aGF0IGlzIHRvIGJlIGRvbmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3dpc2RvbW9mZ2FuZXNoLmJsb2dz cG90LmNvbS5hdS8yMDEyLzA4L2FmdGVyLW5vc3FsLWl0cy10aW1lLWZvci1ub2xkYXAuaHRtbCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93aXNkb21vZmdhbmVzaC5ibG9nc3BvdC5jb20uYXUvMjAx Mi8wOC9hZnRlci1ub3NxbC1pdHMtdGltZS1mb3Itbm9sZGFwLmh0bWw8L2E+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+T24gMTQgQXVndXN0IDIwMTIgMDA6MjcsIEtlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9 Im1haWx0bzprZWxseS5ncml6emxlQHNhaWxwb2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5rZWxs eS5ncml6emxlQHNhaWxwb2ludC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IEFmdGVyIGFs bCwgbm8gb25lIGhhcyBjaGFsbGVuZ2VkIHRoZSBjbGFpbSB0aGF0IHRoaXMgcHJvcG9zYWwgZHJh c3RpY2FsbHkgc2ltcGxpZmllcyB0aGUgQVBJIGZvciB0aGUgY2xpZW50PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYWdyZWUg dGhhdCB5b3VyIHByb3Bvc2FsIG1ha2VzIFBBVENIIHNlbWFudGljcyBzaW1wbGVyIGFuZCBtb3Jl IGVsZWdhbnQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZndDsg4oCmPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5zbyBpdCB3b3Vs ZCBhcHBlYXIgdG8gYmUgd29ydGggZG9pbmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc3Ryb25nbHkgZGlzYWdy ZWUgaGVyZS4mbmJzcDsgVGhpcyBzdGF0ZW1lbnRzIGFzc3VtZXMgdGhhdCBzaW1wbGljaXR5IG9m IHRoZSBjbGllbnQgQVBJIGlzIHRoZSBvbmx5IGZhY3RvciB0aGF0IHNob3VsZCBiZSBjb25zaWRl cmVkIHdpdGggdGhlIHNwZWMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RW1tYW51ZWzigJlzIGV4YW1wbGUgaXMgZnJvbSBhIHJlYWwtd29ybGQgc2VydmljZSBw cm92aWRlciB0aGF0IHdvdWxkIG5vdCBiZSBhYmxlIHRvIGltcGxlbWVudCB0aGUgc3BlYyBlYXNp bHkgd2l0aCBhIHVpZCBwZXIgZWxlbWVudC4mbmJzcDsgSGUgaXMgd29ya2luZw0KIG9uIGEgU0NJ TSBpbnRlcmZhY2UgdGhhdCB3aWxsIGhlbHAgZmFjaWxpdGF0ZSBkYXRhIGV4Y2hhbmdlIGJldHdl ZW4gbXVsdGlwbGUgQWN0aXZlIERpcmVjdG9yeSBzZXJ2ZXJzLiZuYnNwOyBZb3VyIHNvbHV0aW9u IHdhcyB0byBjaGFuZ2UgdGhlIGRhdGEgbW9kZWwgZnJvbSB0aGlzOjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5tYWlsOiA8YSBocmVmPSJt YWlsdG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huX3NtaXRoQHlh aG9vLmNvbTwvYT4sIDxhIGhyZWY9Im1haWx0bzpqb2huLnNtaXRoQGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmpvaG4uc21pdGhAZ21haWwuY29tPC9hPiwgPGEgaHJlZj0ibWFpbHRvOmpzbWl0 aDE5NzBAaG90bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qc21pdGgxOTcwQGhvdG1haWwuY29t PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnRvIHRoaXM6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+bWFpbDombmJzcDthYTY2LWRhZjllYTNiZDkwMj08YSBocmVmPSJt YWlsdG86am9obl9zbWl0aEB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huX3NtaXRoQHlh aG9vLmNvbTwvYT4sOWNkYS04NjQ2YzMwODViYmY9PGEgaHJlZj0ibWFpbHRvOmpvaG4uc21pdGhA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9obi5zbWl0aEBnbWFpbC5jb208L2E+LCZuYnNw OzdhNmQxZGU2NjRlMT08YSBocmVmPSJtYWlsdG86anNtaXRoMTk3MEBob3RtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmpzbWl0aDE5NzBAaG90bWFpbC5jb208L2E+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3Qga25vdyBvZiBhIHNpbmdsZSBvcmdh bml6YXRpb24gdGhhdCB3b3VsZCBjaGFuZ2UgdGhlaXIgQWN0aXZlIERpcmVjdG9yeSBkYXRhIG1v ZGVsIHRvIGZpdCB0aGlzLiZuYnNwOyBGb3Igb25lIHRoaW5nLCBpdCB3b3VsZCBiZSBhIGh1Z2Ug ZGF0YQ0KIG1pZ3JhdGlvbiBlZmZvcnQgKGxpa2VseSBhY3Jvc3Mgb3RoZXIgZG9tYWluIGNvbnRy b2xsZXJzLCBldGPigKYpIHRvIGFzc2lnbiB0aGVzZSB1bmlxdWUgaWRlbnRpZmllcnMuJm5ic3A7 IFRoaXMgYWxzbyBhc3N1bWVzIHRoYXQgU0NJTSBpcyB0aGUgb25seSByZWFkZXIvd3JpdGVyIG9m IHRoaXMgZGF0YSwgd2hpY2ggd2lsbCBhbG1vc3QgbmV2ZXIgYmUgdGhlIGNhc2UuJm5ic3A7IElm IHRoZSBkYXRhIG1vZGVsIHJlcXVpcmVzIHVpZHMgZm9yIGV2ZXJ5IGVsZW1lbnQsDQogdGhlbiBl dmVyeSBwaWVjZSBvZiBub24tU0NJTSBjb2RlIHRoYXQgd3JpdGVzIGRhdGEgaW50byB0aGUgZGly ZWN0b3J5IHdpbGwgaGF2ZSB0byBmb2xsb3cgdGhpcy4mbmJzcDsgQWRkaXRpb25hbGx5LCB0aGVy ZSBhcmUgKjxiPm1hbnk8L2I+KiB0b29scyBhbmQgYXBwbGljYXRpb25zICZuYnNwOyhlZyDigJMg YWRkcmVzcyBib29rcykgdGhhdCByZWx5IG9uIGEgY2VydGFpbiBkYXRhIG1vZGVsIGluIEFjdGl2 ZSBEaXJlY3RvcnksIGFuZCB0aGlzIHdvdWxkIGNhdXNlDQogdGhlbSB0byBicmVhay4mbmJzcDsg SU1PIHRoaXMgc2FtZSBhcmd1bWVudCBob2xkcyB0cnVlIGZvciBtb3N0IHNlcnZpY2UgcHJvdmlk ZXJzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBBVENIIGlzIGFu IG9wdGlvbmFsIHBhcnQgb2YgdGhlIHNwZWMuICZuYnNwO0l0IHdhcyBwcmltYXJpbHkgaW50cm9k dWNlZCB0byBtYWtlIG1vZGlmeWluZyByZXNvdXJjZXMgd2l0aCBsYXJnZSBtdWx0aS12YWx1ZWQg bGlzdHMgbW9yZSBlZmZpY2llbnQuJm5ic3A7DQogSXQgZG9lcyBub3QgbmVlZCB0byBzb2x2ZSBl dmVyeSBwcm9ibGVtIChlZyDigJMgbW9kaWZ5aW5nIHN1Yi1lbGVtZW50cyBpbiBuZXN0ZWQgYXJy YXlzKS4mbmJzcDsgQWRkaW5nIHVpZHMgdG8gZXZlcnkgbXVsdGktdmFsdWVkIGVsZW1lbnQgZG9l cyBub3Qgc3RyaWtlIHRoZSByaWdodCBiYWxhbmNlIGJldHdlZW4gdGhlIG5lZWRzIG9mIHRoZSBj bGllbnQgYW5kIHRoZSBuZWVkcyBvZiB0aGUgc2VydmljZSBwcm92aWRlci48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLUtlbGx5PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9y OmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkdhbmVzaA0KIGFu ZCBTYXNoaSBQcmFzYWQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIEF1 Z3VzdCAxMywgMjAxMiAxOjM1IEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QaGlsIEh1bnQ7IE1lbGluZGEgU2hvcmU8YnI+ DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPkVtbWFudWVsIERyZXV4OyBLZWxseSBHcml6emxlOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc2NpbV0gc2NpbSBEaWdlc3Qs IFZvbCA4LCBJc3N1ZSAyNDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVzcG9uZGluZyB0byBleHRyYWN0IG9mIE1l bGluZGEgU2hvcmUncyBtYWlsIGZyb20gZGlnZXN0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwO3dvcmQt d3JhcDogYnJlYWstd29yZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhlIGlzc3VlIGJlaW5nIHJhaXNlZCBoZXJlIGlzbid0IGVuZHBvaW50IGxvZ2ljLCBidXQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+bmV0d29yayB0cmFmZmljLCBhbmQgSSdtIHByZXR0eSBzdXJlIGl0J3Mgbm90IHZl cnkgaGVscGZ1bCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5yZXNwb25kIHRvIHRoZSBvYnNlcnZhdGlvbiB0aGF0 IHlvdXIgbW9kZWwgcmVxdWlyZXMgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5tZXNzYWdlcyB3aXRoIGEgY29t cGxhaW50IGFib3V0IHdoYXQgeW91IHNlZW0gdG8gdGhpbmsgaXMgYTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5jb21w bGV4IGFsZ29yaXRobSBmb3IgYXR0cmlidXRlIHByb2Nlc3NpbmcuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkl0IGRlcGVuZHMgb24gaG93IGl0J3MgaW1w bGVtZW50ZWQuIEknbSBjb25maWRlbnQgd2UgY2FuIGhhdmUgdGhlIGJlc3Qgb2YgYm90aCAtIHNp bXBsZSBBUEkgd2l0aCBsb3ctb3ZlcmhlYWQgaW1wbGVtZW50YXRpb24uIENhbiB3ZSBicmFpbnN0 b3JtIEhPVyB0aGlzIHByb3Bvc2FsIGNhbiBiZSBpbXBsZW1lbnRlZCByYXRoZXIgdGhhbiBXSFkN CiBpdCBjYW4ndCBiZSBpbXBsZW1lbnRlZCAod2hpY2ggaXMgbW9zdGx5IHdoYXQgSSd2ZSBiZWVu IGhlYXJpbmcgc28gZmFyKT8gQWZ0ZXIgYWxsLCBubyBvbmUgaGFzIGNoYWxsZW5nZWQgdGhlIGNs YWltIHRoYXQgdGhpcyBwcm9wb3NhbCBkcmFzdGljYWxseSBzaW1wbGlmaWVzIHRoZSBBUEkgZm9y IHRoZSBjbGllbnQsIHNvIGl0IHdvdWxkIGFwcGVhciB0byBiZSB3b3J0aCBkb2luZy4mbmJzcDtJ J20gc3VyZSB0aGVyZSdzIG1vcmUgdGhhbiBlbm91Z2ggaW50ZWxsZWN0dWFsDQogaG9yc2Vwb3dl ciBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gcHVsbCB0aGlzIG9mZiBpZiB3ZSBwdXQgb3VyIG1p bmRzIHRvIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+R2FuZXNoPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+T24gMTMgQXVndXN0IDIwMTIgMTM6NTQsIEdhbmVzaCBhbmQg U2FzaGkgUHJhc2FkICZsdDs8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jmd0OyZuYnNwO0kgc3Ryb25nbHkgb2JqZWN0IHRvIGFueXRoaW5nIHRoYXQgbGVhZHMg dG8gYSByZWFkIGJlZm9yZSBtb2RpZnkgcmVxdWlyZW1lbnQuIFRvbyBjb21wbGV4IGFuZCB0b28g Y2hhdHR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNvcnJ5IFBo aWwsIGJ1dCB5b3UncmUgY29udHJhZGljdGluZyB5b3Vyc2VsZiBoZXJlLiZuYnNwO1RoZXJlIHNl ZW1zIHRvIGJlIGFuIGF3ZnVsIGxvdCBvZiBtYXRjaGluZyAoaS5lLiwgcmVhZGluZykgZ29pbmcg b24gaW4gdGhlIHNwZWMgYXMgaXQgc3RhbmRzLCB3aXRoIGlmLXRoZW4gY2xhdXNlcyB0byBkbyBv bmUgdGhpbmcgb3IgYW5vdGhlciBpZg0KIHRoZSBtYXRjaCBlaXRoZXIgc3VjY2VlZHMgb3IgZmFp bHMuIFRoaXMgaXMgYSBjb21wbGV4LCBjaGF0dHkgcHJvdG9jb2wgcmlnaHQgbm93ITxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgTXVs dGktdmFsdWVkIGF0dHJpYnV0ZXM6Jm5ic3A7IEFuIGF0dHJpYnV0ZSB2YWx1ZSBpbiB0aGUgUEFU Q0ggcmVxdWVzdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYm9keSBpcyBhZGRlZCB0byB0aGUgdmFsdWUgY29sbGVjdGlvbiBpZiB0aGUgdmFsdWUgZG9l cyBub3QgZXhpc3Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGFuZCBtZXJnZWQgaWYgYSBtYXRjaGluZyB2YWx1ZSBpcyBwcmVzZW50LiZuYnNwOyBWYWx1 ZXMgYXJlIG1hdGNoZWQgYnk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGNvbXBhcmluZyB0aGUgdmFsdWUgU3ViLUF0dHJpYnV0ZSBmcm9tIHRoZSBQQVRD SCByZXF1ZXN0IGJvZHkgdG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSB2YWx1ZSBTdWItQXR0cmlidXRlIG9mIHRoZSBSZXNvdXJjZS4mbmJzcDsg QXR0cmlidXRlcyB0aGF0IGRvIG5vdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaGF2ZSBhIHZhbHVlIFN1Yi1BdHRyaWJ1dGU7IGUuZy4sIGFkZHJlc3Nl cywgb3IgZG8gbm90IGhhdmUgdW5pcXVlPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSBTdWItQXR0cmlidXRlcyBjYW5ub3QgYmUgbWF0Y2hlZCBh bmQgbXVzdCBpbnN0ZWFkIGJlIGRlbGV0ZWQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZW4gYWRkZWQuJm5ic3A7IFNwZWNpZmljIHZhbHVlcyBjYW4g YmUgcmVtb3ZlZCBmcm9tIGEgUmVzb3VyY2UgYnk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFkZGluZyBhbiAmcXVvdDtvcGVyYXRpb24mcXVvdDsgU3Vi LUF0dHJpYnV0ZSB3aXRoIHRoZSB2YWx1ZSAmcXVvdDtkZWxldGUmcXVvdDsgdG8gdGhlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUgaW4g dGhlIFBBVENIIHJlcXVlc3QgYm9keS4mbmJzcDsgQXMgd2l0aCBhZGRpbmcvdXBkYXRpbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0dHJpYnV0ZSB2 YWx1ZSBjb2xsZWN0aW9ucywgdGhlIHZhbHVlIHRvIGRlbGV0ZSBpcyBkZXRlcm1pbmVkIGJ5PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb21wYXJpbmcg dGhlIHZhbHVlIFN1Yi1BdHRyaWJ1dGUgZnJvbSB0aGUgUEFUQ0ggcmVxdWVzdCBib2R5IHRvPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgdmFsdWUg U3ViLUF0dHJpYnV0ZSBvZiB0aGUgUmVzb3VyY2UuJm5ic3A7IEF0dHJpYnV0ZXMgdGhhdCBkbyBu b3Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmUg YSB2YWx1ZSBTdWItQXR0cmlidXRlIG9yIHRoYXQgaGF2ZSBhIG5vbi11bmlxdWUgdmFsdWUgU3Vi LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQXR0cmli dXRlIGFyZSBtYXRjaGVkIGJ5IGNvbXBhcmluZyBhbGwgU3ViLUF0dHJpYnV0ZSB2YWx1ZXMgZnJv bTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIFBB VENIIHJlcXVlc3QgYm9keSB0byB0aGUgU3ViLUF0dHJpYnV0ZSB2YWx1ZXMgb2YgdGhlPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZXNvdXJjZS4mbmJz cDsgQSBkZWxldGUgb3BlcmF0aW9uIGlzIGlnbm9yZWQgaWYgdGhlIGF0dHJpYnV0ZSdzIG5hbWU8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIGluIHRo ZSBtZXRhLmF0dHJpYnV0ZXMgbGlzdC4mbmJzcDsgSWYgdGhlIHJlcXVlc3RlZCB2YWx1ZSB0byBk ZWxldGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRv ZXMgbm90IG1hdGNoIGEgdW5pcXVlIHZhbHVlIG9uIHRoZSBSZXNvdXJjZSB0aGUgc2VydmVyIE1B WTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJu IGEgSFRUUCA0MDAgZXJyb3IuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPkZvciBhIHNwZWMgdGhhdCBpcyBzdXBwb3NlZCB0byBiZSBhYm91dCBzaW1wbGljaXR5 LCB0aGUgYWJvdmUgZGVzY3JpcHRpb24gaXMgYW55dGhpbmcgYnV0IHNpbXBsZS4gSSBrbm93IHlv dSBndXlzIGhhdmUgd29ya2VkIGhhcmQgb24gdGhpcyBhbmQgSSBkb24ndCBtZWFuIHRvIGRpc3Bh cmFnZSB0aG9zZSBlZmZvcnRzLCBidXQgdGhpbmsgYWJvdXQNCiBob3cgdGhlIGFib3ZlIHBhc3Nh Z2Ugd291bGQgYXBwZWFyIHRvIGEgbmV3IHJlYWRlciAoaS5lLiwgYSBub3ZpY2UgdG8gdGhlIHNw ZWMsIG5vdCBhIHRlY2hub2xvZ3kgbm92aWNlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBpcyBzb21ldGhpbmcgZnVu ZGFtZW50YWxseSBicm9rZW4sIGFuZCBpdCBpcyB0aGlzOiBtdWx0aS12YWx1ZWQgYXR0cmlidXRl cyB3aXRob3V0IGEgdW5pcXVlIGlkZW50aWZpZXIgcGVyIHZhbHVlLiBJZiB5b3UgZG9uJ3QgZml4 IHRoYXQsIHlvdSB3b24ndCBnZXQgc2ltcGxpY2l0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XZSBrbm93IExEQVAgdHJlZXMg YXJlIGJyb2tlbiBmb3IgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMuIEFzIE1hcmsgV2FobDxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRw Oi8vd3d3LmxkYXAuY29tLzEvY29tbWVudGFyeS93YWhsLzIwMDUwNjE3XzAxLnNodG1sIiB0YXJn ZXQ9Il9ibGFuayI+ZmFtb3VzbHkNCiBjb21tZW50ZWQ8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmJhY2sgaW4gMjAwNSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6I0Y1RkFGRCI+ VW5mb3J0dW5hdGVseSwgc29tZSBvZiB0aGUgZW1lcmdpbmcgcHJvdG9jb2xzIHdoaWNoIGFsc28g aW50ZW5kIHRvIHJlcHJlc2VudCBhbmQgdHJhbnNmZXIgcGVyc29uYWwNCiBpZGVudGl0eSBpbmZv cm1hdGlvbiBoYXZlIHBlcmhhcHMgdGFrZW4gYSBzdGVwIGJhY2t3YXJkcyBieSBub3QgZXZlbiBj b25zaWRlcmluZyB0aGVzZSBpc3N1ZXMsIHBlcmhhcHMgc3dlZXBpbmcgdGhlbSB1bmRlciB0aGUg cnVnIGluIHRoZSBndWlzZSBvZiBzaW1wbGljaXR5LCBYTUxpZmljYXRpb24sIG9yICZxdW90O2Zp eCBpbiB0aGUgbmV4dCB2ZXJzaW9uJnF1b3Q7LCB3aGljaCBvbmx5IHBvc3Rwb25lIGZpbmRpbmcg aW50ZXJvcGVyYWJsZSBzb2x1dGlvbnMgdG8NCiBhbGxvd2luZyBhcHBsaWNhdGlvbnMgdG8gZXhw cmVzcyB0aGUgaWRlbnRpdHkgZW50cmllcyB0aGV5IHdhbnQgdG8gZXhwcmVzcy48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+JnF1b3Q7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U0NJTSBpcyBl eGFjdGx5IG9uZSBvZiB0aGVzZSAmcXVvdDtlbWVyZ2luZyBwcm90b2NvbHMmcXVvdDsgV2FobCB0 YWxrcyBhYm91dCwgYW5kIHdoYXQgSSBzZWUgbm93IHN0cmlrZXMgbWUgYXMgJnF1b3Q7c3dlZXBp bmcgdGhlc2UgaXNzdWVzIHVuZGVyIHRoZSBydWcgaW4gdGhlIGd1aXNlIG9mIHNpbXBsaWNpdHkm cXVvdDsuIEFwb2xvZ2llcyBmb3IgdGhlIGJsdW50bmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5NeSB0YWtlIGlzIHRoYXQg U1BzIGFyZSBfYWxyZWFkeV8gc3RydWdnbGluZyB0byBtYW5hZ2UgbXVsdGktdmFsdWVkIGF0dHJp YnV0ZXMsIGFuZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwOi8vZmYxOTU5LndvcmRwcmVzcy5jb20vMjAxMS8wNy8yOC9yZXBsYWNl LWEtdmFsdWUtb2YtYS1tdWx0aS12YWx1ZWQtYXR0cmlidXRlLyIgdGFyZ2V0PSJfYmxhbmsiPmV4 aXN0aW5nDQogbWVjaGFuaXNtcyBhcmUgY2x1bXN5PC9hPi4gVGhleSB3b3VsZCBiZSBncmF0ZWZ1 bCBmb3IgYSBzcGVjaWZpY2F0aW9uIHRoYXQgbWFkZSBvcGVyYXRpb25zIGVhc2llciBhdCB0aGUg Y29zdCBvZiBhIHJlLWVuZ2luZWVyZWQgc2NoZW1hLiBUaGF0IGNhbGxzIGZvciBzb21lIHRob3Vn aHQgbGVhZGVyc2hpcCBmcm9tIHRoaXMgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkdhbmVz aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+T24gMTMgQXVndXN0IDIwMTIgMTA6MTMsIFBoaWwgSHVudCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGhpbC5odW50 QG9yYWNsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgc3Ryb25nbHkgb2JqZWN0IHRvIGFueXRoaW5nIHRo YXQgbGVhZHMgdG8gYSByZWFkIGJlZm9yZSBtb2RpZnkgcmVxdWlyZW1lbnQuIFRvbyBjb21wbGV4 IGFuZCB0b28gY2hhdHR5LiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxicj4NCjxicj4NClBoaWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PGJy Pg0KT24gMjAxMi0wOC0xMiwgYXQgMTU6MjksIEdhbmVzaCBhbmQgU2FzaGkgUHJhc2FkICZsdDs8 YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nLmMu cHJhc2FkQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzBGMjQzRSI+Jmd0OyBXb3VsZCBpdCBoYXZlIHRvIGJlIHN0b3Jl ZCBvbiB0aGUgYWNjb3VudCBkYXRhYmFzZSBvZiB0aGUgc2VydmljZSBwcm92aWRlcj88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMEYyNDNFIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MEYyNDNFIj5ZZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzBGMjQzRSI+Jmd0OyBJZiBzbywgSSBiZWxpZXZl IHRoYXQgdGhpcyBpcyBpbXByYWN0aWNhYmxlIGluIHRoZSBjb3JlIHNjaGVtYS4mbmJzcDtJbmRl ZWQgaXQgaW1wbGllcyB0aGF0IGEgc2VydmljZSBwcm92aWRlciBtdXN0IGV4dGVuZCB0aGUgc2No ZW1hIG9mIGhpcyBhY2NvdW50IHJlcG9zaXRvcnkgKExEQVAgcGFydGl0aW9uLCBTUUwgZGIsIOKA pikgYW5kIOKAnHByZXBhcmUNCiBpdOKAnSBmb3IgU0NJTSBpbnRlZ3JhdGlvbi48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPldoeT8gVGhhdCBkb2Vzbid0IG5lY2Vz c2FyaWx5IGZvbGxvdy4gSW1wbGVtZW50YXRpb24gaXMgaW5kZXBlbmRlbnQgb2YgcmVwcmVzZW50 YXRpb24uIFdlJ3JlIHRhbGtpbmcgYWJvdXQgYSBjaGFuZ2UgaW4gcmVwcmVzZW50YXRpb24gdG8g bWFrZSB0aGUgQVBJIGNsZWFuZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+QXMgYSBzaW1wbGUgZXhhbXBsZSwgaWYgYW4gTERB UCBub2RlIGlzIGJlaW5nIHVzZWQgdG8gaG9sZCBhIGxpc3Qgb2YgY29tbWEtc2VwYXJhdGVkIGVt YWlsIGFkZHJlc3NlcywgaXQgY2FuIGp1c3QgYXMgZWFzaWx5IHN0b3JlIGNvbW1hLXNlcGFyYXRl ZCBuYW1lLXZhbHVlIHBhaXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPm1haWw6IDxhIGhyZWY9Im1haWx0bzpqb2huX3Nt aXRoQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG5fc21pdGhAeWFob28uY29tPC9hPiwg PGEgaHJlZj0ibWFpbHRvOmpvaG4uc21pdGhAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+am9o bi5zbWl0aEBnbWFpbC5jb208L2E+LCA8YSBocmVmPSJtYWlsdG86anNtaXRoMTk3MEBob3RtYWls LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpzbWl0aDE5NzBAaG90bWFpbC5jb208L2E+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Y2FuIGJlIGNoYW5nZWQgdG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5tYWlsOiZuYnNwO2FhNjYtZGFmOWVhM2JkOTAyPTxhIGhyZWY9 Im1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvaG5fc21pdGhA eWFob28uY29tPC9hPiw5Y2RhLTg2NDZjMzA4NWJiZj08YSBocmVmPSJtYWlsdG86am9obi5zbWl0 aEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2huLnNtaXRoQGdtYWlsLmNvbTwvYT4sJm5i c3A7N2E2ZDFkZTY2NGUxPTxhIGhyZWY9Im1haWx0bzpqc21pdGgxOTcwQGhvdG1haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+anNtaXRoMTk3MEBob3RtYWlsLmNvbTwvYT48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlRoYXQncyB3aHkgSSBhc2tlZCBpZiB0aGVyZSB3YXMgYW4gU1AgcmVwcmVzZW50 YXRpdmUgb24gdGhpcyB3b3JraW5nIGdyb3VwIHdobyBjb3VsZCBleHBsYWluIHdoYXQgc3VjaCBh IGNoYW5nZSBjb3VsZCBtZWFuIGZvciB0aGVtLiBBcyBvZiBub3csIGl0IGxvb2tzIGxpa2Ugb3Ro ZXINCiBwZW9wbGUgYXJlIHByZXN1bWluZyB0aGF0IFNQcyB3aWxsIG5vdCBiZSBhYmxlIHRvIGlt cGxlbWVudCB0aGVzZSBjaGFuZ2VzIGVhc2lseSBhbmQgYXJlIHJlamVjdGluZyB0aGVtIGZvciB0 aGF0IHJlYXNvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJk cyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5HYW5lc2g8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIDEzIEF1Z3VzdCAyMDEyIDA0 OjI5LCBFbW1hbnVlbCBEcmV1eCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVkcmV1eEBjbG91ZGl3YXku Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZWRyZXV4QGNsb3VkaXdheS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6YmxhY2siPsOwPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNr Ij4mbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPmFkZHJlc3Nlcy4z Y2JhYWZmOGU4NGUuc3RyZWV0LW51bWJlciA9DQogJnF1b3Q7MjQzJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzBGMjQzRSI+V2hlcmUgd291bGQ8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj4zY2JhYWZmOGU4NGU8L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MEYyNDNFIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzBGMjQzRSI+Y29tZQ0KIGZyb20/IFdvdWxkIGl0IGhhdmUgdG8gYmUgc3RvcmVkIG9uIHRo ZSBhY2NvdW50IGRhdGFiYXNlIG9mIHRoZSBzZXJ2aWNlIHByb3ZpZGVyPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMwRjI0M0UiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMwRjI0M0Ui PklmIHNvLCBJIGJlbGlldmUgdGhhdCB0aGlzIGlzIGltcHJhY3RpY2FibGUgaW4gdGhlIGNvcmUg c2NoZW1hLiBJbmRlZWQgaXQgaW1wbGllcyB0aGF0IGEgc2VydmljZSBwcm92aWRlciBtdXN0IGV4 dGVuZCB0aGUgc2NoZW1hIG9mIGhpcyBhY2NvdW50IHJlcG9zaXRvcnkgKExEQVAgcGFydGl0aW9u LCBTUUwgZGIsIOKApikgYW5kIOKAnHByZXBhcmUNCiBpdOKAnSBmb3IgU0NJTSBpbnRlZ3JhdGlv bi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMEYyNDNFIj5UaGlzIHdvdWxkIGJlIGEgc2hvdyBz dG9wcGVyLiBTQ0lNIG11c3QgYmUgdHJhbnNwYXJlbnQsIGFuZCBtdXN0IGJlIGFibGUgdG8gYmUg cHV0IG9uIHRvcCBvZiBhbiBleGlzdGluZyBzeXN0ZW0gdG8gcHJvdmlkZSBwcm92aXNpb25pbmcg YXBpcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMEYyNDNFIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMEYyNDNFIj5TYWlkIGRpZmZlcmVudGx5LCBTQ0lNIG11c3Qgbm90IGJlIGlu dHJ1c2l2ZSBmb3IgZXhpc3Rpbmcgc3lzdGVtcyBhbmQgbXVzdCBub3QgcmVxdWlyZSBtb2RpZmlj YXRpb25zIHRvIGFsbG93IGl0cyBpbnRlZ3JhdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MEYyNDNFIj5Db3JyZWN0IG1lIGlmIEkgbWlzdW5kZXJzdG9vZCB5b3VyIHN1Z2dlc3Rpb24uPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzBGMjQzRSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LS08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+RW1tYW51ZWwgRHJldXg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHA6Ly93d3cuY2xvdWRpd2F5LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8v d3d3LmNsb3VkaXdheS5jb208L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U ZWw6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9InRlbDolMkIzMyUyMDQlMjAyNiUyMDc4JTIwMTclMjA1OCIgdGFyZ2V0PSJfYmxhbmsiPiYj NDM7MzMgNCAyNiA3OCAxNyA1ODwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pk1vYmlsZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0idGVsOiUyQjMzJTIwNiUyMDQ3JTIwODElMjAyNiUyMDcwIiB0YXJnZXQ9Il9ibGFu ayI+JiM0MzszMyA2IDQ3IDgxIDI2IDcwPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+c2t5cGU6IEVtbWFudWVsLkRyZXV4PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTti b3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkdhbmVzaA0KIGFuZCBT YXNoaSBQcmFzYWQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Zy5jLnByYXNhZEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5nLmMucHJhc2FkQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPkVudm95w6kmbmJzcDs6 PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kaW1h bmNoZSAxMiBhb8O7dCAyMDEyIDA0OjUzPGJyPg0KPGI+w4AmbmJzcDs6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5LZWxseSBHcml6emxlPGJyPg0K PGI+Q2MmbmJzcDs6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNj aW1AaWV0Zi5vcmc8L2E+OyBQaGlsIEh1bnQ8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc2NpbV0gc2Np bSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAyNDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jmd0OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dy b3VuZDp3aGl0ZSI+TXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBkb24ndCBoYXZlIGEgdmFs dWUgc3ViLWF0dHJpYnV0ZSAoZWcgLSBhZGRyZXNzKSBoYXZlDQogdG8gc3BlY2lmaWVkIGNvbXBs ZXRlbHkgZm9yIHVuaXF1ZW5lc3MuJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlRoYXQncyBleGFjdGx5IHRoZSBwb2ludC4gSG93IGRvIHdlICZxdW90 O3NwZWNpZnkgY29tcGxldGVseSBmb3IgdW5pcXVlbmVzcyZxdW90Oz88L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5J biB0aGUgZXhhbXBsZSBiZWxvdywgaG93IGFyZSB5b3UgcHJvcG9zaW5nIHRoYXQgdGhlIGZvbGxv d2luZyBlbGVtZW50IGJlIHVwZGF0ZWQgaWYgd2UgY2FuJ3QgdXNlIHBvc2l0aW9uYWwgaW5kZXhl cz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5hZGRyZXNzZXNbMV0uc3RyZWV0LW51bWJlciA9ICZxdW90OzI0MyZx dW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlVzZXIgb2JqZWN0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj57PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC4uLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyBhZGRyZXNzZXM6IFs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDt0eXBlJnF1b3Q7IDogJnF1b3Q7aG9tZSZxdW90 Oyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm cXVvdDtzdHJlZXQtbnVtYmVyJnF1b3Q7IDogJnF1b3Q7MzUmcXVvdDssPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3RyZWV0LW5hbWUm cXVvdDsgOiAmcXVvdDtIaWdoIFJvYWQmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3VidXJiJnF1b3Q7IDogJnF1b3Q7RWFz dCBDYW1kZW4mcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7cG9zdGNvZGUmcXVvdDsgOiAmcXVvdDs1MzQ2JnF1b3Q7LDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N0 YXRlJnF1b3Q7IDogJnF1b3Q7U0EmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7Y291bnRyeSZxdW90OyA6ICZxdW90O0F1c3Ry YWxpYSZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsg fSw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IHs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDt0eXBl JnF1b3Q7IDogJnF1b3Q7b2ZmaWNlJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N0cmVldC1udW1iZXImcXVvdDsgOiAmcXVv dDsyMTMmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJnF1b3Q7c3RyZWV0LW5hbWUmcXVvdDsgOiAmcXVvdDtNYWluIFN0cmVldCZxdW90 Oyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm cXVvdDtzdWJ1cmImcXVvdDsgOiAmcXVvdDtBZGVsYWlkZSZxdW90Oyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtwb3N0Y29kZSZxdW90 OyA6ICZxdW90OzUwMDAmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7c3RhdGUmcXVvdDsgOiAmcXVvdDtTQSZxdW90Oyw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtj b3VudHJ5JnF1b3Q7IDogJnF1b3Q7QXVzdHJhbGlhJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyB9PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7IF08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj59PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SXQncyBpbXByYWN0aWNhbCB0byB1c2UgdGhlIHZhbHVlIGJlY2F1c2UgaXQncyB0aGUgd2hv bGUgZGljdGlvbmFyeSBlbGVtZW50Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj57PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZxdW90O3R5cGUmcXVvdDsgOiAmcXVvdDtvZmZp Y2UmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZxdW90O3N0 cmVldC1udW1iZXImcXVvdDsgOiAmcXVvdDsyMTMmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7ICZxdW90O3N0cmVldC1uYW1lJnF1b3Q7IDogJnF1b3Q7TWFpbiBT dHJlZXQmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZxdW90 O3N1YnVyYiZxdW90OyA6ICZxdW90O0FkZWxhaWRlJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyAmcXVvdDtwb3N0Y29kZSZxdW90OyA6ICZxdW90OzUwMDAmcXVv dDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZxdW90O3N0YXRlJnF1 b3Q7IDogJnF1b3Q7U0EmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7ICZxdW90O2NvdW50cnkmcXVvdDsgOiAmcXVvdDtBdXN0cmFsaWEmcXVvdDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj59PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XaXRoIG15IHBy b3Bvc2FsLCB0aGUgJnF1b3Q7YWRkcmVzc2VzJnF1b3Q7IGFycmF5IGdldHMgY29udmVydGVkIHRv IGEgZGljdGlvbmFyeSwgYW5kIHRoZW4gd2UgaGF2ZSBhIHN0YWJsZSB3YXkgb2YgcmVmZXJlbmNp bmcgdGhpcyBlbGVtZW50Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5hZGRyZXNzZXMuM2NiYWFmZjhl ODRlLnN0cmVldC1udW1iZXIgPSAmcXVvdDsyNDMmcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj57PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC4uLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyBhZGRyZXNzZXM6IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZxdW90O2Q2ZWEzNjU0NjJmNSZxdW90OyA6PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyB7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7dHlwZSZxdW90OyA6ICZx dW90O2hvbWUmcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7c3RyZWV0LW51bWJlciZxdW90OyA6ICZxdW90OzM1JnF1b3Q7LDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90 O3N0cmVldC1uYW1lJnF1b3Q7IDogJnF1b3Q7SGlnaCBSb2FkJnF1b3Q7LDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N1YnVyYiZxdW90 OyA6ICZxdW90O0Vhc3QgQ2FtZGVuJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3Bvc3Rjb2RlJnF1b3Q7IDogJnF1b3Q7NTM0 NiZxdW90Oyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmcXVvdDtzdGF0ZSZxdW90OyA6ICZxdW90O1NBJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2NvdW50cnkmcXVvdDsg OiAmcXVvdDtBdXN0cmFsaWEmcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgJm5ic3A7IH0sPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZu YnNwOyAmcXVvdDszY2JhYWZmOGU4NGUmcXVvdDsgOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDsgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3R5cGUmcXVvdDsgOiAmcXVvdDtvZmZpY2UmcXVvdDss PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1 b3Q7c3RyZWV0LW51bWJlciZxdW90OyA6ICZxdW90OzIxMyZxdW90Oyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdHJlZXQtbmFtZSZx dW90OyA6ICZxdW90O01haW4gU3RyZWV0JnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O3N1YnVyYiZxdW90OyA6ICZxdW90O0Fk ZWxhaWRlJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZxdW90O3Bvc3Rjb2RlJnF1b3Q7IDogJnF1b3Q7NTAwMCZxdW90Oyw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtzdGF0 ZSZxdW90OyA6ICZxdW90O1NBJnF1b3Q7LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2NvdW50cnkmcXVvdDsgOiAmcXVvdDtBdXN0cmFs aWEmcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IH08 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPn08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZiB5b3UncmUgcHJvcG9zaW5nIG9uZSBt ZWNoYW5pc20gZm9yIGNvbXBvc2l0ZSBhdHRyaWJ1dGVzIGFuZCBhbm90aGVyIG1lY2hhbmlzbSBm b3Igc2ltcGxlIGF0dHJpYnV0ZXMsIEkgd291bGQgc3VnZ2VzdCB0aGF0J3MgYWN0dWFsbHkgbW9y ZSBjb21wbGV4IHRoYW4gYWRvcHRpbmcgYSBzaW5nbGUgbWVjaGFuaXNtIHRoYXQgd29ya3MgdGhl IHNhbWUgd2F5IGZvcg0KIF9hbGxfIGF0dHJpYnV0ZXMuIFJlbWVtYmVyIHRoYXQgYSBsb3Qgb2Yg dGhlIGFkbWluaXN0cmF0aW9uIGlzIHByb2JhYmx5IGdvaW5nIHRvIGJlIHNjcmlwdGVkIHJhdGhl ciB0aGFuIGRvbmUgYnkgaGFuZCwgYW5kIGhhdmluZyB0d28gbWVjaGFuaXNtcyAoZGVwZW5kaW5n IG9uIHdoZXRoZXIgdGhlIGF0dHJpYnV0ZSBpcyBzaW1wbGUgb3IgY29tcG9zaXRlKSB3aWxsIGNv bXBsaWNhdGUgZXZlcnkgc2NyaXB0IHRoYXQgaGFzIHRvIGJlIHdyaXR0ZW4uPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGVyZSdzIGEgbG90IG9mIHRhbGsgYWJvdXQgdGhlICZxdW90O2J1cmRlbiZx dW90OyBvbiB0aGUgU1BzLCBidXQgSSBiZWxpZXZlIHRoaXMgaXMgb3ZlcmJsb3duLiBJcyB0aGVy ZSBhbnkgU1AgcmVwcmVzZW50YXRpdmUgaW4gdGhpcyBXRyB3aG8gY2FuIHRlbGwgdXMgd2hhdCB0 aGlzIHByb3Bvc2FsIHdpbGwgYWN0dWFsbHkgZW50YWlsIGZvciB0aGVtPzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+R2FuZXNoPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMTIgQXVn dXN0IDIwMTIgMTE6NTMsIEtlbGx5IEdyaXp6bGUgJmx0OzxhIGhyZWY9Im1haWx0bzprZWxseS5n cml6emxlQHNhaWxwb2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5rZWxseS5ncml6emxlQHNhaWxw b2ludC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkdhbmVzaCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VGhpcyBpcyBleGFjdGx5IGhvdyBQQVRDSCB3b3JrcyBpbiBTQ0lNIDEuMC4g Jm5ic3A7TXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgdGhhdCBoYXZlIGEgdmFsdWUgc3ViLWF0dHJp YnV0ZSBjYW4gYmUgcmVtb3ZlZCBieSBzcGVjaWZ5aW5nIG9ubHkgdGhlIHZhbHVlIHNpbmNlIGl0 IGlzIHVuaXF1ZS4NCiAmbmJzcDtNdWx0aS12YWx1ZWQgYXR0cmlidXRlcyB0aGF0IGRvbid0IGhh dmUgYSB2YWx1ZSBzdWItYXR0cmlidXRlIChlZyAtIGFkZHJlc3MpIGhhdmUgdG8gc3BlY2lmaWVk IGNvbXBsZXRlbHkgZm9yIHVuaXF1ZW5lc3MuICZuYnNwO0FzIEkgaGF2ZSBzYWlkIGJlZm9yZSwg SSBhbSB2ZXJ5IG9wcG9zZWQgdG8gYWRkaW5nIGEgdW5pcXVlIGlkZW50aWZpZXIgdG8gZWFjaCBl bGVtZW50IGluIGEgbXVsdGktdmFsdWVkIGNvbGxlY3Rpb24gZHVlIHRvIHRoZSBidXJkZW4NCiBp dCB3aWxsIHB1dCBvbiBTUHMuICZuYnNwO0lzIGl0IGVsZWdhbnQ/ICZuYnNwO05vLiAmbmJzcDtJ cyBpdCBmdW5jdGlvbmFsPyAmbmJzcDtZZXMuICZuYnNwO1dpbGwgdGhpcyBub24tZWxlZ2FuY2Ug YWZmZWN0IGFkb3B0aW9uPyAmbmJzcDtNeSBvcGluaW9uIGlzIHRoYXQgYWRkaW5nIHVuaXF1ZSBr ZXlzIHRvIGVhY2ggZWxlbWVudCB3aWxsIGhhdmUgYSBtdWNoIG1vcmUgZGV0cmltZW50YWwgZWZm ZWN0IG9uIGFkb3B0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij5JIGRvIGJlbGlldmUgdGhhdCBpbiBnZW5lcmFsIFBBVENIIGNhbiBiZSBtYWRlIG1vcmUgaW50 dWl0aXZlIHdpdGhvdXQgYWRkaW5nIHVpZHMgdG8gZWFjaCBlbGVtZW50LiAmbmJzcDtUaGUgdmVy YnMgdGhhdCB5b3UgcHJvcG9zZSBtYWtlIHNlbnNlLiAmbmJzcDtUaGVyZSBpcyBhbHNvIGEgSlNP Tg0KIFBhdGNoIGluZm9ybWF0aW9uYWwgZHJhZnQgaW4gdGhlIElFVEYgdGhhdCBpcyBpbnRlcmVz dGluZyAtJm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDIiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRjaC0wMjwvYT4uICZuYnNwO0l0 IHJlbGllcyBvbiBhIEpTT04gUG9pbnRlciBkcmFmdCB3aGljaCB1c2VzDQogaW5kZXgtYmFzZWQg YWRkcmVzc2luZyBmb3IgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMuICZuYnNwO0kgdGhpbmsgdGhh dCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQgd2l0aGluIHRoZSBX RyBhbmQgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIGxlYWQgdGhpcyBlZmZvcnQuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkknbSBjdXJpb3VzIGlmIGFueW9uZSBlbHNl IGluIHRoZSBXRyBpcyBpbiBmYXZvciBvZiB1bmlxdWUgaWRlbnRpZmllcnMgZm9yIGV2ZXJ5IG11 bHRpLXZhbHVlZCBlbGVtZW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4tLUtlbGx5PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWdu PSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSIxMDAlIiBhbGlnbj0i Y2VudGVyIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxh IGhyZWY9Im1haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2lt LWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPls8YSBocmVmPSJtYWlsdG86c2NpbS1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2NpbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCiBvbiBiZWhhbGYgb2YgR2Fu ZXNoIGFuZCBTYXNoaSBQcmFzYWQgWzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2FkQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPl08YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U2F0 dXJkYXksIEF1Z3VzdCAxMSwgMjAxMiAxMDo1MCBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbCBIdW50PGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc2NpbV0gc2NpbSBEaWdlc3QsIFZvbCA4LCBJc3N1ZSAy NDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBoaWwsPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBy ZWFzb24gd2UgY2Fubm90IHVzZSB0aGUgdmFsdWUgaXRzZWxmIHRvIGlkZW50aWZ5IGFuIGVsZW1l bnQgaXMgdGhhdCB0aGlzIG1ldGhvZCB3aWxsIG9ubHkgd29yayBmb3Igc2ltcGxlIGVsZW1lbnRz LCBub3QgZm9yIG5lc3RlZCBzdHJ1Y3R1cmVzLiBpLmUuLCBpZiB3ZSBoYWQgYW4gYXJyYXkgb2Yg ZGljdGlvbmFyaWVzIChlLmcuLCB3ZSBoYWQgdG8gcmVjb3JkDQogYW4gYXJyYXkgb2YgYWRkcmVz c2VzIGZvciBlYWNoIGN1c3RvbWVyLCB3aXRoIGVhY2ggYWRkcmVzcyBlbGVtZW50IGhhdmluZyBz dWItZWxlbWVudHMgbGlrZSBzdHJlZXQgbnVtYmVyLCBzdHJlZXQgbmFtZSwgc3VidXJiLCBldGMu KSwgdGhlbiBpdCB3b3VsZCBiZSBjbHVtc3kgdG8gc3VwcGx5IHRoZSBlbnRpcmUgdmFsdWUgb2Yg dGhlIGFycmF5IGVsZW1lbnQgYmVjYXVzZSBpdCdzIGl0c2VsZiBhIGRpY3Rpb25hcnkuIENyZWF0 aW5nIGEgdW5pcXVlDQoga2V5IGZvciBlYWNoIGVsZW1lbnQgc2NhbGVzIGJldHRlci48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5HYW5lc2g8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIDEyIEF1Z3VzdCAyMDEyIDAx OjEyLCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkdhbmVzaCw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGVyZSdzIHRoZSBzYW1wbGUgdGhhdCBj b25jZXJuZWQgbWUuLi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlIHR3byBvcGVyYXRpb25zIGRpZmZlciBzaWduaWZpY2FudGx5LCBhbmQgaXQncyBu b3QgdmVyeSBpbnR1aXRpdmUuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ V2l0aCBteSBzdWdnZXN0aW9uLCBoZXJlJ3MgaG93IHRvIGRlbGV0ZSBhIHNpbmdsZSBtZW1iZXIg ZnJvbSBhIGdyb3VwOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0NjMtNDY5Mi1i NGZkLTliNGRhM2Y5MDhjZSBIb3N0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFu ayI+ZXhhbXBsZS5jb208L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkFjY2VwdDoNCiBhcHBsaWNhdGlvbi9qc29uIEF1dGhvcml6YXRpb246IEJlYXJl ciBoNDgwZGpzOTNoZDggRVRhZzogVy8mcXVvdDthMzMwYmM1NGYwNjcxYzkmcXVvdDsgezwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtvcGVyYXRpb25zJnF1b3Q7IDogWzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj57PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90O1JF VElSRSZxdW90OyA6IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7a2V5JnF1b3Q7 IDogJnF1b3Q7bWVtYmVycy4yODE5YzIyMy03Zjc2LTQ1M2EtOTE5ZC00MTM4NjE5MDQ2NDYmcXVv dDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+fTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij59PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPl0gfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPllvdSBnYXZlIG90aGVyIGV4YW1wbGVzIG9mIGFuIGF0dHJpYnV0ZSB3aXRoIGFuIGlk ZW50aWZpZXIgdGhhdCBtYXRjaGVkIHRoYXQgdmFsdWUgb3Igb2YgaWRlbnRpZmllcnMgdGhhdCB3 ZXJlIGFkZGl0aW9uYWwgdW5pcXVlIGtleXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkdpdmVuIHRoYXQgbXVsdGktdmFs dWVzIG11c3QgYmUgZWFjaCB1bmlxdWUsIEkgZG9uJ3Qgc2VlIHRoZSBwb2ludCBvZiB0aGUgZXh0 cmEgaW5kZXhpbmcgdG8gc3VwcG9ydCB0aGlzLiBKdXN0IHVzZSB0aGUgdmFsdWUgYXMgdGhlIGl0 ZW0geW91IHdpc2ggdG8gZGVsZXRlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGFncmVlLCB0aGUgZGVsZXRlIHZhbHVl IG9wZXJhdGlvbiBjb3VsZCBiZSBtb3JlIGV4cGxpY2l0IGFuZCBjbGVhciBpbiBnZW5lcmFsLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5QaGlsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5AaW5kZXBlbmRlbnRpZDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tLyIgdGFy Z2V0PSJfYmxhbmsiPnd3dy5pbmRlcGVuZGVudGlkLmNvbTwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEzLjVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIDIwMTItMDgtMTEsIGF0IDI6MzAgQU0sIEdh bmVzaCBhbmQgU2FzaGkgUHJhc2FkIHdyb3RlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7Jm5ic3A7IEZvciB0aGUgbXVs dGktdmFsdWUgZXhhbXBsZSB5b3UgZ2F2ZSB5b3UgdXNlZCB0aGUgdmFsdWUgYXMgdGhlIGF0dHJp YnV0ZSBuYW1lIGtleS4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Tm93IEknbSBjb25mdXNlZCA6LSkuIEkgZG9uJ3Qg YmVsaWV2ZSBhbnkgb2YgbXkgZXhhbXBsZXMgZXZlciB1c2VkIGEgdmFsdWUgYXMgdGhlIGtleS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5Db3VsZCB5b3UgcGxlYXNlIHNob3cgbWUgd2hpY2ggZXhhbXBsZSB5b3Ug bWVhbiwgYW5kIHdoaWNoIHBhcnRzIG9mIGl0IHlvdSBiZWxpZXZlIHRvIGJlIHRoZSB2YWx1ZT88 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5SZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5HYW5lc2gmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9uIDExIEF1 Z3VzdCAyMDEyIDEzOjU5LCBQaGlsIEh1bnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwaGlsLmh1bnRA b3JhY2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsg d3JvdGU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpGb3IgdGhlIG11bHRp LXZhbHVlIGV4YW1wbGUgeW91IGdhdmUgeW91IHVzZWQgdGhlIHZhbHVlIGFzIHRoZSBhdHRyaWJ1 dGUgbmFtZSBrZXkuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhdCBtZWFucyBhIGxvdCBtb3JlIGNv bXBsZXggaW5kZXhpbmcgc3RydWN0dXJlLiBCZXR0ZXIgdG8ganVzdCBzYXkgZGVsZXRlIGEgc3Bl Y2lmaWMgdmFsdWUuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIHNwZWMgYWxyZWFkeSBhbGxvd3Mg bXVsdGlwbGUgdmFsdWVzIHRvIGhhdmUgdGFncyBsaWtlIGhvbWUsIHdvcmssIGV0Yy48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+UGhpbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCk9uIDIwMTItMDgtMTAsIGF0IDIxOjQ1 LCBHYW5lc2ggYW5kIFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mZ3Q7Jm5ic3A7SW4geW91ciBleGFtcGxlIHlvdSBhcmUgY29uZmxhdGluZyB2YWx1ZSB3 aXRoIGFuIGF0dHJpYnV0ZSBpZC4mbmJzcDs8YnI+DQo8YnI+DQpJIGRvbid0IGJlbGlldmUgc28u PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPkknbSBhZG9wdGluZyBhIG1vZGVsIHdoZXJlIGV2ZXJ5IGF0dHJpYnV0ZSBvZiB0aGUg cmVzb3VyY2UgaXMgYSBrZXktdmFsdWUgcGFpci4gVGhlIGtleSBpcyBhIG5hbWUgb3IgSUQuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Rm9yIG5vbi1yZXBlYXRpbmcgYXR0cmlidXRlcyAoYm90aCBzaW1wbGUgYW5k IGNvbXBvc2l0ZSksIHRoZSBrZXkgaXMgdGhlIGF0dHJpYnV0ZSBuYW1lIGl0c2VsZi4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+U2ltcGxlIGF0dHJpYnV0ZTo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5LZXk6 ICZxdW90O2RvYiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlZhbHVlOiAm cXVvdDswMSBKYW4gMTk3MCZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Rm9yIGNvbXBvc2l0 ZSBhdHRyaWJ1dGVzLCB0aGUga2V5IGVtcGxveXMgZG90IG5vdGF0aW9uIHRvIHNwZWNpZnkgdGhl IGZ1bGx5LXF1YWxpZmllZCBhdHRyaWJ1dGUgbmFtZSwgZS5nLiwgJnF1b3Q7YWRkcmVzcy5wb3N0 Y29kZSZxdW90Oy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Db21wb3NpdGUgYXR0cmlidXRlOjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPktleTogJnF1b3Q7YWRkcmVzcy5zdHJlZXQtbnVtYmVyJnF1b3Q7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+VmFsdWU6ICZxdW90OzEwJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+S2V5 OiAmcXVvdDthZGRyZXNzLnN1YnVyYiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPlZhbHVlOiAmcXVvdDtFYXN0IENhbWRlbiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZvciByZXBl YXRpbmcgKG11bHRpLXZhbHVlZCkgYXR0cmlidXRlcywgSSdtIHN1Z2dlc3RpbmcgdGhhdCB0aGVy ZSBiZSBuZXcga2V5cyBmb3IgZWFjaCBpbmRpdmlkdWFsIHZhbHVlLCBvdGhlcndpc2UgdGhleSBh cmUgaW1wb3NzaWJsZSB0byBkaXN0aW5ndWlzaCwgYW5kIGEgcG9zaXRpb25hbCBpbmRleCBpcyBp bmFkZXF1YXRlLiBTbyB3ZSBjb252ZXJ0IHRoZSBhcnJheQ0KIGludG8gYSBkaWN0aW9uYXJ5IGFu ZCB0aGlzIHRoZW4gYmVjb21lcyBhIGNvbXBvc2l0ZSBhdHRyaWJ1dGUgdXNpbmcgZG90IG5vdGF0 aW9uIGZvciB0aGUga2V5Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk11bHRpLXZhbHVlZCBhdHRyaWJ1dGU6PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+S2V5OiAmcXVvdDtlbWFpbHMuN2RmY2I0NDQtNzRkOC00ZjE3LWFhNjYtZGFm OWVhM2JkOTAyJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VmFsdWU6ICZx dW90OzxhIGhyZWY9Im1haWx0bzpqb2huX3NtaXRoQHlhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmpvaG5fc21pdGhAeWFob28uY29tPC9hPiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlNvIHRoaXMgYWxs b3dzIHVzIHRvIGFwcGx5IHVuaWZvcm0gdHJlYXRtZW50IHRvIGFueSBhcmJpdHJhcmlseSBkZWVw IHJlc291cmNlIHN0cnVjdHVyZS4gV2UgY2FuIHJlZmVyIHRvIGV2ZXJ5IGxlYWYgdmFsdWUgd2l0 aCBhIGtleSB0aGF0IGlzIHRoZSBmdWxseS1xdWFsaWZpZWQgbmFtZSB1c2luZyBkb3Qgbm90YXRp b24uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+VGhlIHZlcmJzIGFyZSBqdXN0IHVuYW1iaWd1b3VzIG9wZXJhdGlv bnMgb24gdGhlc2UgKG5vdykgZXhwbGljaXRseSBhZGRyZXNzYWJsZSBhdHRyaWJ1dGVzLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPklOQ0xVREUgdG8gYSBjb2xsZWN0aW9uIGFuZCBzcGVjaWZ5IG9ubHkgdGhlIHZh bHVlLiBUaGUga2V5IGlzIGdlbmVyYXRlZCBhbmQgcmV0dXJuZWQuIFRoZSBmdWxseS1xdWFsaWZp ZWQga2V5IGlzICZsdDtjb2xsZWN0aW9uLW5hbWUmZ3Q7LiZsdDtuZXdseS1nZW5lcmF0ZWQtSUQm Z3Q7IGFuZCB0aGUgdmFsdWUgaXMgd2hhdCB3YXMgc3BlY2lmaWVkIGluIHRoZSBJTkNMVURFLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlJFUExBQ0UgYSBmdWxseS1xdWFsaWZpZWQga2V5IHdpdGggYSBuZXcgdmFs dWUuIElmIHRoZSBrZXkgZG9lc24ndCBleGlzdCwgcmV0dXJuIGEgJnF1b3Q7NDA0IE5vdCBGb3Vu ZCZxdW90Oy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QTEFDRSBhIHZhbHVlIGF0IHRoZSBsb2dpY2FsIGxvY2F0 aW9uIGltcGxpZWQgYnkgdGhlIGZ1bGx5LXF1YWxpZmllZCBrZXkuIElmIHRoZXJlIGlzIGFscmVh ZHkgYSBrZXkgd2l0aCB0aGF0IG5hbWUsIHJldHVybiBhICZxdW90OzQwOSBDb25mbGljdCZxdW90 Oy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5GT1JDRSB0aGUgZnVsbHktcXVhbGlmaWVkIGtleSB0byBob2xkIHRo ZSBnaXZlbiB2YWx1ZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGV4aXN0ZWQgYmVmb3JlIG9y IG5vdC4gT25seSBlcnJvcnMgcG9zc2libGUgYXJlICZxdW90OzQwMCBCYWQgUmVxdWVzdCZxdW90 OyBhbmQgJnF1b3Q7NTAwIEludGVybmFsIEVycm9yJnF1b3Q7Ljwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJFVElS RSBhbiBhdHRyaWJ1dGUgb3IgYSBjb2xsZWN0aW9uIGdpdmVuIGl0cyBmdWxseS1xdWFsaWZpZWQg a2V5LiBUaGUgaW1wbGVtZW50YXRpb24gd2lsbCBkZXRlcm1pbmUgd2hldGhlciB0aGUgYXR0cmli dXRlIHdpbGwgZGlzYXBwZWFyIGVudGlyZWx5IG9yIHdpbGwgZXhpc3QgaG9sZGluZyBhIG51bGwg dmFsdWUgKHRoZSBibGFuayBzdHJpbmcgJnF1b3Q7JnF1b3Q7IG9yIHRoZQ0KIGVtcHR5IG9iamVj dCB7fSApLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkknbGwgZXhwbGFpbiBpbiBhIHNlcGFyYXRlIHBvc3Qgd2h5 IHdlIG5lZWQgb3BlcmF0aW9uIHZlcmJzIGxpa2UgdGhlc2UgdGhhdCBhcmUgaW5kZXBlbmRlbnQg b2YgdGhlIEhUVFAgdmVyYnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5HYW5lc2g8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gMTEgQXVndXN0IDIwMTIgMTA6MzgsICZs dDs8YSBocmVmPSJtYWlsdG86c2NpbS1yZXF1ZXN0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ c2NpbS1yZXF1ZXN0QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBkaWdlc3Qgd2l0aG91dCBhbGwgdGhlIGluZGl2aWR1YWwg bWVzc2FnZTxicj4NCmF0dGFjaG1lbnRzIHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGln ZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0PGJyPg0Kc3Vic2NyaXB0aW9uLiAmbmJzcDtUbyBkbyBz bywgZ28gdG88YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NjaW08L2E+PGJyPg0KPGJyPg0KQ2xpY2sgdGhlICdVbnN1YnNjcmliZSBv ciBlZGl0IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICZxdW90O0dldDxicj4NCk1J TUUgb3IgUGxhaW4gVGV4dCBEaWdlc3RzPyZxdW90OyB0byBNSU1FLiAmbmJzcDtZb3UgY2FuIHNl dCB0aGlzIG9wdGlvbjxicj4NCmdsb2JhbGx5IGZvciBhbGwgdGhlIGxpc3QgZGlnZXN0cyB5b3Ug cmVjZWl2ZSBhdCB0aGlzIHBvaW50Ljxicj4NCjxicj4NCjxicj4NCjxicj4NClNlbmQgc2NpbSBt YWlsaW5nIGxpc3Qgc3VibWlzc2lvbnMgdG88YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnNjaW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zY2ltQGlldGYub3JnPC9h Pjxicj4NCjxicj4NClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdp ZGUgV2ViLCB2aXNpdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW08L2E+PGJyPg0Kb3IsIHZpYSBlbWFp bCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzY2ltLXJlcXVlc3RAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zY2ltLXJlcXVlc3RAaWV0Zi5vcmc8L2E+PGJyPg0KPGJyPg0KWW91IGNh biByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5nIHRoZSBsaXN0IGF0PGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzY2ltLW93bmVyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c2NpbS1vd25lckBpZXRmLm9yZzwvYT48YnI+DQo8YnI+DQpXaGVuIHJlcGx5aW5nLCBwbGVh c2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljPGJyPg0KdGhh biAmcXVvdDtSZTogQ29udGVudHMgb2Ygc2NpbSBkaWdlc3QuLi4mcXVvdDs8YnI+DQo8YnI+DQpU b2RheSdzIFRvcGljczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7MS4gUmU6IFNDSU0gUHJvdG9j b2wgLSAzIHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVudCAoUGhpbCBIdW50KTxicj4NCjxicj4N Cjxicj4NCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLTxicj4NCkZyb206 Jm5ic3A7UGhpbCBIdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7PGJyPg0KVG86Jm5i c3A7R2FuZXNoIGFuZCBTYXNoaSBQcmFzYWQgJmx0OzxhIGhyZWY9Im1haWx0bzpnLmMucHJhc2Fk QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmcuYy5wcmFzYWRAZ21haWwuY29tPC9hPiZndDs8 YnI+DQpDYzombmJzcDsmcXVvdDtEaW9kYXRpLCBNYXJrJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86TWFyay5EaW9kYXRpQGdhcnRuZXIuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWFyay5EaW9kYXRp QGdhcnRuZXIuY29tPC9hPiZndDssIEVtbWFudWVsIERyZXV4ICZsdDs8YSBocmVmPSJtYWlsdG86 ZWRyZXV4QGNsb3VkaXdheS5jb20iIHRhcmdldD0iX2JsYW5rIj5lZHJldXhAY2xvdWRpd2F5LmNv bTwvYT4mZ3Q7LCBUcmV5IERyYWtlICZsdDs8YSBocmVmPSJtYWlsdG86dHJleS5kcmFrZUB1bmJv dW5kaWQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dHJleS5kcmFrZUB1bmJvdW5kaWQuY29tPC9hPiZn dDssDQogS2VsbHkgR3JpenpsZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlbGx5LmdyaXp6bGVAc2Fp bHBvaW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtlbGx5LmdyaXp6bGVAc2FpbHBvaW50LmNvbTwv YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnNjaW1AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2NpbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNjaW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCkRhdGU6Jm5i c3A7RnJpLCAxMCBBdWcgMjAxMiAxNzozNjo1NCAtMDcwMDxicj4NClN1YmplY3Q6Jm5ic3A7UmU6 IFtzY2ltXSBTQ0lNIFByb3RvY29sIC0gMyBzdWdnZXN0aW9ucyBmb3IgaW1wcm92ZW1lbnQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5HYW5lc2gsPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SW4geW91ciBleGFtcGxlIHlvdSBhcmUgY29uZmxhdGluZyB2YWx1ZSB3aXRoIGFuIGF0dHJpYnV0 ZSBpZC4gSSBmaW5kIHRoYXQgY29uZnVzaW5nLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgYWdyZWUg dGhvdWdoIHRoYXQgb3BlcmF0aW9ucyBpbiBwYXRjaCBjb3VsZCBiZSBhIGxvdCBtb3JlIGV4cGxp Y2l0LiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkVnIGV4cGxpY2l0bHkgZGVsZXRpbmcgYSB2YWx1ZSBi eSBzYXlpbmcgZGVsZXRlIG9yIHJldGlyZS4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48YnI+DQpQaGlsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxicj4NCk9uIDIwMTItMDgtMTAsIGF0IDE2OjE5LCBHYW5lc2ggYW5k IFNhc2hpIFByYXNhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmcuYy5wcmFzYWRAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+Zy5jLnByYXNhZEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmZ3Q7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGNvbmNlcm5lZCBhYm91dCB5 b3VyIHNlY29uZCBzdWdnZXN0aW9uOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5MZXQncyBkaXNjdXNzIHRoYXQgbm93Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSB0cmFk ZS1vZmZzIGFyZSB2ZXJ5IGNsZWFyIGhlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UHJvczo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Qcm8gMS4gVGhlIEFQSSB0byBtYW5pcHVsYXRlIHJlc291cmNlcyBiZWNvbWVzIHNvIG11 Y2ggY2xlYW5lciwgY29uc2lzdGVudCBhbmQgaW50dWl0aXZlIHdoZW4gZXZlcnkgaW5kaXZpZHVh bCBhdHRyaWJ1dGUgdmFsdWUgZ2V0cyBpdHMgb3duIElELjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhlcmUncyBo b3cgdG8gZGVsZXRlIGEgc2luZ2xlIG1lbWJlciBmcm9tIGEgR3JvdXAsIGFzIHBlciB0aGUgY3Vy cmVudCBzcGVjOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBQQVRDSCAvR3JvdXBzL2FjYmYzYWU3LTg0 NjMtNDY5Mi1iNGZkLTliNGRhM2Y5MDhjZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBIb3N0OiA8YSBocmVm PSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208L2E+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IEFjY2VwdDogYXBwbGljYXRpb24vanNvbjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEVU YWc6IFcvJnF1b3Q7YTMzMGJjNTRmMDY3MWM5JnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c2NoZW1hcyZxdW90 OzogWyZxdW90O3VybjpzY2ltOnNjaGVtYXM6Y29yZToxLjAmcXVvdDtdLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDttZW1iZXJzJnF1b3Q7OiBbPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGlzcGxheSZxdW90OzogJnF1b3Q7QmFicyBK ZW5zZW4mcXVvdDssPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O3ZhbHVlJnF1b3Q7OiAmcXVvdDsyODE5YzIyMy03Zjc2LTQ1M2EtOTE5 ZC00MTM4NjE5MDQ2NDYmcXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7b3BlcmF0aW9uJnF1b3Q7OiAmcXVvdDtkZWxldGUmcXVv dDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+ DQpIZXJlJ3MgaG93IHRvIGRlbGV0ZSBBTEwgbWVtYmVycyBmcm9tIGEgZ3JvdXAgYWNjb3JkaW5n IHRvIHRoZSBjdXJyZW50IHNwZWM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFBBVENIIC9Hcm91cHMv YWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEhv c3Q6IDxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5leGFtcGxl LmNvbTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQWNjZXB0OiBhcHBsaWNhdGlvbi9qc29uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IEF1dGhvcml6YXRpb246IEJlYXJlciBoNDgwZGpzOTNoZDg8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgRVRhZzogVy8mcXVvdDthMzMwYmM1NGYwNjcxYzkmcXVvdDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtz Y2hlbWFzJnF1b3Q7OiBbJnF1b3Q7dXJuOnNjaW06c2NoZW1hczpjb3JlOjEuMCZxdW90O10sPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O21ldGEmcXVvdDs6IHs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7YXR0cmlidXRlcyZxdW90Ozog Wzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDttZW1iZXJzJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IF08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB9 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PGJyPg0KVGhlIHR3byBvcGVyYXRpb25zIGRpZmZlciBzaWduaWZpY2FudGx5 LCBhbmQgaXQncyBub3QgdmVyeSBpbnR1aXRpdmUuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+V2l0aCBteSBzdWdnZXN0aW9uLCBoZXJlJ3MgaG93IHRvIGRlbGV0ZSBhIHNp bmdsZSBtZW1iZXIgZnJvbSBhIGdyb3VwOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5QQVRDSCAvR3JvdXBzL2FjYmYzYWU3 LTg0NjMtNDY5Mi1iNGZkLTliNGRhM2Y5MDhjZSBIb3N0OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0 YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208L2E+QWNjZXB0Og0KIGFwcGxpY2F0aW9uL2pzb24g QXV0aG9yaXphdGlvbjogQmVhcmVyIGg0ODBkanM5M2hkOCBFVGFnOiBXLyZxdW90O2EzMzBiYzU0 ZjA2NzFjOSZxdW90OyB7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZxdW90O29wZXJhdGlv bnMmcXVvdDsgOiBbPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPns8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+JnF1b3Q7UkVUSVJFJnF1b3Q7IDogezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mcXVvdDtrZXkmcXVvdDsgOiAmcXVvdDttZW1iZXJzLjI4MTljMjIzLTdmNzYtNDUzYS05 MTlkLTQxMzg2MTkwNDY0NiZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj59PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPn08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+XSB9PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCkhlcmUncyBob3cgSSBzdWdnZXN0IGRlbGV0aW5n IEFMTCBtZW1iZXJzIGZyb20gYSBncm91cDo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlBBVENIIC9Hcm91cHMv YWNiZjNhZTctODQ2My00NjkyLWI0ZmQtOWI0ZGEzZjkwOGNlIEhvc3Q6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxl LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5leGFtcGxlLmNvbTwvYT5BY2NlcHQ6DQogYXBwbGljYXRp b24vanNvbiBBdXRob3JpemF0aW9uOiBCZWFyZXIgaDQ4MGRqczkzaGQ4IEVUYWc6IFcvJnF1b3Q7 YTMzMGJjNTRmMDY3MWM5JnF1b3Q7IHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7 b3BlcmF0aW9ucyZxdW90OyA6IFs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ezwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mcXVvdDtSRVRJUkUmcXVvdDsgOiB7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPiZxdW90O2tleSZxdW90OyA6ICZxdW90O21lbWJlcnMmcXVvdDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+fTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj59PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPl0gfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0K SSdtIHN1cmUgeW91J2xsIGFncmVlIHRoYXQgdGhpcyBpcyBzaW1wbGVyLCBtb3JlIGNvbnNpc3Rl bnQgYW5kIG1vcmUgaW50dWl0aXZlIHRvIGEgcmVhZGVyLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBybyAyOiBX ZSBjYW4gYXBwbHkgdGhpcyBtZWNoYW5pc20gY29uc2lzdGVudGx5IHRvIHRocmVlIGFyZWFzOjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPihhKSBNYW5pcHVsYXRpbmcgbXVsdGktdmFs dWVkIGF0dHJpYnV0ZXMgb2YgYSByZXNvdXJjZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPihiKSBNYW5pcHVsYXRpbmcgbWVtYmVycyBvZiBhIGdyb3VwPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+KGMpIFBlcmZvcm1pbmcgYnVsayBvcGVyYXRpb25zLCB3aGVyZSB3ZSBz aW1wbHkgdXNlIEhUVFAgdmVyYnMgaW5zdGVhZCBvZiB0aGUgc3BlY2lhbGlzZWQgKGFuZCBzZW1h bnRpY2FsbHkgbGVzcyBhbWJpZ3VvdXMpIHZlcmJzIEkgc3VnZ2VzdGVkIGZvciBhdHRyaWJ1dGVz LCB0aGUgJnF1b3Q7a2V5JnF1b3Q7IGJlY29tZXMgdGhlIFVSSSwgYW5kIHRoZSAmcXVvdDt2YWx1 ZSZxdW90OyBiZWNvbWVzIHRoZQ0KIGNvcnJlc3BvbmRpbmcgSlNPTiBvYmplY3QuPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+QWxsIG9mIHRoZW0gcmV0dXJuICZxdW90OzIwNyBNdWx0aS1TdGF0dXMmcXVvdDsgd2l0 aCB0aGUgJnF1b3Q7cmVzdWx0cyZxdW90OyBhcnJheSBob2xkaW5nIGluZGl2aWR1YWwgc3RhdHVz IGNvZGVzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkluIHRoZSBjdXJyZW50IHNwZWMsIChhKSBhbmQgKGIpIGFy ZSBkb25lIHNpbWlsYXJseSBidXQgKGMpIGlzIHZlcnkgZGlmZmVyZW50Ljwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlBybyAzOiBBZG9wdGlvbiBvZiB0aGUgc3RhbmRhcmQgYnkgY2xpZW50cyBpcyBsaWtlbHkgdG8g YmUgaGlnaGVyIGJlY2F1c2UgaXQncyBzaW1wbGVyIGZvciB0aGVtLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlBy byA0OiBOZXcgKG5vdCBpbmN1bWJlbnQpIGNsb3VkIHByb3ZpZGVycyB3aWxsIHByb2JhYmx5IGZp bmQgdGhpcyBlYXNpZXIgdG8gaW1wbGVtZW50IGJlY2F1c2UgdGhleSBoYXZlIG5vIGxlZ2FjeS4g VGhleSB3aWxsIHByb2JhYmx5IHVzZSBzb21lIGZvcm0gb2YgTm9TUUwgZGF0YWJhc2UgYW5kIHdv bid0IGJlIGNvbnN0cmFpbmVkIGJ5IHRoZSBsaW1pdGF0aW9ucw0KIG9mIExEQVAgZGlyZWN0b3Jp ZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Q29uczo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Db24gMTogSW5jdW1iZW50IGNs b3VkIHByb3ZpZGVycyB3aXRoIGV4aXN0aW5nIGRhdGEgc3RvcmVzIGluIGEgZGlyZWN0b3J5IGZv cm1hdCAod2hlcmUgbXVsdGktdmFsdWVkIGF0dHJpYnV0ZXMgYXJlIHN0b3JlZCBhcyBjb21tYS1z ZXBhcmF0ZWQgdmFsdWVzIHVuZGVyIGEgc2luZ2xlIGF0dHJpYnV0ZSBub2RlKSB3aWxsIGZpbmQg aXQgZGlmZmljdWx0IHRvIG1pZ3JhdGUNCiB0byB0aGlzIG1vZGVsIGFuZCBzdG9yZSBlYWNoIGF0 dHJpYnV0ZSB2YWx1ZSBhcyBhIHN1Yi1ub2RlIHdpdGggaXRzIG93biBrZXkuIFRoaXMgd2lsbCAm cXVvdDtoaW5kZXIgYWRvcHRpb24gb2YgdGhlIHNwZWMmcXVvdDssIHdoaWNoIGlzIHdoYXQgeW91 IGZlYXIuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+SGF2ZSBJIHN1bW1lZCB1cCB0aGUgUHJvcyBhbmQgQ29ucyBj b3JyZWN0bHk/IEknbSBiaWFzZWQgb2YgY291cnNlLCBzbyBJIGNvdWxkIGhhdmUgbWlzc2VkIGEg Q29uIG9yIGh5cGVkIGEgUHJvIDotKS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JbiBvdGhlciB3b3Jkcywgd2UncmUgZGViYXRpbmcgaW50 ZXJmYWNlIGNvbXBsZXhpdHkgKGN1cnJlbnQgc3BlYykgdmVyc3VzIGltcGxlbWVudGF0aW9uIGNv bXBsZXhpdHkgKG15IHN1Z2dlc3Rpb24pLiBCb3RoIGNhbiBoaW5kZXIgYWRvcHRpb24gb2YgdGhl IHNwZWMgYnkgZGlmZmVyZW50IHBhcnRpZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGVyZSdzIHdoYXQgd2Ug bmVlZCB0byBkaXNjdXNzIC0gRG8gdGhlIFByb3MgbWFrZSB0aGUgc3VnZ2VzdGlvPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzY2ltIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzY2ltQGlldGYub3JnIj5zY2ltQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Np bSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zY2ltPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DF63ACC82673DB40A7AAC08FFA71DFBD274190A0AMXPRD0610MB353_-- From leifj@mnt.se Fri Aug 17 13:26:58 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67B9721E8053 for ; Fri, 17 Aug 2012 13:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya-dpEDYNuUl for ; Fri, 17 Aug 2012 13:26:57 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 432C221E804B for ; Fri, 17 Aug 2012 13:26:57 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q7HKQoci004726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 17 Aug 2012 22:26:55 +0200 (CEST) Message-ID: <502EA90A.5000208@mnt.se> Date: Fri, 17 Aug 2012 22:26:50 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:26:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - - change control is ultimately in the hand of the WG, and - - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 =xZqq -----END PGP SIGNATURE----- From melinda.shore@gmail.com Fri Aug 17 13:28:31 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D267421E8055 for ; Fri, 17 Aug 2012 13:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.574 X-Spam-Level: X-Spam-Status: No, score=-3.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5J7LHHYUgxL for ; Fri, 17 Aug 2012 13:28:31 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 021DA21E8053 for ; Fri, 17 Aug 2012 13:28:30 -0700 (PDT) Received: by dakr19 with SMTP id r19so1039511dak.31 for ; Fri, 17 Aug 2012 13:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KLQM8djBgurwDw4Q+CKwnImkdpu8nvWTLvMtrDbU1sc=; b=a/DcjGwDihuHEkRSctNsGByEFt9TFKDX6MlucBlg7QrDfm8XMixkUtR6k/aSxvrjjt /W6d/j80oe2wtFikRL1YQurp/X1RlKeal1AnNX812OApTz3FLvjbEcb94nIVVmkoGZYA IQaJxspw1fkNXQyTabxryOlvcz8h0wgmARq6VXwe6SzQvYpKHmN87tDQWrOzyFA376Lt d7Z/DBeZge0/XcYR/mbRE+5cLJEFmbp4QYHX8PccnsuvIVA1wHtaIviil4OsWJZYY9Uq 03rq5zJNS5a/NG+hVL2Ab61mnNFNxX/FlrRiJiGNCqqFmvetCejbdsGOPlu/VstIBNDa bwEg== Received: by 10.66.73.69 with SMTP id j5mr12178958pav.8.1345235310567; Fri, 17 Aug 2012 13:28:30 -0700 (PDT) Received: from spandex.local (66-230-81-200-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.81.200]) by mx.google.com with ESMTPS id nd2sm5562725pbc.7.2012.08.17.13.28.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 13:28:29 -0700 (PDT) Message-ID: <502EA96C.4050408@gmail.com> Date: Fri, 17 Aug 2012 12:28:28 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim@ietf.org References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:28:31 -0000 On 8/17/12 12:26 PM, Leif Johansson wrote: > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt +1 +1 Melinda From trey.drake@unboundid.com Fri Aug 17 13:29:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9221E805F for ; Fri, 17 Aug 2012 13:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.133 X-Spam-Level: X-Spam-Status: No, score=-3.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNyuQcSmPl6Y for ; Fri, 17 Aug 2012 13:29:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1789521E805A for ; Fri, 17 Aug 2012 13:29:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so6541784obb.31 for ; Fri, 17 Aug 2012 13:29:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IIGouV0vnjJfV/kURQQhvQxsYzNNppABeGCzzlCmdaw=; b=oBlrUitvJZe6klQnVWR0KL/gXKy9VMg9is6ywc0ITAlR9om2urw+Q/QCQDanavJXiE 8EmN4V9fW63LsBNKX8URCjjdindkaCvVn9wB50kgthJuFlhLWOZ30cld6CXCwWHIJ0r3 KvbV1w0xKEynx7bels1YobAyrBsqJSTHjpenDz4QVQZfe7Jx5HVLM+I3D/qYELDvIvcS ZfdlyXOHKdbphHMqjW1VOxRa7k3AyWpmbOvcMHUMKibNjrBlmekezZWq9uofK8HQPexM yy5iN4FMuhRaTOxR7o8rIyatZcgVQ8wFs5xuMvPZFdhXmOHuwv0umLhj2yFZv6UvSuts dBCQ== Received: by 10.182.37.41 with SMTP id v9mr4950885obj.23.1345235394430; Fri, 17 Aug 2012 13:29:54 -0700 (PDT) Received: from office-dhcp-180.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id qk5sm7506597obc.10.2012.08.17.13.29.53 (version=SSLv3 cipher=OTHER); Fri, 17 Aug 2012 13:29:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Trey Drake In-Reply-To: <502EA96C.4050408@gmail.com> Date: Fri, 17 Aug 2012 15:29:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6330C2F6-95CE-41A2-B8A3-B6883511EB66@unboundid.com> References: <502EA90A.5000208@mnt.se> <502EA96C.4050408@gmail.com> To: Melinda Shore X-Mailer: Apple Mail (2.1485) X-Gm-Message-State: ALoCoQkErXilu6JeR6AFz+6wCZr5+juOnXCY8Cn7LyyMHupG8AguwOp5ON0J72CO7MuFYtQGOoFd Cc: scim@ietf.org Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:29:55 -0000 +1 +1 Thanks, Trey On Aug 17, 2012, at 3:28 PM, Melinda Shore wrote: > On 8/17/12 12:26 PM, Leif Johansson wrote: >> http://www.ietf.org/id/draft-scim-api-01.txt >> http://www.ietf.org/id/draft-scim-core-schema-01.txt > > +1 > +1 > > Melinda > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From linuxwolf@outer-planes.net Fri Aug 17 13:30:51 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B5811E80E1 for ; Fri, 17 Aug 2012 13:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GceN7RmWwu9N for ; Fri, 17 Aug 2012 13:30:50 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8148711E80E0 for ; Fri, 17 Aug 2012 13:30:50 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3953542pbb.31 for ; Fri, 17 Aug 2012 13:30:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-pgp-agent :x-mailer:x-gm-message-state; bh=MQuFb3TkVOyUUoTZdGD+ysqRHMKSaDCh1Uxp9PtNYIA=; b=g7T5wZ+K/cdCGTknsHRGp+d5rBnFUCXtRTtZFm32bFVMiJAmq0gaQ9NyuEqDfYacvO hh/FIHd9fRfpmBFmFiw71X+SPC9LH5Sg/o+JIErm8Kxdbj1ngyXRXmv/9Wp/hOl592vg t2n+CUX7Xndvm2kRoZQiTInjkykg0bvsdUNMiG7dtTACvv20auiVJjcAaRgKXpEFqLVy EN6Nv8Eux07wO+r4u7aumS1MrPbncMIx7/JVpio+jQq43le2Qw5P8w2Vu8uqfo8sm5Jn XuxgsYMdlOc8BdeypOecArkOBGXKZ0pIZFVbqVSR7iCfcK9I8926GqNAfOqyPJDANQ8k FyeQ== Received: by 10.68.193.162 with SMTP id hp2mr14404946pbc.34.1345235450000; Fri, 17 Aug 2012 13:30:50 -0700 (PDT) Received: from [64.101.72.26] ([64.101.72.26]) by mx.google.com with ESMTPS id pn4sm5551490pbb.50.2012.08.17.13.30.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 13:30:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Matthew Miller In-Reply-To: <502EA90A.5000208@mnt.se> Date: Fri, 17 Aug 2012 14:30:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6235899D-1BB1-4AF8-AB80-84AC180FD019@outer-planes.net> References: <502EA90A.5000208@mnt.se> To: Leif Johansson X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnRprEactbDeDrjXdMadFdADrHqEXNyLxCpkIz7BoZ0i14OodmP4VUsu7RerepbfaLh519I Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:30:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +1 +1 - - m&m Matthew A. Miller On Aug 17, 2012, at 14:26, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > This is a call for adoption of >=20 > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt >=20 > as working group documents. >=20 > For those who are new to the IETF this means that >=20 > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus >=20 > but it does not imply that these documents in any way > represent a "finished product". >=20 > In other words, this decision represents the beginning, > not the end. >=20 > If you agree and want the WG to adopt these documents > please '+1' this email. >=20 > Leif & Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =3DxZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQLqn6AAoJEJq6Ou0cgrSPJlkH/iasDZVKVjlPzecCtrdU/IAi 70sUUhnQ+o0V1jWHAsjx/sMtRUM1uojkCZuoPhfz05c5klRG7NbMOhcG45ImwcFN i6eI1rPai8VMcg7aeu5Wj+qgi11h+E3MSp5gy3Zz3mEPgCHwtKNGoXxMPASFnmLR lXB26tEz3or9XY7yXMAStJWfTbG9erNlFDq4rFlHWS4rdxfVmTI5gagKOXOtN3+x 7ybe8JZYo3sJ3xiyR050S/gurlm5jqJOr6YBJi7wiy3q7ly2parvB5zAUn+lxWvU 99499hIlRD1MwUoQKgjeLfxQSQkpeaU6dMx7YozVritDQm/WYVdy7quj/j7k8Y8=3D =3DcSJY -----END PGP SIGNATURE----- From phil.hunt@oracle.com Fri Aug 17 13:30:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D2B21E804B for ; Fri, 17 Aug 2012 13:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.29 X-Spam-Level: X-Spam-Status: No, score=-10.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58f+J0Bf37wB for ; Fri, 17 Aug 2012 13:30:53 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id DF4EF11E80E5 for ; Fri, 17 Aug 2012 13:30:52 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7HKUpSd028749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Aug 2012 20:30:52 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7HKUolJ025181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 20:30:51 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7HKUo1F026433; Fri, 17 Aug 2012 15:30:50 -0500 Received: from [192.168.1.8] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Aug 2012 13:30:50 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <502EA90A.5000208@mnt.se> Date: Fri, 17 Aug 2012 13:30:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: <4CA2F03E-9CB2-4582-86BA-F2117A977C45@oracle.com> References: <502EA90A.5000208@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:30:53 -0000 +1 +1 Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-17, at 1:26 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif & Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =xZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Fri Aug 17 13:36:12 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587FD11E80DC for ; Fri, 17 Aug 2012 13:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.763 X-Spam-Level: X-Spam-Status: No, score=-9.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TSzPpGKDI5o for ; Fri, 17 Aug 2012 13:36:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A19E511E80D1 for ; Fri, 17 Aug 2012 13:36:11 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7HKaAhp026056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Aug 2012 15:36:10 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7HKaAdX003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Aug 2012 15:36:10 -0500 Received: from [135.244.0.186] (faynberg.lra.lucent.com [135.244.0.186]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7HKa8Vg007791; Fri, 17 Aug 2012 15:36:09 -0500 (CDT) Message-ID: <502EAB38.9000105@alcatel-lucent.com> Date: Fri, 17 Aug 2012 16:36:08 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:36:12 -0000 +1 (This was easy!) Igor On 8/17/2012 4:26 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif& Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =xZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Fri Aug 17 13:52:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3737D11E80DC for ; Fri, 17 Aug 2012 13:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.839 X-Spam-Level: X-Spam-Status: No, score=-7.839 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rmq48XvCVLbC for ; Fri, 17 Aug 2012 13:52:12 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFAA11E80D1 for ; Fri, 17 Aug 2012 13:52:12 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q7HKqBBq013520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 Aug 2012 15:52:12 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7HKqBb3006829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Aug 2012 15:52:11 -0500 Received: from [135.244.0.186] (faynberg.lra.lucent.com [135.244.0.186]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7HKqAYg019668; Fri, 17 Aug 2012 15:52:11 -0500 (CDT) Message-ID: <502EAEFA.8080006@alcatel-lucent.com> Date: Fri, 17 Aug 2012 16:52:10 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <502EA90A.5000208@mnt.se> <502EAB38.9000105@alcatel-lucent.com> In-Reply-To: <502EAB38.9000105@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:52:13 -0000 I see, everyone is counting to two, so I stand corrected: +1 +1 Igor On 8/17/2012 4:36 PM, Igor Faynberg wrote: > +1 > > (This was easy!) > > Igor > > On 8/17/2012 4:26 PM, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> This is a call for adoption of >> >> http://www.ietf.org/id/draft-scim-api-01.txt >> http://www.ietf.org/id/draft-scim-core-schema-01.txt >> >> as working group documents. >> >> For those who are new to the IETF this means that >> >> - - change control is ultimately in the hand of the WG, and >> - - changes to these documents will be based on WG consensus >> >> but it does not imply that these documents in any way >> represent a "finished product". >> >> In other words, this decision represents the beginning, >> not the end. >> >> If you agree and want the WG to adopt these documents >> please '+1' this email. >> >> Leif& Mortezza >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 >> PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 >> =xZqq >> -----END PGP SIGNATURE----- >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From zachary.zeltsan@alcatel-lucent.com Fri Aug 17 13:57:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1BC21F8432 for ; Fri, 17 Aug 2012 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lctqYRgwOi-D for ; Fri, 17 Aug 2012 13:57:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 181B121F842E for ; Fri, 17 Aug 2012 13:57:24 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7HKvLbd013066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Aug 2012 22:57:21 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 Aug 2012 22:57:21 +0200 Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.16]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Fri, 17 Aug 2012 16:57:18 -0400 From: "Zeltsan, Zachary (Zachary)" To: "'Leif Johansson'" , "'scim WG'" Thread-Topic: [scim] call for wg adoption Thread-Index: AQHNfLas1Q0NcFQgC0ORkqKntsHbDpdee+oA Date: Fri, 17 Aug 2012 20:57:17 +0000 Message-ID: References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 20:57:26 -0000 +1 for both documents. Zachary -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Friday, August 17, 2012 4:27 PM To: scim WG Subject: [scim] call for wg adoption -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - - change control is ultimately in the hand of the WG, and - - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 =3DxZqq -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From stpeter@stpeter.im Fri Aug 17 15:27:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FB21E8090 for ; Fri, 17 Aug 2012 15:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFOzYOPYJ9Za for ; Fri, 17 Aug 2012 15:27:57 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2270211E80A4 for ; Fri, 17 Aug 2012 15:27:57 -0700 (PDT) Received: from [192.168.0.4] (unknown [67.177.192.224]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3BCFA404EA; Fri, 17 Aug 2012 16:28:30 -0600 (MDT) Message-ID: <502EC56A.7070604@stpeter.im> Date: Fri, 17 Aug 2012 16:27:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leif Johansson References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 22:27:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/17/12 2:26 PM, Leif Johansson wrote: > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. I think they are acceptable starting points. +1 to both. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAuxWoACgkQNL8k5A2w/vzMIQCgwZRiPZPkuhdmrJ6JFFT/kAf1 AiQAoJ1Ut2wdqr62k5S5dla8UxV1CShL =CplB -----END PGP SIGNATURE----- From allan.foster@forgerock.com Fri Aug 17 15:45:34 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16E11E80D7 for ; Fri, 17 Aug 2012 15:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRb1Usmg9A30 for ; Fri, 17 Aug 2012 15:45:34 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFDCB11E80A4 for ; Fri, 17 Aug 2012 15:45:33 -0700 (PDT) Received: by ggnh4 with SMTP id h4so4895619ggn.31 for ; Fri, 17 Aug 2012 15:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=OwjIhqUsFad4RUtVrFmA8qVnzKUxi0R1AOGyH4Z5Xu8=; b=FNY7QhA8COyUtR1VYZUbeI0EPherUuKn23yOOrmvggHxafmAx/Z7h6Cx0wpiBC3CMS HiW4tytc/sEgzCKXNKpfN4uCikj29TRhfYU3vLJfaAMkdVKGg8umcNJqVlYfX2XkZwQa i5Tb8VOHDN5aQx74q2RJ2TZzDeYXD/V7chF1IWfeNuk6/PV7aLtcyGl2G+WB6HlWIjBQ hdy4tPJxuuy3E+7f19KCELpstS/woeNOApTp4Kc+yU3VDaK2FyeX6ePp/dhIge4Z8/ks A/cqM2vciVCzx0ONQv9Ww3xVv3yNU6ZDfZkAAE0fpr6sc+pto0yv15Y77gzpYrnqIL8U sLJw== Received: by 10.100.237.10 with SMTP id k10mr3291846anh.50.1345243533121; Fri, 17 Aug 2012 15:45:33 -0700 (PDT) Received: from [10.241.93.115] (m4c5f36d0.tmodns.net. [208.54.95.76]) by mx.google.com with ESMTPS id k2sm8098497anl.11.2012.08.17.15.45.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 15:45:32 -0700 (PDT) From: Allan Foster Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 17 Aug 2012 18:45:31 -0400 Message-Id: <7F5D62BE-D5DB-4202-98D4-90E631CC1D97@forgerock.com> To: scim@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQllkfLLzlLNrDGXilYWL0QVezp0eRpy3HCqWJNG6p1hutXQO0XwMghReGrwNBgt1V2jRssE Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 22:45:34 -0000 +1 +1 From charliemortimore@gmail.com Fri Aug 17 16:20:57 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6721E8063 for ; Fri, 17 Aug 2012 16:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKVgK1F2UyVJ for ; Fri, 17 Aug 2012 16:20:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DDADC11E80D7 for ; Fri, 17 Aug 2012 16:20:56 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4137979pbb.31 for ; Fri, 17 Aug 2012 16:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=zTZnuliBAy/wuNdbLTj8fN7apN4pEpfN08HxIAWQ7Qs=; b=ZuJs2uIbNbmUaHJyeV8kWuBBEPyB/ISWTjhXoTkZ4vz0LSPmPketWvJ/PTpGsTvTwK rUEfBB2g/07dOfTudML2QDqZ3ErsGuZ+XduQ38yjqZaqALipAS68h7Ul9pvuGTTIqOYe 5JEUWM2SZo1Syzf3Vh2h9o2T14nk5AevYKHTT2pVTlCFA2nkUK+dRQ4f6Y3rGw63pG1v QN9INpxxGvM93JvW4NPC0UfljiQaBQSSa2IMSya22NUZO0rlmCRy20pYBp36V2lPolSL THOcEOLwZlA3afXn9E9VY6r+Sqa8orRBdxbmGmNpt7FjgSdrBQqQ88J0YcSNbLcklVur TY5w== Received: by 10.68.132.194 with SMTP id ow2mr15299334pbb.36.1345245656546; Fri, 17 Aug 2012 16:20:56 -0700 (PDT) Received: from [10.198.16.89] (mobile-198-228-212-232.mycingular.net. [198.228.212.232]) by mx.google.com with ESMTPS id oj8sm5786112pbb.54.2012.08.17.16.20.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 16:20:55 -0700 (PDT) References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <5DC6BEEA-DCD1-4028-903E-674AB2CEC57F@gmail.com> X-Mailer: iPhone Mail (9B179) From: Charliemortimore Date: Fri, 17 Aug 2012 16:20:51 -0700 To: Leif Johansson Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 23:20:57 -0000 +1 +1 - cmort On Aug 17, 2012, at 1:26 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif & Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =xZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From charliemortimore@gmail.com Fri Aug 17 18:05:00 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B2F21E808D for ; Fri, 17 Aug 2012 18:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL82PAJSHftE for ; Fri, 17 Aug 2012 18:04:59 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB711E808E for ; Fri, 17 Aug 2012 18:04:58 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so4236055pbb.31 for ; Fri, 17 Aug 2012 18:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=ElcLR1yWe2VYHxFrhoiQougP4HDXXe+xdtEt9bwSCV4=; b=xH+T4gz/Qi6LE2vGOA3D+aTTSXtccRw/q6cqmy6FIYb9od406BC1cd8IRWRNzv1gXr XolXyK19/zFofphRm/la7Q+T+vgjFhLj/QCUgaCE5sMhJ+eTajnndqe4fwhDxSqYquZy eQ1qq/3CIUHqiieD321GauHa132CFBEYRttq9hqMuXFSgrVr6Gaff1jIIOKFG6KxLn2o 8lqTnMz/iOsGoBarlD/MYgPT+4Y/TiZhzLeZ6Xwj1Ci65pdvlsjAMjVNwdlFRGvPscGw rDaA84fAoEiTv86ZHUAw5AJkGPO72EeSQuc7MaDZsyf7qAwcCFP/tAXwUuphjb6bCbLS jOhw== Received: by 10.66.77.71 with SMTP id q7mr13448384paw.0.1345251898526; Fri, 17 Aug 2012 18:04:58 -0700 (PDT) Received: from [10.198.16.89] (mobile-198-228-212-232.mycingular.net. [198.228.212.232]) by mx.google.com with ESMTPS id pa6sm5947637pbc.47.2012.08.17.18.04.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 18:04:57 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-FCBBCD3E-C0DB-406B-BC9E-3D85990E8CE2 Message-Id: <0F2CB108-45BF-4D9E-99CF-CF9FAA058A30@gmail.com> X-Mailer: iPhone Mail (9B179) From: Charliemortimore Date: Fri, 17 Aug 2012 18:04:50 -0700 To: Chris Phillips Cc: "scim@ietf.org" Subject: Re: [scim] scim Digest, Vol 8, Issue 24 X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 01:05:00 -0000 --Apple-Mail-FCBBCD3E-C0DB-406B-BC9E-3D85990E8CE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to Chris and Phil - cmort On Aug 16, 2012, at 12:23 PM, Chris Phillips wro= te: > +1 to Phil's comments. >=20 > As well, adding a ghost directory to [de|en]code things is just too much o= verhead to build into the protocol. If someone wants to build that on TOP o= f SCIM, that's up to them. =20 >=20 > While I appreciate the thought and time Ganesh has put into the concepts, I= am not convinced the approach would be net better and less complex and so d= o not support it and welcome moving on to other topics. >=20 > C. >=20 > From: Phil Hunt > Date: Thursday, 16 August, 2012 1:42 PM > To: Kelly Grizzle > Cc: Emmanuel Dreux , Anthony Nadalin , Ganesh and Sashi Prasad , Melinda Shore , "scim@ietf.org" > Subject: Re: [scim] scim Digest, Vol 8, Issue 24 >=20 > I do think we need to arrive at some consensus on this now because Ganesh'= s proposal is a major "fork-in-the-road" decision. If we table it, it will b= e hard to come back to. This is why I have engaged on the subject with Ganes= h so thoroughly. Never-the-less, I would like to arrive at some conclusions= here. >=20 > My apologies, but I thought it was worth re-stating the problem for those l= ate to the discussion would be useful. >=20 > Background: > At present, the current spec does not allow you to change a specific sub-a= ttribute in a multi-valued complex attribute structure (e.g. changing street= name in a specific address value instance such as "home"). The proposal is= that each sub attribute in a multi-valued structure gets its own unique ide= ntifier. Then you can directly reference the specific complex attribute com= ponent in a complex value. >=20 > The current draft proposal requires that complex-value (e.g. an address va= lue which is made up of number, street, city, etc) be changed if you want to= change any of the sub-attributes. The current approach seems a reasonable c= ompromise since it is likely the collection of attributes in a complex "valu= e" are often manipulated together. IOW. You tend to set them all at once. G= anesh's proposal allows specific sub-attributes to be directly addressable b= y giving each value instance a unique identifier. =20 >=20 > Another example of this is the group "member" attribute. In the current d= raft, a member can have a value and a display name. In this case you would u= sually change the value (object identifier) and the name as well. Ganesh's p= roposal would allow "Display Name" to be changed or value to be changed. So= mething, IMV, that doesn't occur nearly as often. IOW members change group m= embership, but members rarely change names. >=20 > My conclusion: > If the client must first query (or have synchronized the value identifiers= ), then the client has to do even more work than the current proposal of rep= lacing the enter complex value. Given such a choice I'm really skeptical th= at the pattern proposed by Ganesh would be widely used. While Ganesh's prop= osal may be "specific", the practical simplicity of it is very much debatabl= e. >=20 > The benefit of specific sub-attribute identifiers needs to be substantial.= We're not only talking about changing how infrastructure is done, but also= how applications are written. This leaves out the entire current adopters a= nd all enterprise users. A big concern we have obviously is we have to cons= ider existing infrastructure and data stores and be realistic. I don't think= the benefit is worth the cost. >=20 > I agree with the others that the current draft could be changed to make pa= tch operations more clear to the developer (simpler to read). While this may= not improve logic, it will improve understanding and simplicity. The fact t= hat certain operations may require an entire complex attribute value to be r= eplaced is a reasonable compromise and should not be changed.=20 >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-08-16, at 8:59 AM, Kelly Grizzle wrote: >=20 >> Hi Ganesh =E2=80=A6 your write-up concedes that this will be difficult to= implement for an existing service provider. I=E2=80=99m not sure that I un= derstand the compromise. Are you still suggesting that SCIM move to the uni= que-key-per-element strategy? >> =20 >> If so, the cost/benefit of this seems way off to me. You are gaining a m= ore elegant API by introducing an additional datastore and requiring replica= tion. I don=E2=80=99t know of any service provider that would make this tra= de-off. As you said, this is something that future service providers can ke= ep in mind, but it is not going to help existing providers. >> =20 >> --Kelly >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --Apple-Mail-FCBBCD3E-C0DB-406B-BC9E-3D85990E8CE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1 to Chris and Phil
- cmort

On Aug 16, 2012, at 12:23 PM, Chris Phillips <Chris.Phillips@canarie.ca> w= rote:

+1 to Phil's comments.

As w= ell, adding a ghost directory to [de|en]code things is just too much overhea= d to build into the protocol.  If someone wants to build that on TOP of= SCIM, that's up to them.  

While I appreciate the tho= ught and time Ganesh has put into the concepts, I am not convinced the appro= ach would be net better and less complex and so do not support it and w= elcome moving on to other topics.

C.

From: Phil Hunt <phil= .hunt@oracle.com>
Date: T= hursday, 16 August, 2012 1:42 PM
To: Kelly Grizzle <kelly.= grizzle@sailpoint.com>
Cc: Emmanuel Dreux <edreux@cloudiwa= y.com>, Anthony Nadalin <= tonynad@microsoft.com>, Ganesh and Sashi Prasad <g.c.prasad@gmail.com>, Melinda Shore <melinda.shore@gmail.com>, "scim@ietf.org" <scim@ietf.org>
Subject: <= /span> Re: [scim] scim Digest, Vol 8, Issue 24

=
I do think we need to arrive at some consensus= on this now because Ganesh's proposal is a major "fork-in-the-road" decisio= n. If we table it, it will be hard to come back to. This is why I have engag= ed on the subject with Ganesh so thoroughly.  Never-the-less, I would like to arrive at some conclusions here.

M= y apologies, but I thought it was worth re-stating the problem for those lat= e to the discussion would be useful.

Background:
At present, the current spec does not allow you to change a specific= sub-attribute in a multi-valued complex attribute structure (e.g. changing s= treet name in a specific address value instance such as "home").  The p= roposal is that each sub attribute in a multi-valued structure gets its own unique identifier.  Then you can= directly reference the specific complex attribute component in a complex va= lue.

The current draft proposal requires that compl= ex-value (e.g. an address value which is made up of number, street, city, et= c) be changed if you want to change any of the sub-attributes. The current a= pproach seems a reasonable compromise since it is likely the collection of attributes in a complex "value" are often manipulated tog= ether. IOW. You tend to set them all at once.  Ganesh's proposal allows= specific sub-attributes to be directly addressable by giving each value ins= tance a unique identifier.   

Another exa= mple of this is the group "member" attribute.  In the current draft, a m= ember can have a value and a display name. In this case you would usually ch= ange the value (object identifier) and the name as well.  Ganesh's prop= osal would allow "Display Name" to be changed or value to be changed.  Something, IMV, that does= n't occur nearly as often.  IOW members change group membership, but me= mbers rarely change names.

My conclusion:
If the client must first query (or have synchronized the value identifiers)= , then the client has to do even more work than the current proposal of repl= acing the enter complex value.  Given such a choice I'm really skeptica= l that the pattern proposed by Ganesh would be widely used.  While Ganesh's proposal may be "specific= ", the practical simplicity of it is very much debatable.

The benefit of specific sub-attribute identifiers needs to be substantial. &= nbsp;We're not only talking about changing how infrastructure is done, but a= lso how applications are written. This leaves out the entire current adopter= s and all enterprise users.  A big concern we have obviously is we have to consider existing infrastructure an= d data stores and be realistic. I don't think the benefit is worth the cost.=

I agree with the others that the current draft coul= d be changed to make patch operations more clear to the developer (simpler t= o read). While this may not improve logic, it will improve understanding and= simplicity. The fact that certain operations may require an entire complex attribute value to be replaced is a reasonable co= mpromise and should not be changed. 

Phil

On 2= 012-08-16, at 8:59 AM, Kelly Grizzle wrote:

<= div style=3D"margin-right: 0in; margin-left: 0in; font-size: 12pt; font-fami= ly: 'Times New Roman', serif; margin-top: 0in; margin-bottom: 0.0001pt; ">Hi Ganesh =E2=80=A6 your write-up concedes that this will be d= ifficult to implement for an existing service provider.  I=E2=80=99m no= t sure that I understand the compromise.  Are you still suggesting that SCIM move to the unique-key-per-element strategy?
 
<= o:p> 
--Kelly
=
<= /div>
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
=
= --Apple-Mail-FCBBCD3E-C0DB-406B-BC9E-3D85990E8CE2-- From Chris.Phillips@canarie.ca Fri Aug 17 19:36:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3091311E808A for ; Fri, 17 Aug 2012 19:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iW0R8D-1u0c for ; Fri, 17 Aug 2012 19:36:12 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [IPv6:2001:410:102:3::5]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC211E808E for ; Fri, 17 Aug 2012 19:36:09 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Fri, 17 Aug 2012 22:36:02 -0400 From: Chris Phillips To: scim WG Date: Fri, 17 Aug 2012 22:35:57 -0400 Thread-Topic: [scim] call for wg adoption Thread-Index: Ac186jTRb1ei1RRaSqqwN/Gf1l4mxA== Message-ID: <1A13204F-B7D8-4302-8C63-86A51C3BD601@canarie.ca> References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 02:36:13 -0000 +1 for both documents Chris /mobile_____________________ chris.phillips@canarie.ca On Aug 17, 2012, at 4:27 PM, "Leif Johansson" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > This is a call for adoption of >=20 > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt >=20 > as working group documents. >=20 > For those who are new to the IETF this means that >=20 > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus >=20 > but it does not imply that these documents in any way > represent a "finished product". >=20 > In other words, this decision represents the beginning, > not the end. >=20 > If you agree and want the WG to adopt these documents > please '+1' this email. >=20 > Leif & Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =3DxZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From lear@cisco.com Sat Aug 18 11:26:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77A921F846E for ; Sat, 18 Aug 2012 11:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dt6kxjmblKhO for ; Sat, 18 Aug 2012 11:26:10 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id C3B1921F8464 for ; Sat, 18 Aug 2012 11:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2954; q=dns/txt; s=iport; t=1345314369; x=1346523969; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=/64s3nHVXrCMoSGiLMDTNyffZl1Djc2fxtffizbHwzM=; b=i8olqOhUjf8JW8Sqg3L7OuWuI619oW7O1k/cCNM5i9Y8sHMtvz421898 agtIHYlmpkRDvbonw2+/+P2Kj8ooWH/3Pqh0GXqhyoRRVNkzXFRidphYH hYlTKXc7C5Wi5mOsx+TfMlq4LyLNgLUHEtMUVgR9HNAxqiCRICWNQssZm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHvcL1CQ/khN/2dsb2JhbABFhgG0PYEHgiABAQEEAQEBDwEKBksKAQULCwQUCRYLAgIJAwIBAgEVMAYNAQUCAQEFGYdrC5ktjRiSL5ELgRIDlVCOLIFmgmOBXw X-IronPort-AV: E=Sophos;i="4.77,791,1336348800"; d="scan'208,217";a="7429640" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 18 Aug 2012 18:26:08 +0000 Received: from dhcp-10-55-84-88.cisco.com (dhcp-10-55-84-88.cisco.com [10.55.84.88]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7IIQ8eH028312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2012 18:26:08 GMT Message-ID: <502FDE3F.7010003@cisco.com> Date: Sat, 18 Aug 2012 20:26:07 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leif Johansson References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> X-Enigmail-Version: 1.4.3 Content-Type: multipart/alternative; boundary="------------030600050001060808030809" Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 18:26:10 -0000 This is a multi-part message in MIME format. --------------030600050001060808030809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +1 to both docs. On 8/17/12 10:26 PM, Leif Johansson wrote: > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - change control is ultimately in the hand of the WG, and > - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif & Mortezza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --------------030600050001060808030809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +1 to both docs.


On 8/17/12 10:26 PM, Leif Johansson wrote:

This is a call for adoption of

http://www.ietf.org/id/draft-scim-api-01.txt
http://www.ietf.org/id/draft-scim-core-schema-01.txt

as working group documents.

For those who are new to the IETF this means that

- change control is ultimately in the hand of the WG, and
- changes to these documents will be based on WG consensus

but it does not imply that these documents in any way
represent a "finished product".

In other words, this decision represents the beginning,
not the end.

If you agree and want the WG to adopt these documents
please '+1' this email.

    Leif & Mortezza
> _______________________________________________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>


--------------030600050001060808030809-- From kelly.grizzle@sailpoint.com Sat Aug 18 15:15:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D221F84E4 for ; Sat, 18 Aug 2012 15:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FA0HhnL6TPV for ; Sat, 18 Aug 2012 15:15:26 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 482D721F84E1 for ; Sat, 18 Aug 2012 15:15:25 -0700 (PDT) Received: from mail88-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Sat, 18 Aug 2012 22:15:24 +0000 Received: from mail88-va3 (localhost [127.0.0.1]) by mail88-va3-R.bigfish.com (Postfix) with ESMTP id C5BAA440235; Sat, 18 Aug 2012 22:15:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.85; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371Ic85dh1432Izz1202hzz1033IL8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail88-va3: domain of sailpoint.com designates 157.56.236.85 as permitted sender) client-ip=157.56.236.85; envelope-from=kelly.grizzle@sailpoint.com; helo=BY2PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail88-va3 (localhost.localdomain [127.0.0.1]) by mail88-va3 (MessageSwitch) id 1345328122799395_24381; Sat, 18 Aug 2012 22:15:22 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.243]) by mail88-va3.bigfish.com (Postfix) with ESMTP id BF6D83A0074; Sat, 18 Aug 2012 22:15:22 +0000 (UTC) Received: from BY2PRD0410HT005.namprd04.prod.outlook.com (157.56.236.85) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 18 Aug 2012 22:15:22 +0000 Received: from BY2PRD0410MB354.namprd04.prod.outlook.com ([169.254.10.70]) by BY2PRD0410HT005.namprd04.prod.outlook.com ([10.255.83.40]) with mapi id 14.16.0190.008; Sat, 18 Aug 2012 22:15:17 +0000 From: Kelly Grizzle To: Eliot Lear , Leif Johansson Thread-Topic: [scim] call for wg adoption Thread-Index: AQHNfW72arxT588Zb0+dhza+6uo5N5dgIvU/ Date: Sat, 18 Aug 2012 22:15:16 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330B04B5@BY2PRD0410MB354.namprd04.prod.outlook.com> References: <502EA90A.5000208@mnt.se>,<502FDE3F.7010003@cisco.com> In-Reply-To: <502FDE3F.7010003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: multipart/alternative; boundary="_000_56C3C758F9D6534CA3778EAA1E0C3437330B04B5BY2PRD0410MB354_" MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 22:15:27 -0000 --_000_56C3C758F9D6534CA3778EAA1E0C3437330B04B5BY2PRD0410MB354_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Eliot Lear= [lear@cisco.com] Sent: Saturday, August 18, 2012 1:26 PM To: Leif Johansson Cc: scim WG Subject: Re: [scim] call for wg adoption +1 to both docs. On 8/17/12 10:26 PM, Leif Johansson wrote: This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - change control is ultimately in the hand of the WG, and - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --_000_56C3C758F9D6534CA3778EAA1E0C3437330B04B5BY2PRD0410MB354_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
+1

From: scim-bounces@ietf.org [scim-bounce= s@ietf.org] on behalf of Eliot Lear [lear@cisco.com]
Sent: Saturday, August 18, 2012 1:26 PM
To: Leif Johansson
Cc: scim WG
Subject: Re: [scim] call for wg adoption

+1 to both docs.


On 8/17/12 10:26 PM, Leif Johansson wrote:

This is a call for adoption of

http://www.ietf.org/id/draft-scim-api-01.tx= t
http://www.ietf.org/id/draft-scim-c= ore-schema-01.txt

as working group documents.

For those who are new to the IETF this means that

- change control is ultimately in the hand of the WG, and
- changes to these documents will be based on WG consensus

but it does not imply that these documents in any way
represent a "finished product".

In other words, this decision represents the beginning,
not the end.

If you agree and want the WG to adopt these documents
please '+1' this email.

    Leif & Mortezza
> ______________________________________= _________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>


--_000_56C3C758F9D6534CA3778EAA1E0C3437330B04B5BY2PRD0410MB354_-- From prvs=65783BC25B=erik.wahlstrom@nexussafe.com Sun Aug 19 01:33:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85F21F84FA for ; Sun, 19 Aug 2012 01:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfj8lo-Z61fO for ; Sun, 19 Aug 2012 01:33:29 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB2B21F84F7 for ; Sun, 19 Aug 2012 01:33:28 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.379.0; Sun, 19 Aug 2012 10:33:25 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Sun, 19 Aug 2012 10:33:25 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Kelly Grizzle Thread-Topic: [scim] call for wg adoption Thread-Index: AQHNfW71YWH6xTF4/kydb+X9Sy3K0JdgAX4AgACstQA= Date: Sun, 19 Aug 2012 08:33:25 +0000 Message-ID: References: <502EA90A.5000208@mnt.se>,<502FDE3F.7010003@cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437330B04B5@BY2PRD0410MB354.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330B04B5@BY2PRD0410MB354.namprd04.prod.outlook.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: multipart/alternative; boundary="_000_EE03EF1D307444FBAF7363B2A7FC03FCnexussafecom_" MIME-Version: 1.0 Cc: Leif Johansson , Eliot Lear , scim WG Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 08:33:30 -0000 --_000_EE03EF1D307444FBAF7363B2A7FC03FCnexussafecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 On Aug 19, 2012, at 12:15 AM, Kelly Grizzle wrote: +1 ________________________________ From: scim-bounces@ietf.org [scim-bounces@iet= f.org] on behalf of Eliot Lear [lear@cisco.com] Sent: Saturday, August 18, 2012 1:26 PM To: Leif Johansson Cc: scim WG Subject: Re: [scim] call for wg adoption +1 to both docs. On 8/17/12 10:26 PM, Leif Johansson wrote: This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - change control is ultimately in the hand of the WG, and - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim --_000_EE03EF1D307444FBAF7363B2A7FC03FCnexussafecom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable +1

On Aug 19, 2012, at 12:15 AM, Kelly Grizzle wrote:

+1

From: scim-bounces@ietf.= org [scim-bounces@iet= f.org] on behalf of Eliot Lear [lear@cisco.com]
Sent: Saturday, Au= gust 18, 2012 1:26 PM
To: Leif Johansson=
Cc: scim WG
Subject: Re: [scim= ] call for wg adoption

+1 to both docs.


On 8/17/12 10:26 PM, Leif Johansson wrote:

This is a call for adoption of

http://www.ietf.org/id/draft-scim-api-01.tx= t
http://www.ietf.org/id/draft-scim-c= ore-schema-01.txt

as working group documents.

For those who are new to the IETF this means that

- change control is ultimately in the hand of the WG, and
- changes to these documents will be based on WG consensus

but it does not imply that these documents in any way
represent a "finished product".

In other words, this decision represents the beginning,
not the end.

If you agree and want the WG to adopt these documents
please '+1' this email.

    Leif & Mortezza
> ___________________________________= ____________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>


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

--_000_EE03EF1D307444FBAF7363B2A7FC03FCnexussafecom_-- From hasini@wso2.com Sun Aug 19 02:41:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAEE21F84FB for ; Sun, 19 Aug 2012 02:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj6HiZMPh40j for ; Sun, 19 Aug 2012 02:41:46 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E6AE621F84F8 for ; Sun, 19 Aug 2012 02:41:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5254431vbb.31 for ; Sun, 19 Aug 2012 02:41:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=6iljNVmqOCUgIppB0EvE3pWVzjkcHUrPkw1lvEGdc1U=; b=B9XGiuXEVKqQ8xSLuThnMiZ7KOq8/v/TvwBl9LwVi64vVqQWdCkzfhjtl0dGl6NCiD 4h1w4Y432WkF1c4oK1dJSn5PmiAt+coJ0q8Fu47PrCIjkvvPP31ee5PaWmplJYbC0mRM O37f3qOvYCQhSd7gOagodFTmcaKysKwG++q8Ok3Z5zW/vgS/KpReEEQpcAdyBTBxO/75 jw+taXGMqnpaE0djmjiLgBVZTWCqeV1SFDb22irt7wGxthAuCGfT0kr+Atygf7wRWWLy H2OQ+Qr2wEswW6HZe8urh8PZGyyZxU1Toi5qgyJagK5NbScTCPGMpp72CB+ECzvqBhyn IOvw== MIME-Version: 1.0 Received: by 10.220.142.79 with SMTP id p15mr7210226vcu.24.1345369304901; Sun, 19 Aug 2012 02:41:44 -0700 (PDT) Received: by 10.58.132.179 with HTTP; Sun, 19 Aug 2012 02:41:44 -0700 (PDT) In-Reply-To: References: <502EA90A.5000208@mnt.se> <502FDE3F.7010003@cisco.com> <56C3C758F9D6534CA3778EAA1E0C3437330B04B5@BY2PRD0410MB354.namprd04.prod.outlook.com> Date: Sun, 19 Aug 2012 15:11:44 +0530 Message-ID: From: Hasini Gunasinghe To: =?ISO-8859-1?Q?Erik_Wahlstr=F6m?= Content-Type: multipart/alternative; boundary=f46d042fdb3e82aa5904c79b3346 X-Gm-Message-State: ALoCoQlSPqV4YvqjDEvlxlZ3NZP+QzoHF8eqdhDt0xsnDIwct6+3EJT0aQRd/aj5A6vFr+0kkPpc Cc: Leif Johansson , scim WG , Eliot Lear , Kelly Grizzle Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 09:41:46 -0000 --f46d042fdb3e82aa5904c79b3346 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1. Thanks, Hasini. On Sun, Aug 19, 2012 at 2:03 PM, Erik Wahlstr=F6m < erik.wahlstrom@nexussafe.com> wrote: > +1 > > On Aug 19, 2012, at 12:15 AM, Kelly Grizzle wrote: > > +1 > > ------------------------------ > *From:* scim-bounces@ietf.org [scim-bounces@ietf.org] on behalf of Eliot > Lear [lear@cisco.com] > *Sent:* Saturday, August 18, 2012 1:26 PM > *To:* Leif Johansson > *Cc:* scim WG > *Subject:* Re: [scim] call for wg adoption > > +1 to both docs. > > > On 8/17/12 10:26 PM, Leif Johansson wrote: > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - change control is ultimately in the hand of the WG, and > - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif & Mortezza > > > _______________________________________________ > > scim mailing list > > scim@ietf.org > > https://www.ietf.org/mailman/listinfo/scim > > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > --f46d042fdb3e82aa5904c79b3346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1.

Thanks,
Hasini.

On Sun, Aug 19, 2012 at 2:03 PM, Erik Wahlstr=F6m <erik= .wahlstrom@nexussafe.com> wrote:
+1

On Aug 19, 2012, at 12:15 AM, Kelly Grizzle wrote:

+1

Fro= m:=A0scim-bounces@ietf.org=A0[scim-bounces@ietf.org] on behalf of Eliot Lear [lear@cisco.com]
Sent:=A0Saturday, August 18, 2012 1:26 PM
To:=A0Leif Johansson
Cc:=A0scim WG
Subject:=A0Re: [scim] call for wg adoption

+1 to both docs.


On 8/17/12 10:26 PM, Leif Johansson wrote:

This is a call for adoption of

= http://www.ietf.org/id/draft-scim-api-01.txt
http://www.ietf.org/id/draft-scim-core-schema-01.txt

as working group documents.

For those who are new to the IETF this means that

- change control is ultimately in the hand of the WG, and
- changes to these documents will be based on WG consensus

but it does not imply that these documents in any way
represent a "finished product".

In other words, this decision represents the beginning,
not the end.

If you agree and want the WG to adopt these documents
please '+1' this email.

=A0=A0 =A0Leif & Mortezza
> _________________________________= ______________
> scim mailing list
> scim@ietf.org
> https://www.ietf.org/mailman/listinfo/scim
>
>


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


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


--f46d042fdb3e82aa5904c79b3346-- From smith@Cardiff.ac.uk Sun Aug 19 03:32:21 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E857F21F8508 for ; Sun, 19 Aug 2012 03:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6YYM6Ey5u9a for ; Sun, 19 Aug 2012 03:32:21 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id BA40521F84FB for ; Sun, 19 Aug 2012 03:32:18 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1T32np-0001At-B7 for scim@ietf.org; Sun, 19 Aug 2012 11:32:17 +0100 Received: from [109.154.166.19] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1T32np-0002L9-9Z for scim@ietf.org; Sun, 19 Aug 2012 11:32:17 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Rhys Smith In-Reply-To: <502EA90A.5000208@mnt.se> Date: Sun, 19 Aug 2012 11:32:13 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <502EA90A.5000208@mnt.se> To: scim@ietf.org X-Mailer: Apple Mail (2.1485) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 10:32:22 -0000 Both represent a good starting point. +1 +1 -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 17 Aug 2012, at 21:26, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif & Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =xZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From prvs=571d546e1=Mark.Diodati@gartner.com Sun Aug 19 09:08:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE4D21F853F for ; Sun, 19 Aug 2012 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr+E67OhwYRW for ; Sun, 19 Aug 2012 09:08:53 -0700 (PDT) Received: from zinc-main.gartner.com (zinc-main.gartner.com [207.140.148.90]) by ietfa.amsl.com (Postfix) with ESMTP id C65A121F8516 for ; Sun, 19 Aug 2012 09:08:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAOQOMVAKQCMD/2dsb2JhbABFhgGzVoFvgiEBAQQdBhFVAgEIGgIGIAICAjAVEAIEG61okgKBIYoEhWYyYAOoQ4Fh X-IronPort-AV: E=Sophos;i="4.77,794,1336363200"; d="scan'208";a="107242447" From: "Diodati,Mark" To: scim WG Thread-Topic: [scim] call for wg adoption Thread-Index: AQHNfN2BvoCLBplRPEeiU6ZQ3DIeUpdhT85Q Date: Sun, 19 Aug 2012 16:08:50 +0000 References: <502EA90A.5000208@mnt.se> <502EC56A.7070604@stpeter.im> In-Reply-To: <502EC56A.7070604@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.2.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Message-Id: <20120819160852.C65A121F8516@ietfa.amsl.com> Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 16:08:53 -0000 KzEgZm9yIGJvdGggZG9jdW1lbnRzLg0KDQpNYXJrIERpb2RhdGkNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNClRoaXMgZS1tYWlsIG1lc3NhZ2UsIGluY2x1ZGluZyBh bnkgYXR0YWNobWVudHMsIGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIHBlcnNvbiB0byB3aG9t IGl0IGhhcyBiZWVuIHNlbnQsIGFuZCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNv bmZpZGVudGlhbCBvciBsZWdhbGx5IHByb3RlY3RlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCBvciBoYXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgeW91 IGFyZSBub3QgYXV0aG9yaXplZCB0byBjb3B5LCBkaXN0cmlidXRlLCBvciBvdGhlcndpc2UgdXNl IHRoaXMgbWVzc2FnZSBvciBpdHMgYXR0YWNobWVudHMuIFBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSByZXR1cm4gZS1tYWlsIGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMuIEdhcnRuZXIgbWFrZXMgbm8gd2FycmFudHkg dGhhdCB0aGlzIGUtbWFpbCBpcyBlcnJvciBvciB2aXJ1cyBmcmVlLg0K From paul.madsen@gmail.com Sun Aug 19 13:38:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357CF21F859A for ; Sun, 19 Aug 2012 13:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+BIhwzjZBFB for ; Sun, 19 Aug 2012 13:38:51 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3D21F8595 for ; Sun, 19 Aug 2012 13:38:51 -0700 (PDT) Received: by iabz21 with SMTP id z21so2434848iab.31 for ; Sun, 19 Aug 2012 13:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=0ibCMH2pYirMW5LyWlAeLTxguxdF7J/Fzt1VMqO2Bm4=; b=ma99fNVGnQPzKOHxRDdhN3xAE2jk/f0tY3TTTTf9S+y1ZiayXPTTHi0fiUFU1Aw8xW wuWuXp2n+MWxcsa9fKdoSChC/DZ4eDIJJ+A+19eg9Ai+XyGTQGj2r+hhPjeYhzG9rtTX h304nN+KG/VGnl+t7+fBci2gCW6DXdmNou+s9y9ycE7T7AaxcZgBV1DvcLB42PGWc9qo hpcNQ+zY9epv/mC9cQiegBPzof/m8SN0DT461aySSmLNcNNUSNxuJLY0jqoJo2s4P+7s rPhYHsVYdgdWY5MSyoMUC+kBf9l1SFMKgGErORbjCZdb1X2xx9cSyJnCkvAWu+V6hs0k UDRQ== Received: by 10.50.217.137 with SMTP id oy9mr7860463igc.56.1345408725200; Sun, 19 Aug 2012 13:38:45 -0700 (PDT) Received: from pmadsen-mbp.local (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com. [99.224.20.155]) by mx.google.com with ESMTPS id a3sm10904075igd.7.2012.08.19.13.38.42 (version=SSLv3 cipher=OTHER); Sun, 19 Aug 2012 13:38:44 -0700 (PDT) Message-ID: <50314ED2.5040506@gmail.com> Date: Sun, 19 Aug 2012 16:38:42 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: scim@ietf.org References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Content-Type: multipart/alternative; boundary="------------080709060800010102050603" Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 20:38:52 -0000 This is a multi-part message in MIME format. --------------080709060800010102050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 On 8/17/12 4:26 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is a call for adoption of > > http://www.ietf.org/id/draft-scim-api-01.txt > http://www.ietf.org/id/draft-scim-core-schema-01.txt > > as working group documents. > > For those who are new to the IETF this means that > > - - change control is ultimately in the hand of the WG, and > - - changes to these documents will be based on WG consensus > > but it does not imply that these documents in any way > represent a "finished product". > > In other words, this decision represents the beginning, > not the end. > > If you agree and want the WG to adopt these documents > please '+1' this email. > > Leif& Mortezza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 > PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 > =xZqq > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim --------------080709060800010102050603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

On 8/17/12 4:26 PM, Leif Johansson wrote: 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


This is a call for adoption of

http://www.ietf.org/id/draft-scim-api-01.txt
http://www.ietf.org/id/draft-scim-core-schema-01.txt

as working group documents.

For those who are new to the IETF this means that

- - change control is ultimately in the hand of the WG, and
- - changes to these documents will be based on WG consensus

but it does not imply that these documents in any way
represent a "finished product".

In other words, this decision represents the beginning,
not the end.

If you agree and want the WG to adopt these documents
please '+1' this email.

	Leif & Mortezza
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7
PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52
=xZqq
-----END PGP SIGNATURE-----
_______________________________________________
scim mailing list
scim@ietf.org
https://www.ietf.org/mailman/listinfo/scim
--------------080709060800010102050603-- From leifj@mnt.se Sun Aug 19 23:40:44 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03EF21F841E for ; Sun, 19 Aug 2012 23:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-1.562, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgEy8YW5CbFX for ; Sun, 19 Aug 2012 23:40:43 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81B3611E8091 for ; Sun, 19 Aug 2012 23:40:42 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so3291170lbb.31 for ; Sun, 19 Aug 2012 23:40:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version :x-gm-message-state; bh=wcBpuLbHb8IN934DC8WSgwBgqEeETU5us9f36AbJKlk=; b=UcxGXOekt7QeyF4zyh1tiKZe4ZwCj8hqQOtWwGdcuxU3Kr38uqrrpU7WHYqLpTlN/t IcB4Oeq8dM8/e1Na0dbY3G/m+3U+vn/WCHwPNI/aXHg+nb4G+PxUSZylVnpmk6+9KNTV hu0bx9OMlWA1T07NG5okAkJ0eFsXIorqJhMahzJRAL+a8AQ9bD23b9yym43nyFx0WTv7 h46GmoLD4ZAtCrCqCznX6y19N4l3IbJPicZll4wgWx+F7wiibBh6BP26XokLhjPdjw/s EXV8lCAQeWgNJ22oMds+rT3uPF2uOAo/ZY2vUNI+bW+QWizTLe43QY9eegk7gsEWJF6s qlgQ== Received: by 10.152.112.138 with SMTP id iq10mr12945704lab.13.1345444841515; Sun, 19 Aug 2012 23:40:41 -0700 (PDT) Received: from [172.20.10.3] (2.64.176.56.mobile.tre.se. [2.64.176.56]) by mx.google.com with ESMTPS id lv13sm14907999lab.8.2012.08.19.23.40.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 23:40:40 -0700 (PDT) References: <502EA90A.5000208@mnt.se> <50314ED2.5040506@gmail.com> From: Leif Johansson Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9B206) In-Reply-To: <50314ED2.5040506@gmail.com> Message-Id: <8F348E5C-9A6D-4EAF-857B-6986BBD96CFB@mnt.se> Date: Mon, 20 Aug 2012 08:40:37 +0200 To: scim@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQk3VZTqT+qaLprAIKc1J0rp6C2HEzqA8I4f81agsT2G0gD75LgOiipeGmh/3IbmPe0soKtU Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 06:40:44 -0000 Ok I'm calling this. The WG has achieved consensus. Please take your seats a= nd fasten your seatbelts in preparation for takeoff. From a.paventhan@gmail.com Mon Aug 20 00:15:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57421F8647 for ; Mon, 20 Aug 2012 00:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrcjRgA6DzaZ for ; Mon, 20 Aug 2012 00:15:41 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC48921F863C for ; Mon, 20 Aug 2012 00:15:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5838644vbb.31 for ; Mon, 20 Aug 2012 00:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LUFmgMcXhvNnJipkbilhPKJzWpidEaPtgq4CF/cPeF8=; b=OAOmF73wRr+Nn3g9vI5z4D5QoGmaCu81/A/0NESPFO57xHBIOwGpSCijVId1n2Sb7u e3UUGJmn/k/+RVLQsHY7NLO4NrEfpU5HDr7G7ABaONLlmZTpnEg8RfiiHHifL69uvBmH lZYvZU/We3cQTki319oNccEqwNxVuW+1QydE2o5nYQLrK7Yxv7McfZCEAuuFk+HnR7IS 63i/DzpIFk1Pid8Absc8elmxhpUCQghnQwwupUlGREDpYSjQByIq7qHInAnlVe5rEh+J ITPWMczCy/lHyOOYN3QKqVTaIWX/KiHwIMtFiW1h4XjZ6n+OLTUdv6euFtkWPHsJ1XhK 8azw== MIME-Version: 1.0 Received: by 10.59.1.193 with SMTP id bi1mr9933007ved.57.1345446940108; Mon, 20 Aug 2012 00:15:40 -0700 (PDT) Received: by 10.58.35.40 with HTTP; Mon, 20 Aug 2012 00:15:40 -0700 (PDT) Date: Mon, 20 Aug 2012 12:45:40 +0530 Message-ID: From: A Paventhan To: scim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 07:15:42 -0000 +1 ------------------------------------------------------------------------------------------------------------------- From: Leif Johansson To: scim WG Date: Fri, 17 Aug 2012 22:26:50 +0200 List-id: Simple Cloud Identity Management BOF ________________________________ -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - - change control is ultimately in the hand of the WG, and - - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 =xZqq -----END PGP SIGNATURE----- From michael.hammer@yaanatech.com Mon Aug 20 13:11:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA7E21F852D for ; Mon, 20 Aug 2012 13:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHSfe8Kr3QtH for ; Mon, 20 Aug 2012 13:11:12 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 547D521F852B for ; Mon, 20 Aug 2012 13:11:12 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 20 Aug 2012 13:11:10 -0700 From: Michael Hammer To: "leifj@mnt.se" , "scim@ietf.org" Thread-Topic: [scim] call for wg adoption Thread-Index: AQHNfLaoqkqNKTgyf0aa+W/nxDvv0pdjJl5Q Date: Mon, 20 Aug 2012 20:11:08 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB310AA78A2@EX2K10MB1.corp.yaanatech.com> References: <502EA90A.5000208@mnt.se> In-Reply-To: <502EA90A.5000208@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.22] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0220_01CD7EEE.655BE590" MIME-Version: 1.0 Subject: Re: [scim] call for wg adoption X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:11:13 -0000 ------=_NextPart_000_0220_01CD7EEE.655BE590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 +1 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson Sent: Friday, August 17, 2012 4:27 PM To: scim WG Subject: [scim] call for wg adoption -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a call for adoption of http://www.ietf.org/id/draft-scim-api-01.txt http://www.ietf.org/id/draft-scim-core-schema-01.txt as working group documents. For those who are new to the IETF this means that - - change control is ultimately in the hand of the WG, and - - changes to these documents will be based on WG consensus but it does not imply that these documents in any way represent a "finished product". In other words, this decision represents the beginning, not the end. If you agree and want the WG to adopt these documents please '+1' this email. Leif & Mortezza -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAuqQUACgkQ8Jx8FtbMZncdmACgmwC/WNarupkrK2ls1zLUI0j7 PiMAnR94LOTNYrT3ftDxIkfMOzN1HS52 =xZqq -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0220_01CD7EEE.655BE590 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy MDIwMTEwM1owIwYJKoZIhvcNAQkEMRYEFOYBo6I4Y3j2usl70DbO+hAVh4NkMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGAIv/4Y4DqCA0JtqCs9Q/jxMPgbDg3D4h6rnmecUrVERcV C6EGbFoJ7OPNDM+wIu67QsAVyvrGqtnqr6miV92qWWB039qDO5s0drkOR1A6CzIYiuFILII3J4ZR 7hgUxqKhkpnAJybtZOhmsJjognY2epTzRMuT61DDit2k6qjy2AwAAAAAAAA= ------=_NextPart_000_0220_01CD7EEE.655BE590-- From internet-drafts@ietf.org Mon Aug 27 23:52:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9421E8049; Mon, 27 Aug 2012 23:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQOTgrekEZHj; Mon, 27 Aug 2012 23:52:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4CE21F8425; Mon, 27 Aug 2012 23:52:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828065253.3998.78509.idtracker@ietfa.amsl.com> Date: Mon, 27 Aug 2012 23:52:53 -0700 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-api-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:52:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the System for Cross-domain Identity Manageme= nt Working Group of the IETF. Title : System for Cross-Domain Identity Management:Protocol Author(s) : Trey Drake Chuck Mortimore Morteza Ansari Kelly Grizzle Erik Wahlstroem Filename : draft-ietf-scim-api-00.txt Pages : 47 Date : 2012-08-27 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. 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. It's 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 standard protocols. In essence, make it fast, cheap, and easy to move users in to, out of, and around the cloud. 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Aug 27 23:53:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83B821E8049; Mon, 27 Aug 2012 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4XWZrAUjre; Mon, 27 Aug 2012 23:53:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529DF21E8050; Mon, 27 Aug 2012 23:53:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828065304.11931.23673.idtracker@ietfa.amsl.com> Date: Mon, 27 Aug 2012 23:53:04 -0700 Cc: scim@ietf.org Subject: [scim] I-D Action: draft-ietf-scim-core-schema-00.txt X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:53:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the System for Cross-domain Identity Manageme= nt Working Group of the IETF. Title : System for Cross-Domain Identity Management: Core Schema Author(s) : Chuck Mortimore Patrick Harding Paul Madsen Trey Drake Filename : draft-ietf-scim-core-schema-00.txt Pages : 41 Date : 2012-08-27 Abstract: The System for Cross-Domain Identity Management (SCIM) specification is designed to make managing user identity 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 standard protocols. In essence, make it fast, cheap, and easy to move identity in to, out of, and around the cloud. This document provides a platform neutral schema and extension model for representing users and groups in JSON and XML formats. This schema is intended for exchange and use with cloud service providers. Additional binding documents provide a standard REST API, SAML binding, and use cases. 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-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hasini@wso2.com Tue Aug 28 06:18:23 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8E21F8466 for ; Tue, 28 Aug 2012 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCYaGvIQmq4X for ; Tue, 28 Aug 2012 06:18:22 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4680321F8467 for ; Tue, 28 Aug 2012 06:18:21 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so6580825vcb.31 for ; Tue, 28 Aug 2012 06:18:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=K1qCEJvfojKpW9U2qSJud5oWjnCsfwpem2lmVBvG9aI=; b=RxHH5MMplmjPukcpE7SF27cGlGlteSAjyfbEYlKlTwj/z0gQ42q8yL/a8P1X3mpaC/ WbWDjo6Xqp9DcVldFn2/wFff3KWEhOVuRrk3RsSvf2NHvUS//X3iNUIBUT/UmAhe01Kq NREyAvvlY6nUMNLkLm1yTCbEV7LfQqzBVfzAHRXBlyS12ZJlJJC0E3E3IdOnbpP9s9vp +xIg8yXbxkAEjSlShk36CEz1fKGiSQMWcCET3qHG+WDs+kjk62wLubXXaQRl9sIyG+KH FD9tDCqXbgtLOeVSv6LzrVdXpa3S0nNTN5QwXkQ7tXfD4Uak8zRmpOiwoj3nzEqCytwZ FQ8Q== MIME-Version: 1.0 Received: by 10.220.239.209 with SMTP id kx17mr14581008vcb.41.1346159901047; Tue, 28 Aug 2012 06:18:21 -0700 (PDT) Received: by 10.58.132.179 with HTTP; Tue, 28 Aug 2012 06:18:20 -0700 (PDT) Date: Tue, 28 Aug 2012 18:48:20 +0530 Message-ID: From: Hasini Gunasinghe To: scim@ietf.org Content-Type: multipart/alternative; boundary=14dae9cdbefbb67bb304c8534611 X-Gm-Message-State: ALoCoQm/h9eS5IMvQEKbZZiToHVw7TFFE7dUsG1n0hie0kxO4MBiuiYn9hiXb27yiYrb1W2gTqPw Subject: [scim] SCIM attributes to LDAP attributes mapping {was: Directory mapping discussion at ietf vancouver} X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:18:23 -0000 --14dae9cdbefbb67bb304c8534611 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Did the below mentioned discussion happen? If so, could some one please brief the list what the outcome of the discussion was? Mapping SCIM attributes to LDAP attributes and vice versa is a common requirement that both the SCIM consumer and SP implementations encounter. IMO, we can come up with a Object Class for SCIM User (may be extending inetOrgPerson or a completely new schema) and SCIM Group. Appreciate thoughts on this.. Thanks, Hasini. On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt wrote: > Would anyone be interested in having a broader discussion about ldap > directories and mapping support prior to the scim wg session. > > In particular it would good to explore some alternatives for mapping vs > direct complex attribute support. > > My primary worry is some mapping proposals lead to existing clients having > to change classic ldap queries. I'd like to get to full fidelity > (bi-directional mapping) support and full backwards compatibility for > existing clients if possible. > > I think a good open discussion might take longer than we have scheduled > time in the meeting. :) > > Phil > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > --14dae9cdbefbb67bb304c8534611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Did the below mentioned discussion happen? If so= , could some one please brief the list what the outcome of the discussion w= as?=A0

Mapping SCIM attributes to LDAP attributes = and vice versa is a common requirement that both the SCIM consumer and SP i= mplementations encounter.

IMO, we can come up with a Object Class for SCIM User (= may be extending inetOrgPerson or a completely new schema) and SCIM Group.<= /div>

Appreciate thoughts on this..

Thanks,
Hasini.

On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
Would anyone be interested in having a broad= er discussion about ldap directories and mapping support prior to the scim = wg session.

In particular it would good to explore some alternatives for mapping vs dir= ect complex attribute support.

My primary worry is some mapping proposals lead to existing clients having = to change classic ldap queries. I'd like to get to full fidelity (bi-di= rectional mapping) support and full backwards compatibility for existing cl= ients if possible.

I think a good open discussion might take longer than we have scheduled tim= e in the meeting. :)

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

--14dae9cdbefbb67bb304c8534611-- From phil.hunt@oracle.com Tue Aug 28 06:32:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B011E809C for ; Tue, 28 Aug 2012 06:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6m19DuL9JYpP for ; Tue, 28 Aug 2012 06:32:17 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDD211E808D for ; Tue, 28 Aug 2012 06:32:17 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7SDWFnS011903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Aug 2012 13:32:16 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7SDWEVY019322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 13:32:15 GMT Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7SDWElo029253; Tue, 28 Aug 2012 08:32:14 -0500 Received: from [10.20.250.180] (/204.239.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Aug 2012 06:32:14 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A98BF3C-080D-4693-8877-6359DCD33AA9" From: Phil Hunt In-Reply-To: Date: Tue, 28 Aug 2012 06:32:14 -0700 Message-Id: References: To: Hasini Gunasinghe X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim@ietf.org Subject: Re: [scim] SCIM attributes to LDAP attributes mapping {was: Directory mapping discussion at ietf vancouver} X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:32:18 -0000 --Apple-Mail=_4A98BF3C-080D-4693-8877-6359DCD33AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hasini, Yes. The meeting did happen. I'm putting together a draft right now that = should capture the discussion and some of the previous work that has = been done on mappings. Would be great to have your input. The slides I presented are available here: http://www.ietf.org/proceedings/84/slides/slides-84-scim-0.pdf Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-28, at 6:18 AM, Hasini Gunasinghe wrote: > Hi all, >=20 > Did the below mentioned discussion happen? If so, could some one = please brief the list what the outcome of the discussion was?=20 >=20 > Mapping SCIM attributes to LDAP attributes and vice versa is a common = requirement that both the SCIM consumer and SP implementations = encounter. >=20 > IMO, we can come up with a Object Class for SCIM User (may be = extending inetOrgPerson or a completely new schema) and SCIM Group. >=20 > Appreciate thoughts on this.. >=20 > Thanks, > Hasini. >=20 > On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt = wrote: > Would anyone be interested in having a broader discussion about ldap = directories and mapping support prior to the scim wg session. >=20 > In particular it would good to explore some alternatives for mapping = vs direct complex attribute support. >=20 > My primary worry is some mapping proposals lead to existing clients = having to change classic ldap queries. I'd like to get to full fidelity = (bi-directional mapping) support and full backwards compatibility for = existing clients if possible. >=20 > I think a good open discussion might take longer than we have = scheduled time in the meeting. :) >=20 > Phil > _______________________________________________ > 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 --Apple-Mail=_4A98BF3C-080D-4693-8877-6359DCD33AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 ht= tp://www.ietf.org/proceedings/84/slides/slides-84-scim-0.pdf

Phil

On 2012-08-28, at 6:18 AM, Hasini Gunasinghe = wrote:

Hi all,

Did the below mentioned = discussion happen? If so, could some one please brief the list what the = outcome of the discussion was? 

Mapping = SCIM attributes to LDAP attributes and vice versa is a common = requirement that both the SCIM consumer and SP implementations = encounter.

IMO, we can come up with a Object Class for SCIM = User (may be extending inetOrgPerson or a completely new schema) and = SCIM Group.

Appreciate thoughts on this..

Thanks,
Hasini.

On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Would anyone be = interested in having a broader discussion about ldap directories and = mapping support prior to the scim wg session.

In particular it would good to explore some alternatives for mapping vs = direct complex attribute support.

My primary worry is some mapping proposals lead to existing clients = having to change classic ldap queries. I'd like to get to full fidelity = (bi-directional mapping) support and full backwards compatibility for = existing clients if possible.

I think a good open discussion might take longer than we have scheduled = time in the meeting. :)

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

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

= --Apple-Mail=_4A98BF3C-080D-4693-8877-6359DCD33AA9-- From stpeter@stpeter.im Tue Aug 28 08:18:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24C111E80FF for ; Tue, 28 Aug 2012 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsXY23H21wyp for ; Tue, 28 Aug 2012 08:18:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2624A11E8103 for ; Tue, 28 Aug 2012 08:18:43 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F325404EB for ; Tue, 28 Aug 2012 09:19:50 -0600 (MDT) Message-ID: <503CE150.6030903@stpeter.im> Date: Tue, 28 Aug 2012 09:18:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "scim@ietf.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:18:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While we're discussing mappings to LDAP and such, might it be worthwhile to also discuss the base data format? I've heard that some folks might be interested in or at least open to using, say, vCard4. At the least, it might be good to explore our options even if we end up using the current format. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA84VAACgkQNL8k5A2w/vw9IACfe3R/bDiFKvd6JbXq1+HNA3bH LiAAnjUg3ORZs2ARKemNuzRIueLieGKX =e7Vh -----END PGP SIGNATURE----- From leifj@mnt.se Tue Aug 28 10:51:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF85721F85F9 for ; Tue, 28 Aug 2012 10:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RC1igvXzrhl for ; Tue, 28 Aug 2012 10:51:51 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id C408B21F85F3 for ; Tue, 28 Aug 2012 10:51:47 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7SHoQZU004632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 19:50:30 +0200 (CEST) Message-ID: <503D04E2.9010601@mnt.se> Date: Tue, 28 Aug 2012 19:50:26 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <503CE150.6030903@stpeter.im> In-Reply-To: <503CE150.6030903@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:51:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2012 05:18 PM, Peter Saint-Andre wrote: > While we're discussing mappings to LDAP and such, might it be > worthwhile to also discuss the base data format? I've heard that > some folks might be interested in or at least open to using, say, > vCard4. At the least, it might be good to explore our options even > if we end up using the current format. > You're talking about the object schema (persons, groups, etc) right? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9BOIACgkQ8Jx8FtbMZnd0TQCfSiw+lvXuZQGw5R/B+Qg/GTay 8tgAn1gp1TpcqWPAlqWxAcNy8bSRpk5n =TA0N -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Aug 28 10:54:40 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A824021F84A5 for ; Tue, 28 Aug 2012 10:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuNzN5ZsurCN for ; Tue, 28 Aug 2012 10:54:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C20321F84A0 for ; Tue, 28 Aug 2012 10:54:40 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D8F83404EB; Tue, 28 Aug 2012 11:55:48 -0600 (MDT) Message-ID: <503D05DE.6060502@stpeter.im> Date: Tue, 28 Aug 2012 11:54:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leif Johansson References: <503CE150.6030903@stpeter.im> <503D04E2.9010601@mnt.se> In-Reply-To: <503D04E2.9010601@mnt.se> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:54:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/12 11:50 AM, Leif Johansson wrote: > On 08/28/2012 05:18 PM, Peter Saint-Andre wrote: >> While we're discussing mappings to LDAP and such, might it be >> worthwhile to also discuss the base data format? I've heard that >> some folks might be interested in or at least open to using, >> say, vCard4. At the least, it might be good to explore our >> options even if we end up using the current format. > > You're talking about the object schema (persons, groups, etc) > right? Yes, sorry about the lack of clarity -- too much multitasking! /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9Bd4ACgkQNL8k5A2w/vx6agCfY6SKkeepEADyefMAcXYGzVF2 CtUAoNGPlNC53pl9O6NfueAuo0lJ5afW =xLuz -----END PGP SIGNATURE----- From leifj@mnt.se Tue Aug 28 11:05:37 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B0A21F8613 for ; Tue, 28 Aug 2012 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sHqNaQ7ILVz for ; Tue, 28 Aug 2012 11:05:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0620E21F85F7 for ; Tue, 28 Aug 2012 11:05:35 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7SI4B8w024692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Aug 2012 20:04:15 +0200 (CEST) Message-ID: <503D081B.4030505@mnt.se> Date: Tue, 28 Aug 2012 20:04:11 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <503CE150.6030903@stpeter.im> <503D04E2.9010601@mnt.se> <503D05DE.6060502@stpeter.im> In-Reply-To: <503D05DE.6060502@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:05:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/28/2012 07:54 PM, Peter Saint-Andre wrote: > On 8/28/12 11:50 AM, Leif Johansson wrote: >> On 08/28/2012 05:18 PM, Peter Saint-Andre wrote: >>> While we're discussing mappings to LDAP and such, might it be >>> worthwhile to also discuss the base data format? I've heard >>> that some folks might be interested in or at least open to >>> using, say, vCard4. At the least, it might be good to explore >>> our options even if we end up using the current format. > >> You're talking about the object schema (persons, groups, etc) >> right? > > Yes, sorry about the lack of clarity -- too much multitasking! > > /psa > I only ask because some of the threads in Vancouver suggested a need to finess the framing aswell. Cheers Leif > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9CBsACgkQ8Jx8FtbMZncFjQCgkItTVp794zXpgqlYEOBfb971 xYYAn1WplCfwEqEtFvNPNL+94APczYE2 =R5nS -----END PGP SIGNATURE----- From likepeng@huawei.com Tue Aug 28 17:27:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C5221F8643 for ; Tue, 28 Aug 2012 17:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3Gp2YWQSeDD for ; Tue, 28 Aug 2012 17:27:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E383121F863F for ; Tue, 28 Aug 2012 17:27:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKA67129; Wed, 29 Aug 2012 00:27:24 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 01:23:26 +0100 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 29 Aug 2012 01:23:54 +0100 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.168]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Wed, 29 Aug 2012 08:23:51 +0800 From: Likepeng To: Peter Saint-Andre , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBvjdOYfg7rTkOFhLAjKkL3Lpdv7X7g Date: Wed, 29 Aug 2012 00:23:50 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F21ED3DFAF@szxeml525-mbx.china.huawei.com> References: <503CE150.6030903@stpeter.im> In-Reply-To: <503CE150.6030903@stpeter.im> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.124] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 00:27:27 -0000 PkkndmUgaGVhcmQgdGhhdCBzb21lIGZvbGtzIG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4gb3IgYXQg bGVhc3Qgb3BlbiB0byB1c2luZywgc2F5LCB2Q2FyZDQuDQo+QXQgdGhlIGxlYXN0LCBpdCBtaWdo dCBiZSBnb29kIHRvIGV4cGxvcmUgb3VyIG9wdGlvbnMgZXZlbiBpZiB3ZSBlbmQNCnVwIHVzaW5n IHRoZSBjdXJyZW50IGZvcm1hdC4NCg0KWWVzLCBJIGhhdmUgaW50ZXJlc3QgYWJvdXQgdGhlIG1h cHBpbmcgYmV0d2VlbiB2Q2FyZCA0IGFuZCB0aGUgb2JqZWN0IHNjaGVtYS4NCg0KSSBoYXZlIGRv bmUgc29tZSBhbmFseXNpcyBhbmQgZm91bmQgb3V0IHRoYXQgbW9zdCBvZiB0aGUgZWxlbWVudHMv YXR0cmlidXRlcyBjYW4gYmUgbWFwcGVkLg0KDQpJIGFtIHBsYW5pbmcgdG8gd3JpdGUgYW4gSS1E IHRvIG91dGxpbmUgdGhlIG1hcHBpbmdzLg0KDQpJZiBhbnlib2R5IGVsc2UgaGFzIGludGVyZXN0 LCB3ZSBjYW4gd29yayB0b2dldGhlciBmb3IgdGhpcy4NCg0KVGhhbmtzLA0KS2luZCBSZWdhcmRz DQpLZXBlbmcNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBzY2ltLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpzY2ltLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUGV0ZXIgU2FpbnQtQW5kcmUN Creiy83KsbzkOiAyMDEyxOo41MIyOMjVIDIzOjE5DQrK1bz+yMs6IHNjaW1AaWV0Zi5vcmcNCtb3 zOI6IFtzY2ltXSBkYXRhIGZvcm1hdA0KDQotLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0t LS0tDQpIYXNoOiBTSEExDQoNCldoaWxlIHdlJ3JlIGRpc2N1c3NpbmcgbWFwcGluZ3MgdG8gTERB UCBhbmQgc3VjaCwgbWlnaHQgaXQgYmUNCndvcnRod2hpbGUgdG8gYWxzbyBkaXNjdXNzIHRoZSBi YXNlIGRhdGEgZm9ybWF0PyBJJ3ZlIGhlYXJkIHRoYXQgc29tZQ0KZm9sa3MgbWlnaHQgYmUgaW50 ZXJlc3RlZCBpbiBvciBhdCBsZWFzdCBvcGVuIHRvIHVzaW5nLCBzYXksIHZDYXJkNC4NCkF0IHRo ZSBsZWFzdCwgaXQgbWlnaHQgYmUgZ29vZCB0byBleHBsb3JlIG91ciBvcHRpb25zIGV2ZW4gaWYg d2UgZW5kDQp1cCB1c2luZyB0aGUgY3VycmVudCBmb3JtYXQuDQoNClBldGVyDQoNCi0gLS0gDQpQ ZXRlciBTYWludC1BbmRyZQ0KaHR0cHM6Ly9zdHBldGVyLmltLw0KDQoNCi0tLS0tQkVHSU4gUEdQ IFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRy9NYWNHUEcyIHYyLjAuMTggKERhcndpbikN CkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9lbmlnbWFpbC5tb3pk ZXYub3JnLw0KDQppRVlFQVJFQ0FBWUZBbEE4NFZBQUNna1FOTDhrNUEydy92dzlJQUNmZTNSL2JE aUZLdmQ2SmJYcTErSE5BM2JIDQpMaUFBbmpVZzNPUlpzMkFSS2VtTnV6Ukl1ZUxpZUdLWA0KPWU3 VmgNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNjaW0gbWFpbGluZyBsaXN0DQpzY2ltQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NjaW0NCg== From trey.drake@unboundid.com Tue Aug 28 17:44:16 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51D21F8460 for ; Tue, 28 Aug 2012 17:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeuPodjGvOLA for ; Tue, 28 Aug 2012 17:44:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCF21F8464 for ; Tue, 28 Aug 2012 17:44:15 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so13272849obb.31 for ; Tue, 28 Aug 2012 17:44:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=U3DZmpfzeQPTrmeZJXYnMF/EOqWTgbqbwFdKASD9YTI=; b=eDKhxEmARpcbjQn2FHCJ8AJle9QrgTTPAGLtMti3otgeqa4FGJ45BKYKTnBva3oYoS DBZdkZDuHoVfuXf4xF7wgWTMGk8QbsaIBAVtU/a6N8ZP1zoTJHraGPGo+42zBX27iiJu jZANInlMIpEnBy8+NNrPm5x9MnWbPbpy2Svl9eFO6XXULtqS2Ad2kUX0sg2kKWAbRDk1 av4PnBPGjbkHTjnQAXzU8nR9MPP8Qn0QwMmWadfBeHr+PolNfzot51O/5nnkyqngZnSQ /+beMkYU18SG/gxVFl0+UQcglBMmGf3S/eHcORIdLBiHpQB1sECsatAWPRkSGvbGUkNb XkFw== Received: by 10.60.13.37 with SMTP id e5mr13735857oec.98.1346201055352; Tue, 28 Aug 2012 17:44:15 -0700 (PDT) Received: from office-dhcp-188.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id e9sm15662808oee.12.2012.08.28.17.44.13 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 28 Aug 2012 17:44:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: <503CE150.6030903@stpeter.im> Date: Tue, 28 Aug 2012 19:44:12 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> References: <503CE150.6030903@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQksvLctgWLNvQcR1AsILQj1cSE+SVJvXd1ZpHQD5U+qBo5gv1r/Esvlx0fwzM4ZbLD2XHb8 Cc: "scim@ietf.org" Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 00:44:16 -0000 Peter, Would this be in addition to or in lieu of the JSON and XML formats? Thanks, Trey On Aug 28, 2012, at 10:18 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > While we're discussing mappings to LDAP and such, might it be > worthwhile to also discuss the base data format? I've heard that some > folks might be interested in or at least open to using, say, vCard4. > At the least, it might be good to explore our options even if we end > up using the current format. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAlA84VAACgkQNL8k5A2w/vw9IACfe3R/bDiFKvd6JbXq1+HNA3bH > LiAAnjUg3ORZs2ARKemNuzRIueLieGKX > =e7Vh > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From hasini@wso2.com Tue Aug 28 18:17:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C9E11E80A3 for ; Tue, 28 Aug 2012 18:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5L41Lsulgrh for ; Tue, 28 Aug 2012 18:17:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDB011E809B for ; Tue, 28 Aug 2012 18:17:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so18925vbb.31 for ; Tue, 28 Aug 2012 18:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eN9/j3PH7EDNfz7f7mbSGEheewq02iwdfhQpn8A9yN0=; b=AhwxAZowP4ZGbIr5KlcfqozDP2PiI4CkTxob8QHTl6ynf/D5OEdN8ULbyPgdjuw2Du VH1Et9njac+fsDWhfZPJn3jGwvxBBEQLpmaMi3agATcTWaEYXM3k7Dt1PADJnPlLsRsP 2yLAnS4aUGxCHjUPaYRnHUH01utELv9mlfWvwpQXTgPQr5qyEfd67xDMB4916JUZD+e2 QU/s60fuzaT3NFK+8H4/c7KrOinghJJJ6vI6dP9vX9Wa8STgQXNL/6jiH4AuWxmqHOJu IyLNFrIwnjPvdy/67FT1gOXLG/iqbXthUtI8dPm+5DNw8U51noBLEhRi/cmhPUznXd0Y ofsQ== MIME-Version: 1.0 Received: by 10.220.239.209 with SMTP id kx17mr16355484vcb.41.1346203021282; Tue, 28 Aug 2012 18:17:01 -0700 (PDT) Received: by 10.58.132.179 with HTTP; Tue, 28 Aug 2012 18:17:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Aug 2012 06:47:01 +0530 Message-ID: From: Hasini Gunasinghe To: Phil Hunt Content-Type: multipart/alternative; boundary=14dae9cdbefbe10b7c04c85d5022 X-Gm-Message-State: ALoCoQmo35FN7bPCzT8oqgkbGmvvEsx3fWJKYiOxTBvXpRxTdZUOGSiHSykyzAeMyUkQzY3mH/MI Cc: scim@ietf.org Subject: Re: [scim] SCIM attributes to LDAP attributes mapping {was: Directory mapping discussion at ietf vancouver} X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 01:17:04 -0000 --14dae9cdbefbe10b7c04c85d5022 Content-Type: text/plain; charset=ISO-8859-1 Hi Phil, Thanks for the info. Looking forward for the draft to provide input.. Thanks, Hasini. On Tue, Aug 28, 2012 at 7:02 PM, Phil Hunt wrote: > Hasini, > > Yes. The meeting did happen. I'm putting together a draft right now that > should capture the discussion and some of the previous work that has been > done on mappings. Would be great to have your input. > > The slides I presented are available here: > http://www.ietf.org/proceedings/84/slides/slides-84-scim-0.pdf > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-08-28, at 6:18 AM, Hasini Gunasinghe wrote: > > Hi all, > > Did the below mentioned discussion happen? If so, could some one please > brief the list what the outcome of the discussion was? > > Mapping SCIM attributes to LDAP attributes and vice versa is a common > requirement that both the SCIM consumer and SP implementations encounter. > > IMO, we can come up with a Object Class for SCIM User (may be extending > inetOrgPerson or a completely new schema) and SCIM Group. > > Appreciate thoughts on this.. > > Thanks, > Hasini. > > On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt wrote: > >> Would anyone be interested in having a broader discussion about ldap >> directories and mapping support prior to the scim wg session. >> >> In particular it would good to explore some alternatives for mapping vs >> direct complex attribute support. >> >> My primary worry is some mapping proposals lead to existing clients >> having to change classic ldap queries. I'd like to get to full fidelity >> (bi-directional mapping) support and full backwards compatibility for >> existing clients if possible. >> >> I think a good open discussion might take longer than we have scheduled >> time in the meeting. :) >> >> Phil >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > > --14dae9cdbefbe10b7c04c85d5022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Phil,

Thanks for the info.

L= ooking forward for the draft to provide input..

Th= anks,
Hasini.

On Tue, Aug 28, 2= 012 at 7:02 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Hasini,<= div>
Yes. The meeting did happen. I'm putting together a = draft right now that should capture the discussion and some of the previous= work that has been done on mappings. =A0Would be great to have your input.=

The slides I presented are available here:
http://www.ietf.org/proceedings/84/slides/slides-84-scim-0.= pdf

Phil

On 2012-08-28, at 6:18 AM, Hasini Gunasinghe wrote:

=
Hi all,

Did the below mentione= d discussion happen? If so, could some one please brief the list what the o= utcome of the discussion was?=A0

Mapping SCIM attributes to LDAP attributes and vice ver= sa is a common requirement that both the SCIM consumer and SP implementatio= ns encounter.

IMO, we can come up with a Object Class for SCIM User (= may be extending inetOrgPerson or a completely new schema) and SCIM Group.<= /div>

Appreciate thoughts on this..

Thanks,
Hasini.

On Sat, Jul 14, 2012 at 11:46 PM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
Would anyone be interested in having a broad= er discussion about ldap directories and mapping support prior to the scim = wg session.

In particular it would good to explore some alternatives for mapping vs dir= ect complex attribute support.

My primary worry is some mapping proposals lead to existing clients having = to change classic ldap queries. I'd like to get to full fidelity (bi-di= rectional mapping) support and full backwards compatibility for existing cl= ients if possible.

I think a good open discussion might take longer than we have scheduled tim= e in the meeting. :)

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

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


--14dae9cdbefbe10b7c04c85d5022-- From stpeter@stpeter.im Tue Aug 28 18:17:07 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9227211E80C5 for ; Tue, 28 Aug 2012 18:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju41NEQyW66h for ; Tue, 28 Aug 2012 18:17:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F411E809B for ; Tue, 28 Aug 2012 18:17:06 -0700 (PDT) Received: from [192.168.1.19] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 88662404EB; Tue, 28 Aug 2012 19:18:15 -0600 (MDT) Message-ID: <503D6D90.5060402@stpeter.im> Date: Tue, 28 Aug 2012 19:17:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Trey Drake References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> In-Reply-To: <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 01:17:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/28/12 6:44 PM, Trey Drake wrote: > Peter, > > Would this be in addition to or in lieu of the JSON and XML > formats? Trey, that is a good question. There's an XML representation for vCard4 (RFC 6351) and I've contributed to a document defining a JSON representation (draft-bhat-vcarddav-json), so we could potentially use those (which seems preferable to defining yet another one-off data model with both JSON and XML representations). Ideally, I think we'd settle on just one mandatory-to-implement representation of whatever data model we choose. Furthermore, in the terms of RFC 3444 ("On the Difference between Information Models and Data Models"), we are talking about a data model here (my use of the word "format" was ill-chosen). In essence, it seems to me that iNetOrgPerson and vCard4 and SCIM 1.0 share the same information model (yes, there are some differences, perhaps even some of significance), but that information model has been mapped to several different data models. So I see two separate questions here: 1. Can we use one of the standardized data models (such as iNetOrgPerson or vCard4, perhaps with extensions as needed)? 2. What representations (e.g., XML or JSON or both or other) do we want to support, and can we get away with supporting only one? The reason I asked about vCard4 now is that, if we think we might go down the path of vCard4 in its JSON representation, then we will want to coordinate with the VCARDDAV WG (and I will want to put more time and effort into the I-D I started with my colleague). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9bZAACgkQNL8k5A2w/vxb1QCg0maBkVB+SO8ZKbbFJLE9iuXI /+wAoI3pIxfbsej37qQ9VDpFGSjonr4g =6zuT -----END PGP SIGNATURE----- From leifj@mnt.se Wed Aug 29 00:41:53 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665921F84F9 for ; Wed, 29 Aug 2012 00:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.144 X-Spam-Level: X-Spam-Status: No, score=-3.144 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xmf0pucRKUzr for ; Wed, 29 Aug 2012 00:41:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5B21F84EC for ; Wed, 29 Aug 2012 00:41:52 -0700 (PDT) Received: from [192.36.125.241] (dhcp.pilsnet.sunet.se [192.36.125.241] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7T77lLd019649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 09:07:50 +0200 (CEST) Message-ID: <503DBFC3.90402@mnt.se> Date: Wed, 29 Aug 2012 09:07:47 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim WG X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [scim] Melinda Shore => tracker chief X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:41:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Melinda Shore has volunteered to help the WG by "running the tracker" for the WG specs. In the next few days she'll help the authors get organized bringing some of the relevant issues from the google group tracker into the WG for discussion. Melindas main task will be to make sure we don't loose issues as the WG start to work on "2.0". For those of you who don't know her, Melinda is a long time IETF participant who has been involved in various efforts in this community over the years. Thanks for volunteering Melinda! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9v8MACgkQ8Jx8FtbMZncZZQCfWuXnKm7qcCWFD9TDaTLyiyN8 WewAni3DTlxbYWHqURiZfdVYAvpd+iMk =zWH7 -----END PGP SIGNATURE----- From leifj@mnt.se Wed Aug 29 00:41:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3641F21F84EC for ; Wed, 29 Aug 2012 00:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oF35HodwLLUq for ; Wed, 29 Aug 2012 00:41:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6687C21F84F6 for ; Wed, 29 Aug 2012 00:41:53 -0700 (PDT) Received: from [192.36.125.241] (dhcp.pilsnet.sunet.se [192.36.125.241] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7T78csJ027516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 09:08:41 +0200 (CEST) Message-ID: <503DBFF6.7090609@mnt.se> Date: Wed, 29 Aug 2012 09:08:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> In-Reply-To: <503D6D90.5060402@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:41:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: > On 8/28/12 6:44 PM, Trey Drake wrote: >> Peter, > >> Would this be in addition to or in lieu of the JSON and XML >> formats? > > Trey, that is a good question. There's an XML representation for > vCard4 (RFC 6351) and I've contributed to a document defining a > JSON representation (draft-bhat-vcarddav-json), so we could > potentially use those (which seems preferable to defining yet > another one-off data model with both JSON and XML representations). > Ideally, I think we'd settle on just one mandatory-to-implement > representation of whatever data model we choose. My recollection is that the wg in Vancouver expressed a pretty clear consensus that it wanted to deprecate the XML representation in favor of JSON. This will obviously need to be confirmed on the list but it probably means that if vCard is to be considered that JSON version is going to be important. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj =Niog -----END PGP SIGNATURE----- From samuel@erdtman.se Wed Aug 29 02:41:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06E521F8595 for ; Wed, 29 Aug 2012 02:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHOPi6bWhXe5 for ; Wed, 29 Aug 2012 02:41:25 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9EB321F858A for ; Wed, 29 Aug 2012 02:41:25 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so466076vcb.31 for ; Wed, 29 Aug 2012 02:41:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=rGlCaWQeEAYyihCUUNV+9nV5kIiegxk83eY64ghJIFE=; b=eq/9TpV6KZW2hDMFZVV2AZ7vRFmj7zH9RA/uMoMWqDGzR5Z0cGzDl/z9k2g24s0u0i Gz/vPoEr8o13wZwcJezTkafqm18imVsgkFGqvFVDEVZVmPniHwwUPeGMzBAfkGVuajAi MkoRhxBJGlvcoLZeOMra+LNDTe+n2V1FITq/gFwLQ+sQH65hiCUwXrlxHq+RudOflFQW k8cdyqGdKEC1rUsvTKmuQODnjy4rQRRuxmMGdmtlvTvMs4AHpwrRUA4uLbKnTkcnA9Wp NjtGjoNd34x5fzilaSv3OFBIG6vyd5pQqKQLPJg0wm1RbOby0cBXiKUuEGa7ussNjLqy DWTw== MIME-Version: 1.0 Received: by 10.58.116.175 with SMTP id jx15mr835884veb.6.1346233284768; Wed, 29 Aug 2012 02:41:24 -0700 (PDT) Received: by 10.220.58.205 with HTTP; Wed, 29 Aug 2012 02:41:24 -0700 (PDT) In-Reply-To: <503DBFF6.7090609@mnt.se> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> Date: Wed, 29 Aug 2012 11:41:24 +0200 Message-ID: From: Samuel Erdtman To: Leif Johansson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl83hpkAgfVd5I5h4sty5O+Dig5/TOx1ldKx8uo4/RDajSBKkeAah14kMzxItti/PmZPlWk Cc: scim@ietf.org Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 09:41:26 -0000 Should we also look att aligning attributes to Windows Azure Active Directory Graph, or is that a completely different discussion? regards //Samuel On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: >> On 8/28/12 6:44 PM, Trey Drake wrote: >>> Peter, >> >>> Would this be in addition to or in lieu of the JSON and XML >>> formats? >> >> Trey, that is a good question. There's an XML representation for >> vCard4 (RFC 6351) and I've contributed to a document defining a >> JSON representation (draft-bhat-vcarddav-json), so we could >> potentially use those (which seems preferable to defining yet >> another one-off data model with both JSON and XML representations). >> Ideally, I think we'd settle on just one mandatory-to-implement >> representation of whatever data model we choose. > > My recollection is that the wg in Vancouver expressed a pretty clear > consensus that it wanted to deprecate the XML representation in favor > of JSON. This will obviously need to be confirmed on the list but it > probably means that if vCard is to be considered that JSON version is > going to be important. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 > Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj > =Niog > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Wed Aug 29 04:56:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA60521F8647 for ; Wed, 29 Aug 2012 04:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+tlRJ+XeZYD for ; Wed, 29 Aug 2012 04:56:18 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [193.10.252.66]) by ietfa.amsl.com (Postfix) with ESMTP id B620E21F84AF for ; Wed, 29 Aug 2012 04:56:17 -0700 (PDT) Received: from [192.36.125.241] (dhcp.pilsnet.sunet.se [192.36.125.241] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7TBsr5M015347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 13:54:56 +0200 (CEST) Message-ID: <503E030D.3000303@mnt.se> Date: Wed, 29 Aug 2012 13:54:53 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Samuel Erdtman References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 11:56:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 11:41 AM, Samuel Erdtman wrote: > Should we also look att aligning attributes to Windows Azure > Active Directory Graph, or is that a completely different > discussion? With my chairs hat on: describe the problem and lets have a discussion on the list! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+Aw0ACgkQ8Jx8FtbMZnezyACeMW+1/W/PwbhSj6VKWBaqaw9i 4QEAoICRYaz8RpzZkz44ibltU60p8H60 =K1Ui -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Aug 29 05:43:13 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F38B21F85AA for ; Wed, 29 Aug 2012 05:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tC7itI33ll+B for ; Wed, 29 Aug 2012 05:43:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 374A221F8525 for ; Wed, 29 Aug 2012 05:43:12 -0700 (PDT) Received: from [192.168.1.23] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 00193404EB; Wed, 29 Aug 2012 06:44:22 -0600 (MDT) Message-ID: <503E0E60.5070400@stpeter.im> Date: Wed, 29 Aug 2012 06:43:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Leif Johansson References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: <503DBFF6.7090609@mnt.se> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: scim@ietf.org Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:43:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/29/12 1:08 AM, Leif Johansson wrote: > On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: >> On 8/28/12 6:44 PM, Trey Drake wrote: >>> Peter, > >>> Would this be in addition to or in lieu of the JSON and XML >>> formats? > >> Trey, that is a good question. There's an XML representation for >> vCard4 (RFC 6351) and I've contributed to a document defining a >> JSON representation (draft-bhat-vcarddav-json), so we could >> potentially use those (which seems preferable to defining yet >> another one-off data model with both JSON and XML >> representations). Ideally, I think we'd settle on just one >> mandatory-to-implement representation of whatever data model we >> choose. > > My recollection is that the wg in Vancouver expressed a pretty > clear consensus that it wanted to deprecate the XML representation > in favor of JSON. This will obviously need to be confirmed on the > list but it probably means that if vCard is to be considered that > JSON version is going to be important. Noted. I've forwarded your message to the chair of the VCARDDAV WG so he's aware that SCIM folks might have an interest. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+DmAACgkQNL8k5A2w/vxEMACg8EohUS20UzSEeT2vfkUBFBOi dhgAn2QQy5gjygeWSKJTit0Zu0xS8ms4 =Pi48 -----END PGP SIGNATURE----- From tonynad@microsoft.com Wed Aug 29 07:43:42 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAB11E80CC for ; Wed, 29 Aug 2012 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.729 X-Spam-Level: X-Spam-Status: No, score=-0.729 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM13+PzgS2QH for ; Wed, 29 Aug 2012 07:43:41 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id E1D1811E80D5 for ; Wed, 29 Aug 2012 07:43:30 -0700 (PDT) Received: from mail71-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:43:28 +0000 Received: from mail71-db3 (localhost [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id E254D4C01CF for ; Wed, 29 Aug 2012 14:43:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VS-34(zzbb2dI98dI154cP9371I542M1432Izz1202h1082kzz8275ch1033IL8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail71-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 1346251363526059_2270; Wed, 29 Aug 2012 14:42:43 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.240]) by mail71-db3.bigfish.com (Postfix) with ESMTP id 7ADD580047 for ; Wed, 29 Aug 2012 14:42:43 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:42:24 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 29 Aug 2012 14:42:16 +0000 Received: from mail120-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:42:11 +0000 Received: from mail120-am1 (localhost [127.0.0.1]) by mail120-am1-R.bigfish.com (Postfix) with ESMTP id B41A21E010F for ; Wed, 29 Aug 2012 14:42:11 +0000 (UTC) Received: from mail120-am1 (localhost.localdomain [127.0.0.1]) by mail120-am1 (MessageSwitch) id 1346251330257678_28490; Wed, 29 Aug 2012 14:42:10 +0000 (UTC) Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.244]) by mail120-am1.bigfish.com (Postfix) with ESMTP id 32CF41C0046; Wed, 29 Aug 2012 14:42:10 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS020.bigfish.com (10.3.207.158) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:42:10 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.235]) by BL2PRD0310HT004.namprd03.prod.outlook.com ([10.255.97.39]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 14:42:09 +0000 From: Anthony Nadalin To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTB9l1Lv55pR3k62fypdT/wSB5dv9G8AgAAJLwCAAGI6AIAAfpPA Date: Wed, 29 Aug 2012 14:42:09 +0000 Message-ID: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: <503DBFF6.7090609@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC104.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:43:42 -0000 I'm in favor of only a JSON representation -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 12:09 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: > On 8/28/12 6:44 PM, Trey Drake wrote: >> Peter, >=20 >> Would this be in addition to or in lieu of the JSON and XML formats? >=20 > Trey, that is a good question. There's an XML representation for > vCard4 (RFC 6351) and I've contributed to a document defining a JSON=20 > representation (draft-bhat-vcarddav-json), so we could potentially use=20 > those (which seems preferable to defining yet another one-off data=20 > model with both JSON and XML representations). > Ideally, I think we'd settle on just one mandatory-to-implement=20 > representation of whatever data model we choose. My recollection is that the wg in Vancouver expressed a pretty clear consen= sus that it wanted to deprecate the XML representation in favor of JSON. Th= is will obviously need to be confirmed on the list but it probably means th= at if vCard is to be considered that JSON version is going to be important. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj =3DNiog -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Aug 29 07:44:38 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3F21F84AE for ; Wed, 29 Aug 2012 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.707 X-Spam-Level: X-Spam-Status: No, score=-3.707 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF6jams+TxNo for ; Wed, 29 Aug 2012 07:44:38 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD5221F84F9 for ; Wed, 29 Aug 2012 07:44:37 -0700 (PDT) Received: from mail52-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:44:36 +0000 Received: from mail52-db3 (localhost [127.0.0.1]) by mail52-db3-R.bigfish.com (Postfix) with ESMTP id 3A605C013C; Wed, 29 Aug 2012 14:44:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: PS-37(zzbb2dI98dI154cP9371I542M1432Izz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail52-db3: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail52-db3 (localhost.localdomain [127.0.0.1]) by mail52-db3 (MessageSwitch) id 1346251473686183_31477; Wed, 29 Aug 2012 14:44:33 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.234]) by mail52-db3.bigfish.com (Postfix) with ESMTP id 9A89C20004F; Wed, 29 Aug 2012 14:44:33 +0000 (UTC) Received: from CH1PRD0410HT002.namprd04.prod.outlook.com (157.56.244.181) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:44:30 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT002.namprd04.prod.outlook.com ([10.255.147.37]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 14:44:30 +0000 From: Kelly Grizzle To: Anthony Nadalin , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxPp+upQZsY0WMNXUF2RsSi5dv9G8AgAAJLwCAAGI6AIAAfraAgAAAntA= Date: Wed, 29 Aug 2012 14:44:29 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330DD162@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:44:38 -0000 +1 -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Ant= hony Nadalin Sent: Wednesday, August 29, 2012 9:42 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format I'm in favor of only a JSON representation -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 12:09 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: > On 8/28/12 6:44 PM, Trey Drake wrote: >> Peter, >=20 >> Would this be in addition to or in lieu of the JSON and XML formats? >=20 > Trey, that is a good question. There's an XML representation for > vCard4 (RFC 6351) and I've contributed to a document defining a JSON=20 > representation (draft-bhat-vcarddav-json), so we could potentially use=20 > those (which seems preferable to defining yet another one-off data=20 > model with both JSON and XML representations). > Ideally, I think we'd settle on just one mandatory-to-implement=20 > representation of whatever data model we choose. My recollection is that the wg in Vancouver expressed a pretty clear consen= sus that it wanted to deprecate the XML representation in favor of JSON. Th= is will obviously need to be confirmed on the list but it probably means th= at if vCard is to be considered that JSON version is going to be important. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj =3DNiog -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Wed Aug 29 07:45:19 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AB821F8505 for ; Wed, 29 Aug 2012 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMqu8f6wwZcS for ; Wed, 29 Aug 2012 07:45:18 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 408B221F84F9 for ; Wed, 29 Aug 2012 07:45:18 -0700 (PDT) Received: from mail89-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:45:16 +0000 Received: from mail89-co1 (localhost [127.0.0.1]) by mail89-co1-R.bigfish.com (Postfix) with ESMTP id C0ED768018B for ; Wed, 29 Aug 2012 14:45:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: VS-34(zzbb2dI98dI154cP9371I542M1432Izz1202h1082kzz8275ch1033IL8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail89-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail89-co1 (localhost.localdomain [127.0.0.1]) by mail89-co1 (MessageSwitch) id 1346251515265844_19011; Wed, 29 Aug 2012 14:45:15 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.234]) by mail89-co1.bigfish.com (Postfix) with ESMTP id 3DAA12C006E for ; Wed, 29 Aug 2012 14:45:15 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:45:14 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 29 Aug 2012 14:45:05 +0000 Received: from mail65-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:45:03 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id C1A301C00D1 for ; Wed, 29 Aug 2012 14:45:03 +0000 (UTC) Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1346251501875078_15802; Wed, 29 Aug 2012 14:45:01 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.225]) by mail65-am1.bigfish.com (Postfix) with ESMTP id D3490100230; Wed, 29 Aug 2012 14:45:01 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:45:00 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.235]) by BL2PRD0310HT005.namprd03.prod.outlook.com ([10.255.97.40]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 14:45:00 +0000 From: Anthony Nadalin To: Samuel Erdtman , Leif Johansson Thread-Topic: [scim] data format Thread-Index: AQHNhTB9l1Lv55pR3k62fypdT/wSB5dv9G8AgAAJLwCAAGI6AIAAKq8AgABUhhA= Date: Wed, 29 Aug 2012 14:44:59 +0000 Message-ID: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ERDTMAN.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC106.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC106.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Cc: "scim@ietf.org" Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:45:19 -0000 Not sure I quite understand the issue, I thought the issue would be more ar= ound the wire format and API then the attributes -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sam= uel Erdtman Sent: Wednesday, August 29, 2012 2:41 AM To: Leif Johansson Cc: scim@ietf.org Subject: Re: [scim] data format Should we also look att aligning attributes to Windows Azure Active Directo= ry Graph, or is that a completely different discussion? regards //Samuel On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: >> On 8/28/12 6:44 PM, Trey Drake wrote: >>> Peter, >> >>> Would this be in addition to or in lieu of the JSON and XML formats? >> >> Trey, that is a good question. There's an XML representation for >> vCard4 (RFC 6351) and I've contributed to a document defining a JSON=20 >> representation (draft-bhat-vcarddav-json), so we could potentially=20 >> use those (which seems preferable to defining yet another one-off=20 >> data model with both JSON and XML representations). >> Ideally, I think we'd settle on just one mandatory-to-implement=20 >> representation of whatever data model we choose. > > My recollection is that the wg in Vancouver expressed a pretty clear=20 > consensus that it wanted to deprecate the XML representation in favor=20 > of JSON. This will obviously need to be confirmed on the list but it=20 > probably means that if vCard is to be considered that JSON version is=20 > going to be important. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 > Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj > =3DNiog > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From leifj@mnt.se Wed Aug 29 07:51:56 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8209E21F8557 for ; Wed, 29 Aug 2012 07:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.028 X-Spam-Level: X-Spam-Status: No, score=-3.028 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkLxQbcENKOi for ; Wed, 29 Aug 2012 07:51:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id CC88521F867A for ; Wed, 29 Aug 2012 07:51:54 -0700 (PDT) Received: from [192.36.125.241] (dhcp.pilsnet.sunet.se [192.36.125.241] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7TEpiJ1018046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 16:51:47 +0200 (CEST) Message-ID: <503E2C80.1020502@mnt.se> Date: Wed, 29 Aug 2012 16:51:44 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: scim@ietf.org References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:51:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =c//K -----END PGP SIGNATURE----- From kelly.grizzle@sailpoint.com Wed Aug 29 07:58:09 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A5521F853A for ; Wed, 29 Aug 2012 07:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.191 X-Spam-Level: X-Spam-Status: No, score=-5.191 tagged_above=-999 required=5 tests=[AWL=1.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPoArHCR3rKU for ; Wed, 29 Aug 2012 07:58:08 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9941221F84FD for ; Wed, 29 Aug 2012 07:58:08 -0700 (PDT) Received: from mail184-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 14:58:07 +0000 Received: from mail184-va3 (localhost [127.0.0.1]) by mail184-va3-R.bigfish.com (Postfix) with ESMTP id 4F27EE00A8; Wed, 29 Aug 2012 14:58:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: PS-36(zzbb2dI98dI154cP9371I542Mzz1202hzz8275ch1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h) Received-SPF: pass (mail184-va3: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail184-va3 (localhost.localdomain [127.0.0.1]) by mail184-va3 (MessageSwitch) id 1346252284779378_7004; Wed, 29 Aug 2012 14:58:04 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.247]) by mail184-va3.bigfish.com (Postfix) with ESMTP id BA51B8007A; Wed, 29 Aug 2012 14:58:04 +0000 (UTC) Received: from CH1PRD0410HT002.namprd04.prod.outlook.com (157.56.244.181) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 14:58:00 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT002.namprd04.prod.outlook.com ([10.255.147.37]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 14:58:00 +0000 From: Kelly Grizzle To: Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxPp+upQZsY0WMNXUF2RsSi5dv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkA Date: Wed, 29 Aug 2012 14:58:00 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> In-Reply-To: <503E2C80.1020502@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:58:09 -0000 Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From trey.drake@unboundid.com Wed Aug 29 08:01:52 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30CD21F8679 for ; Wed, 29 Aug 2012 08:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+OdraQYvgIU for ; Wed, 29 Aug 2012 08:01:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0BAE21F8627 for ; Wed, 29 Aug 2012 08:01:51 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1383002obb.31 for ; Wed, 29 Aug 2012 08:01:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=jmn2CXujcgk4S57d0AnugfBjPs0UuljlihiMeKeTSzQ=; b=LJ8Q+sUEabtuiyqAWy0WNwsZP3XfILhDq1g/nePpG6q46cEy4HY2SRt0POP2RWf3+U 5z45HLmKHnFSQgKKsiypkBezHNlXz2b/0PB/P3YCyZpbNv0tEj0FhmHt7rLZQS7SoH0d 16I5nFZYbYLYt9sORLF9XFOUsPQ2yA5QclzhIMU5IwMW6q9OqQ6GF9r4QbNhhQaqmKVz cWlHf/gdrpA4nPsYiHFjx236EHSErb3LEBd3K/HnmK0WqtwPwQNw8A8+CzkWi0zmhUdJ y/R0qf6ZJeeWBrOpTCq613fOrT39h6eeHNu94WrSRPYvAmMi6ArVmJYrofFbKKuEv5yk wUxQ== Received: by 10.60.10.225 with SMTP id l1mr673494oeb.28.1346252511490; Wed, 29 Aug 2012 08:01:51 -0700 (PDT) Received: from office-dhcp-188.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id cp8sm22643255obc.23.2012.08.29.08.01.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 08:01:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: Date: Wed, 29 Aug 2012 10:01:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D5C0054-D226-4D36-9DC5-9C258F49398B@unboundid.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> To: Anthony Nadalin X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQkDcW2GYicvOhEbe4o605T+az0cpB3iJzcGRknZPD6qY80w1+K71OigrkCynPHL9FgSu6Se Cc: Samuel Erdtman , "scim@ietf.org" , Leif Johansson Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:01:52 -0000 A discussion on both makes sense though they should be handled = separately. The information model and supported data models ought to be = orthogonal to specification of a common set of resources and attributes. = With regards to supported representations I'd be in favor of ditching = XML in all forms. On Aug 29, 2012, at 9:44 AM, Anthony Nadalin = wrote: > Not sure I quite understand the issue, I thought the issue would be = more around the wire format and API then the attributes >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Samuel Erdtman > Sent: Wednesday, August 29, 2012 2:41 AM > To: Leif Johansson > Cc: scim@ietf.org > Subject: Re: [scim] data format >=20 > Should we also look att aligning attributes to Windows Azure Active = Directory Graph, or is that a completely different discussion? >=20 > regards > //Samuel >=20 >=20 > On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: >>> On 8/28/12 6:44 PM, Trey Drake wrote: >>>> Peter, >>>=20 >>>> Would this be in addition to or in lieu of the JSON and XML = formats? >>>=20 >>> Trey, that is a good question. There's an XML representation for >>> vCard4 (RFC 6351) and I've contributed to a document defining a JSON=20= >>> representation (draft-bhat-vcarddav-json), so we could potentially=20= >>> use those (which seems preferable to defining yet another one-off=20 >>> data model with both JSON and XML representations). >>> Ideally, I think we'd settle on just one mandatory-to-implement=20 >>> representation of whatever data model we choose. >>=20 >> My recollection is that the wg in Vancouver expressed a pretty clear=20= >> consensus that it wanted to deprecate the XML representation in favor=20= >> of JSON. This will obviously need to be confirmed on the list but it=20= >> probably means that if vCard is to be considered that JSON version is=20= >> going to be important. >>=20 >> Cheers Leif >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 >> Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj >> =3DNiog >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From tonynad@microsoft.com Wed Aug 29 08:06:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5276F21F8595 for ; Wed, 29 Aug 2012 08:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.712 X-Spam-Level: X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvCihM-EX5h2 for ; Wed, 29 Aug 2012 08:06:09 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8F221F855E for ; Wed, 29 Aug 2012 08:06:09 -0700 (PDT) Received: from mail94-co1-R.bigfish.com (10.243.78.251) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 15:06:08 +0000 Received: from mail94-co1 (localhost [127.0.0.1]) by mail94-co1-R.bigfish.com (Postfix) with ESMTP id B63C1B401CE for ; Wed, 29 Aug 2012 15:06:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VS-33(zzbb2dI98dI154cP9371I542Mzz1202h1082kzz8275ch1033IL8275dhz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail94-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail94-co1 (localhost.localdomain [127.0.0.1]) by mail94-co1 (MessageSwitch) id 1346252765921730_15183; Wed, 29 Aug 2012 15:06:05 +0000 (UTC) Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.237]) by mail94-co1.bigfish.com (Postfix) with ESMTP id CD1A1D00045 for ; Wed, 29 Aug 2012 15:06:05 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 15:06:02 +0000 Received: from db3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 29 Aug 2012 15:05:49 +0000 Received: from mail8-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE009.bigfish.com (10.3.84.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 15:04:15 +0000 Received: from mail8-db3 (localhost [127.0.0.1]) by mail8-db3-R.bigfish.com (Postfix) with ESMTP id 8C3822E00A7 for ; Wed, 29 Aug 2012 15:04:15 +0000 (UTC) Received: from mail8-db3 (localhost.localdomain [127.0.0.1]) by mail8-db3 (MessageSwitch) id 1346252652548515_14109; Wed, 29 Aug 2012 15:04:12 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.247]) by mail8-db3.bigfish.com (Postfix) with ESMTP id 7A2A02200A4; Wed, 29 Aug 2012 15:04:12 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 15:04:11 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.235]) by BL2PRD0310HT001.namprd03.prod.outlook.com ([10.255.97.36]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 15:04:08 +0000 From: Anthony Nadalin To: Kelly Grizzle , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTB9l1Lv55pR3k62fypdT/wSB5dv9G8AgAAJLwCAAGI6AIAAKq8AgABUhhCAAAIuAIAAAcEAgAABK8A= Date: Wed, 29 Aug 2012 15:04:07 +0000 Message-ID: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:06:10 -0000 You will have to define "data model" to be sure we all understand as in the= first sentence both schema and data model are used -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 7:58 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From edreux@cloudiway.com Wed Aug 29 08:30:12 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C714921F86D6 for ; Wed, 29 Aug 2012 08:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.107 X-Spam-Level: X-Spam-Status: No, score=-4.107 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH8lsNNS7l0e for ; Wed, 29 Aug 2012 08:30:12 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 81DF621F86D1 for ; Wed, 29 Aug 2012 08:30:11 -0700 (PDT) Received: from mail12-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 15:30:10 +0000 Received: from mail12-db3 (localhost [127.0.0.1]) by mail12-db3-R.bigfish.com (Postfix) with ESMTP id E43A41600EE; Wed, 29 Aug 2012 15:30:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.248.213; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0610HT004.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -87 X-BigFish: PS-87(zzbb2dI98dI154cP9371Ic89bh542M1432I15caKJzz1202hzz8275ch1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah1155h) Received-SPF: pass (mail12-db3: domain of cloudiway.com designates 157.56.248.213 as permitted sender) client-ip=157.56.248.213; envelope-from=edreux@cloudiway.com; helo=AMXPRD0610HT004.eurprd06.prod.outlook.com ; .outlook.com ; Received: from mail12-db3 (localhost.localdomain [127.0.0.1]) by mail12-db3 (MessageSwitch) id 1346254207139536_29373; Wed, 29 Aug 2012 15:30:07 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.228]) by mail12-db3.bigfish.com (Postfix) with ESMTP id 10A284000AE; Wed, 29 Aug 2012 15:30:07 +0000 (UTC) Received: from AMXPRD0610HT004.eurprd06.prod.outlook.com (157.56.248.213) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 15:30:05 +0000 Received: from AMXPRD0610MB353.eurprd06.prod.outlook.com ([169.254.2.58]) by AMXPRD0610HT004.eurprd06.prod.outlook.com ([10.255.58.39]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 15:30:03 +0000 From: Emmanuel Dreux To: Anthony Nadalin , Samuel Erdtman , Leif Johansson Thread-Topic: [scim] data format Thread-Index: AQHNhfXklAbiunLGqUyoQ+ZQN5g+c5dw481g Date: Wed, 29 Aug 2012 15:30:02 +0000 Message-ID: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.14.240.38] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cloudiway.com Cc: "scim@ietf.org" Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:30:13 -0000 We've tested the Azure Active Directory Graph. It's also restful apis excha= nging JSON data. The schema used by Active Directory Graph uses the standard LDAP attributes= names (GivenName, Surname, UserPrincipalName, etc...).=20 Schemas are therefore incompatible but it's not complex for implementations= to develop a "bridge" that convert one format into the other. I feel that it does not need to be defined in the specs. It's just a matter= of creating an extended user schema that uses LDAP attributes names instea= d of the SCIM attributes names. -- Regards, Emmanuel Dreux http://www.cloudiway.com Tel: +33 4 26 78 17 58 Mobile: +33 6 47 81 26 70 skype: Emmanuel.Dreux -----Message d'origine----- De=A0: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 Envoy=E9=A0: mercredi 29 ao=FBt 2012 16:45 =C0=A0: Samuel Erdtman; Leif Johansson Cc=A0: scim@ietf.org Objet=A0: Re: [scim] data format Not sure I quite understand the issue, I thought the issue would be more ar= ound the wire format and API then the attributes -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Sam= uel Erdtman Sent: Wednesday, August 29, 2012 2:41 AM To: Leif Johansson Cc: scim@ietf.org Subject: Re: [scim] data format Should we also look att aligning attributes to Windows Azure Active Directo= ry Graph, or is that a completely different discussion? regards //Samuel On Wed, Aug 29, 2012 at 9:08 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/29/2012 03:17 AM, Peter Saint-Andre wrote: >> On 8/28/12 6:44 PM, Trey Drake wrote: >>> Peter, >> >>> Would this be in addition to or in lieu of the JSON and XML formats? >> >> Trey, that is a good question. There's an XML representation for >> vCard4 (RFC 6351) and I've contributed to a document defining a JSON=20 >> representation (draft-bhat-vcarddav-json), so we could potentially=20 >> use those (which seems preferable to defining yet another one-off=20 >> data model with both JSON and XML representations). >> Ideally, I think we'd settle on just one mandatory-to-implement=20 >> representation of whatever data model we choose. > > My recollection is that the wg in Vancouver expressed a pretty clear=20 > consensus that it wanted to deprecate the XML representation in favor=20 > of JSON. This will obviously need to be confirmed on the list but it=20 > probably means that if vCard is to be considered that JSON version is=20 > going to be important. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlA9v/YACgkQ8Jx8FtbMZnfcTACfRDTzx7cS742H3wIrPeAXYzD0 > Gv8An2AIGV4JsB+gBRZgKxkIU6ZTrMLj > =3DNiog > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Aug 29 09:32:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1684021F84D7 for ; Wed, 29 Aug 2012 09:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NTJx6VJ4knK for ; Wed, 29 Aug 2012 09:32:45 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id E23DA21F84CD for ; Wed, 29 Aug 2012 09:32:44 -0700 (PDT) Received: from mail111-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 16:32:43 +0000 Received: from mail111-am1 (localhost [127.0.0.1]) by mail111-am1-R.bigfish.com (Postfix) with ESMTP id 9A8D9340085; Wed, 29 Aug 2012 16:32:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT004.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -42 X-BigFish: PS-42(zzbb2dI98dI154cP9371I542M1418Izz1202hzz8275ch1033IL8275bh8275dh186Mz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail111-am1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT004.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail111-am1 (localhost.localdomain [127.0.0.1]) by mail111-am1 (MessageSwitch) id 1346257961165771_32580; Wed, 29 Aug 2012 16:32:41 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.242]) by mail111-am1.bigfish.com (Postfix) with ESMTP id 1BBE7E0048; Wed, 29 Aug 2012 16:32:41 +0000 (UTC) Received: from CH1PRD0410HT004.namprd04.prod.outlook.com (157.56.244.181) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 16:32:39 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT004.namprd04.prod.outlook.com ([10.255.147.39]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 16:32:37 +0000 From: Kelly Grizzle To: Anthony Nadalin , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxPp+upQZsY0WMNXUF2RsSi5dv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkAgAACXYCAABDeYA== Date: Wed, 29 Aug 2012 16:32:37 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:32:46 -0000 By "data model" I really meant schema (ie - a set of attribute definitions = that defines an object). My point was that (from an interoperability persp= ective) using a common set of attributes is just as important as getting th= e wire protocol and API right. Peter asked: "Can we use one of the standardized data models (such as iNetO= rgPerson or vCard4, perhaps with extensions as needed)?" I think that Samu= el's suggestion (if I understood it correctly) was to consider the data mod= els that WAAD Graph API uses for User[1] and Group[2] along with the two th= at Peter mentioned. --Kelly [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 -----Original Message----- From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 Sent: Wednesday, August 29, 2012 10:04 AM To: Kelly Grizzle; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format You will have to define "data model" to be sure we all understand as in the= first sentence both schema and data model are used -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 7:58 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From prvs=058862F6F5=erik.wahlstrom@nexussafe.com Wed Aug 29 09:43:28 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AEC21F867E for ; Wed, 29 Aug 2012 09:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HKCBwerCclG for ; Wed, 29 Aug 2012 09:43:28 -0700 (PDT) Received: from MailEdge.nexussafe.com (mailedge.nexussafe.com [83.241.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 7764B21F867D for ; Wed, 29 Aug 2012 09:43:26 -0700 (PDT) Received: from MARVMAILCAS.technxs.com (10.75.28.35) by MailEdge.nexussafe.com (83.241.133.98) with Microsoft SMTP Server (TLS) id 14.1.379.0; Wed, 29 Aug 2012 18:43:21 +0200 Received: from MARVMAILDB.technxs.com ([fe80::b01b:248c:aaec:bf11]) by MarvMailCAS.technxs.com ([::1]) with mapi id 14.01.0355.002; Wed, 29 Aug 2012 18:43:06 +0200 From: =?iso-8859-1?Q?Erik_Wahlstr=F6m?= To: Kelly Grizzle Thread-Topic: [scim] data format Thread-Index: AQHNhTBsEA0kjbqTDkCx51YqB03niZdv0ugAgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAAcEAgAABtYCAABi6gIAAAuGA Date: Wed, 29 Aug 2012 16:43:02 +0000 Message-ID: <5AFB8F1A-E8CA-4EAD-8FD9-FC0BE293B318@nexussafe.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.28.12] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <75196EC2D49ED2488D4B3FA98D212D12@nexussafe.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Anthony Nadalin , "scim@ietf.org" , Leif Johansson Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:43:28 -0000 Yes, and what ever we consider. Lets just do one, to ease interops. And I'm= all for making it a JSON only one :) / Erik On Aug 29, 2012, at 6:32 PM, Kelly Grizzle wrote: > By "data model" I really meant schema (ie - a set of attribute definition= s that defines an object). My point was that (from an interoperability per= spective) using a common set of attributes is just as important as getting = the wire protocol and API right. >=20 > Peter asked: "Can we use one of the standardized data models (such as iNe= tOrgPerson or vCard4, perhaps with extensions as needed)?" I think that Sa= muel's suggestion (if I understood it correctly) was to consider the data m= odels that WAAD Graph API uses for User[1] and Group[2] along with the two = that Peter mentioned. >=20 > --Kelly >=20 > [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 > [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 >=20 >=20 > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Wednesday, August 29, 2012 10:04 AM > To: Kelly Grizzle; Leif Johansson; scim@ietf.org > Subject: RE: [scim] data format >=20 > You will have to define "data model" to be sure we all understand as in t= he first sentence both schema and data model are used >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of K= elly Grizzle > Sent: Wednesday, August 29, 2012 7:58 AM > To: Leif Johansson; scim@ietf.org > Subject: Re: [scim] data format >=20 > Yes - both the attributes and the wire format are important, which is why= the core schema draft provides data models for user, group, and enterprise= group. >=20 > To achieve some level of interoperability it is important to have a commo= n data model. This is one of the things that prevented adoption of SPML. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of L= eif Johansson > Sent: Wednesday, August 29, 2012 9:52 AM > To: scim@ietf.org > Subject: Re: [scim] data format >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >> Not sure I quite understand the issue, I thought the issue would be=20 >> more around the wire format and API then the attributes >=20 > I would have thought both... >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu > s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk > =3Dc//K > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Aug 29 09:51:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B021F86C9 for ; Wed, 29 Aug 2012 09:51:54 -0700 (PDT) X-Quarantine-ID: <0FboaLX0aymP> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): References: ...9@BL2PRD0310MB362.namprd03.prod.outlook.com>\n X-Spam-Flag: NO X-Spam-Score: -3.837 X-Spam-Level: X-Spam-Status: No, score=-3.837 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FboaLX0aymP for ; Wed, 29 Aug 2012 09:51:53 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5968921F86C7 for ; Wed, 29 Aug 2012 09:51:53 -0700 (PDT) Received: from mail191-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 16:51:52 +0000 Received: from mail191-co1 (localhost [127.0.0.1]) by mail191-co1-R.bigfish.com (Postfix) with ESMTP id DEC03B80126; Wed, 29 Aug 2012 16:51:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT002.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -42 X-BigFish: PS-42(zzbb2dI98dI154cP9371I542M1418Izz1202hzz8275ch1033IL8275bh8275dh186Mz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail191-co1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT002.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail191-co1 (localhost.localdomain [127.0.0.1]) by mail191-co1 (MessageSwitch) id 1346259111130029_10255; Wed, 29 Aug 2012 16:51:51 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.250]) by mail191-co1.bigfish.com (Postfix) with ESMTP id 1B14980045; Wed, 29 Aug 2012 16:51:51 +0000 (UTC) Received: from CH1PRD0410HT002.namprd04.prod.outlook.com (157.56.244.181) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 16:51:50 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT002.namprd04.prod.outlook.com ([10.255.147.37]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 16:51:50 +0000 From: Kelly Grizzle To: Anthony Nadalin , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxPp+upQZsY0WMNXUF2RsSi5dv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkAgAACXYCAABDeYIAAC9uQ Date: Wed, 29 Aug 2012 16:51:49 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330DE6A6@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:51:54 -0000 > Can we use one of the standardized data models (such as iNetOrgPerson or = vCard4, perhaps with extensions as needed)? BTW - my answer for this question is that I am all for consistency and avoi= ding reinventing the wheel. IMO we should look at inetOrgPerson, vCard4, G= raph API users and groups, and any other existing "identity data model" and= weigh their merits and short-comings against the current SCIM proposal. --Kelly -----Original Message----- From: Kelly Grizzle=20 Sent: Wednesday, August 29, 2012 11:33 AM To: 'Anthony Nadalin'; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format By "data model" I really meant schema (ie - a set of attribute definitions = that defines an object). My point was that (from an interoperability persp= ective) using a common set of attributes is just as important as getting th= e wire protocol and API right. Peter asked: "Can we use one of the standardized data models (such as iNetO= rgPerson or vCard4, perhaps with extensions as needed)?" I think that Samu= el's suggestion (if I understood it correctly) was to consider the data mod= els that WAAD Graph API uses for User[1] and Group[2] along with the two th= at Peter mentioned. --Kelly [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 -----Original Message----- From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Wednesday, August 29, 2012 10:04 AM To: Kelly Grizzle; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format You will have to define "data model" to be sure we all understand as in the= first sentence both schema and data model are used -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 7:58 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From igor.faynberg@alcatel-lucent.com Wed Aug 29 10:51:04 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D521F86D5 for ; Wed, 29 Aug 2012 10:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.617 X-Spam-Level: X-Spam-Status: No, score=-9.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRfX0tcuIeAl for ; Wed, 29 Aug 2012 10:51:03 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 353E821F86D4 for ; Wed, 29 Aug 2012 10:51:03 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q7THp2uE021157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 29 Aug 2012 12:51:02 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q7THp1Nu021046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Aug 2012 12:51:02 -0500 Received: from [135.244.2.36] (faynberg.lra.lucent.com [135.244.2.36]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q7THp0pE022369; Wed, 29 Aug 2012 12:51:01 -0500 (CDT) Message-ID: <503E5684.9050002@alcatel-lucent.com> Date: Wed, 29 Aug 2012 13:51:00 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: scim@ietf.org References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> <5AFB8F1A-E8CA-4EAD-8FD9-FC0BE293B318@nexussafe.com> In-Reply-To: <5AFB8F1A-E8CA-4EAD-8FD9-FC0BE293B318@nexussafe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:51:04 -0000 +1 Igor On 8/29/2012 12:43 PM, Erik Wahlström wrote: > Yes, and what ever we consider. Lets just do one, to ease interops. And I'm all for making it a JSON only one :) > / Erik > > On Aug 29, 2012, at 6:32 PM, Kelly Grizzle wrote: > >> By "data model" I really meant schema (ie - a set of attribute definitions that defines an object). My point was that (from an interoperability perspective) using a common set of attributes is just as important as getting the wire protocol and API right. >> >> Peter asked: "Can we use one of the standardized data models (such as iNetOrgPerson or vCard4, perhaps with extensions as needed)?" I think that Samuel's suggestion (if I understood it correctly) was to consider the data models that WAAD Graph API uses for User[1] and Group[2] along with the two that Peter mentioned. >> >> --Kelly >> >> [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 >> [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 >> >> >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Wednesday, August 29, 2012 10:04 AM >> To: Kelly Grizzle; Leif Johansson; scim@ietf.org >> Subject: RE: [scim] data format >> >> You will have to define "data model" to be sure we all understand as in the first sentence both schema and data model are used >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kelly Grizzle >> Sent: Wednesday, August 29, 2012 7:58 AM >> To: Leif Johansson; scim@ietf.org >> Subject: Re: [scim] data format >> >> Yes - both the attributes and the wire format are important, which is why the core schema draft provides data models for user, group, and enterprise group. >> >> To achieve some level of interoperability it is important to have a common data model. This is one of the things that prevented adoption of SPML. >> >> --Kelly >> >> >> -----Original Message----- >> From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Leif Johansson >> Sent: Wednesday, August 29, 2012 9:52 AM >> To: scim@ietf.org >> Subject: Re: [scim] data format >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >>> Not sure I quite understand the issue, I thought the issue would be >>> more around the wire format and API then the attributes >> I would have thought both... >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >> >> iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu >> s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk >> =c//K >> -----END PGP SIGNATURE----- >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >> >> >> >> >> >> >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From Chris.Phillips@canarie.ca Wed Aug 29 11:44:05 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAB121F8621 for ; Wed, 29 Aug 2012 11:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D61fp3Hk0VpV for ; Wed, 29 Aug 2012 11:44:04 -0700 (PDT) Received: from mail.canarie.ca (mail.canarie.ca [205.189.33.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6770221F8616 for ; Wed, 29 Aug 2012 11:44:04 -0700 (PDT) Received: from RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d]) by RANCOR.canarie.local ([fe80::5c7e:71ff:1ed0:916d%10]) with mapi; Wed, 29 Aug 2012 14:44:03 -0400 From: Chris Phillips To: "scim@ietf.org" Date: Wed, 29 Aug 2012 14:44:01 -0400 Thread-Topic: [scim] data format Thread-Index: Ac2GFkIsFHVu0gtXTVGiDGtFUzErMw== Message-ID: In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330DE6A6@CH1PRD0410MB357.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:44:05 -0000 +1 to Kelly's comments. A bit of background from previous SCIM schema work by the SCIM group: A mapping process around SCIM schema happened a few months ago[1] with a few others. The exercise was comparing the SCIM schema to other ones with discussion revolving around what to do about the higher fidelity of SCIM compared to others. The approach was to do a hybrid approach and have a high fidelity SCIM schema(ie. SCIM-to-SCIM transactions) and separate mappings documented recommending specifics on what to map to other schemas and have those published as best practices in the SCIM sphere of control. =20 Given the mention of the other schemas, extending the columns in the mapping[2] to include Graph API and vCard4 are just a function of time and effort. The reality will be that the first person to map a new schema to SCIM will set the precedent on the mappings, right or wrong, and is that acceptable to the spec? =20 Will the spec have in scope common mappings to increase the utility of the spec? Is this in scope of the WG? With these questions and others in mind, I think it would be useful to talk about schema principles first and THEN specifics about a given schema with these principles in mind. Mindful of course of what is in and out of scope for SCIM given the slippery slope of sliding into identity management practice discussions when we are really talking about a spec to move identity related data around. >From my perspective, all schemas will have pros and cons (and advocates) and no one schema will map 100%, so the mapping exercise is practically inescapable. I would err on the side of leadership on a common set of mappings that would grow (and age) and would like to hear other opinions. As a parting thought about the attribute registry[3] and schemas, certainly the pedigree of an attribute and what schema(s) it appears in are valuable to track and so would it not in turn be a schema registry? Is this a better context/home for the schema conversation? Chris. [1] https://groups.google.com/group/cloud-directory/msg/e887d8842a1879d1 [2] http://bit.ly/scimmappings [3] http://tools.ietf.org/id/draft-johansson-areg-reqs-00.html On 12-08-29 12:51 PM, "Kelly Grizzle" wrote: >> Can we use one of the standardized data models (such as iNetOrgPerson >>or vCard4, perhaps with extensions as needed)? > >BTW - my answer for this question is that I am all for consistency and >avoiding reinventing the wheel. IMO we should look at inetOrgPerson, >vCard4, Graph API users and groups, and any other existing "identity data >model" and weigh their merits and short-comings against the current SCIM >proposal. > >--Kelly > >-----Original Message----- >From: Kelly Grizzle >Sent: Wednesday, August 29, 2012 11:33 AM >To: 'Anthony Nadalin'; Leif Johansson; scim@ietf.org >Subject: RE: [scim] data format > >By "data model" I really meant schema (ie - a set of attribute >definitions that defines an object). My point was that (from an >interoperability perspective) using a common set of attributes is just as >important as getting the wire protocol and API right. > >Peter asked: "Can we use one of the standardized data models (such as >iNetOrgPerson or vCard4, perhaps with extensions as needed)?" I think >that Samuel's suggestion (if I understood it correctly) was to consider >the data models that WAAD Graph API uses for User[1] and Group[2] along >with the two that Peter mentioned. > >--Kelly > >[1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 >[2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 > > >-----Original Message----- >From: Anthony Nadalin [mailto:tonynad@microsoft.com] >Sent: Wednesday, August 29, 2012 10:04 AM >To: Kelly Grizzle; Leif Johansson; scim@ietf.org >Subject: RE: [scim] data format > >You will have to define "data model" to be sure we all understand as in >the first sentence both schema and data model are used > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Kelly Grizzle >Sent: Wednesday, August 29, 2012 7:58 AM >To: Leif Johansson; scim@ietf.org >Subject: Re: [scim] data format > >Yes - both the attributes and the wire format are important, which is why >the core schema draft provides data models for user, group, and >enterprise group. > >To achieve some level of interoperability it is important to have a >common data model. This is one of the things that prevented adoption of >SPML. > >--Kelly > > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Leif Johansson >Sent: Wednesday, August 29, 2012 9:52 AM >To: scim@ietf.org >Subject: Re: [scim] data format > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >> Not sure I quite understand the issue, I thought the issue would be >> more around the wire format and API then the attributes > >I would have thought both... > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > >iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu >s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk >=3Dc//K >-----END PGP SIGNATURE----- >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim > > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim > > > > > > > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From michael.hammer@yaanatech.com Wed Aug 29 12:04:10 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE0E21F8555 for ; Wed, 29 Aug 2012 12:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvUemGvkIYU4 for ; Wed, 29 Aug 2012 12:04:09 -0700 (PDT) Received: from email1.corp.yaanatech.com (email1.corp.yaanatech.com [205.140.198.134]) by ietfa.amsl.com (Postfix) with ESMTP id 5404F21F84C2 for ; Wed, 29 Aug 2012 12:04:09 -0700 (PDT) Received: from EX2K10MB2.corp.yaanatech.com ([fe80::5d11:66a1:e508:6871]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 29 Aug 2012 12:04:08 -0700 From: Michael Hammer To: "Chris.Phillips@canarie.ca" , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxA1kghOaEhE+GuBiWcBf2Y5dv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkAgAACXYCAABDeYIAAC9uQgACWEID//48C0A== Date: Wed, 29 Aug 2012 19:04:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB31336FCC8@ex2k10mb2.corp.yaanatech.com> References: <56C3C758F9D6534CA3778EAA1E0C3437330DE6A6@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.88.5] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01CD85F7.88BBFC90" MIME-Version: 1.0 Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:04:10 -0000 ------=_NextPart_000_0048_01CD85F7.88BBFC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Chris, It might be useful to setup a means by which the elements of different sources can be compared side by side. Then let those who care about a particular mapping fill in the blanks. If all the others have something that SCIM doesn't, that's a clue. If all the others don't have something that SCIM has, maybe also a clue. Look for what is the center of mass, or what hits the most elements for the buck. When you reach critical mass (diminishing returns), maybe punt to extension objects. Just brainstorming here. Mike -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Chris Phillips Sent: Wednesday, August 29, 2012 2:44 PM To: scim@ietf.org Subject: Re: [scim] data format +1 to Kelly's comments. A bit of background from previous SCIM schema work by the SCIM group: A mapping process around SCIM schema happened a few months ago[1] with a few others. The exercise was comparing the SCIM schema to other ones with discussion revolving around what to do about the higher fidelity of SCIM compared to others. The approach was to do a hybrid approach and have a high fidelity SCIM schema(ie. SCIM-to-SCIM transactions) and separate mappings documented recommending specifics on what to map to other schemas and have those published as best practices in the SCIM sphere of control. Given the mention of the other schemas, extending the columns in the mapping[2] to include Graph API and vCard4 are just a function of time and effort. The reality will be that the first person to map a new schema to SCIM will set the precedent on the mappings, right or wrong, and is that acceptable to the spec? Will the spec have in scope common mappings to increase the utility of the spec? Is this in scope of the WG? With these questions and others in mind, I think it would be useful to talk about schema principles first and THEN specifics about a given schema with these principles in mind. Mindful of course of what is in and out of scope for SCIM given the slippery slope of sliding into identity management practice discussions when we are really talking about a spec to move identity related data around. >From my perspective, all schemas will have pros and cons (and advocates) and no one schema will map 100%, so the mapping exercise is practically inescapable. I would err on the side of leadership on a common set of mappings that would grow (and age) and would like to hear other opinions. As a parting thought about the attribute registry[3] and schemas, certainly the pedigree of an attribute and what schema(s) it appears in are valuable to track and so would it not in turn be a schema registry? Is this a better context/home for the schema conversation? Chris. [1] https://groups.google.com/group/cloud-directory/msg/e887d8842a1879d1 [2] http://bit.ly/scimmappings [3] http://tools.ietf.org/id/draft-johansson-areg-reqs-00.html On 12-08-29 12:51 PM, "Kelly Grizzle" wrote: >> Can we use one of the standardized data models (such as iNetOrgPerson >>or vCard4, perhaps with extensions as needed)? > >BTW - my answer for this question is that I am all for consistency and >avoiding reinventing the wheel. IMO we should look at inetOrgPerson, >vCard4, Graph API users and groups, and any other existing "identity >data model" and weigh their merits and short-comings against the >current SCIM proposal. > >--Kelly > >-----Original Message----- >From: Kelly Grizzle >Sent: Wednesday, August 29, 2012 11:33 AM >To: 'Anthony Nadalin'; Leif Johansson; scim@ietf.org >Subject: RE: [scim] data format > >By "data model" I really meant schema (ie - a set of attribute >definitions that defines an object). My point was that (from an >interoperability perspective) using a common set of attributes is just >as important as getting the wire protocol and API right. > >Peter asked: "Can we use one of the standardized data models (such as >iNetOrgPerson or vCard4, perhaps with extensions as needed)?" I think >that Samuel's suggestion (if I understood it correctly) was to consider >the data models that WAAD Graph API uses for User[1] and Group[2] along >with the two that Peter mentioned. > >--Kelly > >[1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 >[2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 > > >-----Original Message----- >From: Anthony Nadalin [mailto:tonynad@microsoft.com] >Sent: Wednesday, August 29, 2012 10:04 AM >To: Kelly Grizzle; Leif Johansson; scim@ietf.org >Subject: RE: [scim] data format > >You will have to define "data model" to be sure we all understand as in >the first sentence both schema and data model are used > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Kelly Grizzle >Sent: Wednesday, August 29, 2012 7:58 AM >To: Leif Johansson; scim@ietf.org >Subject: Re: [scim] data format > >Yes - both the attributes and the wire format are important, which is >why the core schema draft provides data models for user, group, and >enterprise group. > >To achieve some level of interoperability it is important to have a >common data model. This is one of the things that prevented adoption >of SPML. > >--Kelly > > >-----Original Message----- >From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >Leif Johansson >Sent: Wednesday, August 29, 2012 9:52 AM >To: scim@ietf.org >Subject: Re: [scim] data format > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >> Not sure I quite understand the issue, I thought the issue would be >> more around the wire format and API then the attributes > >I would have thought both... > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.11 (GNU/Linux) >Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > >iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu >s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk >=c//K >-----END PGP SIGNATURE----- >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim > > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim > > > > > > > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim ------=_NextPart_000_0048_01CD85F7.88BBFC90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP6zCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTXMIIDv6ADAgECAhBcX1ns/Jl/DtI19/BXCcuBMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwNDAzMDAwMDAwWhcNMTMwNDAzMjM1OTU5WjCCAR4xFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pY2hhZWwgSGFtbWVy MSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFuYXRlY2guY29tMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDoKTk9rP/4lG6CLqIR4++IFTuOSLF6bmhDr6eiSahqU0VNP+H/LbiD MAZsK9GQoBYPKQdKzy/gM+fl3Gm6VOdjKl8M3GB6LGgAK8d3ETN5dyKe5CAG7EEbKg9wxHWcuXW7 KYd052ven5Ec+Xj++v3HsE423O5q2mNh1Q8FNsnlXQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYD VR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2ln bi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYD VR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20v SW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQA8rhDezFsw7OlR3+mZOZ39 SCKWNJ4gMlQEe31NNtvs6BUzE1uN+fJeZrJ5zjTdJWeG1NgVugcuzQfdv/m5BYbhgJvNfW6ElqZh cye6imOUx8diekkeHXKYSLnEvCdJItXsC1h/huIT9e83WksM92qI/TFyCq6u39cGf9PaBYbcKcZk jHjNi3SPnGifMC6opGiiyK/vB1lituoBRcJ13Y7XoXA8T0kSR8Dtmqvo1JudcFAbS1srytG1QX1H XTsPkTDKHlwv2ZfmCSKK3sWHDrZfpRglxvcX2OwibcKVkKBJRRw36UuJOIj/u0WYABcYtusAb2+0 nqoGmOEYARnrseTZMIIG7jCCBdagAwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUF ADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZv ciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkw NDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP 6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYH r54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50 ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yx BF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ 6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CG SAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYI KwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6Al hiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYI KwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQ UjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1Ud EQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EI Qf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZ gbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v 8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM6 1a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/ XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4 VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggS4MIIEtAIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTsw OQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykw OTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI19/BXCcuBMAkGBSsO AwIaBQCgggMbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDgy OTE5MDQwNlowIwYJKoZIhvcNAQkEMRYEFCUlDLKXj+Zl+XdnGj7n44Zsm2yXMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIIBAwYJKwYB BAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMCEFxfWez8mX8O0jX38FcJy4EwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5W ZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhBcX1ns/Jl/DtI1 9/BXCcuBMA0GCSqGSIb3DQEBAQUABIGA4S53oOgftfVch6g/3N6RU3K95tR1bOvLwuJmr967ovP7 /lbnWQ/X02o3SqzotMPY5fS3eWw4j2CqHx0gb/YcAh62y4X3Rys/+9WIy8xrcaTYgPWLzCIv5uWh NS+QA7Oq2zoffq8eReMW+FjtCZhYWjdR5RocF/XSLewrtHueQLIAAAAAAAA= ------=_NextPart_000_0048_01CD85F7.88BBFC90-- From tonynad@microsoft.com Wed Aug 29 12:36:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18111E80F3 for ; Wed, 29 Aug 2012 12:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C83ZQbuN8R0I for ; Wed, 29 Aug 2012 12:36:35 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id E116A11E80F1 for ; Wed, 29 Aug 2012 12:36:34 -0700 (PDT) Received: from mail98-am1-R.bigfish.com (10.3.201.249) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 19:36:33 +0000 Received: from mail98-am1 (localhost [127.0.0.1]) by mail98-am1-R.bigfish.com (Postfix) with ESMTP id AC82EE0082 for ; Wed, 29 Aug 2012 19:36:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -40 X-BigFish: VS-40(zzbb2dI98dI154cP9371I542M1418I1447Izz1202h1082kzz8275ch1033IL8275bh8275dh186Mz2fh2a8h683h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail98-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=tonynad@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail98-am1 (localhost.localdomain [127.0.0.1]) by mail98-am1 (MessageSwitch) id 1346268987151240_2891; Wed, 29 Aug 2012 19:36:27 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.251]) by mail98-am1.bigfish.com (Postfix) with ESMTP id E7A4880046 for ; Wed, 29 Aug 2012 19:36:26 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 19:36:25 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 29 Aug 2012 19:36:18 +0000 Received: from mail34-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 19:36:17 +0000 Received: from mail34-ch1 (localhost [127.0.0.1]) by mail34-ch1-R.bigfish.com (Postfix) with ESMTP id 31B4E44018E for ; Wed, 29 Aug 2012 19:36:17 +0000 (UTC) Received: from mail34-ch1 (localhost.localdomain [127.0.0.1]) by mail34-ch1 (MessageSwitch) id 1346268974769086_8464; Wed, 29 Aug 2012 19:36:14 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail34-ch1.bigfish.com (Postfix) with ESMTP id AEC2C3A01E1; Wed, 29 Aug 2012 19:36:14 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 19:36:12 +0000 Received: from BL2PRD0310MB362.namprd03.prod.outlook.com ([169.254.12.235]) by BL2PRD0310HT003.namprd03.prod.outlook.com ([10.255.97.38]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 19:36:12 +0000 From: Anthony Nadalin To: Kelly Grizzle , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTB9l1Lv55pR3k62fypdT/wSB5dv9G8AgAAJLwCAAGI6AIAAKq8AgABUhhCAAAIuAIAAAcEAgAABK8CAABlEgIAAMtWw Date: Wed, 29 Aug 2012 19:36:11 +0000 Message-ID: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SAILPOINT.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%MNT.SE$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:36:36 -0000 Thanks for the clarification as I would have taken the data model to be mor= e of what OData offers and how that is exposed in WAAD then the actual attr= ibute definitions -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 9:33 AM To: Anthony Nadalin; Leif Johansson; scim@ietf.org Subject: Re: [scim] data format By "data model" I really meant schema (ie - a set of attribute definitions = that defines an object). My point was that (from an interoperability persp= ective) using a common set of attributes is just as important as getting th= e wire protocol and API right. Peter asked: "Can we use one of the standardized data models (such as iNetO= rgPerson or vCard4, perhaps with extensions as needed)?" I think that Samu= el's suggestion (if I understood it correctly) was to consider the data mod= els that WAAD Graph API uses for User[1] and Group[2] along with the two th= at Peter mentioned. --Kelly [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 -----Original Message----- From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Wednesday, August 29, 2012 10:04 AM To: Kelly Grizzle; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format You will have to define "data model" to be sure we all understand as in the= first sentence both schema and data model are used -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 7:58 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Wed Aug 29 14:14:26 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE321F863F for ; Wed, 29 Aug 2012 14:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.814 X-Spam-Level: X-Spam-Status: No, score=-3.814 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T511Qo6Jd++I for ; Wed, 29 Aug 2012 14:14:25 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8D84F21F8627 for ; Wed, 29 Aug 2012 14:14:24 -0700 (PDT) Received: from mail74-db3-R.bigfish.com (10.3.81.251) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Aug 2012 21:14:23 +0000 Received: from mail74-db3 (localhost [127.0.0.1]) by mail74-db3-R.bigfish.com (Postfix) with ESMTP id 7951B3C022C; Wed, 29 Aug 2012 21:14:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -43 X-BigFish: PS-43(zzbb2dI98dI154cP9371I542M1418I1447Izz1202hzz8275ch1033IL8275bh8275dh186Mz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail74-db3: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail74-db3 (localhost.localdomain [127.0.0.1]) by mail74-db3 (MessageSwitch) id 1346274861888094_14863; Wed, 29 Aug 2012 21:14:21 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.249]) by mail74-db3.bigfish.com (Postfix) with ESMTP id D5CE9260048; Wed, 29 Aug 2012 21:14:21 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Aug 2012 21:14:20 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0190.008; Wed, 29 Aug 2012 21:14:18 +0000 From: Kelly Grizzle To: Anthony Nadalin , Leif Johansson , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBxPp+upQZsY0WMNXUF2RsSi5dv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkAgAACXYCAABDeYIAAOyaAgAAYl/A= Date: Wed, 29 Aug 2012 21:14:18 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330DE8F1@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:14:26 -0000 Sure thing. FWIW, I think that some of the things that are brought into th= e Graph API from OData are very nice and warrant some thought within SCIM. = One that is quite interesting to me is a stronger concept of relationships= as described in section 4.2 Representing a Navigation Property [1]. My in= itial opinion (without having delved too deeply into Graph API or OData) is= that OData seems like a pretty meaty spec and that SCIM should adopt some = of these ideas but try to remain fairly light. --Kelly [1] http://www.odata.org/media/30002/OData%20JSON%20Verbose%20Format.html -----Original Message----- From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 Sent: Wednesday, August 29, 2012 2:36 PM To: Kelly Grizzle; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format Thanks for the clarification as I would have taken the data model to be mor= e of what OData offers and how that is exposed in WAAD then the actual attr= ibute definitions -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 9:33 AM To: Anthony Nadalin; Leif Johansson; scim@ietf.org Subject: Re: [scim] data format By "data model" I really meant schema (ie - a set of attribute definitions = that defines an object). My point was that (from an interoperability persp= ective) using a common set of attributes is just as important as getting th= e wire protocol and API right. Peter asked: "Can we use one of the standardized data models (such as iNetO= rgPerson or vCard4, perhaps with extensions as needed)?" I think that Samu= el's suggestion (if I understood it correctly) was to consider the data mod= els that WAAD Graph API uses for User[1] and Group[2] along with the two th= at Peter mentioned. --Kelly [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 -----Original Message----- From: Anthony Nadalin [mailto:tonynad@microsoft.com] Sent: Wednesday, August 29, 2012 10:04 AM To: Kelly Grizzle; Leif Johansson; scim@ietf.org Subject: RE: [scim] data format You will have to define "data model" to be sure we all understand as in the= first sentence both schema and data model are used -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Kel= ly Grizzle Sent: Wednesday, August 29, 2012 7:58 AM To: Leif Johansson; scim@ietf.org Subject: Re: [scim] data format Yes - both the attributes and the wire format are important, which is why t= he core schema draft provides data models for user, group, and enterprise g= roup. To achieve some level of interoperability it is important to have a common = data model. This is one of the things that prevented adoption of SPML. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Wednesday, August 29, 2012 9:52 AM To: scim@ietf.org Subject: Re: [scim] data format -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/29/2012 04:44 PM, Anthony Nadalin wrote: > Not sure I quite understand the issue, I thought the issue would be=20 > more around the wire format and API then the attributes I would have thought both... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk =3Dc//K -----END PGP SIGNATURE----- _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Aug 29 14:29:36 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C433D11E80A5 for ; Wed, 29 Aug 2012 14:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.302 X-Spam-Level: X-Spam-Status: No, score=-10.302 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl5yWEjXtNyK for ; Wed, 29 Aug 2012 14:29:35 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id D13C511E809C for ; Wed, 29 Aug 2012 14:29:35 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7TLTY9T007923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Aug 2012 21:29:35 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7TLTY84002808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 29 Aug 2012 21:29:34 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7TLTYxk017692 for ; Wed, 29 Aug 2012 16:29:34 -0500 Received: from [10.151.96.87] (/148.87.13.11) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 14:29:33 -0700 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2012 14:29:31 -0700 Message-Id: To: scim WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:29:36 -0000 Folks, I know there has been a lot of discussion about modifying the patch = command to make it easier to read. A new requirement came up that seems = more generally useful, especially in cross domain scenarios. Issue, sometimes when you modify an attribute you want to confirm the = state of an attribute (or set) before completing the operation. This = could be done with a search, but the preference would be to do it in a = single operation. Let me take the (somewhat horrible) example of modifying passwords (it = could be anything else). Before modifying the password, you want to = confirm the old password is a match. This could be expressed in a couple of ways: Option 1 - replace old value PATCH /Users/phunt321 { "schemas": "......", =20 "password": {[ {"value" : "oldpassword", "operation" : "delete"} {"value":"newpassword"} ]} } Issue --> if password is single valued, then treating as multi-valued = may make no sense unless we allow it. It can only really test if a = pre-existing value is present -- not that broadly useful. Option 2 - a more generalized conditional modify PATCH /Users/phunt321 { "schemas":" .... ", "password": { "value":"newpassword", "condition":"filter=3Dpassword eq \"oldvalue\" and status eq = \"active\"", "critical" : "true" } In the above example, the condition is a filter about the resource that = must match (in this case testing the old value matches and that status = is active). Critical indicates whether the entire PATCH fails if the = filter does not match. It seems that in the cross-domain cases there may be many times when we = can't assume full state of a resource is known. It may be reasonable in = many cases (other than password setting), that the client may want to do = a conditional patch in a single operation (as opposed to a query = followed by a modify). =20 Phil @independentid www.independentid.com phil.hunt@oracle.com From trey.drake@unboundid.com Wed Aug 29 14:36:43 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B2C11E80EA for ; Wed, 29 Aug 2012 14:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T38sSfo6qIwN for ; Wed, 29 Aug 2012 14:36:42 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE211E80A5 for ; Wed, 29 Aug 2012 14:36:42 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2302086obb.31 for ; Wed, 29 Aug 2012 14:36:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=1HnulxRRx5CLqbQFUoCHfLFgtHVoqphfUln+YWYyIY0=; b=Tt25fMNmuAHE5OnHZGKkp61qmizaIM90++XvL214lXaO4pF+pn8CUd3uPVzNGCacnB tYzzeh/dg4gydS/3v055eqLhWymwgw+dqbvfSYRjOuxq8UM/Rc2p2CWJRLxdsl7aTov8 bGTzBDPe2yn5MPkml92bG7BRwBLnnWnkSu6goPoO6HOy5prwlLW5u+bYbLu4W62WsBD/ zHBnUJN2lZSfHaIIPvjtoTPScvkPPk47sU22fAIYWyL6nYR9nzAmdLWP07GYkC2rWvEr 4c59iBay/z3u2oTJNMQ7QzYpfyFsICI948R98Xy4Wdzvx0kzdVXvIAa/zIaGjR9Y3wtS YVkw== Received: by 10.60.3.106 with SMTP id b10mr2539291oeb.119.1346276201955; Wed, 29 Aug 2012 14:36:41 -0700 (PDT) Received: from office-dhcp-188.unboundid.lab (24-155-184-100.static.grandenetworks.net. [24.155.184.100]) by mx.google.com with ESMTPS id ac10sm1743544obc.7.2012.08.29.14.36.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 14:36:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330DE8F1@CH1PRD0410MB357.namprd04.prod.outlook.com> Date: Wed, 29 Aug 2012 16:36:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <503CE150.6030903@stpeter.im> <4BB9235E-F71A-4CFD-9D8F-28A1FB6AA6DF@unboundid.com> <503D6D90.5060402@stpeter.im> <503DBFF6.7090609@mnt.se> <503E2C80.1020502@mnt.se> <56C3C758F9D6534CA3778EAA1E0C3437330DD5A3@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DD652@CH1PRD0410MB357.namprd04.prod.outlook.com> <56C3C758F9D6534CA3778EAA1E0C3437330DE8F1@CH1PRD0410MB357.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQnjsa0FXFcJRhMiXXDYsl1qyZoaN9Ixr5mLtcdGPy0knIATCuPxYvIHqt0YGOfzaQk7x218 Cc: Anthony Nadalin , "scim@ietf.org" , Leif Johansson Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:36:43 -0000 Perhaps a more fundamental spec to look at w.r.t. linking is = Atom/AtomPub (RFC 4287/5023)? =20 Thanks, Trey On Aug 29, 2012, at 4:14 PM, Kelly Grizzle = wrote: > Sure thing. FWIW, I think that some of the things that are brought = into the Graph API from OData are very nice and warrant some thought = within SCIM. One that is quite interesting to me is a stronger concept = of relationships as described in section 4.2 Representing a Navigation = Property [1]. My initial opinion (without having delved too deeply into = Graph API or OData) is that OData seems like a pretty meaty spec and = that SCIM should adopt some of these ideas but try to remain fairly = light. >=20 > --Kelly >=20 > [1] = http://www.odata.org/media/30002/OData%20JSON%20Verbose%20Format.html >=20 >=20 > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Wednesday, August 29, 2012 2:36 PM > To: Kelly Grizzle; Leif Johansson; scim@ietf.org > Subject: RE: [scim] data format >=20 > Thanks for the clarification as I would have taken the data model to = be more of what OData offers and how that is exposed in WAAD then the = actual attribute definitions >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Kelly Grizzle > Sent: Wednesday, August 29, 2012 9:33 AM > To: Anthony Nadalin; Leif Johansson; scim@ietf.org > Subject: Re: [scim] data format >=20 > By "data model" I really meant schema (ie - a set of attribute = definitions that defines an object). My point was that (from an = interoperability perspective) using a common set of attributes is just = as important as getting the wire protocol and API right. >=20 >=20 > Peter asked: "Can we use one of the standardized data models (such as = iNetOrgPerson or vCard4, perhaps with extensions as needed)?" I think = that Samuel's suggestion (if I understood it correctly) was to consider = the data models that WAAD Graph API uses for User[1] and Group[2] along = with the two that Peter mentioned. >=20 > --Kelly >=20 > [1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 > [2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 >=20 >=20 > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Wednesday, August 29, 2012 10:04 AM > To: Kelly Grizzle; Leif Johansson; scim@ietf.org > Subject: RE: [scim] data format >=20 > You will have to define "data model" to be sure we all understand as = in the first sentence both schema and data model are used >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Kelly Grizzle > Sent: Wednesday, August 29, 2012 7:58 AM > To: Leif Johansson; scim@ietf.org > Subject: Re: [scim] data format >=20 > Yes - both the attributes and the wire format are important, which is = why the core schema draft provides data models for user, group, and = enterprise group. >=20 > To achieve some level of interoperability it is important to have a = common data model. This is one of the things that prevented adoption of = SPML. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Leif Johansson > Sent: Wednesday, August 29, 2012 9:52 AM > To: scim@ietf.org > Subject: Re: [scim] data format >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >> Not sure I quite understand the issue, I thought the issue would be=20= >> more around the wire format and API then the attributes >=20 > I would have thought both... >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >=20 > iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu > s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk > =3Dc//K > -----END PGP SIGNATURE----- > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From moransar@cisco.com Wed Aug 29 14:46:18 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED2A11E80EF for ; Wed, 29 Aug 2012 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnFBs9twbnGi for ; Wed, 29 Aug 2012 14:46:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 613E411E80A5 for ; Wed, 29 Aug 2012 14:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=moransar@cisco.com; l=6605; q=dns/txt; s=iport; t=1346276777; x=1347486377; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9IYyYRGDe/0fixo62u5DtNaVQy+w9BxqV16j3rvf/vA=; b=Lxlzl3SmbzuiNUtcLSOW6Y6LW5uruYh7o8fkOz14AdTHzAhwQ0avB3Sq gdtBcqBqUin+UTcHvsYvDYcmNG2hbSavrSU5oAmhfwmj6Fsj3kHCdTfCD b+Hgl20SA+iYOVdagZJ4fZmG9ZS6r5AVeyCDHc34Hree72QrDlID8nm2X 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGqMPlCtJXHB/2dsb2JhbAA8CbpxgQeCIAEBAQQBAQEPASc0FwYBCBEEAQEBHgkuCxQJCAIEARIbB4drC5tYjXKSUIsIEYZIA5Fvg2eBFIl9gx2BZ4Jj X-IronPort-AV: E=Sophos;i="4.80,335,1344211200"; d="scan'208";a="116544229" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 29 Aug 2012 21:46:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q7TLkGSK006860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Aug 2012 21:46:16 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.212]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 16:46:16 -0500 From: "Morteza Ansari (moransar)" To: Chris Phillips , "scim@ietf.org" Thread-Topic: [scim] data format Thread-Index: AQHNhTBx1XcAUVCLDEeIN5XRBVtzIZdv9G8AgAAJLwCAAGI6AIAAKq8AgABU0oCAAAHiAIAAARkAgAACXYCAABDeYIAAC9uQgAB0iYD//72RAA== Date: Wed, 29 Aug 2012 21:46:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.166.156] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19148.001 x-tm-as-result: No--41.644500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <7E8B5A80CE31BE43BCF021F00E9FF338@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [scim] data format X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:46:18 -0000 LDAP mapping specification is definitely within the charter of the WG and we have milestones for it. Similarly SAML binding is spelled out in the charter. Also during chartering discussion for the WG there was a lot of discussion on which schema should be used and I believe the consensus was that the WG should study the various existing standards and decide on the best solution for SCIM. Cheers, Morteza On 8/29/12 11:44 AM, "Chris Phillips" wrote: >+1 to Kelly's comments. > >A bit of background from previous SCIM schema work by the SCIM group: > >A mapping process around SCIM schema happened a few months ago[1] with a >few others. >The exercise was comparing the SCIM schema to other ones with discussion >revolving around what to do about the higher fidelity of SCIM compared to >others. The approach was to do a hybrid approach and have a high fidelity >SCIM schema(ie. SCIM-to-SCIM transactions) and separate mappings >documented recommending specifics on what to map to other schemas and have >those published as best practices in the SCIM sphere of control. >=20 > >Given the mention of the other schemas, extending the columns in the >mapping[2] to include Graph API and vCard4 are just a function of time >and effort. > >The reality will be that the first person to map a new schema to SCIM will >set the precedent on the mappings, right or wrong, and is that acceptable >to the spec? =20 >Will the spec have in scope common mappings to increase the utility of the >spec? Is this in scope of the WG? > >With these questions and others in mind, I think it would be useful to >talk about schema principles first and THEN specifics about a given schema >with these principles in mind. Mindful of course of what is in and out of >scope for SCIM given the slippery slope of sliding into identity >management practice discussions when we are really talking about a spec to >move identity related data around. > >From my perspective, all schemas will have pros and cons (and advocates) >and no one schema will map 100%, so the mapping exercise is practically >inescapable. I would err on the side of leadership on a common set of >mappings that would grow (and age) and would like to hear other opinions. > >As a parting thought about the attribute registry[3] and schemas, >certainly the pedigree of an attribute and what schema(s) it appears in >are valuable to track and so would it not in turn be a schema registry? Is >this a better context/home for the schema conversation? > > >Chris. > >[1] https://groups.google.com/group/cloud-directory/msg/e887d8842a1879d1 >[2] http://bit.ly/scimmappings >[3] http://tools.ietf.org/id/draft-johansson-areg-reqs-00.html > > > > >On 12-08-29 12:51 PM, "Kelly Grizzle" wrote: > >>> Can we use one of the standardized data models (such as iNetOrgPerson >>>or vCard4, perhaps with extensions as needed)? >> >>BTW - my answer for this question is that I am all for consistency and >>avoiding reinventing the wheel. IMO we should look at inetOrgPerson, >>vCard4, Graph API users and groups, and any other existing "identity data >>model" and weigh their merits and short-comings against the current SCIM >>proposal. >> >>--Kelly >> >>-----Original Message----- >>From: Kelly Grizzle >>Sent: Wednesday, August 29, 2012 11:33 AM >>To: 'Anthony Nadalin'; Leif Johansson; scim@ietf.org >>Subject: RE: [scim] data format >> >>By "data model" I really meant schema (ie - a set of attribute >>definitions that defines an object). My point was that (from an >>interoperability perspective) using a common set of attributes is just as >>important as getting the wire protocol and API right. >> >>Peter asked: "Can we use one of the standardized data models (such as >>iNetOrgPerson or vCard4, perhaps with extensions as needed)?" I think >>that Samuel's suggestion (if I understood it correctly) was to consider >>the data models that WAAD Graph API uses for User[1] and Group[2] along >>with the two that Peter mentioned. >> >>--Kelly >> >>[1] http://msdn.microsoft.com/en-us/library/windowsazure/hh974483 >>[2] http://msdn.microsoft.com/en-us/library/windowsazure/hh974486 >> >> >>-----Original Message----- >>From: Anthony Nadalin [mailto:tonynad@microsoft.com] >>Sent: Wednesday, August 29, 2012 10:04 AM >>To: Kelly Grizzle; Leif Johansson; scim@ietf.org >>Subject: RE: [scim] data format >> >>You will have to define "data model" to be sure we all understand as in >>the first sentence both schema and data model are used >> >>-----Original Message----- >>From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >>Kelly Grizzle >>Sent: Wednesday, August 29, 2012 7:58 AM >>To: Leif Johansson; scim@ietf.org >>Subject: Re: [scim] data format >> >>Yes - both the attributes and the wire format are important, which is why >>the core schema draft provides data models for user, group, and >>enterprise group. >> >>To achieve some level of interoperability it is important to have a >>common data model. This is one of the things that prevented adoption of >>SPML. >> >>--Kelly >> >> >>-----Original Message----- >>From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of >>Leif Johansson >>Sent: Wednesday, August 29, 2012 9:52 AM >>To: scim@ietf.org >>Subject: Re: [scim] data format >> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On 08/29/2012 04:44 PM, Anthony Nadalin wrote: >>> Not sure I quite understand the issue, I thought the issue would be >>> more around the wire format and API then the attributes >> >>I would have thought both... >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.11 (GNU/Linux) >>Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ >> >>iEYEARECAAYFAlA+LIAACgkQ8Jx8FtbMZndNEACfSjjpxpkLLxJ/K4Yq6l5b4kgu >>s24An3yj7ARb6FD5ZcFnPDXfFdR+quGk >>=3Dc//K >>-----END PGP SIGNATURE----- >>_______________________________________________ >>scim mailing list >>scim@ietf.org >>https://www.ietf.org/mailman/listinfo/scim >> >> >>_______________________________________________ >>scim mailing list >>scim@ietf.org >>https://www.ietf.org/mailman/listinfo/scim >> >> >> >> >> >> >> >>_______________________________________________ >>scim mailing list >>scim@ietf.org >>https://www.ietf.org/mailman/listinfo/scim > >_______________________________________________ >scim mailing list >scim@ietf.org >https://www.ietf.org/mailman/listinfo/scim From olds@rbcon.com Wed Aug 29 16:30:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BF611E8101 for ; Wed, 29 Aug 2012 16:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgtXtd1-ftY0 for ; Wed, 29 Aug 2012 16:30:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 67B1F11E80FF for ; Wed, 29 Aug 2012 16:30:10 -0700 (PDT) Received: by qadz3 with SMTP id z3so925206qad.10 for ; Wed, 29 Aug 2012 16:30:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=c9IYUPL6zq4Vqd3dh5jH4Eg06Ka1ljK7CD02ghZv5NQ=; b=ZfhvyTBAtzfmy4U7+aKeEu3QWcU5ghi9q+fDOS+sqRKbeEP4cTdzTsgk6n4/DVj/mt BbM4YGQG8l04BkoTGjIo9MUHdhIq5zWxDrCEC5Jr3Yaic1d95xaj89Pgd5IpQ1VN3EsV IGG/4yP+NrAc19kC+i7H+WinmwiMBEtEhoxzV4CWejjMaywdBuVcCeMOY/RbRHe5YokF tcFkKA2mRUGhxoCG7fpou23VCONT9yh1Ehr/HMcjxZJgbX/zT6uAvaIb+bTYoHEnsM86 knKd09G2cbr32NfIE9wMs2JGUcQ8br8Cpk2CqVbGIZGNi0yFwd8DJCG+gvJixeNmWtVq 3XHA== Received: by 10.229.136.8 with SMTP id p8mr1893363qct.3.1346283009378; Wed, 29 Aug 2012 16:30:09 -0700 (PDT) Received: from [10.0.0.12] (h-64-105-137-167.snvacaid.dynamic.covad.net. [64.105.137.167]) by mx.google.com with ESMTPS id j5sm537708qac.4.2012.08.29.16.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 16:30:08 -0700 (PDT) Message-ID: <503EA5FF.7030102@rbcon.com> Date: Wed, 29 Aug 2012 16:30:07 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkt5ALFscb+GbRwPbjjF9iQAibJsARmHvuVvIcWdL415fAnibavMe+7Aw8ukccHsGS5MwZ7 Subject: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 23:30:46 -0000 I am looking at draft-ietf-scim-api-00, though I think this issue has not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an example query of: GET /Users?attributes=userName In the example reply, the results include just the userName attribute of all users (since no filter was included). Section 3.7 describes the use of the attributes parameter. > Consumers MAY request a partial Resource representation on any > operation that returns a Resource within the response by specifying > the URL query parameter 'attributes'. When specified, each Resource > returned MUST contain the minimal set of Resource attributes and, MUST > contain no other attributes or Sub-Attributes than those explicitly > requested. The query parameter attributes value is a comma separated > list of Resource attribute names in standard,attribute notation > form > (e.g. userName, name, emails). My questions about this section: 1. If an attribute parameter is used to request a partial resource representation, does that mean lack of an attributes parameter means the full resource representation is returned? 2. If #1 is 'no', can a full representation be requested without knowing the attribute names beforehand? 3. the phrase "MUST contain the minimal set of Resource attributes and, MUST contain no other attributes or Sub-Attributes than those explicitly requested" only applies if the attribute parameter is given. I assume the minimal set of attributes is that referred to in section 3.2, but does that phrase mean union or intersection of minimal set and requested set? If I request attribute=userName, should I get the id and metadata back with each resource? 4. If #3 is 'intersection', is there some way to specify that I want the requested attribute + whatever the service provider defines as the minimal set? --Dale From trey.drake@unboundid.com Wed Aug 29 18:09:22 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF7E21E8041 for ; Wed, 29 Aug 2012 18:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKm62znDxbec for ; Wed, 29 Aug 2012 18:09:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF94111E8102 for ; Wed, 29 Aug 2012 18:09:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2584713obb.31 for ; Wed, 29 Aug 2012 18:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rxfPXWQvQ/C6n8q05qbZJVLrEwL1DhFxOd822pvdprg=; b=SgSE0PpIe0Z3j8H2m69JJ2jQdxc3k/j572cFcU9UXl/mBAWFh/6B5fXIZC2i4hKT6q SY8bCdauT5P/BNGjZ20TQFE0IG/9ZELrFIYBHfW8+4Wv5bQ76mzRQEwKFWvuV3PBWZp0 yREMJnaG/uJ/Y2OE0j248Usu2qIoUCYwKNtK4Apn23mpuVK2nMojONITuFV33mjJ1gcV R6pv8/Xu9J12EFuycCuP3hy/WXUYshJy3TMBljQgYg90FkM3OwtAkWn7q6VoUmrw/wRi eIY1YcPB2qHOczrINKarHCNyhqFMz7o4ew97/ZaiKJawQGX56YML+PRSDlDd2/GA9wLk OX7g== Received: by 10.60.170.18 with SMTP id ai18mr2825566oec.125.1346288957260; Wed, 29 Aug 2012 18:09:17 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id ig3sm223630obb.0.2012.08.29.18.09.15 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 18:09:16 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: <503EA5FF.7030102@rbcon.com> Date: Wed, 29 Aug 2012 20:09:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> References: <503EA5FF.7030102@rbcon.com> To: Dale Olds X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmSECwPazKjqfisZOdwqIDS3sOzKgjgqmYHf/jQDsSUDMgELqiay50U3g/eHhSzRvBc/Za6 Cc: "scim@ietf.org" Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:09:22 -0000 On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: > I am looking at draft-ietf-scim-api-00, though I think this issue has = not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an = example query of: >=20 > GET /Users?attributes=3DuserName >=20 > In the example reply, the results include just the userName attribute = of all users (since no filter was included). Section 3.7 describes the = use of the attributes parameter. >=20 >> Consumers MAY request a partial Resource representation on any >> operation that returns a Resource within the response by specifying >> the URL query parameter 'attributes'. When specified, each Resource >> returned MUST contain the minimal set of Resource attributes and, = MUST >> contain no other attributes or Sub-Attributes than those explicitly >> requested. The query parameter attributes value is a comma separated >> list of Resource attribute names in standard,attribute notation >> = form >> (e.g. userName, name, emails). >=20 > My questions about this section: >=20 > 1. If an attribute parameter is used to request a partial resource = representation, does that mean lack of an attributes parameter means the = full resource representation is returned? Yes*. I add the asterisk as the Service Provider may choose to filter = the set of returned attributes. =20 >=20 > 2. If #1 is 'no', can a full representation be requested without = knowing the attribute names beforehand? N/A >=20 > 3. the phrase "MUST contain the minimal set of Resource attributes = and, MUST contain no other attributes or Sub-Attributes than those = explicitly requested" only applies if the attribute parameter is given. = I assume the minimal set of attributes is that referred to in section = 3.2, but does that phrase mean union or intersection of minimal set and = requested set? If I request attribute=3DuserName, should I get the id = and metadata back with each resource? >=20 Currently, it does specify the Service Provider return the id and = meta-data. We discussed considering meta-data akin to LDAP operational = attributes, but we didn't play that thought process out.=20 > 4. If #3 is 'intersection', is there some way to specify that I want = the requested attribute + whatever the service provider defines as the = minimal set? >=20 N/A > --Dale Thanks, Trey >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From olds@rbcon.com Wed Aug 29 18:34:27 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043511E8106 for ; Wed, 29 Aug 2012 18:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-LIv6-I03h5 for ; Wed, 29 Aug 2012 18:34:27 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D26E21F84AE for ; Wed, 29 Aug 2012 18:34:26 -0700 (PDT) Received: by dadf8 with SMTP id f8so780823dad.31 for ; Wed, 29 Aug 2012 18:34:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=HsPYep7p2yK6AUX1LJ4+KPRSem81E+z9krg+Dtz/hrU=; b=mXL5TxJXZEV0TbSm58oV1xrbA3nNo3L3FUMQn0rLfOkRO0ZVEs0I1BRtqZd14UC/g8 y6a+8V4BIrfLMFjSDo/zDXvNQYVYR4mP8+Wk3vwMPgU6rERYDxpTJInm65O+KZ4B2TGy h6Wj8tkOyXMp3rf7XfvczpwwQaXIEsEW+D17UeQg22UV/gbhFCRgby7oUTGHZglpy0Dh Or7kJsAKiJbT50u7O1bpFtRv9qp2db1LP5OCFjQ/DL2s3lym0sSsA9RbwKKc0uQOosyl w7pAwuJtj593yuaTtMuPlR4bM+G4g/Hql33IANahmks3AK72CxrZfbDsy7RywuG3MwGL B/yA== Received: by 10.68.136.40 with SMTP id px8mr8212669pbb.153.1346290461755; Wed, 29 Aug 2012 18:34:21 -0700 (PDT) Received: from [10.40.32.89] ([173.243.48.220]) by mx.google.com with ESMTPS id oj8sm450304pbb.54.2012.08.29.18.34.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 18:34:21 -0700 (PDT) Message-ID: <503EC31B.5070200@rbcon.com> Date: Wed, 29 Aug 2012 18:34:19 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Trey Drake References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> In-Reply-To: <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkihhxhkgmp71oABvBSCOU50nrtIejtlAUaVK4v7LSQXwgWQ8UDh+CjD0UJoT7cjkEy5IMj Cc: "scim@ietf.org" Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:34:27 -0000 Thanks, Trey. Does the following updated paragraph give the correct meaning? Consumers MAY request a partial Resource representation on any operation that returns a Resource within the response by specifying the URL query parameter 'attributes'. When specified, each Resource returned MUST contain the attributes or Sub-Attributes explicitly requested in addition to the minimal set of Resource attributes, and no others. The query parameter 'attributes' value is a comma separated list of Resource attribute names in standard, attribute notation form (e.g. userName, name, emails). If no 'attributes' parameter is given, a full Resource representation is returned. --Dale On 08/29/2012 06:09 PM, Trey Drake wrote: > On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: > >> I am looking at draft-ietf-scim-api-00, though I think this issue has not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an example query of: >> >> GET /Users?attributes=userName >> >> In the example reply, the results include just the userName attribute of all users (since no filter was included). Section 3.7 describes the use of the attributes parameter. >> >>> Consumers MAY request a partial Resource representation on any >>> operation that returns a Resource within the response by specifying >>> the URL query parameter 'attributes'. When specified, each Resource >>> returned MUST contain the minimal set of Resource attributes and, MUST >>> contain no other attributes or Sub-Attributes than those explicitly >>> requested. The query parameter attributes value is a comma separated >>> list of Resource attribute names in standard,attribute notation >>> form >>> (e.g. userName, name, emails). >> My questions about this section: >> >> 1. If an attribute parameter is used to request a partial resource representation, does that mean lack of an attributes parameter means the full resource representation is returned? > Yes*. I add the asterisk as the Service Provider may choose to filter the set of returned attributes. > >> 2. If #1 is 'no', can a full representation be requested without knowing the attribute names beforehand? > N/A >> 3. the phrase "MUST contain the minimal set of Resource attributes and, MUST contain no other attributes or Sub-Attributes than those explicitly requested" only applies if the attribute parameter is given. I assume the minimal set of attributes is that referred to in section 3.2, but does that phrase mean union or intersection of minimal set and requested set? If I request attribute=userName, should I get the id and metadata back with each resource? >> > Currently, it does specify the Service Provider return the id and meta-data. We discussed considering meta-data akin to LDAP operational attributes, but we didn't play that thought process out. > >> 4. If #3 is 'intersection', is there some way to specify that I want the requested attribute + whatever the service provider defines as the minimal set? >> > N/A >> --Dale > > Thanks, > Trey >> >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim From trey.drake@unboundid.com Wed Aug 29 18:40:03 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454DA11E8105 for ; Wed, 29 Aug 2012 18:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.161 X-Spam-Level: X-Spam-Status: No, score=-3.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbqzKpmOAzOs for ; Wed, 29 Aug 2012 18:40:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5645311E8103 for ; Wed, 29 Aug 2012 18:40:02 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so2622114obb.31 for ; Wed, 29 Aug 2012 18:40:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=m1TcdZ1spbBdw7Qt4f56FZ7LjYi/dHtOVrR0AhrE0WQ=; b=NbDgfZC0dYMLuxf/g7hk13DZIbMYSncWuymLD600tK3phgx90xzjf54YJjNVpiWSjM Ox0Xhqrxq3+FfOB1t5HijFJN8bYriYKz/Tn/NJt134158jK8PqLOZSOWq+DvtWvif52v J4Geh0rB6ZfTy9DJGr/jUTcoObrAS80DOIJJmdbQNRnN9D4rgXxoLjejbCEAdOMuyUJT u0X5hu2Xg9vDvtN4miiKm5/wilErTQfxmRoSGVHiYOK0awiRci1YI33J/g4LYGDXOwsR 3S1Xo0aGIPIsw+9B8qzSDeQLAWIIhMR7lHxpbkwVr06c5Fk/rLtdFTfJFOkvlMAoDcjK KPkA== Received: by 10.182.217.38 with SMTP id ov6mr2938402obc.33.1346290801933; Wed, 29 Aug 2012 18:40:01 -0700 (PDT) Received: from [10.0.1.42] (cpe-66-69-203-135.austin.res.rr.com. [66.69.203.135]) by mx.google.com with ESMTPS id d6sm262397obx.15.2012.08.29.18.40.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 18:40:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Trey Drake In-Reply-To: <503EC31B.5070200@rbcon.com> Date: Wed, 29 Aug 2012 20:39:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> To: Dale Olds X-Mailer: Apple Mail (2.1486) X-Gm-Message-State: ALoCoQmjh+LEeck+EsNhXt6lkQx7Il1ulGy4gnrrzaT7/veYFROzShLIIfSYqAnaen4mK49AFvzD Cc: "scim@ietf.org" Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 01:40:03 -0000 Yes. On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: > Thanks, Trey. Does the following updated paragraph give the correct = meaning? >=20 > Consumers MAY request a partial Resource representation on any = operation that returns a Resource within the response by specifying the = URL query parameter 'attributes'. When specified, each Resource returned = MUST contain the attributes or Sub-Attributes explicitly requested in = addition to the minimal set of Resource attributes, and no others. The = query parameter 'attributes' value is a comma separated list of Resource = attribute names in standard, attribute notation form (e.g. userName, = name, emails). If no 'attributes' parameter is given, a full Resource = representation is returned. >=20 > --Dale >=20 > On 08/29/2012 06:09 PM, Trey Drake wrote: >> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>=20 >>> I am looking at draft-ietf-scim-api-00, though I think this issue = has not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an = example query of: >>>=20 >>> GET /Users?attributes=3DuserName >>>=20 >>> In the example reply, the results include just the userName = attribute of all users (since no filter was included). Section 3.7 = describes the use of the attributes parameter. >>>=20 >>>> Consumers MAY request a partial Resource representation on any >>>> operation that returns a Resource within the response by specifying >>>> the URL query parameter 'attributes'. When specified, each Resource >>>> returned MUST contain the minimal set of Resource attributes and, = MUST >>>> contain no other attributes or Sub-Attributes than those explicitly >>>> requested. The query parameter attributes value is a comma = separated >>>> list of Resource attribute names in standard,attribute notation >>>> = form >>>> (e.g. userName, name, emails). >>> My questions about this section: >>>=20 >>> 1. If an attribute parameter is used to request a partial resource = representation, does that mean lack of an attributes parameter means the = full resource representation is returned? >> Yes*. I add the asterisk as the Service Provider may choose to = filter the set of returned attributes. >>=20 >>> 2. If #1 is 'no', can a full representation be requested without = knowing the attribute names beforehand? >> N/A >>> 3. the phrase "MUST contain the minimal set of Resource attributes = and, MUST contain no other attributes or Sub-Attributes than those = explicitly requested" only applies if the attribute parameter is given. = I assume the minimal set of attributes is that referred to in section = 3.2, but does that phrase mean union or intersection of minimal set and = requested set? If I request attribute=3DuserName, should I get the id = and metadata back with each resource? >>>=20 >> Currently, it does specify the Service Provider return the id and = meta-data. We discussed considering meta-data akin to LDAP operational = attributes, but we didn't play that thought process out. >>=20 >>> 4. If #3 is 'intersection', is there some way to specify that I want = the requested attribute + whatever the service provider defines as the = minimal set? >>>=20 >> N/A >>> --Dale >>=20 >> Thanks, >> Trey >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >=20 From samuel@erdtman.se Wed Aug 29 23:13:54 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C123011E80AE for ; Wed, 29 Aug 2012 23:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmS-5fZkRSPr for ; Wed, 29 Aug 2012 23:13:53 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C366611E80AD for ; Wed, 29 Aug 2012 23:13:52 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1688835vbb.31 for ; Wed, 29 Aug 2012 23:13:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=hUzkHeL+cO4yQTMkhPwAzQautd2MBPESuA+Y1xESamc=; b=JPUCWaTfmeTEZQ7powB1djrvF5Lf22YmsNIMAe5bnUT0AUOnEp38XtACm7T3LIP3ZI OVbtuUBXen2xDANdbInoAFTMTzEAQmHnKOwQdZ+1rCPGr1b2bD/zLvZXy8K52RXVzpk9 RLB9vUPA8Pv39+bJQjeGpIS67V6pCd/VCJk2ZuNgTbA0gUuWDXoLrNfbySumiAQXun8m XvLMYSQpCTkuiJZAEoq3DhkitW19OZNxTDForK+8MltJGu2rBZbJPkTXr+ArqSYT2psh WepE2seEkQWtFs6YpLDfb/01lTcr+riNT/vHzBrxvE7WXqh90g6kV+Jk++9wn0iurfl5 QOSg== MIME-Version: 1.0 Received: by 10.52.16.50 with SMTP id c18mr1997399vdd.76.1346307232118; Wed, 29 Aug 2012 23:13:52 -0700 (PDT) Received: by 10.220.58.205 with HTTP; Wed, 29 Aug 2012 23:13:52 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Aug 2012 08:13:52 +0200 Message-ID: From: Samuel Erdtman To: Phil Hunt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl/Z+dk8gBt1UjfWhi3T2hiTrTZs+UIpaEdqIE4O5dO89FMko2d+Rv4k7dXkK7iUdTYZBk/ Cc: scim WG Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:13:54 -0000 Interesting, another way to do the same thing but without cluttering the resource representation would be to put the filter part in the query instead of within the resource-object, this would in addition to allow conditional updates of one user allow for updates of all users matching a certain criteria. To update the title of all Tour Guides: PATCH /Users?filter=3Dtitle eq "Tour Guide", { "title": "Tour Master", } To update the title of one specific Tour Guide if he is a tour guide PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", { "title": "Tour Guide Manager", } To update one users password if that user is active PATCH /Users?filter=3Did eq "saerd" and active eq "true", { "password": "newvalue", } Thoughts? Cheers //Samuel On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt wrote: > Folks, > > I know there has been a lot of discussion about modifying the patch comma= nd to make it easier to read. A new requirement came up that seems more ge= nerally useful, especially in cross domain scenarios. > > Issue, sometimes when you modify an attribute you want to confirm the sta= te of an attribute (or set) before completing the operation. This could be= done with a search, but the preference would be to do it in a single opera= tion. > > Let me take the (somewhat horrible) example of modifying passwords (it co= uld be anything else). Before modifying the password, you want to confirm = the old password is a match. > > This could be expressed in a couple of ways: > > Option 1 - replace old value > > PATCH /Users/phunt321 > > { "schemas": "......", > > "password": {[ > {"value" : "oldpassword", > "operation" : "delete"} > {"value":"newpassword"} > ]} > } > > Issue --> if password is single valued, then treating as multi-valued may= make no sense unless we allow it. It can only really test if a pre-existi= ng value is present -- not that broadly useful. > > Option 2 - a more generalized conditional modify > > PATCH /Users/phunt321 > { > "schemas":" .... ", > > "password": { > "value":"newpassword", > "condition":"filter=3Dpassword eq \"oldvalue\" and status eq \"active= \"", > "critical" : "true" > } > > In the above example, the condition is a filter about the resource that m= ust match (in this case testing the old value matches and that status is ac= tive). Critical indicates whether the entire PATCH fails if the filter does= not match. > > It seems that in the cross-domain cases there may be many times when we c= an't assume full state of a resource is known. It may be reasonable in many= cases (other than password setting), that the client may want to do a cond= itional patch in a single operation (as opposed to a query followed by a mo= dify). > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Aug 29 23:38:06 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0470A11E8097 for ; Wed, 29 Aug 2012 23:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.609 X-Spam-Level: X-Spam-Status: No, score=-9.609 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwsk0Fn5vlpC for ; Wed, 29 Aug 2012 23:38:05 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0711E80BA for ; Wed, 29 Aug 2012 23:38:00 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7U6bvxx006024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 06:37:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7U6bv26020496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 06:37:57 GMT Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7U6buq0024446; Thu, 30 Aug 2012 01:37:56 -0500 Received: from [192.168.4.13] (/12.217.162.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 23:37:56 -0700 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <623B5DAE-7E91-4FF0-9BD2-0AD25CAD8E73@oracle.com> X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Wed, 29 Aug 2012 23:37:53 -0700 To: Samuel Erdtman X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: scim WG Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:38:06 -0000 Yes agreed. However as with GET there is need to keep some filter terms out o= f the URL. Phil On 2012-08-29, at 23:13, Samuel Erdtman wrote: > Interesting, another way to do the same thing but without cluttering > the resource representation would be to put the filter part in the > query instead of within the resource-object, this would in addition to > allow conditional updates of one user allow for updates of all users > matching a certain criteria. >=20 > To update the title of all Tour Guides: > PATCH /Users?filter=3Dtitle eq "Tour Guide", > { > "title": "Tour Master", > } >=20 > To update the title of one specific Tour Guide if he is a tour guide > PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", > { > "title": "Tour Guide Manager", > } >=20 > To update one users password if that user is active > PATCH /Users?filter=3Did eq "saerd" and active eq "true", > { > "password": "newvalue", > } >=20 > Thoughts? >=20 > Cheers > //Samuel >=20 >=20 >=20 > On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt wrote: >> Folks, >>=20 >> I know there has been a lot of discussion about modifying the patch comma= nd to make it easier to read. A new requirement came up that seems more gen= erally useful, especially in cross domain scenarios. >>=20 >> Issue, sometimes when you modify an attribute you want to confirm the sta= te of an attribute (or set) before completing the operation. This could be d= one with a search, but the preference would be to do it in a single operatio= n. >>=20 >> Let me take the (somewhat horrible) example of modifying passwords (it co= uld be anything else). Before modifying the password, you want to confirm t= he old password is a match. >>=20 >> This could be expressed in a couple of ways: >>=20 >> Option 1 - replace old value >>=20 >> PATCH /Users/phunt321 >>=20 >> { "schemas": "......", >>=20 >> "password": {[ >> {"value" : "oldpassword", >> "operation" : "delete"} >> {"value":"newpassword"} >> ]} >> } >>=20 >> Issue --> if password is single valued, then treating as multi-valued may= make no sense unless we allow it. It can only really test if a pre-existin= g value is present -- not that broadly useful. >>=20 >> Option 2 - a more generalized conditional modify >>=20 >> PATCH /Users/phunt321 >> { >> "schemas":" .... ", >>=20 >> "password": { >> "value":"newpassword", >> "condition":"filter=3Dpassword eq \"oldvalue\" and status eq \"active\= "", >> "critical" : "true" >> } >>=20 >> In the above example, the condition is a filter about the resource that m= ust match (in this case testing the old value matches and that status is act= ive). Critical indicates whether the entire PATCH fails if the filter does n= ot match. >>=20 >> It seems that in the cross-domain cases there may be many times when we c= an't assume full state of a resource is known. It may be reasonable in many c= ases (other than password setting), that the client may want to do a conditi= onal patch in a single operation (as opposed to a query followed by a modify= ). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Wed Aug 29 23:42:15 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0859111E80FE for ; Wed, 29 Aug 2012 23:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.602 X-Spam-Level: X-Spam-Status: No, score=-9.602 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYHa0vMZs1dj for ; Wed, 29 Aug 2012 23:42:14 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id F3DA611E80A3 for ; Wed, 29 Aug 2012 23:42:10 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7U6g907019854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Aug 2012 06:42:09 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7U6g83V000584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Aug 2012 06:42:08 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7U6g7XH003019; Thu, 30 Aug 2012 01:42:07 -0500 Received: from [192.168.4.13] (/12.217.162.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Aug 2012 23:42:07 -0700 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Phil Hunt Date: Wed, 29 Aug 2012 23:42:04 -0700 To: Samuel Erdtman X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: scim WG Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:42:15 -0000 Also on the URL, the condition would apply to the entire operation rather th= an just one particular attribute. =20 Both could be useful though.=20 Phil On 2012-08-29, at 23:13, Samuel Erdtman wrote: > Interesting, another way to do the same thing but without cluttering > the resource representation would be to put the filter part in the > query instead of within the resource-object, this would in addition to > allow conditional updates of one user allow for updates of all users > matching a certain criteria. >=20 > To update the title of all Tour Guides: > PATCH /Users?filter=3Dtitle eq "Tour Guide", > { > "title": "Tour Master", > } >=20 > To update the title of one specific Tour Guide if he is a tour guide > PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", > { > "title": "Tour Guide Manager", > } >=20 > To update one users password if that user is active > PATCH /Users?filter=3Did eq "saerd" and active eq "true", > { > "password": "newvalue", > } >=20 > Thoughts? >=20 > Cheers > //Samuel >=20 >=20 >=20 > On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt wrote: >> Folks, >>=20 >> I know there has been a lot of discussion about modifying the patch comma= nd to make it easier to read. A new requirement came up that seems more gen= erally useful, especially in cross domain scenarios. >>=20 >> Issue, sometimes when you modify an attribute you want to confirm the sta= te of an attribute (or set) before completing the operation. This could be d= one with a search, but the preference would be to do it in a single operatio= n. >>=20 >> Let me take the (somewhat horrible) example of modifying passwords (it co= uld be anything else). Before modifying the password, you want to confirm t= he old password is a match. >>=20 >> This could be expressed in a couple of ways: >>=20 >> Option 1 - replace old value >>=20 >> PATCH /Users/phunt321 >>=20 >> { "schemas": "......", >>=20 >> "password": {[ >> {"value" : "oldpassword", >> "operation" : "delete"} >> {"value":"newpassword"} >> ]} >> } >>=20 >> Issue --> if password is single valued, then treating as multi-valued may= make no sense unless we allow it. It can only really test if a pre-existin= g value is present -- not that broadly useful. >>=20 >> Option 2 - a more generalized conditional modify >>=20 >> PATCH /Users/phunt321 >> { >> "schemas":" .... ", >>=20 >> "password": { >> "value":"newpassword", >> "condition":"filter=3Dpassword eq \"oldvalue\" and status eq \"active\= "", >> "critical" : "true" >> } >>=20 >> In the above example, the condition is a filter about the resource that m= ust match (in this case testing the old value matches and that status is act= ive). Critical indicates whether the entire PATCH fails if the filter does n= ot match. >>=20 >> It seems that in the cross-domain cases there may be many times when we c= an't assume full state of a resource is known. It may be reasonable in many c= ases (other than password setting), that the client may want to do a conditi= onal patch in a single operation (as opposed to a query followed by a modify= ). >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Thu Aug 30 14:52:34 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77CB21F8535 for ; Thu, 30 Aug 2012 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.292 X-Spam-Level: X-Spam-Status: No, score=-10.292 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFzX0VRTfixo for ; Thu, 30 Aug 2012 14:52:34 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id EE87A21F8534 for ; Thu, 30 Aug 2012 14:52:33 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7ULqVpK013129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 30 Aug 2012 21:52:32 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7ULqVWs019607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Aug 2012 21:52:31 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7ULqURx014515 for ; Thu, 30 Aug 2012 16:52:30 -0500 Received: from dhcp-whq-twvpn-1-vpnpool-10-159-220-144.vpn.oracle.com (/10.159.220.144) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Aug 2012 14:52:30 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Phil Hunt In-Reply-To: Date: Thu, 30 Aug 2012 14:52:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82D996E8-D525-42A5-9155-3701DEDFDB33@oracle.com> References: To: scim WG X-Mailer: Apple Mail (2.1278) X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:52:35 -0000 Murray and Leif suggested taking a look at: draft-ietf-appsawg-json-patch - = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02 The spec seems relatively simple and might improve the overall PATCH = operation.=20 My only concern is that the spec is based on another spec JSON Pointer = (http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01) JSON Pointer is good for straight forward JSON structures, however it = ends up being a bit like XML Paths. I wonder if a version of this where = we use just attributes wouldn't work even better. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-29, at 11:42 PM, Phil Hunt wrote: > Also on the URL, the condition would apply to the entire operation = rather than just one particular attribute. =20 >=20 > Both could be useful though.=20 >=20 > Phil >=20 > On 2012-08-29, at 23:13, Samuel Erdtman wrote: >=20 >> Interesting, another way to do the same thing but without cluttering >> the resource representation would be to put the filter part in the >> query instead of within the resource-object, this would in addition = to >> allow conditional updates of one user allow for updates of all users >> matching a certain criteria. >>=20 >> To update the title of all Tour Guides: >> PATCH /Users?filter=3Dtitle eq "Tour Guide", >> { >> "title": "Tour Master", >> } >>=20 >> To update the title of one specific Tour Guide if he is a tour guide >> PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", >> { >> "title": "Tour Guide Manager", >> } >>=20 >> To update one users password if that user is active >> PATCH /Users?filter=3Did eq "saerd" and active eq "true", >> { >> "password": "newvalue", >> } >>=20 >> Thoughts? >>=20 >> Cheers >> //Samuel >>=20 >>=20 >>=20 >> On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt = wrote: >>> Folks, >>>=20 >>> I know there has been a lot of discussion about modifying the patch = command to make it easier to read. A new requirement came up that seems = more generally useful, especially in cross domain scenarios. >>>=20 >>> Issue, sometimes when you modify an attribute you want to confirm = the state of an attribute (or set) before completing the operation. = This could be done with a search, but the preference would be to do it = in a single operation. >>>=20 >>> Let me take the (somewhat horrible) example of modifying passwords = (it could be anything else). Before modifying the password, you want to = confirm the old password is a match. >>>=20 >>> This could be expressed in a couple of ways: >>>=20 >>> Option 1 - replace old value >>>=20 >>> PATCH /Users/phunt321 >>>=20 >>> { "schemas": "......", >>>=20 >>> "password": {[ >>> {"value" : "oldpassword", >>> "operation" : "delete"} >>> {"value":"newpassword"} >>> ]} >>> } >>>=20 >>> Issue --> if password is single valued, then treating as = multi-valued may make no sense unless we allow it. It can only really = test if a pre-existing value is present -- not that broadly useful. >>>=20 >>> Option 2 - a more generalized conditional modify >>>=20 >>> PATCH /Users/phunt321 >>> { >>> "schemas":" .... ", >>>=20 >>> "password": { >>> "value":"newpassword", >>> "condition":"filter=3Dpassword eq \"oldvalue\" and status eq = \"active\"", >>> "critical" : "true" >>> } >>>=20 >>> In the above example, the condition is a filter about the resource = that must match (in this case testing the old value matches and that = status is active). Critical indicates whether the entire PATCH fails if = the filter does not match. >>>=20 >>> It seems that in the cross-domain cases there may be many times when = we can't assume full state of a resource is known. It may be reasonable = in many cases (other than password setting), that the client may want to = do a conditional patch in a single operation (as opposed to a query = followed by a modify). >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From olds@rbcon.com Thu Aug 30 22:53:08 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E74D321F8448 for ; Thu, 30 Aug 2012 22:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4DLTks9aV54 for ; Thu, 30 Aug 2012 22:53:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A61A321F845C for ; Thu, 30 Aug 2012 22:53:07 -0700 (PDT) Received: by iabz21 with SMTP id z21so5032060iab.31 for ; Thu, 30 Aug 2012 22:53:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=p2kxIFFEwJy/S/6HByM1F5bLgVt8Wa/v6NjWfVWuavE=; b=AD8TDes0nOMOcuYjSCZDAIo5/LhxQUUxImCyclwC+dpWKoRH5PXLwPfOIDnsrBWRzQ AW9C+ZjeTNVbh+Dd3xsxkR/La46M2cEaquH9pBoZ4aYOteLDT20UgVbXgN2o1Ljcm4QK 6sMj4Er8b/qRO7ANBODCKRQg+yWshqc2uQuSHfN4+rkGD9Tbpt1+gd97X4Nxo5OnDYd4 AZgzMWVKQ68sWur6M2PsbDLqQw3O8Ys8S4ivUWcNEX8O0M5pgb8b76ldZIGSQrbkI8HK XjYedp6WF/CT7h8PV9izaAV/Osf4etjUNWl4TqM/MECustJkKcF9aa0RSjnk7FymaySw ELAA== Received: by 10.50.10.166 with SMTP id j6mr1103226igb.13.1346392385479; Thu, 30 Aug 2012 22:53:05 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id n5sm6199169igw.13.2012.08.30.22.53.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 22:53:04 -0700 (PDT) Message-ID: <5040513F.5080806@rbcon.com> Date: Thu, 30 Aug 2012 22:53:03 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Trey Drake References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> In-Reply-To: <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl1OJHAj3Tlv0NwyWwoB+xB3P/YCwJLGRbHGdoTU0bIJE1FpsjLvTQ7/GDbZw5GETdAU3Lz Cc: "scim@ietf.org" Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 05:53:09 -0000 On more nit on this issue. It would also be useful for the example output in section 3.2.2 to reflect the union of minimal and requested attributes. Instead of this: HTTP/1.1 200 OK Content-Type: application/json { "totalResults":2, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ { "userName":"bjensen" }, { "userName":"jsmith" } ] } it should be (if I understand the minimal set of id, meta, and perhaps externalId correctly): HTTP/1.1 200 OK Content-Type: application/json { "totalResults":2, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ { "userName":"bjensen", "id":"2819c223-7f76-453a-919d-413861904646", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "version":"W\/\"a330bc54f0671c9\"" } { "userName":"jsmith" "id":"3819c223-7f76-453a-919d-413861904647", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", "version":"W\/\"a330bc54f0671c9\"" } } ] } On 08/29/2012 06:39 PM, Trey Drake wrote: > Yes. > > On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: > >> Thanks, Trey. Does the following updated paragraph give the correct meaning? >> >> Consumers MAY request a partial Resource representation on any operation that returns a Resource within the response by specifying the URL query parameter 'attributes'. When specified, each Resource returned MUST contain the attributes or Sub-Attributes explicitly requested in addition to the minimal set of Resource attributes, and no others. The query parameter 'attributes' value is a comma separated list of Resource attribute names in standard, attribute notation form (e.g. userName, name, emails). If no 'attributes' parameter is given, a full Resource representation is returned. >> >> --Dale >> >> On 08/29/2012 06:09 PM, Trey Drake wrote: >>> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>> >>>> I am looking at draft-ietf-scim-api-00, though I think this issue has not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an example query of: >>>> >>>> GET /Users?attributes=userName >>>> >>>> In the example reply, the results include just the userName attribute of all users (since no filter was included). Section 3.7 describes the use of the attributes parameter. >>>> >>>>> Consumers MAY request a partial Resource representation on any >>>>> operation that returns a Resource within the response by specifying >>>>> the URL query parameter 'attributes'. When specified, each Resource >>>>> returned MUST contain the minimal set of Resource attributes and, MUST >>>>> contain no other attributes or Sub-Attributes than those explicitly >>>>> requested. The query parameter attributes value is a comma separated >>>>> list of Resource attribute names in standard,attribute notation >>>>> form >>>>> (e.g. userName, name, emails). >>>> My questions about this section: >>>> >>>> 1. If an attribute parameter is used to request a partial resource representation, does that mean lack of an attributes parameter means the full resource representation is returned? >>> Yes*. I add the asterisk as the Service Provider may choose to filter the set of returned attributes. >>> >>>> 2. If #1 is 'no', can a full representation be requested without knowing the attribute names beforehand? >>> N/A >>>> 3. the phrase "MUST contain the minimal set of Resource attributes and, MUST contain no other attributes or Sub-Attributes than those explicitly requested" only applies if the attribute parameter is given. I assume the minimal set of attributes is that referred to in section 3.2, but does that phrase mean union or intersection of minimal set and requested set? If I request attribute=userName, should I get the id and metadata back with each resource? >>>> >>> Currently, it does specify the Service Provider return the id and meta-data. We discussed considering meta-data akin to LDAP operational attributes, but we didn't play that thought process out. >>> >>>> 4. If #3 is 'intersection', is there some way to specify that I want the requested attribute + whatever the service provider defines as the minimal set? >>>> >>> N/A >>>> --Dale >>> Thanks, >>> Trey >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim From lear@cisco.com Fri Aug 31 00:27:47 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D3A21F84C4 for ; Fri, 31 Aug 2012 00:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taxOWxTOKxle for ; Fri, 31 Aug 2012 00:27:46 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0921F846B for ; Fri, 31 Aug 2012 00:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=5694; q=dns/txt; s=iport; t=1346398066; x=1347607666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ER+gWSHOFoNcj8ISDIO3nuAPToSqQzFhrr4Y/PhAfDA=; b=HS3mz4AChy5t+KPkacezTV/PDIy+B8KMTGAT3EiY/Ssn1EQbTxcMvMgY 15O//nIA0kAZxfdB+3mXmS1mJa9Ew8uo5nz/xCBZlXuhBO2jXm+MXYesh UE8Q1yyUlH7DVsL3PM8a/GzTjp5SmI+72JfayjUm5FHtnKPZoLPGr3XLZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKVmQFCQ/khN/2dsb2JhbABFhgS1EoEHgiABAQEEAQEBDwEQSwoBEAsYAgIFFgsCAgkDAgECARUwBg0BBQIBAR6HawucJ40YkwKBIYlkhW+BEgOVV44ygWeCZQ X-IronPort-AV: E=Sophos;i="4.80,346,1344211200"; d="scan'208";a="7705774" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 31 Aug 2012 07:27:44 +0000 Received: from dhcp-10-55-84-39.cisco.com (dhcp-10-55-84-39.cisco.com [10.55.84.39]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q7V7Rhpo016988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 07:27:44 GMT Message-ID: <50406771.3060702@cisco.com> Date: Fri, 31 Aug 2012 09:27:45 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Dale Olds References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> <5040513F.5080806@rbcon.com> In-Reply-To: <5040513F.5080806@rbcon.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 07:27:47 -0000 Just along these lines, I'd like to strongly suggest to the working group that we clearly describe the correct way for others to extend the use of SCIM. XML is a natural for this with its use of namespaces. I'm not sufficiently versed in JSON to say how it should be done that way, but I'm sure something can be done, right? Eliot On 8/31/12 7:53 AM, Dale Olds wrote: > On more nit on this issue. It would also be useful for the example > output in section 3.2.2 to reflect the union of minimal and requested > attributes. > > Instead of this: > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen" > }, > { > "userName":"jsmith" > } > ] > } > > it should be (if I understand the minimal set of id, meta, and perhaps > externalId correctly): > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen", > "id":"2819c223-7f76-453a-919d-413861904646", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > { > "userName":"jsmith" > "id":"3819c223-7f76-453a-919d-413861904647", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > } > ] > } > > > On 08/29/2012 06:39 PM, Trey Drake wrote: >> Yes. >> >> On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: >> >>> Thanks, Trey. Does the following updated paragraph give the correct >>> meaning? >>> >>> Consumers MAY request a partial Resource representation on any >>> operation that returns a Resource within the response by specifying >>> the URL query parameter 'attributes'. When specified, each Resource >>> returned MUST contain the attributes or Sub-Attributes explicitly >>> requested in addition to the minimal set of Resource attributes, and >>> no others. The query parameter 'attributes' value is a comma >>> separated list of Resource attribute names in standard, attribute >>> notation form (e.g. userName, name, emails). If no 'attributes' >>> parameter is given, a full Resource representation is returned. >>> >>> --Dale >>> >>> On 08/29/2012 06:09 PM, Trey Drake wrote: >>>> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>>> >>>>> I am looking at draft-ietf-scim-api-00, though I think this issue >>>>> has not changed since the 1.0 and 1.1 API specs. Section 3.2.2 >>>>> shows an example query of: >>>>> >>>>> GET /Users?attributes=userName >>>>> >>>>> In the example reply, the results include just the userName >>>>> attribute of all users (since no filter was included). Section 3.7 >>>>> describes the use of the attributes parameter. >>>>> >>>>>> Consumers MAY request a partial Resource representation on any >>>>>> operation that returns a Resource within the response by specifying >>>>>> the URL query parameter 'attributes'. When specified, each Resource >>>>>> returned MUST contain the minimal set of Resource attributes and, >>>>>> MUST >>>>>> contain no other attributes or Sub-Attributes than those explicitly >>>>>> requested. The query parameter attributes value is a comma separated >>>>>> list of Resource attribute names in standard,attribute notation >>>>>> form >>>>>> >>>>>> (e.g. userName, name, emails). >>>>> My questions about this section: >>>>> >>>>> 1. If an attribute parameter is used to request a partial resource >>>>> representation, does that mean lack of an attributes parameter >>>>> means the full resource representation is returned? >>>> Yes*. I add the asterisk as the Service Provider may choose to >>>> filter the set of returned attributes. >>>> >>>>> 2. If #1 is 'no', can a full representation be requested without >>>>> knowing the attribute names beforehand? >>>> N/A >>>>> 3. the phrase "MUST contain the minimal set of Resource attributes >>>>> and, MUST contain no other attributes or Sub-Attributes than those >>>>> explicitly requested" only applies if the attribute parameter is >>>>> given. I assume the minimal set of attributes is that referred to >>>>> in section 3.2, but does that phrase mean union or intersection of >>>>> minimal set and requested set? If I request attribute=userName, >>>>> should I get the id and metadata back with each resource? >>>>> >>>> Currently, it does specify the Service Provider return the id and >>>> meta-data. We discussed considering meta-data akin to LDAP >>>> operational attributes, but we didn't play that thought process out. >>>> >>>>> 4. If #3 is 'intersection', is there some way to specify that I >>>>> want the requested attribute + whatever the service provider >>>>> defines as the minimal set? >>>>> >>>> N/A >>>>> --Dale >>>> Thanks, >>>> Trey >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > From kelly.grizzle@sailpoint.com Fri Aug 31 06:20:11 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD921F85B1 for ; Fri, 31 Aug 2012 06:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.898 X-Spam-Level: X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bVyYEN7PUQt for ; Fri, 31 Aug 2012 06:20:10 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69221F85AD for ; Fri, 31 Aug 2012 06:20:10 -0700 (PDT) Received: from mail5-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 13:20:09 +0000 Received: from mail5-ch1 (localhost [127.0.0.1]) by mail5-ch1-R.bigfish.com (Postfix) with ESMTP id 24B7320007A; Fri, 31 Aug 2012 13:20:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I542M1432I4015Izz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail5-ch1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail5-ch1 (localhost.localdomain [127.0.0.1]) by mail5-ch1 (MessageSwitch) id 1346419207752539_9272; Fri, 31 Aug 2012 13:20:07 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail5-ch1.bigfish.com (Postfix) with ESMTP id B1DB4300047; Fri, 31 Aug 2012 13:20:07 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 13:20:05 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0190.008; Fri, 31 Aug 2012 13:20:05 +0000 From: Kelly Grizzle To: Eliot Lear , Dale Olds Thread-Topic: [scim] attribute selection in query responses Thread-Index: AQHNhj5unR2mt05hMEGCkGDwZVhYZ5dxi6YAgAAHA4CAAAGVgIAB2QmAgAAadoCAAGEu8A== Date: Fri, 31 Aug 2012 13:20:04 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E02DE@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> <5040513F.5080806@rbcon.com> <50406771.3060702@cisco.com> In-Reply-To: <50406771.3060702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 13:20:11 -0000 SCIM does define an extension model, although it could be described more ex= plicitly in the spec. Section 4 of the core schema draft explains how to e= xtend a schema - http://tools.ietf.org/html/draft-ietf-scim-core-schema-00#= section-4. =20 You can see an example of how this is done in the enterprise user extension= representation - http://tools.ietf.org/html/draft-ietf-scim-core-schema-00= #section-11.3. Note that the schemas attribute has declares use of the ent= erprise extension. The actual enterprise attributes are namespaced by the = schema URN, like this: -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eli= ot Lear Sent: Friday, August 31, 2012 2:28 AM To: Dale Olds Cc: scim@ietf.org; Trey Drake Subject: Re: [scim] attribute selection in query responses Just along these lines, I'd like to strongly suggest to the working group t= hat we clearly describe the correct way for others to extend the use of SCI= M. XML is a natural for this with its use of namespaces. I'm not sufficie= ntly versed in JSON to say how it should be done that way, but I'm sure som= ething can be done, right? Eliot On 8/31/12 7:53 AM, Dale Olds wrote: > On more nit on this issue. It would also be useful for the example=20 > output in section 3.2.2 to reflect the union of minimal and requested=20 > attributes. > > Instead of this: > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen" > }, > { > "userName":"jsmith" > } > ] > } > > it should be (if I understand the minimal set of id, meta, and perhaps=20 > externalId correctly): > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen", > "id":"2819c223-7f76-453a-919d-413861904646", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41386 > 1904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > { > "userName":"jsmith" > "id":"3819c223-7f76-453a-919d-413861904647", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41386 > 1904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > } > ] > } > > > On 08/29/2012 06:39 PM, Trey Drake wrote: >> Yes. >> >> On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: >> >>> Thanks, Trey. Does the following updated paragraph give the correct=20 >>> meaning? >>> >>> Consumers MAY request a partial Resource representation on any=20 >>> operation that returns a Resource within the response by specifying=20 >>> the URL query parameter 'attributes'. When specified, each Resource=20 >>> returned MUST contain the attributes or Sub-Attributes explicitly=20 >>> requested in addition to the minimal set of Resource attributes, and=20 >>> no others. The query parameter 'attributes' value is a comma=20 >>> separated list of Resource attribute names in standard, attribute=20 >>> notation form (e.g. userName, name, emails). If no 'attributes' >>> parameter is given, a full Resource representation is returned. >>> >>> --Dale >>> >>> On 08/29/2012 06:09 PM, Trey Drake wrote: >>>> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>>> >>>>> I am looking at draft-ietf-scim-api-00, though I think this issue=20 >>>>> has not changed since the 1.0 and 1.1 API specs. Section 3.2.2=20 >>>>> shows an example query of: >>>>> >>>>> GET /Users?attributes=3DuserName >>>>> >>>>> In the example reply, the results include just the userName=20 >>>>> attribute of all users (since no filter was included). Section 3.7=20 >>>>> describes the use of the attributes parameter. >>>>> >>>>>> Consumers MAY request a partial Resource representation on any=20 >>>>>> operation that returns a Resource within the response by=20 >>>>>> specifying the URL query parameter 'attributes'. When specified,=20 >>>>>> each Resource returned MUST contain the minimal set of Resource=20 >>>>>> attributes and, MUST contain no other attributes or=20 >>>>>> Sub-Attributes than those explicitly requested. The query=20 >>>>>> parameter attributes value is a comma separated list of Resource=20 >>>>>> attribute names in standard,attribute notation=20 >>>>>> >>>>> te-notation>form >>>>>> >>>>>> (e.g. userName, name, emails). >>>>> My questions about this section: >>>>> >>>>> 1. If an attribute parameter is used to request a partial resource=20 >>>>> representation, does that mean lack of an attributes parameter=20 >>>>> means the full resource representation is returned? >>>> Yes*. I add the asterisk as the Service Provider may choose to=20 >>>> filter the set of returned attributes. >>>> >>>>> 2. If #1 is 'no', can a full representation be requested without=20 >>>>> knowing the attribute names beforehand? >>>> N/A >>>>> 3. the phrase "MUST contain the minimal set of Resource attributes=20 >>>>> and, MUST contain no other attributes or Sub-Attributes than those=20 >>>>> explicitly requested" only applies if the attribute parameter is=20 >>>>> given. I assume the minimal set of attributes is that referred to=20 >>>>> in section 3.2, but does that phrase mean union or intersection of=20 >>>>> minimal set and requested set? If I request attribute=3DuserName,=20 >>>>> should I get the id and metadata back with each resource? >>>>> >>>> Currently, it does specify the Service Provider return the id and=20 >>>> meta-data. We discussed considering meta-data akin to LDAP=20 >>>> operational attributes, but we didn't play that thought process out. >>>> >>>>> 4. If #3 is 'intersection', is there some way to specify that I=20 >>>>> want the requested attribute + whatever the service provider=20 >>>>> defines as the minimal set? >>>>> >>>> N/A >>>>> --Dale >>>> Thanks, >>>> Trey >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Fri Aug 31 06:21:45 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF19021F85AD for ; Fri, 31 Aug 2012 06:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzQZE5ZTsRoi for ; Fri, 31 Aug 2012 06:21:44 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id E354F21F854E for ; Fri, 31 Aug 2012 06:21:43 -0700 (PDT) Received: from mail115-co1-R.bigfish.com (10.243.78.230) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 13:21:43 +0000 Received: from mail115-co1 (localhost [127.0.0.1]) by mail115-co1-R.bigfish.com (Postfix) with ESMTP id 02EAA900155; Fri, 31 Aug 2012 13:21:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT005.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I542M1432I4015Izz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail115-co1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT005.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail115-co1 (localhost.localdomain [127.0.0.1]) by mail115-co1 (MessageSwitch) id 1346419301193147_19073; Fri, 31 Aug 2012 13:21:41 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.230]) by mail115-co1.bigfish.com (Postfix) with ESMTP id 2B18CC0048; Fri, 31 Aug 2012 13:21:41 +0000 (UTC) Received: from CH1PRD0410HT005.namprd04.prod.outlook.com (157.56.244.181) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 13:21:35 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT005.namprd04.prod.outlook.com ([10.255.147.40]) with mapi id 14.16.0190.008; Fri, 31 Aug 2012 13:21:34 +0000 From: Kelly Grizzle To: Kelly Grizzle , Eliot Lear , Dale Olds Thread-Topic: [scim] attribute selection in query responses Thread-Index: AQHNhj5unR2mt05hMEGCkGDwZVhYZ5dxi6YAgAAHA4CAAAGVgIAB2QmAgAAadoCAAGEu8IAAAVnA Date: Fri, 31 Aug 2012 13:21:33 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E02EF@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> <5040513F.5080806@rbcon.com> <50406771.3060702@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Trey Drake Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 13:21:45 -0000 Sorry for the misfire ... sent to early! ;) ... like this: "urn:scim:schemas:extension:enterprise:1.0": { "employeeNumber": "701984", "costCenter": "4130", "organization": "Universal Studios", "division": "Theme Park", "department": "Tour Operations", "manager": { "managerId": "26118915-6090-4610-87e4-49d8ca9f808d", "displayName": "John Smith" } } --Kelly -----Original Message----- From: Kelly Grizzle=20 Sent: Friday, August 31, 2012 8:20 AM To: 'Eliot Lear'; Dale Olds Cc: scim@ietf.org; Trey Drake Subject: RE: [scim] attribute selection in query responses SCIM does define an extension model, although it could be described more ex= plicitly in the spec. Section 4 of the core schema draft explains how to e= xtend a schema - http://tools.ietf.org/html/draft-ietf-scim-core-schema-00#= section-4. =20 You can see an example of how this is done in the enterprise user extension= representation - http://tools.ietf.org/html/draft-ietf-scim-core-schema-00= #section-11.3. Note that the schemas attribute has declares use of the ent= erprise extension. The actual enterprise attributes are namespaced by the = schema URN, like this: -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Eli= ot Lear Sent: Friday, August 31, 2012 2:28 AM To: Dale Olds Cc: scim@ietf.org; Trey Drake Subject: Re: [scim] attribute selection in query responses Just along these lines, I'd like to strongly suggest to the working group t= hat we clearly describe the correct way for others to extend the use of SCI= M. XML is a natural for this with its use of namespaces. I'm not sufficie= ntly versed in JSON to say how it should be done that way, but I'm sure som= ething can be done, right? Eliot On 8/31/12 7:53 AM, Dale Olds wrote: > On more nit on this issue. It would also be useful for the example=20 > output in section 3.2.2 to reflect the union of minimal and requested=20 > attributes. > > Instead of this: > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen" > }, > { > "userName":"jsmith" > } > ] > } > > it should be (if I understand the minimal set of id, meta, and perhaps=20 > externalId correctly): > > HTTP/1.1 200 OK > Content-Type: application/json > > { > "totalResults":2, > "schemas":["urn:scim:schemas:core:1.0"], > "Resources":[ > { > "userName":"bjensen", > "id":"2819c223-7f76-453a-919d-413861904646", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41386 > 1904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > { > "userName":"jsmith" > "id":"3819c223-7f76-453a-919d-413861904647", > "meta":{ > "created":"2011-08-01T18:29:49.793Z", > "lastModified":"2011-08-01T18:29:49.793Z", > "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-41386 > 1904646", > > "version":"W\/\"a330bc54f0671c9\"" > } > } > ] > } > > > On 08/29/2012 06:39 PM, Trey Drake wrote: >> Yes. >> >> On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: >> >>> Thanks, Trey. Does the following updated paragraph give the correct=20 >>> meaning? >>> >>> Consumers MAY request a partial Resource representation on any=20 >>> operation that returns a Resource within the response by specifying=20 >>> the URL query parameter 'attributes'. When specified, each Resource=20 >>> returned MUST contain the attributes or Sub-Attributes explicitly=20 >>> requested in addition to the minimal set of Resource attributes, and=20 >>> no others. The query parameter 'attributes' value is a comma=20 >>> separated list of Resource attribute names in standard, attribute=20 >>> notation form (e.g. userName, name, emails). If no 'attributes' >>> parameter is given, a full Resource representation is returned. >>> >>> --Dale >>> >>> On 08/29/2012 06:09 PM, Trey Drake wrote: >>>> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>>> >>>>> I am looking at draft-ietf-scim-api-00, though I think this issue=20 >>>>> has not changed since the 1.0 and 1.1 API specs. Section 3.2.2=20 >>>>> shows an example query of: >>>>> >>>>> GET /Users?attributes=3DuserName >>>>> >>>>> In the example reply, the results include just the userName=20 >>>>> attribute of all users (since no filter was included). Section 3.7=20 >>>>> describes the use of the attributes parameter. >>>>> >>>>>> Consumers MAY request a partial Resource representation on any=20 >>>>>> operation that returns a Resource within the response by=20 >>>>>> specifying the URL query parameter 'attributes'. When specified,=20 >>>>>> each Resource returned MUST contain the minimal set of Resource=20 >>>>>> attributes and, MUST contain no other attributes or=20 >>>>>> Sub-Attributes than those explicitly requested. The query=20 >>>>>> parameter attributes value is a comma separated list of Resource=20 >>>>>> attribute names in standard,attribute notation=20 >>>>>> >>>>> te-notation>form >>>>>> >>>>>> (e.g. userName, name, emails). >>>>> My questions about this section: >>>>> >>>>> 1. If an attribute parameter is used to request a partial resource=20 >>>>> representation, does that mean lack of an attributes parameter=20 >>>>> means the full resource representation is returned? >>>> Yes*. I add the asterisk as the Service Provider may choose to=20 >>>> filter the set of returned attributes. >>>> >>>>> 2. If #1 is 'no', can a full representation be requested without=20 >>>>> knowing the attribute names beforehand? >>>> N/A >>>>> 3. the phrase "MUST contain the minimal set of Resource attributes=20 >>>>> and, MUST contain no other attributes or Sub-Attributes than those=20 >>>>> explicitly requested" only applies if the attribute parameter is=20 >>>>> given. I assume the minimal set of attributes is that referred to=20 >>>>> in section 3.2, but does that phrase mean union or intersection of=20 >>>>> minimal set and requested set? If I request attribute=3DuserName,=20 >>>>> should I get the id and metadata back with each resource? >>>>> >>>> Currently, it does specify the Service Provider return the id and=20 >>>> meta-data. We discussed considering meta-data akin to LDAP=20 >>>> operational attributes, but we didn't play that thought process out. >>>> >>>>> 4. If #3 is 'intersection', is there some way to specify that I=20 >>>>> want the requested attribute + whatever the service provider=20 >>>>> defines as the minimal set? >>>>> >>>> N/A >>>>> --Dale >>>> Thanks, >>>> Trey >>>>> _______________________________________________ >>>>> scim mailing list >>>>> scim@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim > > _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Fri Aug 31 06:51:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79DF21F8623 for ; Fri, 31 Aug 2012 06:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.779 X-Spam-Level: X-Spam-Status: No, score=-3.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMjECRZjcEEQ for ; Fri, 31 Aug 2012 06:51:27 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id BE22521F8622 for ; Fri, 31 Aug 2012 06:51:27 -0700 (PDT) Received: from mail120-ch1-R.bigfish.com (10.43.68.226) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 13:51:27 +0000 Received: from mail120-ch1 (localhost [127.0.0.1]) by mail120-ch1-R.bigfish.com (Postfix) with ESMTP id 39DF83A0143; Fri, 31 Aug 2012 13:51:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: PS-31(zz98dI9371I617I936eI1521I542M1432Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail120-ch1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail120-ch1 (localhost.localdomain [127.0.0.1]) by mail120-ch1 (MessageSwitch) id 1346421084447328_20102; Fri, 31 Aug 2012 13:51:24 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail120-ch1.bigfish.com (Postfix) with ESMTP id 60EFB3E0047; Fri, 31 Aug 2012 13:51:24 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 13:51:23 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0190.008; Fri, 31 Aug 2012 13:51:23 +0000 From: Kelly Grizzle To: Phil Hunt , scim WG Thread-Topic: [scim] Conditional Patch Thread-Index: AQHNhi1o+mhZI1bx1UWIeUFk6wF2VZdx4OYAgAAH4QCAAP5egIABBnkQ Date: Fri, 31 Aug 2012 13:51:22 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E0335@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <82D996E8-D525-42A5-9155-3701DEDFDB33@oracle.com> In-Reply-To: <82D996E8-D525-42A5-9155-3701DEDFDB33@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.182.10.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 13:51:31 -0000 Yes - I have looked at this also and think there is some good stuff here. = It is similar to what Ganesh proposed for PATCH but limits the verbs and (a= s you pointed out) relies on JSON Pointer rather than unique identifiers. I agree that JSON Pointer may not be the way to go. My primary concern is = the use of indexes to address list elements (this is always where things ge= t tricky, isn't it?) since list indexes are not very stable. In your password example this could look more like: PATCH /Users/phunt321 { "schemas":" .... ", =20 "commands": [ { "operation": "replace", "attribute": "password", "value": "newpassword", "previousValue": "oldvalue" } ] } I think something like this would be cleaner than the current use of meta.a= ttributes and operation=3D"delete", and would lend itself better to extensi= ons like you are proposing. --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Phi= l Hunt Sent: Thursday, August 30, 2012 4:52 PM To: scim WG Subject: Re: [scim] Conditional Patch Murray and Leif suggested taking a look at: draft-ietf-appsawg-json-patch - http://tools.ietf.org/html/draft-ietf-appsa= wg-json-patch-02 The spec seems relatively simple and might improve the overall PATCH operat= ion.=20 My only concern is that the spec is based on another spec JSON Pointer (htt= p://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01) JSON Pointer is good for straight forward JSON structures, however it ends = up being a bit like XML Paths. I wonder if a version of this where we use j= ust attributes wouldn't work even better. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-29, at 11:42 PM, Phil Hunt wrote: > Also on the URL, the condition would apply to the entire operation rather= than just one particular attribute. =20 >=20 > Both could be useful though.=20 >=20 > Phil >=20 > On 2012-08-29, at 23:13, Samuel Erdtman wrote: >=20 >> Interesting, another way to do the same thing but without cluttering=20 >> the resource representation would be to put the filter part in the=20 >> query instead of within the resource-object, this would in addition=20 >> to allow conditional updates of one user allow for updates of all=20 >> users matching a certain criteria. >>=20 >> To update the title of all Tour Guides: >> PATCH /Users?filter=3Dtitle eq "Tour Guide", { >> "title": "Tour Master", >> } >>=20 >> To update the title of one specific Tour Guide if he is a tour guide=20 >> PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", { >> "title": "Tour Guide Manager", >> } >>=20 >> To update one users password if that user is active PATCH=20 >> /Users?filter=3Did eq "saerd" and active eq "true", { >> "password": "newvalue", >> } >>=20 >> Thoughts? >>=20 >> Cheers >> //Samuel >>=20 >>=20 >>=20 >> On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt wrote= : >>> Folks, >>>=20 >>> I know there has been a lot of discussion about modifying the patch com= mand to make it easier to read. A new requirement came up that seems more = generally useful, especially in cross domain scenarios. >>>=20 >>> Issue, sometimes when you modify an attribute you want to confirm the s= tate of an attribute (or set) before completing the operation. This could = be done with a search, but the preference would be to do it in a single ope= ration. >>>=20 >>> Let me take the (somewhat horrible) example of modifying passwords (it = could be anything else). Before modifying the password, you want to confir= m the old password is a match. >>>=20 >>> This could be expressed in a couple of ways: >>>=20 >>> Option 1 - replace old value >>>=20 >>> PATCH /Users/phunt321 >>>=20 >>> { "schemas": "......", >>>=20 >>> "password": {[ >>> {"value" : "oldpassword", >>> "operation" : "delete"} >>> {"value":"newpassword"} >>> ]} >>> } >>>=20 >>> Issue --> if password is single valued, then treating as multi-valued m= ay make no sense unless we allow it. It can only really test if a pre-exis= ting value is present -- not that broadly useful. >>>=20 >>> Option 2 - a more generalized conditional modify >>>=20 >>> PATCH /Users/phunt321 >>> { >>> "schemas":" .... ", >>>=20 >>> "password": { >>> "value":"newpassword", >>> "condition":"filter=3Dpassword eq \"oldvalue\" and status eq \"active= \"", >>> "critical" : "true" >>> } >>>=20 >>> In the above example, the condition is a filter about the resource that= must match (in this case testing the old value matches and that status is = active). Critical indicates whether the entire PATCH fails if the filter do= es not match. >>>=20 >>> It seems that in the cross-domain cases there may be many times when we= can't assume full state of a resource is known. It may be reasonable in ma= ny cases (other than password setting), that the client may want to do a co= nditional patch in a single operation (as opposed to a query followed by a = modify). >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From phil.hunt@oracle.com Fri Aug 31 08:41:33 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1003921F8666 for ; Fri, 31 Aug 2012 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh-FxoKMc6Ai for ; Fri, 31 Aug 2012 08:41:31 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 782EC21F8652 for ; Fri, 31 Aug 2012 08:41:31 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q7VFfRq1012415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 31 Aug 2012 15:41:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q7VFfR7k013493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Aug 2012 15:41:27 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q7VFfRDx024581; Fri, 31 Aug 2012 10:41:27 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 31 Aug 2012 08:41:26 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <56C3C758F9D6534CA3778EAA1E0C3437330E0335@CH1PRD0410MB357.namprd04.prod.outlook.com> Date: Fri, 31 Aug 2012 08:41:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82D996E8-D525-42A5-9155-3701DEDFDB33@oracle.com> <56C3C758F9D6534CA3778EAA1E0C3437330E0335@CH1PRD0410MB357.namprd04.prod.outlook.com> To: Kelly Grizzle X-Mailer: Apple Mail (2.1278) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: scim WG Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:41:33 -0000 Agreed. Reliance on index position increases the amount of binding and = thus the chance of breakage as state between cross-domain entities is = likely to be more inconsistent over time.=20 The "replace" operation is useful in times when the client wants to be = sure about what value is being replaced. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-08-31, at 6:51 AM, Kelly Grizzle wrote: > Yes - I have looked at this also and think there is some good stuff = here. It is similar to what Ganesh proposed for PATCH but limits the = verbs and (as you pointed out) relies on JSON Pointer rather than unique = identifiers. >=20 > I agree that JSON Pointer may not be the way to go. My primary = concern is the use of indexes to address list elements (this is always = where things get tricky, isn't it?) since list indexes are not very = stable. >=20 > In your password example this could look more like: >=20 > PATCH /Users/phunt321 > { > "schemas":" .... ", >=20 > "commands": [ > { > "operation": "replace", > "attribute": "password", > "value": "newpassword", > "previousValue": "oldvalue" > } > ] > } >=20 > I think something like this would be cleaner than the current use of = meta.attributes and operation=3D"delete", and would lend itself better = to extensions like you are proposing. >=20 > --Kelly >=20 >=20 > -----Original Message----- > From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf = Of Phil Hunt > Sent: Thursday, August 30, 2012 4:52 PM > To: scim WG > Subject: Re: [scim] Conditional Patch >=20 > Murray and Leif suggested taking a look at: > draft-ietf-appsawg-json-patch - = http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02 >=20 > The spec seems relatively simple and might improve the overall PATCH = operation.=20 >=20 > My only concern is that the spec is based on another spec JSON Pointer = (http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-01) >=20 > JSON Pointer is good for straight forward JSON structures, however it = ends up being a bit like XML Paths. I wonder if a version of this where = we use just attributes wouldn't work even better. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-08-29, at 11:42 PM, Phil Hunt wrote: >=20 >> Also on the URL, the condition would apply to the entire operation = rather than just one particular attribute. =20 >>=20 >> Both could be useful though.=20 >>=20 >> Phil >>=20 >> On 2012-08-29, at 23:13, Samuel Erdtman wrote: >>=20 >>> Interesting, another way to do the same thing but without cluttering=20= >>> the resource representation would be to put the filter part in the=20= >>> query instead of within the resource-object, this would in addition=20= >>> to allow conditional updates of one user allow for updates of all=20 >>> users matching a certain criteria. >>>=20 >>> To update the title of all Tour Guides: >>> PATCH /Users?filter=3Dtitle eq "Tour Guide", { >>> "title": "Tour Master", >>> } >>>=20 >>> To update the title of one specific Tour Guide if he is a tour guide=20= >>> PATCH /Users?filter=3Did eq "saerd" and title eq "Tour Guide", { >>> "title": "Tour Guide Manager", >>> } >>>=20 >>> To update one users password if that user is active PATCH=20 >>> /Users?filter=3Did eq "saerd" and active eq "true", { >>> "password": "newvalue", >>> } >>>=20 >>> Thoughts? >>>=20 >>> Cheers >>> //Samuel >>>=20 >>>=20 >>>=20 >>> On Wed, Aug 29, 2012 at 11:29 PM, Phil Hunt = wrote: >>>> Folks, >>>>=20 >>>> I know there has been a lot of discussion about modifying the patch = command to make it easier to read. A new requirement came up that seems = more generally useful, especially in cross domain scenarios. >>>>=20 >>>> Issue, sometimes when you modify an attribute you want to confirm = the state of an attribute (or set) before completing the operation. = This could be done with a search, but the preference would be to do it = in a single operation. >>>>=20 >>>> Let me take the (somewhat horrible) example of modifying passwords = (it could be anything else). Before modifying the password, you want to = confirm the old password is a match. >>>>=20 >>>> This could be expressed in a couple of ways: >>>>=20 >>>> Option 1 - replace old value >>>>=20 >>>> PATCH /Users/phunt321 >>>>=20 >>>> { "schemas": "......", >>>>=20 >>>> "password": {[ >>>> {"value" : "oldpassword", >>>> "operation" : "delete"} >>>> {"value":"newpassword"} >>>> ]} >>>> } >>>>=20 >>>> Issue --> if password is single valued, then treating as = multi-valued may make no sense unless we allow it. It can only really = test if a pre-existing value is present -- not that broadly useful. >>>>=20 >>>> Option 2 - a more generalized conditional modify >>>>=20 >>>> PATCH /Users/phunt321 >>>> { >>>> "schemas":" .... ", >>>>=20 >>>> "password": { >>>> "value":"newpassword", >>>> "condition":"filter=3Dpassword eq \"oldvalue\" and status eq = \"active\"", >>>> "critical" : "true" >>>> } >>>>=20 >>>> In the above example, the condition is a filter about the resource = that must match (in this case testing the old value matches and that = status is active). Critical indicates whether the entire PATCH fails if = the filter does not match. >>>>=20 >>>> It seems that in the cross-domain cases there may be many times = when we can't assume full state of a resource is known. It may be = reasonable in many cases (other than password setting), that the client = may want to do a conditional patch in a single operation (as opposed to = a query followed by a modify). >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim >>> _______________________________________________ >>> scim mailing list >>> scim@ietf.org >>> https://www.ietf.org/mailman/listinfo/scim >> _______________________________________________ >> scim mailing list >> scim@ietf.org >> https://www.ietf.org/mailman/listinfo/scim >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim >=20 >=20 > _______________________________________________ > scim mailing list > scim@ietf.org > https://www.ietf.org/mailman/listinfo/scim From kelly.grizzle@sailpoint.com Fri Aug 31 10:35:46 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58E621F861C for ; Fri, 31 Aug 2012 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMo+zORfwHRP for ; Fri, 31 Aug 2012 10:35:46 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 776BE21F8618 for ; Fri, 31 Aug 2012 10:35:45 -0700 (PDT) Received: from mail31-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 17:35:44 +0000 Received: from mail31-am1 (localhost [127.0.0.1]) by mail31-am1-R.bigfish.com (Postfix) with ESMTP id DE6FBA028B; Fri, 31 Aug 2012 17:35:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.181; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0410HT001.namprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zzbb2dI98dI9371I542M1432I4015Izz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h944hd25hf0ah107ah1220h1155h) Received-SPF: pass (mail31-am1: domain of sailpoint.com designates 157.56.244.181 as permitted sender) client-ip=157.56.244.181; envelope-from=kelly.grizzle@sailpoint.com; helo=CH1PRD0410HT001.namprd04.prod.outlook.com ; .outlook.com ; Received: from mail31-am1 (localhost.localdomain [127.0.0.1]) by mail31-am1 (MessageSwitch) id 1346434542226740_14784; Fri, 31 Aug 2012 17:35:42 +0000 (UTC) Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.226]) by mail31-am1.bigfish.com (Postfix) with ESMTP id 2BB15400044; Fri, 31 Aug 2012 17:35:42 +0000 (UTC) Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 17:35:40 +0000 Received: from CH1PRD0410MB357.namprd04.prod.outlook.com ([169.254.4.160]) by CH1PRD0410HT001.namprd04.prod.outlook.com ([10.255.147.36]) with mapi id 14.16.0190.008; Fri, 31 Aug 2012 17:35:40 +0000 From: Kelly Grizzle To: Dale Olds , Trey Drake Thread-Topic: [scim] attribute selection in query responses Thread-Index: AQHNhj5unR2mt05hMEGCkGDwZVhYZ5dxi6YAgAAHA4CAAAGVgIAB2QmAgADD5rA= Date: Fri, 31 Aug 2012 17:35:40 +0000 Message-ID: <56C3C758F9D6534CA3778EAA1E0C3437330E05C9@CH1PRD0410MB357.namprd04.prod.outlook.com> References: <503EA5FF.7030102@rbcon.com> <617D0646-D595-4656-A819-C27AF6417161@unboundid.com> <503EC31B.5070200@rbcon.com> <446BBF88-04EA-400A-BFB4-67E4B1D86FB1@unboundid.com> <5040513F.5080806@rbcon.com> In-Reply-To: <5040513F.5080806@rbcon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.226.147.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sailpoint.com Cc: "scim@ietf.org" , Melinda Shore Subject: Re: [scim] attribute selection in query responses X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 17:35:46 -0000 I agree with both the new text and the need for the minimal attributes in t= he example. Melinda, could you please add this to the tracker when you get= a chance? --Kelly -----Original Message----- From: scim-bounces@ietf.org [mailto:scim-bounces@ietf.org] On Behalf Of Dal= e Olds Sent: Friday, August 31, 2012 12:53 AM To: Trey Drake Cc: scim@ietf.org Subject: Re: [scim] attribute selection in query responses On more nit on this issue. It would also be useful for the example output i= n section 3.2.2 to reflect the union of minimal and requested attributes. Instead of this: HTTP/1.1 200 OK Content-Type: application/json { "totalResults":2, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ { "userName":"bjensen" }, { "userName":"jsmith" } ] } it should be (if I understand the minimal set of id, meta, and perhaps exte= rnalId correctly): HTTP/1.1 200 OK Content-Type: application/json { "totalResults":2, "schemas":["urn:scim:schemas:core:1.0"], "Resources":[ { "userName":"bjensen", "id":"2819c223-7f76-453a-919d-413861904646", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-4138619046= 46", "version":"W\/\"a330bc54f0671c9\"" } { "userName":"jsmith" "id":"3819c223-7f76-453a-919d-413861904647", "meta":{ "created":"2011-08-01T18:29:49.793Z", "lastModified":"2011-08-01T18:29:49.793Z", "location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-4138619046= 46", "version":"W\/\"a330bc54f0671c9\"" } } ] } On 08/29/2012 06:39 PM, Trey Drake wrote: > Yes. > > On Aug 29, 2012, at 8:34 PM, Dale Olds wrote: > >> Thanks, Trey. Does the following updated paragraph give the correct mean= ing? >> >> Consumers MAY request a partial Resource representation on any operation= that returns a Resource within the response by specifying the URL query pa= rameter 'attributes'. When specified, each Resource returned MUST contain t= he attributes or Sub-Attributes explicitly requested in addition to the min= imal set of Resource attributes, and no others. The query parameter 'attrib= utes' value is a comma separated list of Resource attribute names in standa= rd, attribute notation form (e.g. userName, name, emails). If no 'attribute= s' parameter is given, a full Resource representation is returned. >> >> --Dale >> >> On 08/29/2012 06:09 PM, Trey Drake wrote: >>> On Aug 29, 2012, at 6:30 PM, Dale Olds wrote: >>> >>>> I am looking at draft-ietf-scim-api-00, though I think this issue has = not changed since the 1.0 and 1.1 API specs. Section 3.2.2 shows an example= query of: >>>> >>>> GET /Users?attributes=3DuserName >>>> >>>> In the example reply, the results include just the userName attribute = of all users (since no filter was included). Section 3.7 describes the use = of the attributes parameter. >>>> >>>>> Consumers MAY request a partial Resource representation on any=20 >>>>> operation that returns a Resource within the response by=20 >>>>> specifying the URL query parameter 'attributes'. When specified,=20 >>>>> each Resource returned MUST contain the minimal set of Resource=20 >>>>> attributes and, MUST contain no other attributes or Sub-Attributes=20 >>>>> than those explicitly requested. The query parameter attributes=20 >>>>> value is a comma separated list of Resource attribute names in=20 >>>>> standard,attribute notation=20 >>>>> >>>> e-notation>form >>>>> (e.g. userName, name, emails). >>>> My questions about this section: >>>> >>>> 1. If an attribute parameter is used to request a partial resource rep= resentation, does that mean lack of an attributes parameter means the full = resource representation is returned? >>> Yes*. I add the asterisk as the Service Provider may choose to filter = the set of returned attributes. >>> >>>> 2. If #1 is 'no', can a full representation be requested without knowi= ng the attribute names beforehand? >>> N/A >>>> 3. the phrase "MUST contain the minimal set of Resource attributes and= , MUST contain no other attributes or Sub-Attributes than those explicitly = requested" only applies if the attribute parameter is given. I assume the m= inimal set of attributes is that referred to in section 3.2, but does that = phrase mean union or intersection of minimal set and requested set? If I re= quest attribute=3DuserName, should I get the id and metadata back with each= resource? >>>> >>> Currently, it does specify the Service Provider return the id and meta-= data. We discussed considering meta-data akin to LDAP operational attribut= es, but we didn't play that thought process out. >>> >>>> 4. If #3 is 'intersection', is there some way to specify that I want t= he requested attribute + whatever the service provider defines as the minim= al set? >>>> >>> N/A >>>> --Dale >>> Thanks, >>> Trey >>>> _______________________________________________ >>>> scim mailing list >>>> scim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/scim _______________________________________________ scim mailing list scim@ietf.org https://www.ietf.org/mailman/listinfo/scim From olds@rbcon.com Fri Aug 31 14:59:30 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA8A521F84A6 for ; Fri, 31 Aug 2012 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAcdfGgXW1hd for ; Fri, 31 Aug 2012 14:59:29 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C070B21F84AE for ; Fri, 31 Aug 2012 14:59:29 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5264907pbb.31 for ; Fri, 31 Aug 2012 14:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=zXzb/iygmo+cxAGPDrwoYUXeW7QI8q5LwcT6gYrqN1g=; b=NsI58LngQOSRq8KnjN5BySXuaOfN2Dt/YGrrRAKAufM+ttxkYJw2GmKfrO0+CtQOvC SKeK82mKLNTw90du0z5gUbL0PkT6znrejlVooMgeGh5OnBsce6s/s2oYMPGP9dW47n6j LkON5urYo0CAkwmhjaS9rD6ro7A/9GQvHcc8iYPME18/0q31u0poG4bebtXOLiuI4NeC Ct4S2Hjk5a1MqkgQf8iv5t9/1YcOEiPyv1M64lnzeQij75+hZhUzKLe0dsCbn8/rrZ5Q NwB1gSB8CbOPcTet2ULt+s4gDWY3ivGgw9mkE5jdvfs8cFu0RHD59pvRa/kEg+mQ//ka wvCw== Received: by 10.66.75.73 with SMTP id a9mr17683724paw.43.1346450369391; Fri, 31 Aug 2012 14:59:29 -0700 (PDT) Received: from [192.168.0.23] (c-174-62-80-224.hsd1.ca.comcast.net. [174.62.80.224]) by mx.google.com with ESMTPS id qn3sm4236607pbc.6.2012.08.31.14.59.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 31 Aug 2012 14:59:28 -0700 (PDT) Message-ID: <504133BE.4020704@rbcon.com> Date: Fri, 31 Aug 2012 14:59:26 -0700 From: Dale Olds User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "scim@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkxSetuzDTuwN0EjgnNUo8QJPcilaYcEQKsd2ob2YMahqYZLfZRQ8Yb0vmAIefIaELBmhS6 Subject: [scim] userids, usernames, and group names X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 21:59:30 -0000 In our scim implementation we assign the following meanings to these user attributes: * id: unique, immutable, required, not intended to be typed by humans. The only identifier safe to store in external systems. * userName: unique, mutable, required, though rarely changed in practice, not localized -- more like a keyword. It's what humans can use when they need to type in a reference to a user. * displayName: not unique, mutable, optional, used as input to some display context but might not be literally displayed. Access control for the id and userName fields is identical -- they are both essentially treated as identifiers, displayName is different. These meanings work for us. All 3 attributes are used for specific purposes, and I believe our use does not violate the current spec. BTW, thanks for changing userName to be mutable in 1.1. We are now implementing groups. IIRC, the only choice the spec gives for human readable group names is displayName, but we have tools (e.g. CLIs) that need to accept a reference to a group typed in by a user. We could use displayName for that purpose, but then we lose the displayName capability that we have for users. I've checked for this issue in the list archives but did not see any discussion. Has the group discussed a naming attribute for groups that would be more like userName than displayName? A related issue is compound attributes such as Users.groups and Groups.members. If Groups had groupName attribute similar to userName for users, it would be most useful if these attributes could have sub-attributes like this: User: { id: 111111 userName: 'joe' groups: [{display: 'Hiking Tour Guides', name: 'guides', value: 22222}] } Group: { id: 22222 groupName: 'guides' members: [{display: 'Joey', name: 'joe', value: 11111}] } I suppose we could add this capability as an extension, but would like to see if others would find this useful as well. --Dale From g.c.prasad@gmail.com Fri Aug 31 17:32:55 2012 Return-Path: X-Original-To: scim@ietfa.amsl.com Delivered-To: scim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B102421F8471 for ; Fri, 31 Aug 2012 17:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxhs34e2Bo5e for ; Fri, 31 Aug 2012 17:32:54 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9D21F846F for ; Fri, 31 Aug 2012 17:32:54 -0700 (PDT) Received: by bkty12 with SMTP id y12so1532460bkt.31 for ; Fri, 31 Aug 2012 17:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=cQRAWv+R2wgeoTsVm1KruSxwGlhxqhGslnc92EoNWc8=; b=SDeMvW8q73WSgwEk4aNPs0MsK/QQpcF4LyRthkSihtM/zHVBXdHA26dA/EGWXTM1H7 g0r9GH98iftpA2j87mVty7IhKEtA2vQgj6Sq/oJesEl5LB34F5MJYGHNswKwScA23wYE uUbUYRh5ZGjvq/klyv50Qwe8aCm8SMq21gwYSJm6i1fq2kAywTrIDLyfP/Wgj/N0XAZ9 Sno6aB3ExGAzIK2bK5KOwkpiRojc4plU8nRXUIyS7VWSREY0GkOYpP+lcKc2zS0wJquL ZgVcBKxSO1KY0WTJe+GsSg4GxAetodTQEa17NGuHB92thLEnX8cv8KUyEzRu4BUf19oG UgNw== Received: by 10.204.152.137 with SMTP id g9mr4951150bkw.106.1346459573261; Fri, 31 Aug 2012 17:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.185.195 with HTTP; Fri, 31 Aug 2012 17:32:32 -0700 (PDT) From: Ganesh and Sashi Prasad Date: Sat, 1 Sep 2012 10:32:32 +1000 Message-ID: To: scim@ietf.org Content-Type: multipart/alternative; boundary=0015175cf76491966c04c8990c30 Subject: Re: [scim] Conditional Patch X-BeenThere: scim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Simple Cloud Identity Management BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 00:32:55 -0000 --0015175cf76491966c04c8990c30 Content-Type: text/plain; charset=ISO-8859-1 Kelly Grizzle wrote: > Yes - I have looked at this also and think there is some good stuff here. It is similar to what Ganesh proposed for PATCH but limits the verbs and (as you pointed out) relies > on JSON Pointer rather than unique identifiers. > I agree that JSON Pointer may not be the way to go. My primary concern is the use of indexes to address list elements (this is always where things get tricky, isn't it?) > since list indexes are not very stable. I have been following Leif's advice to write up an Internet Draft and it is underway, but I thought I would share my thinking early on two aspects. 1. I take on board the requirement to support _some_ multi-valued attributes, but I would also like to combine that with addressability for all values. So my ideal data structures are now three: a) Nested dictionaries, where every value has its own key { "fully" : { "qualified" : { "key" : "value" } } } Example of reference: "fully.qualified.key" b) Fixed-length arrays, where the index can be assumed to be stable "timesheet" : [ "8.0", "8.0", "4.0", "0.0", "8.0"] Example of reference: "timesheet[2]" c) Sets, where all values in the list are assumed to be unique (they should also be simple, i.e., whole numbers or strings, not dictionaries or arrays) "categories" : ["drama", "action", "comedy"] Example of reference: "categories.drama" (All other lists will unfortunately have to be turned into dictionaries with server-generated keys, which could be in sequence if order is important.) Now we can still use the 5 simple (and unambiguous) verbs (INCLUDE, PLACE, REPLACE, FORCE and RETIRE) to manipulate the resource at any level of granularity. 2. I wonder why there is a special key called "meta". Isn't everything meta-information, except the resource itself? I see the document as a soup of meta-tags, with just one of them referring to the resource representation. So this turns the model inside-out, so to speak. If we do this, conditional expressions can be painlessly introduced. An example may illustrate what I'm thinking. (Ignore the leading underscores - I'm using that as a conventional for the protocol's own keywords and server-generated keys as opposed to the resource's original keys.) Assume a resource (/Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a) with this structure: { "item" : "automobile", "parts" : { "_40e1f8b2101b" : "wheels", "_63ac7da834ff" : "engine", "_9d7e0fcc70a3" : "upholstery", "_a2ff51106dea" : "body" }, "price" : { "currency" : "AUD", "amount" : "10.00" } } A conditional update of the price could look like this: PATCH /Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a { "_verb" : "REPLACE", "_key" : "price.amount", "_expected" : "< 15.00", "_value" : "15.00" }, We can also think of a separate "_condition" tag that refers to any expression, not just the value of the attribute being updated. Regards, Ganesh --0015175cf76491966c04c8990c30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kelly Grizzle wrote:
>=A0Yes = - I have looked at this also and think there is some good stuff here. =A0It= is similar to what Ganesh proposed for PATCH but limits the verbs and (as = you pointed out) relies=A0
> on JSON Pointer rather tha= n unique identifiers.

> I agree that JSON Pointer may n= ot be the way to go. =A0My primary concern is the use of indexes to address= list elements (this is always where things get tricky, isn't it?)=A0
> since list indexes are not very= stable.

I have been follow= ing Leif's advice to write up an Internet Draft and it is underway, but= I thought I would share my thinking early on two aspects.

1. I take on board the requirement to support= _some_ multi-valued attributes, but I would also like to combine that with= addressability for all values. So my ideal data structures are now three:<= /span>

a) Nested dictionaries, where every value has= its own key=A0
{ "fully" : { "q= ualified" : { "key" : "value" } } }
Example of reference: "ful= ly.qualified.key"

b) Fixed-length ar= rays, where the index can be assumed to be stable
"timesheet" : [ "8.0", &= quot;8.0", "4.0", "0.0", "8.0"]
Example of reference: "tim= esheet[2]"
c) Sets, where all= values in the list are assumed to be unique (they should also be simple, i= .e., whole numbers or strings, not dictionaries or arrays)
"categories" : ["= ;drama", "action", "comedy"]
Example of reference: "categories.d= rama"

(All other lists will unfortunately have to b= e turned into dictionaries with server-generated keys, which could be in se= quence if order is important.)

Now we can still use the 5 simple (and unambi= guous) verbs (INCLUDE, PLACE, REPLACE, FORCE and RETIRE) to manipulate the = resource at any level of granularity.

2. I wonder why there is a special key called= "meta". Isn't everything meta-information, except the resour= ce itself? I see the document as a soup of meta-tags, with just one of them= referring to the resource representation. So this turns the model inside-o= ut, so to speak.

If we do this, conditional expressions can be= painlessly introduced.=A0An = example may illustrate what I'm thinking. (Ignore the leading underscor= es - I'm using that as a conventional for the protocol's own keywor= ds and server-generated keys as opposed to the resource's original keys= .)

Assume a resource (/Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a) with this structure:

{
=A0 =A0 "item" : "automobile",
= =A0 =A0 "parts" : {
=A0 =A0 =A0 =A0 "_40e1f8b2101b= " : "wheels",=A0
=A0 =A0 =A0 =A0 "_63ac7da834= ff" : "engine",=A0
=A0 =A0 =A0 =A0 "_9d7e0fcc70a3" : "upholstery",
=A0 =A0 =A0 =A0 "_a2ff51106dea" : "body"
<= div>=A0 =A0 },
=A0 =A0 "price" : {
=A0 =A0 = =A0 =A0 "currency" : "AUD",
=A0 =A0 =A0 =A0 "amount" : "10.00"
=A0 = =A0 }
}

A conditional update of the price could look like this:=

PATCH /Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a

{
=A0 =A0 "_verb" : "REPLACE",
=A0 = =A0 "_key" : "price.amount",
=A0 =A0 "_e= xpected" : "< 15.00",
=A0 =A0 "_value"= ; : "15.00"
},

We can also think of a separate "_con= dition" tag that refers to any expression, not just the value of the a= ttribute being updated.

Regards,
Ganesh<= /div>
--0015175cf76491966c04c8990c30-- 

The iss=
ue being raised here isn't endpoint logic, but
network traffic, and I'm pretty sure it's not very helpful to
respond to the observation that your model requires more
messages with a complaint about what you seem to think is a
complex algorithm for attribute processing.

It depends on how it's implemented. I'm c= onfident we can have the best of both - simple API with low-overhead implem= entation. Can we brainstorm HOW this proposal can be implemented rather tha= n WHY it can't be implemented (which is mostly what I've been heari= ng so far)? After all, no one has challenged the claim that this proposal d= rastically simplifies the API for the client, so it would appear to be wort= h doing.=A0I'm sure there's more than enough intellectual horsepowe= r in this working group to pull this off if we put our minds to it.

Regards,
Ganesh

On 13 August 2012 13:54, Ganesh and Sashi Prasad &= lt;g.c.prasad@gma= il.com> wrote:
>=A0I strongly object t= o anything that leads to a read before modify requirement. Too complex and = too chatty.

Sorry Phil, but you're contradicting yourself here.=A0There s= eems to be an awful lot of matching (i.e., reading) going on in the spec as= it stands, with if-then clauses to do one thing or another if the match ei= ther succeeds or fails. This is a complex, chatty protocol right now!

   Multi-valued attributes:  An attribute value in the PATCH request
      body is added to the value collection if the value does not exist
      and merged if a matching value is present.  Values are matched by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute; e.g., addresses, or do not have unique
      value Sub-Attributes cannot be matched and must instead be deleted
      then added.  Specific values can be removed from a Resource by
      adding an "operation" Sub-Attribute with the value "de=
lete" to the
      attribute in the PATCH request body.  As with adding/updating
      attribute value collections, the value to delete is determined by
      comparing the value Sub-Attribute from the PATCH request body to
      the value Sub-Attribute of the Resource.  Attributes that do not
      have a value Sub-Attribute or that have a non-unique value Sub-
      Attribute are matched by comparing all Sub-Attribute values from
      the PATCH request body to the Sub-Attribute values of the
      Resource.  A delete operation is ignored if the attribute's name
      is in the meta.attributes list.  If the requested value to delete
      does not match a unique value on the Resource the server MAY
      return a HTTP 400 error.

For a spec that is supposed to be about sim= plicity, the above description is anything but simple. I know you guys have= worked hard on this and I don't mean to disparage those efforts, but t= hink about how the above passage would appear to a new reader (i.e., a novi= ce to the spec, not a technology novice).

There is something fundamentally broken, and it is this= : multi-valued attributes without a unique identifier per value. If you don= 't fix that, you won't get simplicity.

We know LDAP trees are broken for multi-valued attributes. As Mark Wahl famously commented back in 2005,

"= ;Unfortunately, some of the emerging protocols which als= o intend to represent and transfer personal identity information have perha= ps taken a step backwards by not even considering these issues, perhaps swe= eping them under the rug in the guise of simplicity, XMLification, or "= ;fix in the next version", which only postpone finding interoperable s= olutions to allowing applications to express the identity entries they want= to express."

SCIM is exactly one of these "emerging protocols&q= uot; Wahl talks about, and what I see now strikes me as "sweeping thes= e issues under the rug in the guise of simplicity". Apologies for the = bluntness.

My take is that SPs are _already_ struggling to manage = multi-valued attributes, and existin= g mechanisms are clumsy. They would be grateful for a specification tha= t made operations easier at the cost of a re-engineered schema. That calls = for some thought leadership from this working group.

Regards,
Ganesh

On 13 August 2012 10:13, Phil Hunt <phil.hu= nt@oracle.com> wrote:
I strongly obj= ect to anything that leads to a read before modify requirement. Too complex= and too chatty.=A0

Phil

On 2012-08-12, at 15:29, Gan= esh and Sashi Prasad <g.c.prasad@gmail.com> wrote:

=

> Would it have to be stored on the accoun= t database of the service provider?

=A0=

Y= es.


> If so, I believe that this is impracticable= in the core schema.=A0Indeed it= implies that a service provider must extend the schema of his account repo= sitory (LDAP partition, SQL db, =85) and =93prepare it=94 for SCIM integrat= ion.


Why? That doesn't necessarily follow. Implementatio= n is independent of representation. We're talking about a change in rep= resentation to make the API cleaner.

As a simple e= xample, if an LDAP node is being used to hold a list of comma-separated ema= il addresses, it can just as easily store comma-separated name-value pairs.=

<= div>
mail:=A0aa66-daf9ea3bd902=3Djohn_smith@yahoo.com= ,9cda-8646c3085bbf=3Djohn.smith@gmail.com,=A07a6d1de664e1=3Djsmith1970@hotmail.com

That's why I asked if there was an S= P representative on this working group who could explain what such a change= could mean for them. As of now, it looks like other people are presuming t= hat SPs will not be able to implement these changes easily and are rejectin= g them for that reason.

Regards,
Ganesh

On 13 August 2012 04:29, Emmanuel Dreux <= span dir=3D"ltr"><edreux@cloudiway.com> wrote:

=F0=A0 addresses.3cbaaff8e84e.str= eet-number =3D "243"

=A0=

Where woul= d 3cbaaff8e84e come from? Would it have to be stored= on the account database of the service provider?

= =A0

If so, = I believe that this is impracticable in the core schema. Indeed it implies = that a service provider must extend the schema of his account repository (L= DAP partition, SQL db, =85) and =93prepare it=94 for SCIM integration.

This wo= uld be a show stopper. SCIM must be transparent, and must be able to be put= on top of an existing system to provide provisioning apis.

= =A0

Said di= fferently, SCIM must not be intrusive for existing systems and must not req= uire modifications to allow its integration.

Correct= me if I misunderstood your suggestion.

= =A0

--<= u>

Regards,

Emmanuel Dreux<= /u>

http://www.cloudiway.com

Tel: +33 4 26= 78 17 58

Mobile: +33 6= 47 81 26 70

skype: Emmanuel.Dreux<= /u>

=A0<= /p>

De=A0: Ganesh = and Sashi Prasad [mailto:g.c.prasad@gmail.com]
Envoy=E9=A0: dimanche 12 ao=FBt 2012 04:53
=C0=A0: Kelly Grizzle
Cc=A0: scim@ietf.= org; Phil Hunt
Objet=A0: Re: [scim] scim Digest, Vol 8, Issue 24

=A0

>=A0 Multi-valued attributes that don't have a value sub-attribute (eg - add= ress) have to specified completely for uniqueness.=A0=A0

=A0

That's exactly the point. How do we "specif= y completely for uniqueness"?

=A0

In the example below, how are you proposing that the= following element be updated if we can't use positional indexes?

=A0

addresses[1].street-number =3D "243"

=A0

User object:

=A0

{

=A0 ...

=A0 addresses: [

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 ]

}

=A0

It's impractical to use the value because it'= ;s the whole dictionary element:

=A0

{

=A0 "type" : "office",=

=A0 "street-number" : "213",<= /u>

=A0 "street-name" : "Main Street"= ;,

=A0 "suburb" : "Adelaide",

=A0 "postcode" : "5000",<= u>

=A0 "state" : "SA",

=A0 "country" : "Australia"

}

=A0

With my proposal, the "addresses" array ge= ts converted to a dictionary, and then we have a stable way of referencing = this element:

=A0

addresses.3cbaaff8e84e.street-number =3D "243&q= uot;

=A0

{

=A0 ...

=A0 addresses: {

=A0 =A0 "d6ea365462f5" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "home",<= /u>

=A0 =A0 =A0 "street-number" : "35&quo= t;,

=A0 =A0 =A0 "street-name" : "High Roa= d",

=A0 =A0 =A0 "suburb" : "East Camden&q= uot;,

=A0 =A0 =A0 "postcode" : "5346",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 },

=A0 =A0 "3cbaaff8e84e" :

=A0 =A0 {

=A0 =A0 =A0 "type" : "office",

=A0 =A0 =A0 "street-number" : "213&qu= ot;,

=A0 =A0 =A0 "street-name" : "Main Str= eet",

=A0 =A0 =A0 "suburb" : "Adelaide"= ;,

=A0 =A0 =A0 "postcode" : "5000",=

=A0 =A0 =A0 "state" : "SA",

=A0 =A0 =A0 "country" : "Australia&qu= ot;

=A0 =A0 }

=A0 }

}

=A0

If you're proposing one mechanism for composite = attributes and another mechanism for simple attributes, I would suggest tha= t's actually more complex than adopting a single mechanism that works t= he same way for _all_ attributes. Remember that a lot of the administration is probably going to be scripted rather t= han done by hand, and having two mechanisms (depending on whether the attri= bute is simple or composite) will complicate every script that has to be wr= itten.

=A0

There's a lot of talk about the "burden&quo= t; on the SPs, but I believe this is overblown. Is there any SP representat= ive in this WG who can tell us what this proposal will actually entail for = them?

=A0

Regards,

Ganesh

=A0

On 12 August 2012 11:53, Kelly Grizzle <kelly.grizzle@sai= lpoint.com> wrote:

Ganesh,

=A0

This is exactly how PATCH works in SCIM = 1.0. =A0Multi-valued attributes that have a value sub-attribute can be remo= ved by specifying only the value since it is unique. =A0Multi-valued attributes that don't have a value sub-attribute (eg - address) have t= o specified completely for uniqueness. =A0As I have said before, I am very = opposed to adding a unique identifier to each element in a multi-valued col= lection due to the burden it will put on SPs. =A0Is it elegant? =A0No. =A0Is it functional? =A0Yes. =A0Will this= non-elegance affect adoption? =A0My opinion is that adding unique keys to = each element will have a much more detrimental effect on adoption.

=A0

I do believe that in general PATCH can b= e made more intuitive without adding uids to each element. =A0The verbs tha= t you propose make sense. =A0There is also a JSON Patch informational draft in the IETF that is interesting -=A0http://tools.ietf= .org/html/draft-ietf-appsawg-json-patch-02. =A0It relies on a JSON Poin= ter draft which uses index-based addressing for multi-valued attributes. =A0I think that this is something that should= be looked at within the WG and I would be willing to lead this effort.<= /u>

=A0

I'm curious if anyone else in the WG= is in favor of unique identifiers for every multi-valued element.

=A0

--Kelly

=A0

From: scim-bounces@iet= f.org [scim-= bounces@ietf.org] on behalf of Ganesh and Sashi Prasad [g.c.prasad@gmail.com]
Sent: Saturday, August 11, 2012 10:50 AM
To: Phil Hunt
Cc: scim@ietf.org=
Subject: Re: [scim] scim Digest, Vol 8, Issue 24

Phil,

=A0

The reason we cannot use the value itself to identif= y an element is that this method will only work for simple elements, not fo= r nested structures. i.e., if we had an array of dictionaries (e.g., we had= to record an array of addresses for each customer, with each address element having sub-elements like street n= umber, street name, suburb, etc.), then it would be clumsy to supply the en= tire value of the array element because it's itself a dictionary. Creat= ing a unique key for each element scales better.

=A0

Regards,

Ganesh<= /p>

On 12 August 2012 01:12, Phil Hunt <phil.hunt@oracle.com> w= rote:

Ganesh,

=A0

Here's the sample that concerned me...=

The two operations differ significantly, and it'= s not very intuitive.=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }

=A0

=A0

You gave other examples of an attribute with an identifier = that matched that value or of identifiers that were additional unique keys.=

=A0

Given that multi-values must be each unique, I don't se= e the point of the extra indexing to support this. Just use the value as th= e item you wish to delete.

=A0

I agree, the delete value operation could be more explicit = and clear in general.

=A0

=A0

On 2012-08-11, at 2:30 AM, Ganesh and Sashi Prasad w= rote:



>=A0 For the multi-value example you gave you use= d the value as the attribute name key.=A0

=A0

Now I'm confused :-). I don't believe any of= my examples ever used a value as the key.

=A0

Could you please show me which example you mean, and= which parts of it you believe to be the value?

=A0

Regards,

Ganesh=A0

On 11 August 2012 13:59, Phil Hunt <phil.hunt@oracle.com> w= rote:


For the multi-value example you gave you used the value as the attribute na= me key.=A0

=A0

That means a lot more complex indexing structure. Be= tter to just say delete a specific value.=A0

=A0

The spec already allows multiple values to have tags= like home, work, etc.

=A0

Phil


On 2012-08-10, at 21:45, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

>=A0In your example you are conflating value with= an attribute id.=A0

I don't believe so.

=A0

I'm adopting a model where every attribute of th= e resource is a key-value pair. The key is a name or ID.

=A0

For non-repeating attributes (both simple and compos= ite), the key is the attribute name itself.=A0

=A0

Simple attribute:

=A0

Key: "dob"

Value: "01 Jan 1970"

=A0

For composite attributes, the key employs dot notati= on to specify the fully-qualified attribute name, e.g., "address.postc= ode".

=A0

Composite attribute:

=A0

Key: "address.street-number"=

Value: "10"

=A0

Key: "address.suburb"

Value: "East Camden"

=A0

For repeating (multi-valued) attributes, I'm sug= gesting that there be new keys for each individual value, otherwise they ar= e impossible to distinguish, and a positional index is inadequate. So we co= nvert the array into a dictionary and this then becomes a composite attribute using dot notation for the key.=

=A0

Multi-valued attribute:

=A0

Key: "emails.7dfcb444-74d8-4f17-aa66-daf9ea3bd9= 02"

=A0

So this allows us to apply uniform treatment to any = arbitrarily deep resource structure. We can refer to every leaf value with = a key that is the fully-qualified name using dot notation.

=A0

The verbs are just unambiguous operations on these (= now) explicitly addressable attributes.

=A0

INCLUDE to a collection and specify only the value. = The key is generated and returned. The fully-qualified key is <collectio= n-name>.<newly-generated-ID> and the value is what was specified i= n the INCLUDE.

=A0

REPLACE a fully-qualified key with a new value. If t= he key doesn't exist, return a "404 Not Found".=

=A0

PLACE a value at the logical location implied by the= fully-qualified key. If there is already a key with that name, return a &q= uot;409 Conflict".

=A0

FORCE the fully-qualified key to hold the given valu= e, regardless of whether it existed before or not. Only errors possible are= "400 Bad Request" and "500 Internal Error".<= /u>

=A0

RETIRE an attribute or a collection given its fully-= qualified key. The implementation will determine whether the attribute will= disappear entirely or will exist holding a null value (the blank string &q= uot;" or the empty object {} ).

=A0

I'll explain in a separate post why we need oper= ation verbs like these that are independent of the HTTP verbs.

=A0

Regards,

Ganesh

=A0

On 11 August 2012 10:38, <scim-request@ietf.org> wrote:=

If you have received this digest without all the ind= ividual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

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

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



Send scim mailing list submissions to
=A0 =A0 =A0 =A0 scim@iet= f.org

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

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

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

Today's Topics:

=A0 =A01. Re: SCIM Protocol - 3 suggestions for improvement (Phil Hunt)


---------- Forwarded message ----------
From:=A0Phil Hunt <phil.hunt@oracle.com>
To:=A0Ganesh and Sashi Prasad <g.c.prasad@gmail.com>
Cc:=A0"Diodati, Mark" <Mark.Diodati@gartner.com>, Emmanuel Dreux <= ;edreux@cloudiway= .com>, Trey Drake <trey.drake@unboundid.com>, Kelly Grizzle <kelly.grizzle@sailpoint.com>, "scim@ietf.org" <scim@ietf.org>
Date:=A0Fri, 10 Aug 2012 17:36:54 -0700
Subject:=A0Re: [scim] SCIM Protocol - 3 suggestions for improvement<= u>

Ganesh,

=A0

In your example you are conflating value with an att= ribute id. I find that confusing.=A0

=A0

I agree though that operations in patch could be a l= ot more explicit.=A0

=A0

Eg explicitly deleting a value by saying delete or r= etire.=A0


Phil


On 2012-08-10, at 16:19, Ganesh and Sashi Prasad <g.c.prasad@gmail.com> wrote:<= /u>

=A0>=A0=A0I am concern= ed about your second suggestion:=A0

=A0

Let's discuss that now.

=A0

The trade-offs are very clear here.

=A0

Pros:

=A0

Pro 1. The API to manipulate resources becomes so mu= ch cleaner, consistent and intuitive when every individual attribute value = gets its own ID.

=A0

Here's how to delete a single member from a Grou= p, as per the current spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "members": [
=A0=A0=A0=A0=A0=A0 {
=A0=A0=A0=A0=A0=A0=A0=A0 "displa=
y": "Babs Jensen",
=A0=A0=A0=A0=A0=A0=A0=A0 "value&=
quot;: "2819c223-7f76-453a-919d-413861904646"
=A0=A0=A0=A0=A0=A0=A0=A0 "operat=
ion": "delete"
=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0 ]

=A0=A0 }




Here's how to delete ALL members from a group according to the current =
spec:

=A0

=A0=A0 PATCH /Groups/acbf3ae7-8463-46=
92-b4fd-9b4da3f908ce
=A0=A0 Host: example.com
=A0=A0 Accept: application/json
=A0=A0 Authorization: Bearer h480djs9=
3hd8
=A0=A0 ETag: W/"a330bc54f0671c9&=
quot;
=A0
=A0=A0 {
=A0=A0=A0=A0 "schemas": [&q=
uot;urn:scim:schemas:core:1.0"],
=A0=A0=A0=A0 "meta": {
=A0=A0=A0=A0=A0=A0 "attributes&q=
uot;: [
=A0=A0=A0=A0=A0=A0=A0=A0 "member=
s"
=A0=A0=A0=A0=A0=A0 ]
=A0=A0=A0=A0 }

=A0=A0 }




The two operations differ significantly, and it's not very intuitive.=
=A0

With my suggestion, here's how to delete a singl= e member from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members.2819c223-7f76-453a-919d-413= 861904646"

}

}

] }
Here's how I suggest deleting ALL members from a group:

=A0

PATCH /Groups/acbf3ae7-8463-4692-b4fd-9b4da3f908ce Host: example.com Accept: a= pplication/json Authorization: Bearer h480djs93hd8 ETag: W/"a330bc54f0= 671c9" {

"operations" : [

{

"RETIRE" : {

"key" : "members"<= /p>

}

}

] }


I'm sure you'll agree that this is simpler, more consistent and mor= e intuitive to a reader.

=A0

Pro 2: We can apply this mechanism consistently to t= hree areas:

(a) Manipulating multi-valued attributes of a resour= ce

(b) Manipulating members of a group

(c) Performing bulk operations, where we simply use = HTTP verbs instead of the specialised (and semantically less ambiguous) ver= bs I suggested for attributes, the "key" becomes the URI, and the= "value" becomes the corresponding JSON object.

=A0

All of them return "207 Multi-Status" with= the "results" array holding individual status codes.

=A0

In the current spec, (a) and (b) are done similarly = but (c) is very different.

=A0

Pro 3: Adoption of the standard by clients is likely= to be higher because it's simpler for them.

=A0

Pro 4: New (not incumbent) cloud providers will prob= ably find this easier to implement because they have no legacy. They will p= robably use some form of NoSQL database and won't be constrained by the= limitations of LDAP directories.

=A0

Cons:

=A0

Con 1: Incumbent cloud providers with existing data = stores in a directory format (where multi-valued attributes are stored as c= omma-separated values under a single attribute node) will find it difficult= to migrate to this model and store each attribute value as a sub-node with its own key. This will "hinde= r adoption of the spec", which is what you fear.

=A0

Have I summed up the Pros and Cons correctly? I'= m biased of course, so I could have missed a Con or hyped a Pro :-).=

=A0

In other words, we're debating interface complex= ity (current spec) versus implementation complexity (my suggestion). Both c= an hinder adoption of the spec by different parties.

=A0

Here's what we need to discuss - Do the Pros mak= e the suggestio

<= /div>